The native app's Safety & Security section as this machine's findings: design's phase-4 Findings copied first, then made the person's, in one finding shape the company's plane speaks too (findings bubble up, trainings and follow-ups bubble down).

One page in the native app, under This machine, that manages qcontrol's config.yaml in three modes: edit it here (in an editor, from a library of starters), governed by the company's plane, or fetched once from a published file. An agent drafts the file over the app's MCP server from the person's plain instructions. The draft is checked by qcontrol and applied by the person.

The native app's **Safety & Security → Findings · Settings** in place of c4's Messages section: this machine's findings, in the person's words, on the same record the company's plane keeps (one finding, append-only events, three writers). c4's notification plumbing, tray, quiet hours and Focus stay and announce findings.

Small, ad-hoc changes to the native app and its component library (QGUIkit, crates/qguikit), and to the web layer (q-nuxt-layer) when an item reaches it.

The Config page under This machine, and the guide's config tools. An agent reads, checks and proposes the person's config.yaml; only the person applies it.

the guide walk's report (cycles/notes/2026-11-13-guide-agent-walk.md): what an evaluator's agent driving the guide MCP server needs, in the report's order.

Tours the person's own agent can give over our MCP server. *New here*, at a level the person picks, from ELI5 to "I have networking degrees". *AI, on your own machine*, an AI primer with the person's computer as the subject. And the *doomsday scenarios*: stories of AI going wrong, played out in the dashboard on synthetic data, in **theatre mode**. Every theatre tour begins with the person and the agent switching synthetic data on together and ends with switching it off. Each scenario's beats double as acceptance tests for the dashboard.

Every thread's new work merged into main and pulled locally, across design, qnative, the layer and the sister repos, with conflicts untangled by hand, and one place that holds what is still open.

Model a new mode with Mark, the guided tour of a cycle, by giving real tours of recent cycles on the generated pages of the design site and writing down what worked, so the mode can become a skill or extend an existing one.

