Native — the desktop app's screens

The native app (GPUI, ../qnative) has no DOM to transcribe and no URL to capture, so its screens follow the loop in process.md: sketched and reviewed here in a native skin, built of record as stories in the app. Here, the mocks: the app's chrome drawn with our tokens and Inter, the pages composed from the layer's components, the rows read from the app's own named synthetic worlds through useNativeWorld (c131 D15, c132 D6). A mock names its world the way a native story does, so a lab capture and a native capture show the same rows. 15 pages so far.

Cycle: c132 Native Design Prototyping · ← Phase 4

The bake-off

Medium A (these mocks) beside medium B (the real app, captured by qnative c2) on Inventory, three views in three worlds, with time and friction per medium. Mark picks the medium in Phase 2.

Native — the bake-off: A beside Bc132 native-design-prototyping — Phase 1 bake-off, 2026-11-11

c132 Phase 1: medium A's captures (Vue mocks in a native skin) beside medium B's (the real app on GPUI, captured off-screen by qnative c2) per view and state on Inventory, with the time each took, the friction met, and what the evidence suggests for Mark's pick (Phase 2)

Pages in the native skin

The app opens on Status (c131 D21): the "This machine" group holds Status, Sensor and Activity, then Inventory keeps its own index. Each page takes ?world=fresh · minimal · meridian-day90 · pilot and ?period=24h · 7d · 30d · all; the harness page takes ?adapterId=; Status and Sensor take ?state= and ?plane= for the states no world carries. The worlds are copies of ../qnative/crates/fixtures/world/ (scripts/sync-worlds.sh); the sensor's six shapes come from the bridge beside each world (app/data/worlds/bridge/, D10) until c131 D17's routes land.

Native — Inventory overviewc132 native-design-prototyping — Phase 1 bake-off, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 1, medium A (Vue mocks in a native skin): the native app's Inventory landing as qnative c2 built it, twenty micros from the seven listings on one machine, inside the app's chrome (title bar, the 212 px rail, the footer that names the data source) drawn with our tokens and Inter. Rows come from the named synthetic worlds through useNativeWorld (fresh · minimal · meridian-day90), never invented; ?world= and ?period= name the state

Native — Harnessesc132 native-design-prototyping — Phase 1 bake-off, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 1, medium A: the Harnesses listing translated fleet → personal as c2 did (Installed here with a monitored or shadow mark per harness, Work; the ledger without endpoints, with version and last active brought forward; Kind / Provider quick filter and the column picker), in the native skin on the three worlds

Native — the harness pagec132 native-design-prototyping — Phase 1 bake-off, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 1, medium A: the merged harness page (Harness detail and Harness install detail as one, c2 rule 3): the identity header with Status and the install's long tail, tiles Providers · Tokens by model · Spend, jump pills, Sessions, Configured here and the Surface, in the native skin; ?adapterId= picks the harness, and a world without it shows the not-on-this-machine state

Native — Status, the landingc132 native-design-prototyping — Phase 4, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 4, the worked example (Mark's pick, 2026-11-11), reshaped by c131 D21 the same evening: the native app opens on Status. The one-line state (off · starting · on · degraded, with why) and the plane line; what it has found on this machine (sessions, events, tokens and spend, the harnesses here, out of sight, the record); the Inventory overview's twenty micros below. Rows from the four worlds; the state and the plane from the bridge beside each world (D10), the footer saying so; ?state= and ?plane= are lab knobs for the states no world carries

Native — Sensorc132 native-design-prototyping — Phase 4, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 4 after c131 D21 (S3, S5): the sensor's five facts in full, the process (version, build, uptime, workers, CPU and RSS), reads (source, machine, plane, last sync), configuration (file, mode, which won, plugins, managed), the config file's text, the plane connection, and the log tail. From the bridge beside each world (D10) until c131 D17's routes land; a row says "not served yet" naming its route where nothing serves it. The same knob as Status

Native — Activityc132 native-design-prototyping — Phase 4, 2026-11-11freshmeridian-day90minimalpilot

c132 Phase 4 after c131 D21 (S4): sessions over time on this machine, as qdash's /monitor/activity (the plane app calls sessions Activity): a day-by-day history by harness for the shared period, the window's sessions, tokens and spend, and the sessions ledger. Rows from /api/sessions?period= in the four worlds

c139 Phase 2: the app's first Settings page, at the foot of the rail, open on Updates. One sentence per state and what happens next (up to date · checking · available · downloading with download, verify, stage · ready to restart · installed quietly, then what's new · failed · offline · managed by Homebrew; later also HQ's policy); the versions of the app and of qcontrol (the bridge's) with Copy version info; the preference as three tiles (Automatically · Ask me first · Manually); the channel (build partners now, Stable or Beta later); the notes (internal, drafted from the cycle records with their sources, now; public later); the footer's trace. ?state= ?pref= ?era= ?sensor=1 ?skip=1 are the knob, since no world carries update state

