Component Cleanup

The layer grew with the work: c92 through c128 added components as pages needed them, qdash staged its own library-grade pieces, and two parallel apps (c99) left a list of fixes. The catalog has duplicates and near cousins, components whose shape predates component_philosophy.md, code with no annotation, and documentation pages that show a default rather than the flavors the dashboard actually uses. The control plane web app will stand on this layer for years; the native app's token bridge needs the tokens clean. This is the moment Mark named.

The component philosophy is the measure: functional not decorative, composition over configuration, Tailwind-native, states explicit, the demo is the test. Twelve notes; the cleanup is tuning them, not adding a thirteenth.

Sketch: The scorecard, drawn 2026-11-10 in the design system; Mark's own drawings may replace it.

Done means: a scorecard with one row per component (five checks, used by, cousins, resolution), generated by a script and kept as a living page; the census of duplicates and cousins ruled with Mark; every group brought to five passes with annotations, harvested flavors and adminProps in its docs, released and consumers bumped; the annotation lint on for the whole layer; coverage before and after, the retired and merged lists, component_philosophy.md and /document-components updated.

• Layer: ../q-nuxt-layer/components/* (23 groups), the lint, releases
• Design repo: cycles/c135.component-cleanup/ (scorecard.md), app/data/component-registry.ts, app/pages/components/_demos/*, the scorecard page, /document-components
• Consumers bumped: design, qdash UI, www, app.qpoint.io (if still kept green; clarifying question 1)
• Out: new components for the native app (the kit's); page work in qdash; the token bridge itself (c132)

• stage 1 (2026-11-09): prompt and plan written from c130's split: the scorecard, six resolution strategies, eight defaults, five phases. CYCLE.md written before kick-off at Mark's request (c130 clarifying question 6).
• 2026-11-09, later: Mark: the consumer to keep green is app.qpoint.io's successor (c134), which starts from a blank slate, so the waiting-list extractions happen in this cycle, ahead of their groups (D8 revised). Committed the same day.
• sketch and story (2026-11-10): the scorecard sketch (app/pages/cycles/design/sketches/c135-scorecard.vue, captured as c135-sketch-scorecard.png), the story module (app/data/stories/c135.ts, D1–D8 as decisions, the sketch as hero) and this record's sketch line and "The shape" section.
• 2026-11-12, from c140 (Mark's ruling D4): c135 covers both surfaces. Each group is cleaned once, on Vue and on QGUIkit, the Rust twin in qnative's layer crate (being renamed qguikit, c140 D2). That widens Scope's "Out: new components for the native app (the kit's)", which was written before c131 D18 made the layer a drawn Rust twin with 36 counterparts. The QGUIkit crate's restructure (D9), its renames to the web's names (D8) and the token sweep (D5) land first, in one qnative cycle after the merge (c140 D14, ../c140.surface-evaluation/handon-qnative.md). The groups here then clean against those names. The parity register that keeps the two in step is c141. Evidence: /cycles/design/c140/scorecard.

Not started.

Documents: the plan · Mark's prompt

The problem. The layer grew with the work and nobody has measured it: duplicates and cousins, shapes that predate the philosophy, code without annotation, docs pages that show one default where the dashboard uses five flavors. The control plane web app (c134) will stand on this layer for years and starts from a blank slate, so the layer must already hold what it needs.

The core idea. Measure before changing: every component gets one row against Mark's five checks, with who uses it, which cousins it overlaps and one of six resolutions. The census is ruled with Mark once; then the groups are brought to five passes in D1's order, one release each, and the lint keeps them there.

The pieces.

• The scorecard: scorecard.md here, generated by the Phase 0 script, and a living page on the design site (like /layer/consolidation-gaps).
• The five checks and the six resolutions: plan.md §The scorecard and §Resolution strategies.
• The waiting lists: qdash ui/LAYER-CANDIDATES.md and the Opus track's 59 fixes, merged in the layer repo at Phase 1 and extracted in Phase 2, ahead of their groups (D8).
• The annotation standard and its lint: the layer repo, written from the first group's practice (D6).
• The docs: app/data/component-registry.ts and app/pages/components/_demos/*, with flavors harvested from qdash by /scan-patterns (D5).
• The sketch: /cycles/design/sketches/c135-scorecard and its capture, the story's hero.

The pattern we follow. Archaeology, then formula: surface what real use made of the catalog (usages scanned, flavors harvested, not invented), then apply the principles group by group, with more order as the stage gets later. The demo is the test (component philosophy, principle 8): a docs page showing the dashboard's real flavors is the component's test. The five checks are the component philosophy read as questions: modular (purpose and protocol), clean (Tailwind-native, the layer's lint), documented, shaped (composition over configuration, states explicit), a docs page.

What stays open. Release cadence during the cleanup (per group, or fewer and larger); which families Mark already knows are duplicates, so the census starts from his list; the lint's exact rule, written after the first group passes.