This commit is contained in:
2025-11-09 02:08:31 +07:00
parent 1ed58d1a98
commit 7dba29c66f
57 changed files with 8362 additions and 359 deletions

View File

@@ -0,0 +1,243 @@
# build-solution
## When to Use
Use this command when you want to:
- Build the entire .NET solution
- Fix compilation errors automatically
- Verify the solution builds successfully
- Check for and resolve build warnings
## Prerequisites
- .NET SDK installed (`dotnet --version`)
- Solution file exists: `src/Managing.sln`
- All project files are present and valid
## Execution Steps
### Step 1: Verify Solution File Exists
Check that the solution file exists:
Run: `test -f src/Managing.sln`
**If solution file doesn't exist:**
- Error: "❌ Solution file not found at src/Managing.sln"
- **STOP**: Cannot proceed without solution file
### Step 2: Restore NuGet Packages
Restore packages before building:
Run: `dotnet restore src/Managing.sln`
**If restore succeeds:**
- Continue to Step 3
**If restore fails:**
- Show restore errors
- Common issues:
- Network connectivity issues
- NuGet feed authentication
- Package version conflicts
- **Try to fix:**
- Check network connectivity
- Verify NuGet.config exists and is valid
- Clear NuGet cache: `dotnet nuget locals all --clear`
- Retry restore
- **If restore still fails:**
- Show detailed error messages
- **STOP**: Cannot build without restored packages
### Step 3: Build Solution
Build the solution:
Run: `dotnet build src/Managing.sln --no-restore`
**If build succeeds with no errors:**
- Show: "✅ Build successful!"
- Show summary of warnings (if any)
- **SUCCESS**: Build completed
**If build fails with errors:**
- Continue to Step 4 to fix errors
**If build succeeds with warnings only:**
- Show warnings summary
- Ask user if they want to fix warnings
- If yes: Continue to Step 5
- If no: **SUCCESS**: Build completed with warnings
### Step 4: Fix Compilation Errors
Analyze build errors and fix them automatically:
**Common error types:**
1. **Project reference errors:**
- Error: "project was not found"
- **Fix**: Check project file paths in .csproj files
- Verify project file names match references
- Update incorrect project references
2. **Missing using statements:**
- Error: "The type or namespace name 'X' could not be found"
- **Fix**: Add missing `using` statements
- Check namespace matches
3. **Type mismatches:**
- Error: "Cannot implicitly convert type 'X' to 'Y'"
- **Fix**: Add explicit casts or fix type definitions
- Check nullable reference types
4. **Missing method/property:**
- Error: "'X' does not contain a definition for 'Y'"
- **Fix**: Check if method/property exists
- Verify spelling and accessibility
5. **Nullable reference warnings (CS8625, CS8618):**
- **Fix**: Add `?` to nullable types or initialize properties
- Use null-forgiving operator `!` if appropriate
- Add null checks where needed
6. **Package version conflicts:**
- Warning: "Detected package version outside of dependency constraint"
- **Fix**: Update package versions in .csproj files
- Align package versions across projects
**For each error:**
- Identify the error type and location
- Read the file containing the error
- Fix the error following .NET best practices
- Re-run build to verify fix
- Continue until all errors are resolved
**If errors cannot be fixed automatically:**
- Show detailed error messages
- Explain what needs to be fixed manually
- **STOP**: User intervention required
### Step 5: Fix Warnings (Optional)
If user wants to fix warnings:
**Common warning types:**
1. **Nullable reference warnings (CS8625, CS8618):**
- **Fix**: Add nullable annotations or initialize properties
- Use `string?` for nullable strings
- Initialize properties in constructors
2. **Package version warnings (NU1608, NU1603, NU1701):**
- **Fix**: Update package versions to compatible versions
- Align MediatR versions across projects
- Update Microsoft.Extensions packages
3. **Obsolete API warnings:**
- **Fix**: Replace with recommended alternatives
- Update to newer API versions
**For each warning:**
- Identify warning type and location
- Fix following best practices
- Re-run build to verify fix
**If warnings cannot be fixed:**
- Show warning summary
- Inform user warnings are acceptable
- **SUCCESS**: Build completed with acceptable warnings
### Step 6: Verify Final Build
Run final build to confirm all errors are fixed:
Run: `dotnet build src/Managing.sln --no-restore`
**If build succeeds:**
- Show: "✅ Build successful! All errors fixed."
- Show final warning count (if any)
- **SUCCESS**: Solution builds successfully
**If errors remain:**
- Show remaining errors
- Return to Step 4
- **STOP** if errors cannot be resolved after multiple attempts
## Error Handling
**If solution file not found:**
- Check path: `src/Managing.sln`
- Verify you're in the correct directory
- **STOP**: Cannot proceed without solution file
**If restore fails:**
- Check network connectivity
- Verify NuGet.config exists
- Clear NuGet cache: `dotnet nuget locals all --clear`
- Check for authentication issues
- Retry restore
**If project reference errors:**
- Check .csproj files for incorrect references
- Verify project file names match references
- Common issue: `Managing.Infrastructure.Database.csproj` vs `Managing.Infrastructure.Databases.csproj`
- Fix project references
**If compilation errors persist:**
- Read error messages carefully
- Check file paths and line numbers
- Verify all dependencies are restored
- Check for circular references
- **STOP** if errors require manual intervention
**If package version conflicts:**
- Update MediatR.Extensions.Microsoft.DependencyInjection to match MediatR version
- Update Microsoft.Extensions.Caching.Memory versions
- Align AspNetCore.HealthChecks.NpgSql versions
- Update packages in all affected projects
## Example Execution
**User input:** `/build-solution`
**AI execution:**
1. Verify solution: `test -f src/Managing.sln` → ✅ Exists
2. Restore packages: `dotnet restore src/Managing.sln` → ✅ Restored
3. Build solution: `dotnet build src/Managing.sln --no-restore`
- Found error: Project reference to `Managing.Infrastructure.Database.csproj` not found
4. Fix error: Update `Managing.Workers.Api.csproj` reference to `Managing.Infrastructure.Databases.csproj`
5. Re-build: `dotnet build src/Managing.sln --no-restore` → ✅ Build successful
6. Success: "✅ Build successful! All errors fixed."
**If nullable warnings:**
1-3. Same as above
4. Build succeeds with warnings: CS8625 nullable warnings
5. Fix warnings: Add `?` to nullable parameters, initialize properties
6. Re-build: `dotnet build src/Managing.sln --no-restore` → ✅ Build successful, warnings reduced
7. Success: "✅ Build successful! Warnings reduced."
**If package conflicts:**
1-3. Same as above
4. Build succeeds with warnings: NU1608 MediatR version conflicts
5. Fix warnings: Update MediatR.Extensions.Microsoft.DependencyInjection to 12.x
6. Re-build: `dotnet build src/Managing.sln --no-restore` → ✅ Build successful
7. Success: "✅ Build successful! Package conflicts resolved."
## Important Notes
-**Always restore first** - Ensures packages are available
-**Fix errors before warnings** - Errors block builds, warnings don't
-**Check project references** - Common source of build errors
-**Verify file names match** - Project file names must match references exactly
-**Nullable reference types** - Use `?` for nullable, initialize non-nullable properties
- ⚠️ **Package versions** - Keep versions aligned across projects
- ⚠️ **Warnings are acceptable** - Some warnings (like NU1701) may be acceptable
- 📦 **Solution location**: `src/Managing.sln`
- 🔧 **Build command**: `dotnet build src/Managing.sln`
- 🗄️ **Common fixes**: Project references, nullable types, package versions

