Every other doc in this repo describes a component, a pattern, or a principle on its own. This tree runs the opposite direction: it takes one real, shipping page and reads every layer that put it on screen, from the shell that wraps it down to the exact canon rule that shaped a single prop. The two speedway pages and the two walmart pages are frozen product surfaces, so their breakdowns document what shipped and where it now diverges from the canon. The two kit pages are the playground's own component galleries, so their breakdowns feed fixes back into the kit itself.

What is this?#

A breakdown is not a tutorial and not a review score. It is an inventory. It states which shell renders the page, which composition rule ordered its sections, which kit primitive drew each piece with the exact props that called it, which named pattern the piece instantiates, and which canon document ruled that shape. A "Lapses" section closes each doc with the places the page's own history left it behind the canon, cited the same way as everything above it, never softened into a vague "could be improved."

The backend twins#

The platform contract keeps the same kind of breakdown for what runs below the screen: ~/Code/Versable/gcp/contract/instances/speedway.md and ~/Code/Versable/gcp/contract/instances/walmart-mvp.md, one seven-section template across five instances, with file:line citations. Read 01 or 03 beside its twin to see one app whole.

Why these six#

Doc 57's owner sitting picked two shipping pages per app plus the kit's two richest single-component galleries (D12a, D13a), so the set spans a frozen product surface with real data, an app built on the kit's newest shell primitive, and the kit's own reference demonstrations of that primitive and its most-used control. A page and its gallery read differently. A shipping page shows a primitive under product pressure: real data, real empty states, a duplicate-resolution flow. A gallery shows the same primitive with every prop it owns, deliberately including the ones no shipping screen has exercised yet.

The breakdown template#

Every doc in this tree follows one shape, so a reader who has read one already knows where to find the next fact.

1. Page and route. The URL and the file that renders it.
2. What the reader sees. Three sentences, no jargon, what a person looking at the screen would say it does.
3. Layer 1, shell. Which shell wraps the page, and the exact file:line that puts it there.
4. Layer 2, composition. The section order inside the page, and the canon doc that rules it (docs/app-patterns doc 9).
5. Layer 3, primitives. A table. One row per kit component the page calls, its actual props, the file:line that calls it, and the contract doc that governs it.
6. Layer 4, patterns. Which named pattern under /patterns the page instantiates, if any, linked by its playground route.
7. Layer 5, canon rules in force. The specific docs/design-language sections that shaped what Layers 1 through 4 found, cited by file and line.
8. Lapses. Where the page's own code departs from a rule named above. Each entry names the rule, the file:line of the departure, and what the fix would be. For the frozen speedway and walmart pages this is a record, not a task. For the two kit pages it is a punch list.
9. See also. The contract docs, pattern pages, and sibling breakdowns a reader would want next.

A citation is a claim, not a decoration#

Every file:line in this tree was opened and read at that line before it was written down, not inferred from a component's name or copied from another doc's paraphrase of it. Where a doc borrows a characterization from docs/design-language rather than re-deriving it from a large file directly, it says so. A canon doc's own claim and this doc's independent reading are different kinds of evidence, and a reader deciding whether to trust a line should be able to tell them apart.