c139 Phase 2: the tray menu on a desktop with the update's one line (Restart to update, Update available, the download, Updates aren't installing) and the icon's dot only where the person asked to be asked or updates keep failing; the version line and the window's footer after a quiet install; every state side by side. The sensor's line and what it found from the world; the update line from the same view function as Settings › Updates

Native — Configc146 config-file — Phase 2, 2026-11-13freshmeridian-day90minimalpilot

c146 Phase 2, medium A: the Config page under This machine (R3), built on c121's Policy Config › Config File (R2). Three modes: Edit here (the editor with Written · Effective, the starter library in its tray, Recommended · Developer laptop · Data or analyst laptop, a check with line and nearest key, Apply or Discard edits, versions with Restore; an agent's draft as a diff the person applies, R4, R7); Managed by your company (connect, signing in, connected read-only, an agent refused, refused, not answering); From a published file (address or the library, fetching, shown, invalid, written with its record of origin, Check for changes, R1). This machine's file from the bridge beside each world; the rest fixtures in config-c146.ts. ?mode= and ?view= are the knobs

Native — Findingsc147 findings-common-tongue — Phase 2, 2026-11-13freshmeridian-day90minimalpilot

c147 Phase 2, medium A: the copy of S2 (the composed Findings) under Safety & Security in the native skin, on the world's derived findings (/api/findings and /api/policies from the c147 sidecar, Phase 1): the listing bar (Outcome · Severity · Status · Framework, Grouped ⇄ Individual), the grouped ledger with the policy in context, the member table and its card, in the operator's words and S2's defaults (Open · Enforced). Fleet → personal: the Subject leaves the rows for the harness; the operator's verbs are not drawn. ?world= picks the machine (meridian-day90: 13 Observed; pilot: 54, 42 prevented)

Native — Finding detailc147 findings-common-tongue — Phase 2, 2026-11-13freshmeridian-day90minimalpilot

c147 Phase 2, medium A: the copy of S1 (the composed Finding detail) in the native skin: the crumb, the policy with the status and the outcome at detection, What happened | Why it violates, History (Time · Kind · Actor · What → State · Cause), Details without User, Team and Endpoint, Related Findings and Session; no Resolve. ?findingId= names a derived finding; an unknown one shows the honest absence

Native — Findings, the person's viewc147 findings-common-tongue — Phase 3, 2026-11-13freshmeridian-day90minimalpilot

c147 Phase 3, medium A: the person's view of this machine's findings under Safety & Security: the first-run card (how much should qcontrol tell you), Observed open by default in five columns with no SLA clock, Prevented as one quiet group with a line per thing and its days, Resolved; the person's own events show in the status column. The same derived findings as the copy (?world=)

Native — a finding, the person's viewc147 findings-common-tongue — Phase 3, 2026-11-13freshmeridian-day90minimalpilot

c147 Phase 3, medium A: one finding for the person: What happened, Why your company's policy covers this, What you can do (Ask for access, Ask IT, each a `from: person` event that never moves the status), What happened since in sentences, What's recorded. ?findingId= names a derived finding

Native — Safety & Security settingsc147 findings-common-tongue — Phase 3, 2026-11-13freshmeridian-day90minimalpilot

c147 Phase 3, medium A: how much qcontrol says, one control (Quietly, the default · When it matters · Teach me), each position with what it would have announced on this machine in its last 30 days; each kind under the chosen position; the tray counts only what needs the person. ?noise= picks the position

Qpoint Brand Style Guide