platepilot

Figma handoff

Status

The repository does not claim a complete Figma design system. M1 Task 7 mobile screens were implemented from the approved written UX specifications; use this checklist to reconcile them with future Figma artifacts and to hand remaining M1+ concepts to engineering and research.

File organization

Use pages in this order:

1. 00 Cover and status
2. 01 Foundations
3. 02 Components
4. 03 M0 implemented reference
5. 10 Onboarding
6. 11 Meal logging
7. 12 Water and dashboard
8. 13 Planning
9. 14 Household
10. 15 Subscription
11. 16 Settings
12. 90 Prototypes
13. 99 Archive

Each flow frame starts with a status badge: M0 reference, M1+ specification, Research only, or Deprecated. Never present a future frame as shipped.

Naming

• Components: Category/Component/Variant
• Frames: Area.Step.State.Platform
• Tokens: match semantic roles in Design tokens and accessibility
• Flows: Actor – goal – happy/alternate/error

Use stable frame names in tickets and review notes; do not rely on page coordinates.

Required handoff detail

For each screen:

• Purpose, entry points, exit paths, and milestone status
• Owning adult and any household visibility rule
• Data source: local draft, API, provider estimate, adult-confirmed, or shared
• Loading, empty, offline, pending, stale, permission, error, and success states
• All interactive states and disabled reasons
• Validation rules, units, limits, truncation, and localization behavior
• Keyboard, focus, screen-reader labels/order, dynamic type, and reduced-motion notes
• Analytics event proposal without photo, free text, or sensitive payloads
• Retention/deletion effect for photos and other restricted data
• Exact approved copy or a link to the content decision

Prototype data

Use clearly synthetic adults, meals, amounts, subscriptions, and household invitations. Do not paste real photos, emails, access tokens, customer support records, medical details, or vendor output. Use neutral placeholder meal imagery with recorded usage rights.

Component delivery

1. Map each component property to a semantic token or explain the exception.
2. Include all states, modes, target sizes, and responsive constraints.
3. Separate visual variants from data status: “pending” is not just a color variant.
4. Identify whether a component already exists in M0 or is proposed.
5. Compare proposed interfaces with shared contracts; document mismatches instead of hiding them in copy.
6. Supply exportable assets only when native/vector construction is unsuitable; include sizing and accessibility treatment.

Review sequence

1. Product confirms scope and milestone status.
2. Privacy/safety reviews adult-only, photo, household, export, and deletion effects.
3. Content reviews uncertainty, wellness disclaimer, errors, and subscription language.
4. Engineering reviews contract, platform, offline, and provider feasibility.
5. Accessibility review covers every state and prototype path.
6. Research validates high-risk assumptions before build.

Handoff acceptance checklist

• Every frame has an implementation status
• Happy, alternate, failure, offline, and recovery paths connect
• Token names match the implementation source of truth
• Measurements and responsive constraints are inspectable
• Accessibility annotations are complete
• Copy is approved and localization-ready
• No real personal data or unlicensed asset is present
• Provisional analysis and manual fallback are visible
• Household boundaries and destructive-action ownership are explicit
• Open decisions and non-goals are listed