View File

@@ -0,0 +1,299 @@
# implement-api-changes
## When to Use
Use this command when:
- `ManagingApi.ts` has been updated (regenerated from backend)
- New API endpoints or types have been added to the backend
- You need to implement frontend features that use the new API changes
## Prerequisites
- Git repository initialized
- `ManagingApi.ts` file exists at `src/Managing.WebApp/src/generated/ManagingApi.ts`
- Backend API is running and accessible
- Frontend project structure is intact
## Execution Steps
### Step 1: Check if ManagingApi.ts Has Changed
Check git status for changes to ManagingApi.ts:
Run: `git status --short src/Managing.WebApp/src/generated/ManagingApi.ts`
**If file is modified:**
- Continue to Step 2
**If file is not modified:**
- Check if file exists: `test -f src/Managing.WebApp/src/generated/ManagingApi.ts`
- If missing: Error "ManagingApi.ts not found. Please regenerate it first."
- If exists but not modified: Inform "No changes detected in ManagingApi.ts. Nothing to implement."
- **STOP**: No changes to process
### Step 2: Analyze Git Changes
Get the diff to see what was added/changed:
Run: `git diff HEAD src/Managing.WebApp/src/generated/ManagingApi.ts`
**Analyze the diff to identify:**
- New client classes (e.g., `export class JobClient`)
- New methods in existing clients (e.g., `backtest_NewMethod()`)
- New interfaces/types (e.g., `export interface NewType`)
- New enums (e.g., `export enum NewEnum`)
- Modified existing types/interfaces
**Extract key information:**
- Client class names (e.g., `JobClient`, `BacktestClient`)
- Method names and signatures (e.g., `job_GetJobs(page: number, pageSize: number)`)
- Request/Response types (e.g., `PaginatedJobsResponse`, `JobStatus`)
- HTTP methods (GET, POST, PUT, DELETE)
### Step 3: Determine Frontend Implementation Needs
Based on the changes, determine what needs to be implemented:
**For new client classes:**
- Create or update hooks/services to use the new client
- Identify which pages/components should use the new API
- Determine data fetching patterns (useQuery, useMutation)
**For new methods in existing clients:**
- Find existing components using that client
- Determine if new UI components are needed
- Check if existing components need updates
**For new types/interfaces:**
- Identify where these types should be used
- Check if new form components are needed
- Determine if existing components need type updates
**Common patterns to look for:**
- `*Client` classes → Create hooks in `src/Managing.WebApp/src/hooks/`
- `Get*` methods → Use `useQuery` for data fetching
- `Post*`, `Put*`, `Delete*` methods → Use `useMutation` for mutations
- `Paginated*` responses → Create paginated table components
- `*Request` types → Create form components
### Step 4: Search Existing Frontend Code
Search for related code to understand context:
**For new client classes:**
- Search: `grep -r "Client" src/Managing.WebApp/src --include="*.tsx" --include="*.ts" | grep -i "similar"`
- Look for similar client usage patterns
- Find related pages/components
**For new methods:**
- Search: `grep -r "ClientName" src/Managing.WebApp/src --include="*.tsx" --include="*.ts"`
- Find where the client is already used
- Check existing patterns
**For new types:**
- Search: `grep -r "TypeName" src/Managing.WebApp/src --include="*.tsx" --include="*.ts"`
- Find if type is referenced anywhere
- Check related components
### Step 5: Implement Frontend Features
Based on analysis, implement the frontend code:
#### 5.1: Create/Update API Hooks
**For new client classes:**
- Create hook file: `src/Managing.WebApp/src/hooks/use[ClientName].tsx`
- Pattern:
```typescript
import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'
import { [ClientName] } from '../generated/ManagingApi'
import { useApiUrlStore } from '../app/store/apiUrlStore'
export const use[ClientName] = () => {
const { apiUrl } = useApiUrlStore()
const queryClient = useQueryClient()
const client = new [ClientName]({}, apiUrl)
// Add useQuery hooks for GET methods
// Add useMutation hooks for POST/PUT/DELETE methods
return { /* hooks */ }
}
```
**For new methods in existing clients:**
- Update existing hook file
- Add new useQuery/useMutation hooks following existing patterns
#### 5.2: Create/Update Components
**For GET methods (data fetching):**
- Create components that use `useQuery` with the new hook
- Follow existing component patterns (e.g., tables, lists, detail views)
- Use TypeScript types from ManagingApi.ts
**For POST/PUT/DELETE methods (mutations):**
- Create form components or action buttons
- Use `useMutation` with proper error handling
- Show success/error toasts
- Invalidate relevant queries after mutations
**For paginated responses:**
- Create paginated table components
- Use existing pagination patterns from the codebase
- Include sorting, filtering if supported
#### 5.3: Create/Update Pages
**If new major feature:**
- Create new page in `src/Managing.WebApp/src/pages/`
- Add routing if needed
- Follow existing page structure patterns
**If extending existing feature:**
- Update existing page component
- Add new sections/components as needed
#### 5.4: Update Types and Interfaces
**If new types are needed:**
- Import types from ManagingApi.ts
- Use types in component props/interfaces
- Ensure type safety throughout
### Step 6: Follow Frontend Patterns
**Always follow these patterns:**
1. **API Client Usage:**
- Get `apiUrl` from `useApiUrlStore()`
- Create client: `new ClientName({}, apiUrl)`
- Use in hooks, not directly in components
2. **Data Fetching:**
- Use `useQuery` from `@tanstack/react-query`
- Set proper `queryKey` for caching
- Handle loading/error states
3. **Mutations:**
- Use `useMutation` from `@tanstack/react-query`
- Invalidate related queries after success
- Show user-friendly error messages
4. **Component Structure:**
- Use functional components with TypeScript
- Place static content at file end
- Use DaisyUI/Tailwind for styling
- Wrap in Suspense with fallback
5. **Error Handling:**
- Catch errors in services/hooks
- Return user-friendly error messages
- Use error boundaries for unexpected errors
### Step 7: Verify Implementation
**Check for:**
- TypeScript compilation errors: `cd src/Managing.WebApp && npm run type-check` (if available)
- Import errors: All imports resolve correctly
- Type safety: All types from ManagingApi.ts are used correctly
- Pattern consistency: Follows existing codebase patterns
**If errors found:**
- Fix TypeScript errors
- Fix import paths
- Ensure types match API definitions
- **STOP** if critical errors cannot be resolved
### Step 8: Test Integration Points
**Verify:**
- API client is instantiated correctly
- Query keys are unique and appropriate
- Mutations invalidate correct queries
- Error handling works properly
- Loading states are handled
## Error Handling
**If ManagingApi.ts doesn't exist:**
- Check path: `src/Managing.WebApp/src/generated/ManagingApi.ts`
- If missing: Inform user to regenerate using NSwag
- Suggest: Run backend API, then `cd src/Managing.Nswag && dotnet build`
**If git diff is empty:**
- Check if file is staged: `git diff --cached`
- Check if file is untracked: `git status`
- If untracked: Use `git diff /dev/null src/Managing.WebApp/src/generated/ManagingApi.ts`
**If cannot determine changes:**
- Show the diff output to user
- Ask user to clarify what needs to be implemented
- Proceed with manual implementation guidance
**If frontend patterns unclear:**
- Search for similar implementations in codebase
- Follow closest matching pattern
- Ask user for clarification if needed
**If TypeScript errors:**
- Check type definitions in ManagingApi.ts
- Ensure imports are correct
- Verify types match API response structure
- Fix type mismatches
## Example Execution
**User input:** `/implement-api-changes`
**AI execution:**
1. Check changes: `git status --short src/Managing.WebApp/src/generated/ManagingApi.ts` → Modified
2. Analyze diff: `git diff HEAD src/Managing.WebApp/src/generated/ManagingApi.ts`
- Found: New `JobClient` class
- Found: Methods: `job_GetJobs()`, `job_GetJobStatus()`, `job_CancelJob()`
- Found: Types: `PaginatedJobsResponse`, `BacktestJobStatusResponse`, `JobStatus` enum
3. Determine needs:
- Create `useJobClient` hook
- Create jobs list page/component
- Create job status component
- Add cancel job functionality
4. Search existing code:
- Found similar pattern: `useBacktestClient` hook
- Found similar page: `backtestPage` structure
5. Implement:
- Create `src/Managing.WebApp/src/hooks/useJobClient.tsx`
- Create `src/Managing.WebApp/src/pages/jobsPage/jobs.tsx`
- Create `src/Managing.WebApp/src/components/mollecules/JobStatusCard.tsx`
- Update routing if needed
6. Verify: Check TypeScript errors, imports, types
7. Success: "✅ Frontend implementation completed for Job API changes"
**If new method in existing client:**
1-2. Same as above
3. Found: New method `backtest_GetJobStatus(jobId: string)` in `BacktestClient`
4. Search: Found `BacktestClient` used in `backtestPage`
5. Implement:
- Update existing `useBacktestClient` hook
- Add job status display to backtest page
- Add polling for job status updates
6. Verify and complete
## Important Notes
-**Always use TanStack Query** - Never use useEffect for data fetching
-**Follow existing patterns** - Match codebase style and structure
-**Type safety first** - Use types from ManagingApi.ts
-**Error handling** - Services throw user-friendly errors
-**Query invalidation** - Invalidate related queries after mutations
-**Component structure** - Functional components, static content at end
-**Styling** - Use DaisyUI/Tailwind, mobile-first approach
- ⚠️ **Don't update ManagingApi.ts** - It's auto-generated
- ⚠️ **Check existing code** - Reuse components/hooks when possible
- ⚠️ **Test integration** - Verify API calls work correctly
- 📦 **Hook location**: `src/Managing.WebApp/src/hooks/`
- 🔧 **Component location**: `src/Managing.WebApp/src/components/`
- 📄 **Page location**: `src/Managing.WebApp/src/pages/`
- 🗄️ **API types**: Import from `src/Managing.WebApp/src/generated/ManagingApi.ts`

