screen-deep-divelisted

# Screen deep-dive One screen, all sizes, UX and layout and visuals together, ending in a decision and issues — not in code. The audits judge the whole app against criteria; this argues for one screen from measurements and shows the alternatives working. Product code ships afterwards through `create-issue` → `implement`. **The lever is frequency.** Every screen has controls used every time and controls used rarely. Most layout trouble is rare controls rendered at the size of common ones. Classify before you measure; it decides tier B below. ## The brief — what "better" means here The operator's standing brief for a deep-dive, first given for the session setup screen on 2026-09-11: **be bold and creative, aiming at a great, fresh, cool, fancy, lightweight experience — nothing on the screen is set in stone.** Every proposal has to pass all four readings of that sentence: - **Lightweight.** Fewer things on screen at once, fewer taps for the common case, no scrolling past the rare to reach the usual — and lightweight in the codebase: no dependency, no build step, no new stored state when an existing mechanism (tags, the vote, retire, the filters) already answers the need. The operator prefers the existing mechanism over a new field every time; "add a feature to fix a layout" defaults to no, and a proposal that adds a mechanism must argue why the existing one cannot carry it. - **Fresh and fancy.** At least one character moment per proposal — a scene, motion, th