Stage 3.5 · structure before taste
Every box below traces to a feature in the screen inventory, and the navigation at the bottom of each screen is the same CSS component rendered six times. It cannot drift, because there is only one of it. This is the stage you drive: say what should move and it re-renders in seconds.
01 — The sheet
No colour, no character, no imagery. Taste arguments belong in the next stage; this one is only about what exists on each screen and in what order. Structure you can argue with beats a picture you can only react to.
Read the tab bars. Five items, same order, correct active state, on every screen — not because anything was checked, but because .tabs is one block of CSS. The onboarding screen has none, correctly: it happens before the app exists.
02 — The loop you drive
Wireframes are HTML, so a revision is an edit rather than a re-roll. Asking an image model to "move the week strip above the hero" repaints the entire screen and changes nine other things. Here it moves the week strip.
No colour to be distracted by, no character to be charmed by. The question on the table is only whether the right things are on the screen in the right order.
"Today so far should be above the week strip. A parent checks the numbers before the photos."
Each revision is a new version with the prior retained, so a direction you dislike is one click back. The criticism log becomes the design rationale, which is the thing normally lost between a review and a build.
The manifest records every element and which feature it serves. A hi-fi comp that drops an element, or invents one, fails the consistency gate. That is how the pretty stage stays honest.
03 — Not every app gets a face
A mascot carries a parenting app and sinks a deployment dashboard. So it is declared per product, recommended from what the category's leaders actually do, and confirmed by you:
brand:
register: consumer-warm
character: required
identity_carriers: [character, color, illustration]
Wobbleby is consumer-warm with character: required, so the penguin gets a reference sheet and every render is anchored to it. A coding tool would be professional-dense with character: none, and its identity would be carried by type, data density, and motion instead.
With character: none the character stage is skipped entirely, that budget moves to the declared carriers, and any comp containing an illustrated character fails the gate. With character: required, any comp whose character drifts from the reference sheet fails. It is enforcement, not a style note.