c141. Surface Docs

Opened at Stage 1 on 2026-11-12 by Mark's ruling in c140 (D3: "a new small cycle" for the dual-surface docs; D10: the capture manifest's field split with it). His words, from the c140 prompt, verbatim:

Surface

The surface we are deploying our components on. The first expression of our component system was Vue via q-nuxt-layer. We are ultimately adding a second expression onto QPUIkit. I want our public documentation to track both expressions and to be honest where capabilities or flavors diverge. We are going to maintain as close to parity as we can, but acknowlege and welcome the instances where they diverge and note that to the future operators who will be deploying thes components.

crux ides, is it the Vue app or the QGUIkit app

What c140 ruled that this cycle starts from (../c140.surface-evaluation/review-1.md § Ruled):

• D1, D2: the second surface is QGUIkit, and the qnative crate layer becomes qguikit.
• D3: this cycle builds the parity register (the scorecard as shared data, with the Rust symbol, fidelity, the divergences and the Vue file's SHA when each row was checked) and a Surfaces panel on every design-site component page, each divergence marked flavor or gap. The proposal is on /cycles/design/c140/parity § Both surfaces in the public docs.
• D10: the capture manifest's surface field splits into surface (vue · qguikit) and kind (app · mock · docs · preview).
• The seed: the divergence register's eleven entries are in app/data/c140-evaluation.ts (DIVERGENCES).

Create a plan, ask any clarifying questions, suggest patterns I may not be considering.