View File

@@ -0,0 +1,265 @@
# migration-local
## When to Use
Use this command when you want to:
- Create a new EF Core migration based on model changes
- Apply the migration to your local PostgreSQL database
- Update your local database schema to match the current code
## Prerequisites
- .NET SDK installed (`dotnet --version`)
- PostgreSQL running locally
- Local database connection configured (default: `Host=localhost;Port=5432;Database=managing;Username=postgres;Password=postgres`)
## Execution Steps
### Step 1: Verify Database Project Structure
Check that the database project exists:
- Database project: `src/Managing.Infrastructure.Database`
- Startup project: `src/Managing.Api`
- Migrations folder: `src/Managing.Infrastructure.Database/Migrations`
### Step 2: Build the Solution
Before creating migrations, ensure the solution builds successfully:
Run: `dotnet build src/Managing.sln`
**If build succeeds:**
- Continue to Step 3
**If build fails:**
- Show build errors
- Analyze errors:
- C# compilation errors
- Missing dependencies
- Configuration errors
- **Try to fix errors automatically:**
- Fix C# compilation errors
- Fix missing imports
- Fix configuration issues
- **If errors can be fixed:**
- Fix the errors
- Re-run build
- If build succeeds, continue to Step 3
- If build still fails, show errors and ask user for help
- **If errors cannot be fixed automatically:**
- Show detailed error messages
- Explain what needs to be fixed
- **STOP**: Do not proceed until build succeeds
### Step 3: Check for Pending Model Changes
Check if there are any pending model changes that require a new migration:
Run: `cd src/Managing.Infrastructure.Database && dotnet ef migrations add --dry-run --startup-project ../Managing.Api --name "CheckPendingChanges_$(date +%s)"`
**If no pending changes detected:**
- Inform: "✅ No pending model changes detected. All migrations are up to date."
- Ask user: "Do you want to create a migration anyway? (y/n)"
- If yes: Continue to Step 4
- If no: **STOP** - No migration needed
**If pending changes detected:**
- Show what changes require migrations
- Continue to Step 4
### Step 4: Generate Migration Name
Ask the user for a migration name, or generate one automatically:
**Option 1: User provides name**
- Prompt: "Enter a migration name (e.g., 'AddBacktestJobsTable'):"
- Use the provided name
**Option 2: Auto-generate name**
- Analyze model changes to suggest a descriptive name
- Format: `Add[Entity]Table`, `Update[Entity]Field`, `Remove[Entity]Field`, etc.
- Examples:
- `AddBacktestJobsTable`
- `AddJobTypeToBacktestJobs`
- `UpdateUserTableSchema`
- Ask user to confirm or modify the suggested name
### Step 5: Create Migration
Create the migration using EF Core:
Run: `cd src/Managing.Infrastructure.Database && dotnet ef migrations add "<migration-name>" --startup-project ../Managing.Api`
**If migration creation succeeds:**
- Show: "✅ Migration created successfully: <migration-name>"
- Show the migration file path
- Continue to Step 6
**If migration creation fails:**
- Show error details
- Common issues:
- Database connection issues
- Model configuration errors
- Missing design-time factory
- **Try to fix automatically:**
- Check connection string in `DesignTimeDbContextFactory.cs`
- Verify database is running
- Check model configurations
- **If errors can be fixed:**
- Fix the errors
- Re-run migration creation
- If succeeds, continue to Step 6
- **If errors cannot be fixed:**
- Show detailed error messages
- Explain what needs to be fixed
- **STOP**: Do not proceed until migration is created
### Step 6: Review Migration File (Optional)
Show the user the generated migration file:
Run: `cat src/Managing.Infrastructure.Database/Migrations/<timestamp>_<migration-name>.cs`
Ask: "Review the migration file above. Does it look correct? (y/n)"
**If user confirms:**
- Continue to Step 7
**If user wants to modify:**
- Allow user to edit the migration file
- After editing, ask to confirm again
- Continue to Step 7
### Step 7: Apply Migration to Local Database
Apply the migration to the local database:
Run: `cd src/Managing.Infrastructure.Database && dotnet ef database update --startup-project ../Managing.Api`
**If update succeeds:**
- Show: "✅ Migration applied successfully to local database"
- Show: "Database schema updated: <migration-name>"
- Continue to Step 8
**If update fails:**
- Show error details
- Common issues:
- Database connection issues
- Migration conflicts
- Database schema conflicts
- Constraint violations
- **Try to fix automatically:**
- Check database connection
- Check for conflicting migrations
- Verify database state
- **If errors can be fixed:**
- Fix the errors
- Re-run database update
- If succeeds, continue to Step 8
- **If errors cannot be fixed:**
- Show detailed error messages
- Explain what needs to be fixed
- Suggest: "You may need to manually fix the database or rollback the migration"
- **STOP**: Do not proceed until migration is applied
### Step 8: Verify Migration Status
Verify that the migration was applied successfully:
Run: `cd src/Managing.Infrastructure.Database && dotnet ef migrations list --startup-project ../Managing.Api`
**If migration is listed as applied:**
- Show: "✅ Migration status verified"
- Show the list of applied migrations
- Success message: "✅ Migration created and applied successfully!"
**If migration is not listed or shows as pending:**
- Warn: "⚠️ Migration may not have been applied correctly"
- Show migration list
- Suggest checking the database manually
## Error Handling
### If build fails:
- **STOP immediately** - Do not create migrations for broken code
- Show build errors in detail
- Try to fix common errors automatically:
- C# compilation errors
- Import path errors
- Syntax errors
- Missing imports
- If errors can be fixed:
- Fix them automatically
- Re-run build
- If build succeeds, continue
- If build still fails, show errors and ask for help
- If errors cannot be fixed:
- Show detailed error messages
- Explain what needs to be fixed
- **STOP**: Do not proceed until build succeeds
### If database connection fails:
- Check if PostgreSQL is running: `pg_isready` or `psql -h localhost -U postgres -c "SELECT 1"`
- Verify connection string in `DesignTimeDbContextFactory.cs`
- Check if database exists: `psql -h localhost -U postgres -lqt | cut -d \| -f 1 | grep -qw managing`
- If database doesn't exist, create it: `createdb -h localhost -U postgres managing`
- Retry migration creation
### If migration conflicts:
- Check existing migrations: `cd src/Managing.Infrastructure.Database && dotnet ef migrations list --startup-project ../Managing.Api`
- If migration already exists with same name, suggest a different name
- If database schema conflicts, suggest reviewing the migration file
### If database update fails:
- Check database state: `psql -h localhost -U postgres -d managing -c "\dt"`
- Check applied migrations: `psql -h localhost -U postgres -d managing -c "SELECT * FROM \"__EFMigrationsHistory\";"`
- If migration partially applied, may need to rollback or fix manually
- Suggest: "Review the error and fix the database state, or rollback the migration"
## Example Execution
**User input:** `/migration-local`
**AI execution:**
1. Verify structure: Check `src/Managing.Infrastructure.Database` exists ✅
2. Build solution: `dotnet build src/Managing.sln` → ✅ Build successful!
3. Check pending changes: `dotnet ef migrations add --dry-run ...` → ⚠️ Pending changes detected
4. Generate name: Analyze changes → Suggest "AddBacktestJobsTable"
5. Confirm name: "Migration name: 'AddBacktestJobsTable'. Proceed? (y/n)" → User confirms
6. Create migration: `dotnet ef migrations add "AddBacktestJobsTable" ...` → ✅ Migration created
7. Review file: Show migration file → User confirms
8. Apply migration: `dotnet ef database update ...` → ✅ Migration applied
9. Verify status: `dotnet ef migrations list ...` → ✅ Migration verified
10. Success: "✅ Migration created and applied successfully!"
**If build fails:**
1-2. Same as above
3. Build: `dotnet build src/Managing.sln` → ❌ Build failed
4. Analyze errors: C# compilation error in `JobEntity.cs`
5. Fix errors: Update type definitions
6. Re-run build: `dotnet build src/Managing.sln` → ✅ Build successful!
7. Continue with migration creation
**If database connection fails:**
1-5. Same as above
6. Create migration: `dotnet ef migrations add ...` → ❌ Connection failed
7. Check database: `pg_isready` → Database not running
8. Inform user: "PostgreSQL is not running. Please start PostgreSQL and try again."
9. **STOP**: Wait for user to start database
## Important Notes
-**Always build before creating migrations** - ensures code compiles correctly
-**Review migration file before applying** - verify it matches your intent
-**Backup database before applying** - migrations can modify data
-**Use descriptive migration names** - helps track schema changes
- ⚠️ **Migration is applied to local database only** - use other tools for production
- ⚠️ **Ensure PostgreSQL is running** - connection will fail if database is down
- 📦 **Database project**: `src/Managing.Infrastructure.Database`
- 🔧 **Startup project**: `src/Managing.Api`
- 🗄️ **Local connection**: `Host=localhost;Port=5432;Database=managing;Username=postgres;Password=postgres`
- 📁 **Migrations folder**: `src/Managing.Infrastructure.Database/Migrations`

