Cross-Platform & Enterprise AI Prompts: Flutter & .NET Core (2026)

You are a senior architect designing an API for a Flutter mobile app backed by ASP.NET Core.

Design a production API for a field service management app:

Mobile constraints to design for:
- Offline-first: all data must be readable offline; writes queue and sync when connected
- Payload size: mobile DTOs must be flat, minimal, and compressed (no entity graphs)
- Push notifications: APNs (iOS) and FCM (Android) via Azure Notification Hubs
- Auth: Azure AD B2C with JWT; refresh tokens stored in Flutter Secure Storage

ASP.NET Core (.NET 9) backend:
- Architecture: Minimal APIs + MediatR CQRS + EF Core 9 (SQL Server)
- Mobile-specific endpoints: /api/mobile/sync (bulk delta sync), /api/mobile/push-register
- Response DTOs: ProjectSummaryDto, TaskDetailDto, UserProfileDto — flat, no circular refs
- Versioning: URL versioning (/api/v1/) with deprecation headers

Deliver:
1. Endpoint list with HTTP method, route, auth requirement, and response DTO
2. EF Core entity vs mobile DTO mapping strategy (projections in queries, not AutoMapper)
3. Delta sync design: how the client knows what changed since its last sync timestamp
4. SignalR hub design for real-time task assignment updates
5. Offline conflict resolution strategy: last-write-wins vs merge-conflict detection

You are a mobile security engineer building auth for a Flutter app backed by ASP.NET Core.

Implement complete authentication:

ASP.NET Core (.NET 9) backend:
- Auth provider: Azure AD B2C with JWT validation via Microsoft.Identity.Web
- Endpoints: POST /api/v1/auth/token (exchange B2C token), POST /api/v1/auth/refresh, POST /api/v1/auth/logout
- Token strategy: short-lived access token (15 min) + long-lived refresh token (30 days) in response body
- Security: rate limiting (5 attempts/min), JWT audience/issuer validation, refresh token rotation

Flutter frontend:
- Auth service: singleton (Riverpod provider) managing access + refresh tokens
- Token storage: flutter_secure_storage (Keychain on iOS, EncryptedSharedPreferences on Android)
- Token refresh: Dio interceptor that retries on 401, refreshes token, then retries original request
- Session expiry: clear tokens and navigate to login when refresh fails
- Biometric: local_auth for biometric re-authentication after app foreground (not initial login)

Deliver: ASP.NET Core auth middleware setup, Flutter AuthService with Riverpod, Dio interceptor, and BiometricService

You are a .NET 9 backend engineer building an API specifically for mobile consumption.

Build a mobile-optimised Task API endpoint:

Endpoint: GET /api/v1/projects/{projectId}/tasks
- Returns a paginated list of tasks with cursor-based pagination (not offset)
- Response DTO: TaskSummaryDto (flat, no nested objects — IDs only for references)
- Filtering: status, assignedToId, dueDateBefore, dueDateAfter (all optional query params)
- Sorting: by dueDate, createdAt, priority (ascending or descending)
- Response compression: gzip enabled globally; mobile clients always send Accept-Encoding: gzip

EF Core 9 query requirements:
- Project directly to TaskSummaryDto in the query (.Select()) — no entity materialization
- Cursor pagination using the task's cursor field (keyset, not OFFSET)
- Indexes: confirm the query plan uses the composite index on (project_id, status, due_date)
- AsNoTracking() on all read queries

Performance: add response caching headers (Cache-Control: private, max-age=30) for unchanged data

Output: endpoint handler, EF Core query with projection, pagination logic, and integration test

You are a real-time systems engineer working with Flutter and ASP.NET Core SignalR.

Implement real-time task assignment notifications:

ASP.NET Core SignalR hub:
- Hub: TaskHub with methods: SendTaskAssigned(taskId, assigneeId), SendTaskStatusChanged(taskId, newStatus)
- Groups: users join a group per organization (orgId) on connect
- Auth: JWT validation on hub connection
- Scale-out: Redis backplane for multi-instance deployments (StackExchange.Redis)
- Server-push: IHubContext injected into MediatR handlers to push after DB write

Flutter signalr_netcore client:
- SignalR service: singleton Riverpod provider, starts on app launch
- Connection lifecycle: connect on auth, disconnect on logout, reconnect with exponential backoff (max 30s)
- Incoming events: TaskAssignedEvent, TaskStatusChangedEvent as Freezed data classes
- Stream exposure: StreamProvider for each event type, consumed by relevant Riverpod notifiers
- UI update: TaskListNotifier listens to assignment stream, updates Drift local cache, triggers rebuild

Deliver: ASP.NET Core hub, Redis config, Flutter SignalR service, StreamProvider setup, and integration with TaskListNotifier

You are a mobile architect building an offline-first Flutter app with .NET backend sync.

Implement complete offline-first task management:

Local storage (Drift — SQLite ORM for Dart):
- Tables: Task, Project, User, SyncQueue (pending changes not yet synced)
- Drift database class with TypeConverters for enums and DateTime
- Reactive queries: Stream> watchProjectTasks(projectId) — auto-updates UI on change
- SyncQueue: stores {entityType, entityId, operation (create/update/delete), payload, createdAt, attempts}

Sync service (background Isolate):
- Runs on a timer (every 60s) and on network reconnect (connectivity_plus)
- Reads SyncQueue, sends changes to POST /api/v1/sync/batch
- Handles conflicts: server returns conflict items with server version; merge strategy: server wins for status changes, client wins for description edits
- On success: removes items from SyncQueue, merges server response into Drift

ASP.NET Core sync endpoint:
- POST /api/v1/sync/batch: accepts BatchSyncRequest with list of SyncItem
- For each item: apply to DB, detect conflicts (optimistic concurrency with row version), return SyncResult
- Delta pull: GET /api/v1/sync/delta?since={timestamp} returns all changes since the given timestamp

Output: Drift database, SyncQueue table, SyncService in Isolate, ASP.NET Core batch sync endpoint, and conflict resolution logic

You are a .NET 9 architect using MediatR CQRS pattern for a mobile-facing API.

Implement the CreateTask command with full CQRS:

Command and handler:
- CreateTaskCommand: record with TaskTitle, Description, ProjectId, AssignedToId, DueDate, Priority
- CreateTaskCommandHandler: implements IRequestHandler<CreateTaskCommand, Result<TaskDetailDto>>
  - Validate: project exists and user is a member (throw if not — but use Result pattern, not exceptions)
  - Create Task entity, save to EF Core, publish TaskCreatedEvent via MediatR
  - Return Result.Success(TaskDetailDto) or Result.Failure(error message)

Pipeline behaviors (in order):
1. LoggingBehavior: logs command name, execution time, and result outcome
2. ValidationBehavior: runs FluentValidation validators, short-circuits with validation errors
3. TransactionBehavior: wraps handler in EF Core transaction, rolls back on failure

MediatR notification handler:
- TaskCreatedEventHandler: sends SignalR notification to organization group, queues email notification via Hangfire

Minimal API endpoint:
- POST /api/v1/tasks: maps request body to CreateTaskCommand, sends via ISender, returns 201 with TaskDetailDto or 422 with errors

Output: command, handler, three pipeline behaviors, notification handler, and Minimal API endpoint