Design gates

What a human checks before approving each design gate (ADR-0004). The orchestrator copies the stage's list into the gate issue. design/check.mjs already checks structure; these are the things only a person can judge.

#1. Brand and name

• 3 to 5 name options, each with its domain and store search.
• The promise is one sentence a user would say.
• Voice: three words, with a line of copy for each in en and zh-Hans.
• The mark reads at its smallest size, in light and dark.

#2. Design system

• 3 to 5 options, each shown on the same two sample screens.
• Text on every ground meets WCAG AA, in light and dark.
• The chosen option's values are in design/system/tokens.source.json, not only in pictures.
• Components list their states (default, pressed, disabled, loading).

#3. Lo-fi

• Every screen of the PRD is in design/lofi/screens.md, with its states and flows.
• Every screen has loading, empty, error and offline, and they make sense for it.
• The clickable prototype walks the critical flow: onboarding → first value → paywall.
• The tracking plan names the events each screen sends.

#4. Hi-fi (per screen)

• A board for every state in the screen list, and the ready board in zh-Hans too.
• Every value on a board comes from an example API response, local state or the device, as bindings.md says. Nothing is made up to look good.
• Every colour, size and font is a token named in "Tokens used".
• Error boards say whether the user can retry. Offline boards say what still works.
• The paywall's boards follow the pricing gate.

#5. Screenshot direction

• 2 or 3 directions for the first 3 screenshots, each from approved hi-fi screens.
• Captions in en and zh-Hans.
• No prices, URLs or claims that cannot be checked. One direction serves both stores.