View File

@@ -0,0 +1,95 @@
# migration-production
## When to Use
Run database migrations for ProductionLocal environment, apply pending EF Core migrations, create backups (MANDATORY), and verify connectivity.
⚠️ **WARNING**: Production environment - exercise extreme caution.
## Prerequisites
- .NET SDK installed (`dotnet --version`)
- PostgreSQL accessible for ProductionLocal
- Connection string in `appsettings.ProductionLocal.json`
- `scripts/safe-migrate.sh` available and executable
- ⚠️ Production access permissions required
## Execution Steps
### Step 1: Verify Script Exists and is Executable
Check: `test -f scripts/safe-migrate.sh`
**If missing:** Error and **STOP**
**If not executable:** `chmod +x scripts/safe-migrate.sh`
### Step 2: Verify Environment Configuration
Check: `test -f src/Managing.Api/appsettings.ProductionLocal.json`
**If missing:** Check `appsettings.Production.json`, else **STOP**
### Step 3: Production Safety Check
⚠️ **CRITICAL**: Verify authorization, reviewed migrations, rollback plan, backup will be created.
**Ask user:** "⚠️ You are about to run migrations on ProductionLocal. Are you sure? (yes/no)"
**If confirmed:** Continue
**If not confirmed:** **STOP**
### Step 4: Run Migration Script
Run: `./scripts/safe-migrate.sh ProductionLocal`
**Script performs:** Build → Check connectivity → Create DB if needed → Prompt backup (always choose 'y') → Check pending changes → Generate script → Show for review → Wait confirmation → Apply → Verify
**On success:** Show success, backup location, log location, remind to verify application functionality
**On failure:** Show error output, diagnose (connectivity, connection string, server, permissions, data conflicts), provide guidance or **STOP** if unresolvable (suggest testing in non-prod first)
## Error Handling
**Script not found:** Check `ls -la scripts/safe-migrate.sh`, **STOP** if missing
**Not executable:** `chmod +x scripts/safe-migrate.sh`, retry
**Database connection fails:** Verify PostgreSQL running, check connection string in `appsettings.ProductionLocal.json`, verify network/firewall/credentials, ⚠️ **WARN** production connectivity issues require immediate attention
**Build fails:** Show errors (C# compilation, missing dependencies, config errors), try auto-fix (compilation errors, imports, config), if fixed re-run else **STOP** with ⚠️ **WARN** never deploy broken code
**Migration conflicts:** Review migration history, script handles idempotent migrations, schema conflicts may need manual intervention, ⚠️ **WARN** may require downtime
**Backup fails:** **CRITICAL** - script warns, strongly recommend fixing before proceeding, **WARN** extreme risks if proceeding without backup
**Migration partially applies:** ⚠️ **CRITICAL** dangerous state - check `__EFMigrationsHistory`, may need rollback, **STOP** until database state verified
## Example Execution
**Success flow:**
1. Verify script → ✅
2. Check executable → ✅
3. Verify config → ✅
4. Safety check → User confirms
5. Run: `./scripts/safe-migrate.sh ProductionLocal`
6. Script: Build → Connect → Backup → Generate → Review → Confirm → Apply → Verify → ✅
7. Show backup/log locations, remind to verify functionality
**Connection fails:** Diagnose connection string/server, ⚠️ warn production issue, **STOP**
**Build fails:** Show errors, try auto-fix, if fixed re-run else **STOP** with ⚠️ warn
**User skips backup:** ⚠️ ⚠️ ⚠️ **CRITICAL WARNING** extremely risky, ask again, if confirmed proceed with caution else **STOP**
## Important Notes
- ⚠️ ⚠️ ⚠️ **PRODUCTION** - Extreme caution required
- ✅ Backup MANDATORY, review script before applying, verify functionality after
- ✅ Idempotent migrations - safe to run multiple times
- ⚠️ Environment: `ProductionLocal`, Config: `appsettings.ProductionLocal.json`
- ⚠️ Backups: `scripts/backups/ProductionLocal/`, Logs: `scripts/logs/`
- 📦 Keeps last 5 backups automatically
- 🚨 Have rollback plan, test in non-prod first, monitor after migration

View File

@@ -0,0 +1,76 @@
# migration-sandbox
## When to Use
Run database migrations for SandboxLocal environment, apply pending EF Core migrations, create backups, and verify connectivity.
## Prerequisites
- .NET SDK installed (`dotnet --version`)
- PostgreSQL accessible for SandboxLocal
- Connection string in `appsettings.SandboxLocal.json`
- `scripts/safe-migrate.sh` available and executable
## Execution Steps
### Step 1: Verify Script Exists and is Executable
Check: `test -f scripts/safe-migrate.sh`
**If missing:** Error and **STOP**
**If not executable:** `chmod +x scripts/safe-migrate.sh`
### Step 2: Verify Environment Configuration
Check: `test -f src/Managing.Api/appsettings.SandboxLocal.json`
**If missing:** Check `appsettings.Sandbox.json`, else **STOP**
### Step 3: Run Migration Script
Run: `./scripts/safe-migrate.sh SandboxLocal`
**Script performs:** Build projects → Check connectivity → Create DB if needed → Prompt backup → Check pending changes → Generate script → Apply migrations → Verify status
**On success:** Show success message, backup location, log file location
**On failure:** Show error output, diagnose (connectivity, connection string, server status, permissions), provide guidance or **STOP** if unresolvable
## Error Handling
**Script not found:** Check `ls -la scripts/safe-migrate.sh`, **STOP** if missing
**Not executable:** `chmod +x scripts/safe-migrate.sh`, retry
**Database connection fails:** Verify PostgreSQL running, check connection string in `appsettings.SandboxLocal.json`, verify network/firewall/credentials
**Build fails:** Show errors (C# compilation, missing dependencies, config errors), try auto-fix (compilation errors, imports, config), if fixed re-run else **STOP**
**Migration conflicts:** Review migration history, script handles idempotent migrations, schema conflicts may need manual intervention
**Backup fails:** Script warns, recommend fixing before proceeding, warn if proceeding without backup
## Example Execution
**Success flow:**
1. Verify script → ✅
2. Check executable → ✅
3. Verify config → ✅
4. Run: `./scripts/safe-migrate.sh SandboxLocal`
5. Script: Build → Connect → Backup → Generate → Apply → Verify → ✅
6. Show backup/log locations
**Connection fails:** Diagnose connection string/server, provide guidance, **STOP**
**Build fails:** Show errors, try auto-fix, if fixed re-run else **STOP**
## Important Notes
- ✅ Backup recommended, script prompts for it
- ✅ Review migration script before applying
- ✅ Idempotent migrations - safe to run multiple times
- ⚠️ Environment: `SandboxLocal`, Config: `appsettings.SandboxLocal.json`
- ⚠️ Backups: `scripts/backups/SandboxLocal/`, Logs: `scripts/logs/`
- 📦 Keeps last 5 backups automatically

View File

@@ -0,0 +1,626 @@
# responsive
## When to Use
Use this command when you want to:
- Implement responsive/mobile design using DaisyUI components
- Make existing components mobile-friendly with DaisyUI patterns
- Create beautiful, modern responsive layouts following DaisyUI documentation
- Optimize UI for different screen sizes using DaisyUI's responsive features
## Prerequisites
- Component or page file open or specified
- Tailwind CSS configured
- DaisyUI installed and configured
- Reference to DaisyUI documentation: https://daisyui.com/components/
- Understanding of the component's current structure
## Execution Steps
### Step 1: Analyze Current Component
Read the component file to understand its structure:
**If file is open in editor:**
- Use the currently open file
**If file path provided:**
- Read the file: `cat [file-path]`
**Analyze:**
- Current layout structure (grid, flex, etc.)
- Existing responsive classes (if any)
- Component complexity and nesting
- Content that needs to be responsive (tables, forms, charts, cards)
### Step 2: Identify Responsive Requirements
Determine what needs to be responsive:
**Common responsive patterns:**
- **Navigation**: Mobile hamburger menu, desktop horizontal nav
- **Tables**: Horizontal scroll on mobile, full table on desktop
- **Forms**: Stacked inputs on mobile, side-by-side on desktop
- **Cards/Grids**: Single column on mobile, multi-column on desktop
- **Charts**: Smaller on mobile, larger on desktop
- **Modals**: Full screen on mobile, centered on desktop
- **Text**: Smaller on mobile, larger on desktop
- **Spacing**: Tighter on mobile, more spacious on desktop
**Identify:**
- Which elements need responsive behavior
- Breakpoints where layout should change
- Mobile vs desktop content differences
### Step 3: Apply Mobile-First Responsive Design
Implement responsive design using Tailwind's mobile-first approach:
#### 3.1: Breakpoint Strategy
**Tailwind breakpoints (mobile-first):**
- Base (default): Mobile (< 640px)
- `sm:` - Small devices (≥ 640px)
- `md:` - Medium devices (≥ 768px)
- `lg:` - Large devices (≥ 1024px)
- `xl:` - Extra large (≥ 1280px)
- `2xl:` - 2X Extra large (≥ 1536px)
**Pattern:** Start with mobile styles, then add larger breakpoints:
```tsx
// Mobile first: base styles are for mobile
<div className="w-full p-4 md:p-6 lg:p-8">
// Mobile: full width, padding 4
// md+: padding 6
// lg+: padding 8
</div>
```
#### 3.2: Layout Patterns
**Grid Layouts:**
```tsx
// Single column mobile, multi-column desktop
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">
{/* Cards */}
</div>
// Responsive grid with auto-fit
<div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4 md:gap-6">
```
**Flexbox Layouts:**
```tsx
// Stack on mobile, row on desktop
<div className="flex flex-col md:flex-row gap-4">
{/* Items */}
</div>
// Center on mobile, space-between on desktop
<div className="flex flex-col items-center md:flex-row md:justify-between">
```
**Container Patterns:**
```tsx
// Use layout utility class or custom container
<div className="layout">
{/* Content with responsive margins */}
</div>
// Or custom responsive container
<div className="w-full px-4 sm:px-6 lg:px-8 max-w-7xl mx-auto">
```
#### 3.3: Navigation Patterns (DaisyUI Navbar)
**DaisyUI Navbar Pattern** (https://daisyui.com/components/navbar/):
```tsx
// DaisyUI navbar with responsive menu
<div className="navbar bg-base-300">
{/* Mobile menu button */}
<div className="navbar-start">
<button className="btn btn-ghost lg:hidden" onClick={toggleMenu}>
<svg className="h-5 w-5" fill="none" viewBox="0 0 24 24" stroke="currentColor">
<path strokeLinecap="round" strokeLinejoin="round" strokeWidth="2" d="M4 6h16M4 12h16M4 18h16" />
</svg>
</button>
<a className="btn btn-ghost text-xl">Logo</a>
</div>
{/* Desktop navigation */}
<div className="navbar-center hidden lg:flex">
<ul className="menu menu-horizontal px-1">
<li><a>Item 1</a></li>
<li><a>Item 2</a></li>
</ul>
</div>
{/* Navbar end */}
<div className="navbar-end">
<button className="btn btn-primary">Action</button>
</div>
</div>
// Mobile drawer/sidebar (DaisyUI Drawer pattern)
<div className={`drawer lg:drawer-open`}>
<input id="drawer-toggle" type="checkbox" className="drawer-toggle" checked={isOpen} onChange={toggleMenu} />
<div className="drawer-side">
<label htmlFor="drawer-toggle" className="drawer-overlay"></label>
<ul className="menu p-4 w-80 min-h-full bg-base-200 text-base-content">
{/* Mobile menu items */}
</ul>
</div>
</div>
```
#### 3.4: Table Patterns (DaisyUI Table)
**DaisyUI Table Patterns** (https://daisyui.com/components/table/):
```tsx
// Option 1: Horizontal scroll on mobile (recommended)
<div className="overflow-x-auto">
<table className="table table-zebra w-full">
<thead>
<tr>
<th>Header 1</th>
<th>Header 2</th>
</tr>
</thead>
<tbody>
{/* Table rows */}
</tbody>
</table>
</div>
// Option 2: Responsive table size (mobile: table-xs, desktop: table)
<div className="overflow-x-auto">
<table className="table table-xs md:table table-zebra w-full">
{/* Table content */}
</table>
</div>
// Option 3: Card layout on mobile, table on desktop
<div className="block md:hidden space-y-4">
{/* DaisyUI cards for mobile */}
<div className="card bg-base-100 shadow">
<div className="card-body">
{/* Card content matching table data */}
</div>
</div>
</div>
<div className="hidden md:block overflow-x-auto">
<table className="table table-zebra w-full">
{/* Table for desktop */}
</table>
</div>
```
#### 3.5: Form Patterns (DaisyUI Form)
**DaisyUI Form Patterns** (https://daisyui.com/components/form/):
```tsx
// DaisyUI form-control with responsive grid
<form className="w-full max-w-2xl mx-auto space-y-4">
{/* Stacked on mobile, side-by-side on desktop */}
<div className="grid grid-cols-1 md:grid-cols-2 gap-4">
<div className="form-control">
<label className="label">
<span className="label-text">First Name</span>
</label>
<input type="text" className="input input-bordered w-full" />
</div>
<div className="form-control">
<label className="label">
<span className="label-text">Last Name</span>
</label>
<input type="text" className="input input-bordered w-full" />
</div>
</div>
{/* Full width field */}
<div className="form-control">
<label className="label">
<span className="label-text">Email</span>
</label>
<input type="email" className="input input-bordered w-full" />
</div>
{/* Responsive button */}
<div className="form-control mt-6">
<button className="btn btn-primary w-full md:w-auto">Submit</button>
</div>
</form>
```
#### 3.6: Typography Patterns
**Responsive Text:**
```tsx
// Smaller on mobile, larger on desktop
<h1 className="text-2xl md:text-3xl lg:text-4xl font-bold">
Title
</h1>
<p className="text-sm md:text-base lg:text-lg">
Content
</p>
```
#### 3.7: Spacing Patterns
**Responsive Spacing:**
```tsx
// Tighter on mobile, more spacious on desktop
<div className="p-4 md:p-6 lg:p-8">
{/* Content */}
</div>
// Responsive gaps
<div className="flex flex-col gap-2 md:gap-4 lg:gap-6">
{/* Items */}
</div>
```
#### 3.8: Modal/Dialog Patterns (DaisyUI Modal)
**DaisyUI Modal Patterns** (https://daisyui.com/components/modal/):
```tsx
// Full screen on mobile, centered on desktop
<dialog className={`modal ${isOpen ? 'modal-open' : ''}`}>
<div className="modal-box w-full max-w-none md:max-w-2xl mx-auto">
<h3 className="font-bold text-lg">Modal Title</h3>
<p className="py-4">Modal content</p>
<div className="modal-action">
<button className="btn" onClick={closeModal}>Close</button>
</div>
</div>
<form method="dialog" className="modal-backdrop" onClick={closeModal}>
<button>close</button>
</form>
</dialog>
// Responsive modal with different sizes
<dialog className={`modal ${isOpen ? 'modal-open' : ''}`}>
<div className="modal-box w-11/12 max-w-none md:max-w-lg lg:max-w-2xl">
{/* Modal content */}
</div>
</dialog>
```
#### 3.9: Chart/Visualization Patterns
**Responsive Charts:**
```tsx
// Responsive chart container
<div ref={containerRef} className="w-full h-auto">
<Chart
width={containerWidth}
height={containerWidth * (isMobile ? 0.8 : 0.6)}
/>
</div>
// Or use aspect ratio
<div className="w-full aspect-[4/3] md:aspect-[16/9]">
<Chart />
</div>
```
### Step 4: Reference DaisyUI Documentation
**Before implementing any component, check DaisyUI documentation:**
- Open or reference: https://daisyui.com/components/
- Find the component you need (navbar, card, table, modal, etc.)
- Review the component's responsive examples and classes
- Use the exact DaisyUI classes and patterns from the docs
**DaisyUI Documentation Structure:**
- Each component page shows examples
- Copy the exact class names and structure
- Adapt the examples to your use case with responsive breakpoints
### Step 5: Apply DaisyUI Responsive Components
Use DaisyUI components following official documentation: https://daisyui.com/components/
**DaisyUI Responsive Components (from docs):**
1. **Navbar** (https://daisyui.com/components/navbar/):
- Use `navbar` with `navbar-start`, `navbar-center`, `navbar-end`
- Mobile hamburger: `btn btn-ghost lg:hidden`
- Desktop nav: `hidden lg:flex`
```tsx
<div className="navbar bg-base-300">
<div className="navbar-start">
<button className="btn btn-ghost lg:hidden">☰</button>
</div>
<div className="navbar-center hidden lg:flex">
{/* Desktop nav items */}
</div>
</div>
```
2. **Drawer** (https://daisyui.com/components/drawer/):
- Use `drawer` with `drawer-side` for mobile sidebar
- Toggle with `drawer-open` class
```tsx
<div className="drawer lg:drawer-open">
<input id="drawer-toggle" type="checkbox" className="drawer-toggle" />
<div className="drawer-side">
<label htmlFor="drawer-toggle" className="drawer-overlay"></label>
<ul className="menu p-4 w-80 min-h-full bg-base-200">
{/* Sidebar content */}
</ul>
</div>
</div>
```
3. **Card** (https://daisyui.com/components/card/):
- Use `card` with `card-body` for responsive cards
- Responsive grid: `grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3`
```tsx
<div className="card bg-base-100 shadow-xl">
<div className="card-body p-4 md:p-6">
<h2 className="card-title text-lg md:text-xl">Title</h2>
<p className="text-sm md:text-base">Content</p>
</div>
</div>
```
4. **Table** (https://daisyui.com/components/table/):
- Wrap in `overflow-x-auto` for mobile scroll
- Use `table-xs` for mobile, `table` for desktop
```tsx
<div className="overflow-x-auto">
<table className="table table-zebra w-full">
{/* Table content */}
</table>
</div>
```
5. **Modal** (https://daisyui.com/components/modal/):
- Use `modal` with `modal-box` for responsive modals
- Full screen mobile: `w-full max-w-none md:max-w-2xl`
```tsx
<dialog className={`modal ${isOpen ? 'modal-open' : ''}`}>
<div className="modal-box w-full max-w-none md:max-w-2xl">
{/* Modal content */}
</div>
</dialog>
```
6. **Form** (https://daisyui.com/components/form/):
- Use `form-control` with responsive grid
- Inputs: `input input-bordered w-full`
```tsx
<div className="form-control">
<label className="label">
<span className="label-text">Label</span>
</label>
<input type="text" className="input input-bordered w-full" />
</div>
```
7. **Bottom Navigation** (https://daisyui.com/components/bottom-navigation/):
- Use `btm-nav` for mobile bottom navigation
```tsx
<div className="btm-nav lg:hidden fixed bottom-0">
<button className="active">Home</button>
<button>Settings</button>
</div>
```
8. **Tabs** (https://daisyui.com/components/tabs/):
- Use `tabs` with responsive layout
- Mobile: `tabs tabs-boxed`, Desktop: `tabs tabs-lifted`
```tsx
<div className="tabs tabs-boxed md:tabs-lifted">
<a className="tab">Tab 1</a>
<a className="tab tab-active">Tab 2</a>
</div>
```
9. **Dropdown** (https://daisyui.com/components/dropdown/):
- Use `dropdown` with responsive positioning
```tsx
<div className="dropdown dropdown-end">
<label tabIndex={0} className="btn btn-ghost">Menu</label>
<ul className="dropdown-content menu bg-base-100 rounded-box z-[1] w-52 p-2 shadow">
{/* Dropdown items */}
</ul>
</div>
```
10. **Stats** (https://daisyui.com/components/stats/):
- Use `stats` with responsive grid
```tsx
<div className="stats stats-vertical md:stats-horizontal shadow w-full">
<div className="stat">...</div>
</div>
```
### Step 6: Implement Beautiful Mobile UX
**Mobile UX Best Practices:**
1. **Touch Targets:**
- Minimum 44x44px touch targets
- Adequate spacing between interactive elements
```tsx
<button className="btn btn-primary min-h-[44px] min-w-[44px]">
Action
</button>
```
2. **Swipe Gestures:**
- Consider swipeable cards/carousels
- Use libraries like `react-swipeable` if needed
3. **Bottom Navigation** (DaisyUI Bottom Nav - https://daisyui.com/components/bottom-navigation/):
- Use DaisyUI `btm-nav` for mobile bottom navigation
```tsx
<div className="btm-nav lg:hidden fixed bottom-0 z-50 bg-base-300">
<button className="active text-primary">
<svg>...</svg>
<span className="btm-nav-label">Home</span>
</button>
<button>
<svg>...</svg>
<span className="btm-nav-label">Settings</span>
</button>
</div>
```
4. **Sticky Headers:**
- Keep important actions accessible
```tsx
<div className="sticky top-0 z-50 bg-base-100">
{/* Header content */}
</div>
```
5. **Loading States** (DaisyUI Loading - https://daisyui.com/components/loading/):
- Use DaisyUI loading spinners appropriately sized for mobile
```tsx
<div className="flex justify-center items-center min-h-[200px]">
<span className="loading loading-spinner loading-sm md:loading-md lg:loading-lg"></span>
</div>
// Or use loading text
<div className="flex flex-col items-center gap-4">
<span className="loading loading-spinner loading-lg"></span>
<span className="text-sm md:text-base">Loading...</span>
</div>
```
### Step 7: Test Responsive Breakpoints
Verify the implementation works at different breakpoints:
**Test breakpoints:**
- Mobile: 375px, 414px (iPhone sizes)
- Tablet: 768px, 1024px (iPad sizes)
- Desktop: 1280px, 1536px+
**Check:**
- Layout doesn't break at any breakpoint
- Text is readable at all sizes
- Interactive elements are easily tappable
- Content doesn't overflow horizontally
- Images scale appropriately
### Step 8: Optimize Performance
**Mobile Performance:**
1. **Lazy Loading:**
- Lazy load images and heavy components
```tsx
<img
src={imageSrc}
loading="lazy"
className="w-full h-auto"
alt="..."
/>
```
2. **Conditional Rendering:**
- Render mobile/desktop versions conditionally if needed
```tsx
{isMobile ? <MobileComponent /> : <DesktopComponent />}
```
3. **Reduce Animations on Mobile:**
- Consider `prefers-reduced-motion`
```tsx
<div className="transition-transform motion-reduce:transition-none">
```
## Error Handling
**If component file not found:**
- Check file path
- Verify file exists
- **STOP**: Cannot proceed without component
**If Tailwind classes not working:**
- Verify Tailwind config includes the file
- Check if classes are in content paths
- Rebuild Tailwind: `npm run build` or check build process
**If layout breaks at breakpoints:**
- Check for conflicting classes
- Verify breakpoint order (mobile-first)
- Test with browser dev tools
- Fix overflow issues with `overflow-x-hidden` on body
**If DaisyUI components not responsive:**
- Check DaisyUI version: `npm list daisyui`
- Verify Tailwind config includes DaisyUI plugin
- Reference DaisyUI docs: https://daisyui.com/components/
- Use DaisyUI's responsive utilities from documentation
- Ensure you're using the correct DaisyUI class names
## Example Execution
**User input:** `/responsive` (with component file open)
**AI execution:**
1. Analyze component: Read `UnifiedTradingModal.tsx`
- Found: Large form with multiple sections
- Found: Tables and cards
- Found: Some responsive classes already present
2. Identify requirements:
- Form inputs need stacking on mobile
- Tables need horizontal scroll
- Modal needs full-screen on mobile
- Cards need single column on mobile
3. Reference DaisyUI docs:
- Check https://daisyui.com/components/modal/ for modal patterns
- Check https://daisyui.com/components/form/ for form patterns
- Check https://daisyui.com/components/table/ for table patterns
- Check https://daisyui.com/components/card/ for card patterns
4. Implement responsive using DaisyUI:
- Update form: Use `form-control` with `grid grid-cols-1 md:grid-cols-2 gap-4`
- Update tables: Wrap in `overflow-x-auto` with `table table-zebra`
- Update modal: Use DaisyUI `modal` with `modal-box w-full max-w-none md:max-w-2xl`
- Update cards: Use DaisyUI `card` with `grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3`
5. Apply mobile UX:
- Use DaisyUI buttons (already meet 44px touch target)
- Add responsive spacing: `p-4 md:p-6`
- Update typography: `text-sm md:text-base`
6. Test: Verify at 375px, 768px, 1024px breakpoints
7. Success: "✅ Component is now fully responsive using DaisyUI components!"
**If table component:**
1. Analyze: Read table component
2. Identify: Table needs mobile-friendly layout
3. Implement:
- Option 1: Horizontal scroll wrapper
- Option 2: Card layout for mobile, table for desktop
4. Choose best approach based on data complexity
5. Implement chosen pattern
6. Success: "✅ Table is now responsive with [chosen pattern]!"
## Important Notes
- ✅ **Mobile-first approach** - Base styles for mobile, then add larger breakpoints
- ✅ **Use Tailwind breakpoints** - sm: 640px, md: 768px, lg: 1024px, xl: 1280px, 2xl: 1536px
- ✅ **DaisyUI components** - Always use DaisyUI components from https://daisyui.com/components/
- ✅ **Follow DaisyUI docs** - Reference official documentation for component usage
- ✅ **Touch targets** - Minimum 44x44px for mobile (DaisyUI buttons meet this)
- ✅ **No horizontal scroll** - Prevent horizontal overflow on mobile
- ✅ **Test all breakpoints** - Verify at 375px, 768px, 1024px, 1280px
- ✅ **Performance** - Lazy load images, optimize for mobile
- ⚠️ **Breakpoint order** - Always mobile-first: base → sm → md → lg → xl → 2xl
- ⚠️ **Content priority** - Show most important content first on mobile
- ⚠️ **Spacing** - Tighter on mobile, more spacious on desktop
- ⚠️ **DaisyUI classes** - Use DaisyUI utility classes (`btn`, `card`, `input`, etc.)
- 📱 **Mobile breakpoints**: < 640px (base), ≥ 640px (sm), ≥ 768px (md)
- 💻 **Desktop breakpoints**: ≥ 1024px (lg), ≥ 1280px (xl), ≥ 1536px (2xl)
- 🎨 **DaisyUI Components**: `navbar`, `drawer`, `card`, `table`, `modal`, `form`, `btm-nav`, `tabs`, `dropdown`, `stats`
- 📚 **DaisyUI Docs**: https://daisyui.com/components/ - Always reference for component patterns
- 🔧 **Layout utility**: Use `.layout` class or custom responsive containers