15 — The screens, rendered
Summary
The first document in this pack written by somebody who was not in it: a session working from the briefing pack cold, answering if this were implemented as specified, what would it look like? Twelve screens as real markup at real widths, with all seven of document 08's load-bearing strings verbatim — a constraint it set itself and met. Five of its six findings are things the ASCII form could not have surfaced, because a 78-column monospace block has no viewport, no colour, no interaction and no wrap point: colour re-collapses the five result states; the badge's wrap point can produce the exact misreading the badge exists to prevent; nobody and not-yet share a glyph; and a column of five ticks is a page-level tick, which document 08 forbids and which no individual rule was broken to produce.
Key concepts
- The screens themselves — twelve tabbed screens, deep-linkable, no framework and no third-party request
- Adopted as C27–C31 — three corrections about drawing rather than wording, one standing rule, and what the exercise itself established
- An inert control over an absent one — the auditor's screen stays visibly blocked, because the traversal is unwritten code and drawing it would hide that
Key ideas
- The strings are the design — a renderer that paraphrases them in a mockup will paraphrase them in the product.
- A story with no screen is how a story quietly does not ship: document 12's I8 and document 13's fixture flag both landed on screens that predate them.
- Rendering an unbuilt system in real design tokens makes it look shipped, which is why every screen carries a banner saying it is not.
- The first evidence in this record of what know your users and listen to your ecosystem are actually worth — it took one outside reader.