2.1 KiB
2.1 KiB
Mobile Rules
- Flutter mobile rules are maintained here.
- If no more specific rule is defined here, follow the root
AGENTS.md.
Flutter Design-to-Code Workflow
Before writing any Flutter UI code, follow this sequence:
- Get editor state: Use
pencil_get_editor_stateto confirm the active design. - Get structure: Use
pencil_batch_getto inspect node hierarchy and layout. - Get variables: Use
pencil_get_variablesto fetch colors, typography, and tokens. - Implement: Match design values and container hierarchy exactly.
Layout Mapping Rules
Map design layout properties to Flutter explicitly:
- Always set
crossAxisAlignmentonRow/Column:alignItems: center->CrossAxisAlignment.centeralignItems: start->CrossAxisAlignment.startalignItems: stretch->CrossAxisAlignment.stretch
- Map full container chain: From root to leaf, ensure each
alignItemsandjustifyContenthas a Flutter equivalent. - Analyze before coding: Use
pencil_snapshot_layoutorpencil_batch_getto verify each container's alignment settings.
Centering and Visual Balance
Apply these rules on any screen that relies on centered composition:
- Centering must be evaluated inside
SafeAreabounds, not full-screen bounds. - Avoid relying on proportional
Spacervalues as the only centering mechanism for critical content. - For layouts with persistent top/bottom regions (for example headers or footers), center the primary content in the remaining available region.
- Distinguish geometric centering from visual centering; validate final visual balance with screenshot review.
Quality Gate
For important screens, add widget tests that reduce layout-regression risk:
- Verify primary content remains centered relative to the usable viewport.
- Add at least one constrained viewport scenario (small height or large text scale).
Prohibitions
- Do not use colors or themes not defined in the design.
- Do not skip design container layers.
- Do not start implementation before retrieving design variables.
- Do not hardcode colors; use design variables.