# Flutter Mobile Development Constraints

This document defines **hard constraints** for Flutter mobile development. Treat all items as **non-negotiable** unless explicitly overridden.

## 0) Scope and Precedence (MUST)

- This file applies to all changes under `apps/**`.
- It extends root routing rules in `AGENTS.md` and workspace global runtime rules.
- It also incorporates the visual design language from `apps/rules/visual_design_language.md` as a binding constraint.
- If rules conflict, apply the stricter requirement.
- Keep Flutter-specific constraints in this file; avoid duplicating them in root `AGENTS.md`.

## 1) Design Tokens (MUST)

- **MUST** use design tokens from `apps/lib/core/theme/design_tokens.dart`:
  - Colors: `AppColors.*`
  - Spacing: `AppSpacing.*`
  - Radius: `AppRadius.*`
- **MUST NOT** hardcode any visual values.
- Design tokens are the single source of truth for all visual values. Any missing visual semantics should be added to tokens, not approximated locally.
- This ensures consistency with the visual design language defined in `apps/rules/visual_design_language.md`.

## 2) Component Architecture (MUST)

- **SHOULD** extract repeated UI patterns into reusable components.
- **SHOULD** prefer existing shared components before creating new ones.
- **SHOULD** place reusable components in `apps/lib/shared/widgets/` following existing naming conventions.
- **MUST NOT** introduce parallel UI systems (e.g., custom button styles, custom loading indicators) that duplicate existing shared components.
- When creating new UI components, ensure they follow the design tokens and visual design language.

## 3) Layout Mapping & Alignment (MUST)

- **MUST** explicitly set `crossAxisAlignment` for every `Row` / `Column` (do not rely on defaults).
- **MUST** preserve layout semantics from root to leaf:
  - alignment/justification intent must be explicitly represented in Flutter widgets.
- **MUST NOT** skip necessary container layers if doing so loses layout meaning or makes mapping non-traceable.

## 4) Centering & Visual Balance (MUST)

- **MUST** evaluate centering within `SafeArea` usable bounds (not full-screen bounds).
- **MUST NOT** rely on `Spacer` / proportional flex as the only centering mechanism for critical content.
- If persistent header/footer regions exist, **MUST** center primary content within the remaining usable region.
- **MUST** prioritize *visual centering* over purely geometric centering when they differ.

## 5) Testing Strategy (MUST)

Follow lightweight testing strategy - prioritize value over coverage:

**Write tests for:**
- Model / DTO parsing (json → model)
- Service layer logic (business rules, API call handling)
- Complex custom widgets with rich interactions

**Skip for:**
- Simple UI pages, regular buttons, basic layouts

## 6) UI Feedback System (MUST)

- All user-facing feedback **MUST** use the Toast system.
  - Transient notifications: `Toast.show(...)`
  - Persistent inline form errors: `AppBanner`
- **MUST NOT** create custom SnackBar/Dialog/Banner feedback components.
- **MUST NOT** use raw `ScaffoldMessenger` for feedback messaging.

## 7) Agent Chat (AG-UI Protocol) (MUST)

Agent chat functionality **MUST** follow the AG-UI protocol. **Use the `ag-ui` skill** for protocol reference and implementation guidance.

- **MUST** use Server-Sent Events (SSE) for streaming.
- **MUST** emit required lifecycle events:
  - `RUN_STARTED` is required for every run
  - End with exactly one of: `RUN_FINISHED` or `RUN_ERROR`
- **MUST** follow standard text streaming flow:
  - `TEXT_MESSAGE_START` → `TEXT_MESSAGE_CONTENT` (delta) → `TEXT_MESSAGE_END`
- **MUST** support the standard AG-UI event type set as defined in the spec.
- **MUST NOT** return non-streaming responses for agent chat.
- **MUST NOT** omit required lifecycle events.
- **MUST NOT** use non-AG-UI event formats (except where the spec explicitly allows).

## 8) Visual Design Language (MUST)

All UI/UX work **MUST** follow the visual design language defined in `apps/rules/visual_design_language.md`.

- **MUST** ensure screens feel like a premium personal assistant product, not a wireframe, admin console, or document page.
- **MUST** apply the surface-based design system (background, primary, secondary, interactive surfaces).
- **MUST** follow the motion and interaction feel guidelines (soft, responsive, premium).
- **MUST** achieve visual hierarchy through spacing, surface grouping, radius, depth, density, contrast, scale, and motion—not color alone.
- **MUST** follow the screen-level decision rules:
  1. What is the primary focus?
  2. What is the surface hierarchy?
  3. What needs strongest emphasis?
  4. What should be grouped?
  5. What should be lightweight/secondary?
  6. Where should motion reinforce understanding?
  7. How can the result feel more like a premium assistant app and less like a document page?
- **MUST NOT** create UIs that match the anti-patterns listed in the visual design language document:
  - plain document page, white slab with blue buttons, spreadsheet-like admin panel
  - low-fidelity wireframe, default Flutter demo app, generic template marketplace screen
  - full-screen flat white blocks, arbitrary shadow usage, inconsistent card treatments
  - raw container stacking without surface semantics

Before finalizing any UI, mentally verify:
- Does this feel like a product, not a page?
- Is there clear hierarchy?
- Do surfaces feel intentional?
- Does the screen feel calm and premium?
- Is the assistant identity visually present?
- Would this look plausible in a polished shipping app?