57 lines
4.0 KiB
Plaintext
57 lines
4.0 KiB
Plaintext
# GLP-1 Companion Automation & Architecture Rules (.clinerules)
|
|
|
|
## Role & Execution Discipline
|
|
You are acting as an expert Lead Software Architect and Senior Flutter Engineer.
|
|
- Build strictly modular, platform-aware, test-driven Flutter code targeting Android, iOS, Web, macOS, and Windows.
|
|
- Always implement Clean Architecture: Domain (zero external dependencies), Data (repos, DTOs, data sources), and Presentation (Riverpod, platform-adaptive widgets).
|
|
- Never write monolithic files or bypass abstraction layers. Code must compile cleanly across all 5 target platforms.
|
|
|
|
## Architecture & Directory Conventions
|
|
Project structure is feature-first:
|
|
lib/
|
|
├── app/ # App entrypoint, routing (GoRouter), global theme
|
|
├── core/ # Shared utilities, failure models, networking, platform helpers
|
|
│ ├── platform/ # Cross-platform adapters (Health, Notifications, Secure Storage)
|
|
│ ├── theme/ # Adaptive themes (Material 3 for Android/Web/Win, Cupertino for iOS/macOS)
|
|
│ └── network/ # Supabase/REST clients, error interceptors
|
|
└── features/ # Modular bounded contexts
|
|
├── auth/ # Passwordless / OAuth (Google, Apple, Microsoft, Magic Links)
|
|
├── medication/ # GLP-1 tracking, dose schedule, reminders
|
|
├── nutrition/ # Food intake, protein/hydration targets, macro tracking
|
|
├── recipes/ # Web recipe scraper (schema.org/Recipe JSON-LD), catalog
|
|
├── meal_planner/ # Weekly schedule, automatic shopping list generator
|
|
├── pantry/ # Pantry inventory, barcode/expiry tracker
|
|
└── health_sync/ # Health Connect, Apple HealthKit, MFP connector
|
|
|
|
Each feature MUST contain:
|
|
- domain/: Entities, Value Objects, Repository Interfaces, Use Cases.
|
|
- data/: Models (json_serializable/freezed), Datasources (local & remote), Repository Implementations.
|
|
- presentation/: Controllers/Notifiers (StateNotifier / AsyncNotifier), Screens, Adaptive Widgets.
|
|
|
|
## Platform Support Rules (Android, iOS, Web, macOS, Windows)
|
|
1. Never import platform-specific packages (health, flutter_local_notifications, window_manager) directly into presentation or domain layers.
|
|
2. Abstract all OS-level APIs behind pure Dart repository interfaces in core/platform/ and inject implementations conditionally using platform checks (kIsWeb, Platform.isAndroid, etc.) or deferred factory registrations.
|
|
3. Health API Boundary:
|
|
- Android: Health Connect API
|
|
- iOS: Apple HealthKit
|
|
- Web/Desktop: Graceful degradation (read-only manual entry / third-party OAuth REST sync like MyFitnessPal / Fitbit / Withings APIs).
|
|
4. Adaptive UX:
|
|
- On iOS / macOS: Use Cupertino design elements, native navigation bars, and standard Apple HIG gestures.
|
|
- On Android / Web / Windows: Use Material 3 with navigation rails/drawers for large screens.
|
|
- Support responsive breakpoints: Mobile (<600dp), Tablet (600-1024dp), Desktop/Web (>1024dp).
|
|
|
|
## Authentication & Security
|
|
- Primary Auth: OAuth (Apple, Google, Microsoft) and Passwordless Magic Links / OTP via Supabase Auth.
|
|
- Direct username/password is strictly deprecated and disabled by default.
|
|
- Storage: Use flutter_secure_storage with platform-specific options (Keychain for Apple, EncryptedSharedPreferences for Android, DPAPI/Credential Locker for Windows, Keychain for macOS, secure in-memory/cookie for Web).
|
|
- Compliance: Health markers (doses, weight, biometric data) stored locally must use SQLCipher-backed local persistence (drift + sqlcipher).
|
|
|
|
## Automated Workflow Commands
|
|
- After modifying models or Riverpod providers, execute:
|
|
flutter pub run build_runner build --delete-conflicting-outputs
|
|
- Check code quality:
|
|
flutter analyze
|
|
- Run test suites:
|
|
flutter test
|
|
|
|
Before starting any task, read BUILD_STATE.md to determine the current milestone. Upon satisfying all implementation steps and verification commands, update the checkboxes in BUILD_STATE.md before prompting the user. |