An honest evaluation of our component system as drawn in Rust on GPUI (the native app's layer crate and its pages), scored per principle against our foundation docs, with the course corrections, the cost of keeping two surfaces, and the skills and tools the work around the GPUI layer calls for. Opens the glossary with Surface.

design c133's remediation trainings taken in the native app, launched from the inbox's training assignments.

design c140's code rulings, in Mark's order (D14):

The user-facing half of updating the native app: Settings → Updates with the current and new version and release notes, a preference that can make updates invisible, the trace a quiet install leaves, and the difference between the build-partner era (one channel, internal notes) and a later structured rollout (channels, staged percentages, public notes, organisation policy). The low-level update (qupdate) exists; engineering calls go to Tyler.

The native app's developer mode: the live viewer replicated from qdash and improved, Kamal's monitor TUI replicated as Monitor, a Sensor page that makes the data switch a working control, a Config page with three modes, the Guide that tells Kamal how to hook a live sensor, and a curated Events page as the layer of meaning over the same stream. All of it behind a gate that can switch it off or ship without it, with the cost measured.

The native app's left rail replicates the web app's: section headers as small uppercase labels, entries as plain text with no icons, the active entry marked the way the web app marks it, a gap between sections. Nothing else in the window changes.

Two toggles in the open info panel, settable while it is open: **Help Mode** (on / off) and **Dev Mode** (on / off). Dev Mode is developer mode's own switch, the one the tray menu carries, in a second seat. Help Mode is the guide layer staying on as the person moves. Opening the panel switches nothing on.

The Status page, the app's first page and the tray's long form: is qcontrol on, what is it reading, what has it found. Built from design c132's Phase 4 brief and mock (the worked example of the loop for native screens) as the loop's push: the page on our layer, a story per state, the state read from the source and the data and never from a flag in the page, captured per world into both atlases, the budget read with strobe.

The V1 slice of the message channel between the control plane and the person at this machine (design c137, Phase 3): the bones as types, the inbox store, the four ports as far as the endpoint owns them (inbox, tray, OS notification; the web app is c134's), the person's controls over delivery, and the one message that flows in V1, the identity confirmation on Connect. The enforcement notice is drawn from the fixture and flows only in synthetic worlds until qcontrol sends it.

The app's developer mode, and the Events page above it. Live (qdash's live viewer, replicated on the sensor's current event schema and improved), Monitor (Kamal's monitor TUI, replicated), Sensor (the data switch as a working control), Config (three modes), Guide (how to hook a live sensor). Developer mode is an extension behind one Cargo feature, so a build can carry none of it; where it is allowed, the person can still turn it off. Events, the curated layer of meaning over the same stream, is an ordinary page.

c131 Phase 2. The whole qdash Inventory section in this app: seven listings, nine detail pages and the landing, in the Qpoint skin, on the data the web pages show, cut to one machine. We build our components in Rust (crates/layer, with the web layer's names) on top of the kit, and record per component how close it came and what it cost. Stretch: the Tour guide, with Info View and the qpoint-guide MCP driving the app. Extra stretch: the table with an expand row at full fidelity.

The ports and bones of every message between the overseer (the control plane and the people who run it) and the citizen (the employee at the endpoint): one schema, the channels (inbox, tray, OS notification, web app), the inventory of message types the roadmap implies, and the citizen's control over what reaches them. Simple, and never a bombardment.

Time-boxed, categorised, audited access a build partner grants Qpoint on their running plane: "three days to fix this documented problem". The categories (diagnose · fix · implement · hot-fix), the levels (observe · operate · change), the window, the named people, the record; the grant screen in the web app and one honest line in the native app.

The layer catalog audited against Mark's five checks (modular, clean, documented with code annotation, shaped per the component principles, a good docs page), group by group: duplicates and near cousins named and resolved (merge, split, alias and deprecate, retire, extract), every docs page showing the dashboard's real flavors with adminProps, an annotation standard and lint, one release per group. The qdash LAYER-CANDIDATES.md and the Opus track's 59 fixes merge into the work.

qdash leaves qcontrol and becomes the control plane's UI, offered as SaaS and as a self-hosted Docker image (Pulse repurposed with a new data model, Postgres and ClickHouse, no Firebase; Tyler, session 1b21a3ce). app.qpoint.io is the model. Design's slice is the seam: the shell decision (qdash's shell in app.qpoint.io's auth and org frame), the API contract Kamal implements, identity and access without Firebase (including the endpoint's connect credential and mechanic-access grants), the install experience on the wizard kit, and the port plan.

A finding is a teaching moment. Short trainings (one to three minutes: an illustration or animation, what to do instead, a check that it landed), assigned by a policy, an operator or HQ, opened from the native app's message on the web app, and recorded in the audit log as proof of correction. Concrete, respectful, with a path to IT. Three pilots on the lab's top policies.

How design mocks GPUI screens the way it mocks pages today. A bake-off of five media on one page (Vue mocks in a native skin, a stories crate in the app repo, the kit's wasm build embedded in the lab, Figma as an input, Native Shell's TSX); Mark picks; then the loop is rebuilt: a token bridge from design_tokens.md to a kit theme, a native capture mode for the atlas, the kit's skills installed plus ours, one worked example pushed into c131, and the process documented.

Our V1 of the native desktop app in GPUI Kit: the one-machine slice of qdash (Status, Inventory, Events, Config, Connect) and the tray, two states (local and editable, connected and read-only), the DataNozzle with three sources (synthetic, local, plane), the message channel's ports and bones, stories that are tests, packaged for three OSes, measured against a budget with strobe, handed to the engineers as option B.

The 2026-11-05 roadmap pivot, run as a design program. qdash leaves qcontrol. A native desktop app (GPUI Kit, carrying the tray) becomes priority one, followed by the control plane as a self-hostable web app. This cycle holds the roadmap, the GPUI ecosystem primer for designers and builders, the proposed shape of the native app, and the gates for the cycles it spawns: c131 Native App V1, c132 Native Design Prototyping, c133 Remediation Training, c134 Control Plane Web App, c135 Component Cleanup; since the 2026-11-09 rulings also c136 Mechanic Access, c137 App Messaging (overseer and citizen), and c0 Call My Name, the naming cycle in the app's own repo (../qnative, provisional name).

c131 Phase 0: a hello app on GPUI Kit 0.9.1 that answers the platform questions before anything is promised. One window with a sidebar and a data table bound to a JSON inventory; a tray icon beside GPUI's event loop; the DataNozzle with its three transports (synthetic, local, plane) behind one process-wide switch; the footprint measured with strobe; Windows and Linux builds attempted in CI; the findings written back to design's primer.

The names, before the code: the native desktop app (and whether "Qdash" moves to it), the control plane (publicly "Qplane" since 2025 Q3), the third data source and the thing a base URL points at, the two roles (working words: overseer and citizen), and this repository. Grounded in the customer's own words from the market-analyst corpus, the brand's writing rules and the neighbours' precedents; decided in a shared team session with an agent.

Serve the qdash demo as pre-computed worlds (sizes, scenarios, First run stages) from files, switchable instantly, baked daily, with no containers at serve time

Audit every qdash page's data provenance, write the front-end data-interface bible (page → context component → library component; composables modelled on app.qpoint.io's), then plan and execute the conversion of the qdash UI's vibe-coded data layer onto it

Reshape market-analyst into a design tool first — the source of truth for Qpoint's problem space — by adding a micro-problem layer (use case → micro problem → observations) on top of the existing market lens, with a curated registry, extraction-proposed candidates, computed standing, product surfaces, document intake, and briefs/stories that cite problems.

A time-windowed Reports section for qdash. It gives C-level people, auditors and others who see data but get no controls what the dashboard already shows, as documents they can hand on. The two categories are Security (Posture) and IT (Inventory, Deployment status). Every report reads one window: rolling, calendar or custom from–to, with a comparison period.

Visual look and feel, hierarchy, and labeling — tuned by hand

A final, hand-tuned pass over the policy surfaces in the phase-4 lab. We walk each aspect in turn (the listing, the policy header, mode and Until, severity, exceptions, frameworks, findings, history, Policy Config, team Policies) and sand each one by hand. Along the way, each fact about a policy gets one home, and every other place summarizes it and links there.

A tour-guide and self-documenting tool that attaches cleanly to any part of the UI, so the UI becomes the documentation. It has a hover help mode (after Ableton Live's Info View), a numbered-marker overlay for explaining a screen, step-by-step tours that move across pages and highlight what matters, and an AI tour guide over MCP from the start. Its first tour is the operations journey from the 2026-10-26 product session: install to enforcing on a pilot team.

Make the cycle detail page tell the cycle's story at a glance: why it happened, what changed (before → after, in plain words), and who made it better. External market specialists are credited first. Every outcome traces back through its decision to the meeting or conversation it came from. Collaborators get their own unlisted pages, where attributions and accolades build up.

Give the frameworks a good bath and a redress. We finalize the framework page designs and tune their details from the latest designs and what Mark Peterson made clear on 2026-10-26: Qpoint gives evidence, not compliance, under emerging regulatory pressure to govern AI. Most of the work is by hand. We export the current page to Illustrator, Mark reworks it there, and we build the result on a test page. The brief's Frankenstein list (X1–X11) is the checklist for the cleanup.

Build the Phase II governance dashboard for qdash around the object model the ../intents repo describes, so that Findings, Policies, Scope, Groups, Exceptions, Enforcement and Frameworks appear as one coherent system rather than fourteen features

A weekly view of the cycle atlas (started · still open · closed per week) beside the existing numerical view, plus a week details page designed as a _meta mock

Fold qmap into DataSurfaceSection. Draw a thing's Surface (what it reaches) as a scene of pixel pawns, as a second view beside the lists (Map ⇄ List). This starts with a design brief to a designer.

Tame our own design history before telling it. Catalog the Qpoint Design drive (sketches, Illustrator, Photoshop, InDesign, Sketch, Figma) so every file can be found, previewed and traced to its original. Tie each file to a cycle where one exists, otherwise to a startup phase and design generation. Write down an ingestion protocol that ends in a story. Then give the cycle detail page a story-first design pass.

Build the decisions from the week of Oct 19 into the phase-4 lab (/pages/phase4/mock/*). The governing scope is Mark Peterson's v1 guidelines: an exception changes mode only, publication is the whole shared draft, and resolving a finding records a decision.

A /briefs section on the design site, off the main menu, with one page per brief handed to a collaborator outside the org

Re-evaluate the qdash /cost page against what the backend now serves, and re-draw it on the Organization / Inventory listing pattern

Design the three qdash "Design in progress" landings: Home /, /inventory and /team. Each is a 30 ft (300 ft for Home) view of its domain, made more of images than of text.

Keep npm run deploy short as the lab grows. The prerender crawler renders every page it can reach, and the build's time goes wherever the crawl goes.

Explore and integrate Avoma notes data into extraction pipeline and dashboard visualizations.

Refine how extracted data is displayed in the dashboard and improve extraction quality where gaps exist.

Add Google OAuth to restrict dashboard access to @qpoint.io team members.

Methods & tooling retro — evaluate how we work against the design methodology, restore order, modernize the skill/agent tooling, and make the philosophy load-bearing

Build-partner portal — research, ideation, and a plan for a page that makes partners insiders

Align the qcontrol agent-monitoring dashboard to specific personas and find market alignment — hypothesis-first, validated against calls later.

Tours the person's own agent can give over our MCP server. *New here*, at a level the person picks, from ELI5 to "I have networking degrees". *AI, on your own machine*, an AI primer with the person's computer as the subject. And the *doomsday scenarios*: stories of AI going wrong, played out in the dashboard on synthetic data, in **theatre mode**. Every theatre tour begins with the person and the agent switching synthetic data on together and ends with switching it off. Each scenario's beats double as acceptance tests for the dashboard.

The ports and bones of every message between the overseer (the control plane and the people who run it) and the citizen (the employee at the endpoint): one schema, the channels (inbox, tray, OS notification, web app), the inventory of message types the roadmap implies, and the citizen's control over what reaches them. Simple, and never a bombardment.

the guide walk's report (cycles/notes/2026-11-13-guide-agent-walk.md): what an evaluator's agent driving the guide MCP server needs, in the report's order.

c131 Phase 2. The whole qdash Inventory section in this app: seven listings, nine detail pages and the landing, in the Qpoint skin, on the data the web pages show, cut to one machine. We build our components in Rust (crates/layer, with the web layer's names) on top of the kit, and record per component how close it came and what it cost. Stretch: the Tour guide, with Info View and the qpoint-guide MCP driving the app. Extra stretch: the table with an expand row at full fidelity.