# 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