c130 plan: Native App (program)

Reader: Mark first (rulings), then Tyler's requirements working session (mid-November), then whoever picks up a child cycle. A child's agent reads this file and its own plan, not the transcript. Session: 1b21a3ce (2026-11-05). A later session wins; check ../../../market-analyst/sessions/INDEX.md before acting on anything below. Prompt: initial-prompt.md. This plan does not restate it; it sorts it into cycles and adds what the reading turned up. Rulings: D1–D10 and the seven clarifying questions were walked with Mark in session on 2026-11-09. The Ruling column below and the Answers under Clarifying questions are the record; two new children (c136, c137) and a naming cycle in the app's own repo (c0) came out of it. G1 closed on 2026-11-11: shape.md accepted, with its three new proposals confirmed (§Gates).

What was decided on 2026-11-05

Perspective: all internal (team) or advisor. Direction, not customer validation.

What Tyler sketched for the app (transcript lines 394–440, 663–664): tabs for the config file found and the effective config, CPU and RAM, workers, logs and plugins (diagnostics); the event viewer and audit log ported from the web; a localized inventory (harnesses, skills, plugins, sessions, MCP servers); SQLite behind qcontrol locally; when connected to a control plane the config is read-only and the app says so. Rob: "we're mostly gonna start with some of the stuff that we already know well, like the inventory."

The program map

Independent of the gates: c135 can run now; c134 Phase 0 (the inventory of both apps) can run now; c136 Phase 0 (prior art) and c137 Phases 0–2 (inventory, bones, ports) can run now; c131 Phase 0 (the spike) may run now beside the primer (ruled 2026-11-09); c0 runs now and ends in the shared naming session. c132 waits for the primer. c131's build waits for shape.md. c133 waits for c137's bones (a training assignment is a message) and its brief.

Gates

• G1 — Shape ruled. Mark rules D1–D10 below (done 2026-11-09) and accepts shape.md (accepted 2026-11-11, with the local sentence, the connected-state rule and the budget targets confirmed). c131's build and c133 are open.
• G2 — Requirements session. Tyler's working session (mid-November). We bring the primer, the shape, and the c131 spike. The session answers Q1–Q12 and chooses outcome A or B (D3); c0's naming shortlist is on its agenda. If A, c131 becomes "attach at the UI layer" and its plan is rewritten; if B, c131 runs as planned.
• G3 — V1 handoff. c131's Phase 5: the app, its patterns doc, the fixture world and the headless tests handed to the engineers. The program's main deliverable.
• G4 — Control plane port. c134's Phase 4 plan accepted by Tyler and Kamal. Opens the port.

c130's own phases

0. Kick-off (done 2026-11-09)

CYCLE.md, this plan, five children at Stage 1 with plans, CYCLES.md.

1. The primer (research/)

One research pass, written for two readers. Each file leads with what the reader can do with it.

• README.md — the index and the one-page summary.
• gpui.md — GPUI itself: Zed's framework; the element tree, Render, div() with Tailwind-like styling, the GPU renderer, the platform layer (macOS, Windows, Linux), text rendering, what "native" means here (GPUI draws its own controls; the OS provides the window, menus, dialogs, clipboard; see D2).
• gpui-kit.md — the three layers and when to use each: gpui-component (the styled system: 75+ components, data tables with virtual scrolling, lists, dockable panels, charts, a code editor), gpui-base (unstyled primitives for a design system of our own), gpui-shell (JavaScript extensions with capability-based permissions). Theming by semantic tokens (Theme, ThemeColor, ActiveTheme), the built-in theme set, how a theme is defined and loaded. The app skeleton (application(), init(cx), open_window → Root). Headless UI tests (gpui_kit::test, TestWindowExt). AccessKit accessibility. wasm builds. Version churn (0.9.1 today; what breaks between minors).
• native-shell.md — Native Shell (nsh): TSX app code over a Rust core; native views per platform (AppKit, GTK 4, Win32, Web, UIKit, Android, TUI, GPUI); nsh init / run / check / test / package / publish; signed .nshpkg modules with capability grants; embeddable in GPUI Kit apps; the AI-generated UI story. When it is the better tool (mobile, web, a module system) and when it is not.
• platform.md — what neither site mentions and the app needs: tray icons on three OSes (the tray-icon crate qtray already uses; does it coexist with GPUI's event loop?), system notifications, menus, packaging and signing (macOS notarization, Windows signing, Linux formats), auto-update (crates/qupdate exists), startup at login, single-instance, deep links for the connect flow, fonts and licensing, minimum OS versions, memory and CPU measured for a hello app with strobe (§Facts), so footprint is a number, not a quote.
• agent-tooling.md — what an agent gets: the kit's /skills page (per version) and /llms-full.txt, nsh's llms.txt, docs.rs, the GitHub repos and discussions, any MCP servers, Claude Code / Cursor skills found, demo apps (/apps, the gallery), and the videos worth an hour; strobe's skill and MCP server for measuring footprint (Mark, 2026-11-09). Which of these to install into design's .claude/skills for c131 and c132.
• claims.md — the relayed claims checked with sources and dates: "the Electron killer", Discord and Spotify rebuilt on GPUI, memory figures.
• comparison.md — short: GPUI Kit vs Native Shell vs Tauri vs Electron vs keeping the web UI, on our criteria (memory, CPU, binary size, cross-platform tray, agent fluency, a11y, our brand's reach, time to V1).

Method: web research with sources cited and dated; a hello app is not built here (that is c131 Phase 0, which may start on Mark's word while the primer is being written, since the spike answers platform.md's questions faster than reading).

2. The shape (shape.md) (written 2026-11-11)

Written 2026-11-11 as shape.md, with provisional names marked for c0, and accepted by Mark at G1 the same night. The outline below was its brief; the document follows it section for section and carries the amendments ruled since (D5, D6, D7 on 2026-11-11).

A proposal, not a spec. Built from Tyler's sketch, Mark's prompt and the qdash pages we already have.

• The app map. Status (on / off, connected / local, effective config, resources, workers, plugins, logs) · Inventory (harnesses, MCP servers, skills, tools, sessions and workspaces, models and providers seen locally) · Events (the live stream, the audit log) · Config (the file found and the effective result; editable locally, read-only when connected) · Connect (the sign-in that attaches the endpoint to a control plane) · the tray (status at a glance, open the app, the tap toggles qtray has today). Each with its qdash source page and what changes in a one-machine scope.
• Two states of the app: local (reads the file system and SQLite; can edit) and connected (reads the control plane; cannot edit; shows what was found). The sentence the app says in each.
• The data switch (DataNozzle): one switch, three sources (synthetic from the fixture world at a standard location, local from this machine's qcontrol, plane from a running control plane at a base URL with a standardised credential); never a per-page flag. The qdash bible's Transport (R15, R25) is the pattern to port. Ruled 2026-11-09 (D6).
• Access and credentials. The connection layer's standardised credential, how an endpoint finds its plane (configuration, the Connect flow, a deep link), and the pointer to c136 for mechanic access: time-boxed, categorised grants a partner gives Qpoint on their plane.
• Conversant with the web app. What the native app receives (notices from HQ, confirmations of identity, censures with what to stop doing, new responsibilities, training assignments) and what it sends (connect, acknowledgements, training completed, diagnostics on request). Ruled 2026-11-09 (D9): the channel's ports and bones ship in V1 with the Connect confirmations flowing; c137 designs the schema, the channels and the citizen's control; c133 owns training.
• The budget. The qcontrol sensor's own figures (under 1% of a core, under 30 MB) are not the app's, but the app sits next to them on the same machine. A proposal: idle app under a stated RSS, nothing resident when closed, the tray alone minimal; measured per release.
• The brand. Subtle to non-existent at first: the kit's theme with Qpoint's semantic tokens (accent, states, type if licensing allows), the logo in the tray and the title. c132 decides how it is prototyped.
• qmap. V1 links to the control plane's qmap (D8, ruled conservative on 2026-11-09: "we can't spike usage"). The shape lays out the trade-offs of each approach (link, webview embed, native render, opt-in local web app) in memory, CPU and what the person loses, so Mark can judge which matter most; creative approaches stay open for later.
• Decisions and questions (below), carried into the document so it travels alone.

3. The pitch (G2)

A short presentation for Tyler's session: the primer's one page, the shape, the c131 spike running, and our V1 as option B. Tyler's own words make the case ("have Claude build one... watch how fast"). Also the progress clip Mark owes Mark Peterson, which can be cut from the same material.

4. Program tracking and close

Key Changes here record each gate, each child's kick-off and close, and roadmap changes from later sessions. The Outcome is written when c131 hands over (G3) or the roadmap changes.

Decisions for Mark (defaults proposed, ruled 2026-11-09)

Questions for Tyler's working session (G2)

• Q1 The names, prepared by c0 in ../qnative for a Mark–Tyler–agent session: the native app; whether "qdash" stays with the web dashboard or moves to the native app (Mark's prompt: "Qdash receives a new native app including the tray"); Qplane as the public name of the control plane (www.qpoint.io already sells it as such); the words for the two roles.
• Q2 The repo: new, or a crate in qcontrol from day one.
• Q3 What the app reads locally: the qdash socket API (/api/*, 38 routes today), the SQLite directly, or both; and which qcontrol crates it links (qtray links qevents, qconfig, qtap).
• Q4 The tray on Windows and Linux: qtray is macOS only today. Does the native app absorb qtray, or does qtray stay and open the app?
• Q5 Notifications: in or out of V1, and if in, which events.
• Q6 The connect flow: the OAuth-style sign-in's shape, the token's home, what the control plane exposes to a connected endpoint.
• Q7 Packaging, signing and updates: notarization, Windows signing, Linux formats, and qupdate for the app.
• Q8 The budget the app must meet (RSS idle, CPU idle, binary size, startup), and how it is measured.
• Q9 Minimum OS versions and the order of platforms (macOS first?).
• Q10 Timeline: when Kamal is free for the control plane, and when the engineers would take V1.
• Q11 Mechanic access (c136): are diagnose · fix · implement · hot-fix the words partners use, and may the Change level need two admins?
• Q12 Messages (c137): which types flow in V1 beyond the Connect confirmations, and does qcontrol send local enforcement notices before any plane exists?

Facts found so far

• GPUI Kit (gpui-kit.com, github.com/longbridge/gpui-kit, docs.rs/gpui-kit): v0.9.1, Longbridge, Apache-2.0, built on Zed's GPUI. "A production-ready Rust UI framework with 75+ components and primitives." Three layers: gpui-component, gpui-base, gpui-shell. Data tables with virtual scrolling, resizable columns, sorting, cell selection; virtualized lists; a rope-backed code editor with Tree-sitter and LSP; dockable panels with serializable layouts; charts; AccessKit roles and actions; headless UI integration tests; wasm32 builds (nightly); update-on-demand rendering. Theming through semantic tokens, many built-in themes. Cargo.toml: gpui-kit = "0.9.1" (optional gpui-fast feature). Skeleton: application().with_assets(assets::Assets), init(cx) before any window, open_window(WindowOptions::default(), cx, …) wraps the view in a Root that hosts dialogs, sheets and notifications. Agent resources: a /skills page per version and /llms-full.txt; design guides and coding guides. No MCP server mentioned. The getting-started page does not cover tray icons, menus or title bars.
• Native Shell (nsh.dev, github.com/longbridge/nsh): "Build once, native everywhere." TSX app code; the reactive graph, renderer, layout and modules in Rust (nsh_core). Targets: macOS AppKit, Linux GTK 4, Windows Win32 / Direct2D, Web, iOS UIKit, Android, TUI (ratatui), GPUI. Embeddable in GPUI Kit apps. nsh init / run / check / test / package / publish; signed .nshpkg runtime modules with capability grants; nsh/base unstyled components. llms.txt. Apache-2.0 code, CC BY 4.0 docs. Tray, notifications and auto-update not mentioned.
• qtray (../qcontrol/crates/qtray): "macOS menu bar library for qcontrol — passive viewer over monitor inventory with click-to-tap." tray-icon 0.24, tao 0.35, objc2-app-kit; links qevents, qconfig, qtap. Files: tray.rs, menu.rs, model.rs, dashboard.rs. macOS only.
• qdash (../qcontrol/crates/qdash): db.rs (SQLite), hub.rs, live.rs, web.rs; 38 /api/* routes including /api/events/stream, /api/inventory, /api/harnesses, /api/mcp-servers, /api/skills, /api/tools, /api/sessions, /api/workspaces, /api/stats, /api/performance. The UI (ui/) is the c99 Fable app with its data-interface bible (ui/docs/data-interface.md): Transport with http() and local(), R13 (every served shape is a type written from the backend handler), R15 (primitives know transport, not resources), R23 (every number served, derived or staged), R25 (staged state swaps transports in one line). ui/LAYER-CANDIDATES.md lists staged library-grade components (→ c135).
• qupdate (../qcontrol/crates/qupdate): "Shared self-update: sidecar check, download, replace."
• app.qpoint.io: Nuxt 4 SPA, Pinia, @qpoint-io/q-nuxt-layer, Firebase 11 (auth + Firestore), Pulse API plugin, auth.global.ts and context.global.ts middleware, layouts default / global / org / session / dev, SAML routes under server/routes/sso/, alerting rules and integrations, wizards (InstallQtap, DeployQproxy, ConnectApp), a dev/ showcase. Last commit 2026-10-27 (layer bump). Pulse's source is not in this tree.
• Design site: /cycles/design/c130/doc/<path> renders a cycle's markdown, so the primer and the shape need no page work.
• strobe (github.com/anomalyco/strobe; Mark, 2026-11-09, "as we are working to keep our footprint small"): "Measure and explain performance: web pages, Electron apps, Bun/Node, any process. Agent-native CLI + MCP." A Rust CLI with an npm package (@hona/strobe), an MCP server and an agent skill; packages for Windows, macOS and Linux. It measures a process's CPU and memory and explains the result, so the budget (c131 R7) is measured by an agent from the spike on. 141 stars, no release yet, licence not shown on the page.
• Qplane is already public. www.qpoint.io/content/products/qplane.md describes "QPlane, QPoint's optional cloud control plane" with a centralised dashboard, and the blog uses the name. The session's nickname is the product's public name; c0 starts from that fact.

Risks

• API churn. GPUI Kit is 0.x; a minor can move the API. Pin, and keep the patterns doc version-stamped.
• "Native" expectations. Stakeholders may expect OS-drawn controls. D2 names the nuance early.
• Platform tray and notification quirks on Linux desktops and Windows. The spike measures before the plan promises.
• Double work. If the engineers build their own app (outcome A), V1's code may be discarded. The spec, the fixture world, the tests and the patterns doc are written to survive that.
• Rust fluency on the design side. Mitigated by the kit's agent resources and by c132 choosing a medium designers can work in.
• Two apps, one brand, two component systems (the layer for the web, the kit for native). c132's token bridge is the seam; c135 keeps the web side honest.

Patterns Mark may not be considering

• The kit's headless tests are "the demo is the test". A stories crate in the c131 repo, one story per page state, run as tests, is the native app's design site.
• wasm as a review medium. If GPUI Kit's wasm build renders our screens, the lab can embed the real native UI in a page, and capture.mts and the review-walk tooling work unchanged. To verify in the primer; a c132 candidate.
• The Transport pattern is already the DataNozzle. Port R13, R15 and R25 as Rust traits; the TypeScript types/api/* become the contract both apps and the control plane agree on.
• Signed runtime modules (gpui-shell, nsh .nshpkg) are a delivery path for HQ notices and remediation trainings without shipping a new binary (→ c133).
• AccessKit comes with the kit; accessibility is a check in c131's definition of done, not a later cycle.
• Install the kit's skills and llms-full.txt into design's .claude/skills before c131 starts, so every executor has the same ground.
• The pipeline map (brand/pipeline.md) gains a stage: the native app as a production target next to app.qpoint.io / qcontrol. Revise it when c131 kicks off.

Clarifying questions for Mark

1. Does D1 hold (c130 = primer + shape, c131 = the build), or do you want the primer as its own cycle so c131 keeps the number you named?
2. Working name and repo for the native app (D4, Q1, Q2): pick one now, or wait for Tyler's session?
3. May c131 Phase 0 (the spike) start while the primer is being written, on the grounds that a running hello app answers platform.md faster than reading?
4. "Live view" in your prompt: qdash's /live activity stream, read as the Events page (D7)?
5. For c133: a sentence each on "hard-hat training" and "Metamythic (previous experience)" so the brief uses your meaning, not a guess.
6. The children have Stage 1 prompts and plans but no CYCLE.md; they get one at their own kick-off (c127 is the precedent). Fine, or write them now?
7. Should market-analyst promote the 2026-11-05 candidate problem (end users experience enforcement as unexplained disruption) so c133 can cite a problem:<id>?

Answers (2026-11-09)

1. Yes: c130 holds the primer and the shape; c131 is the build.
2. A naming cycle, c0 "Call my name", in the native app's own repo, created now at ../qnative (provisional directory name). Mark: place the suggestions and gear it for a shared agent–human session with Tyler. What makes most sense to the customer? How does the name integrate with their cognitive map of the space they govern and the job they undertake? Where can it meld with their existing mental and technological models? Outcome decided in that session.
3. Yes: the spike runs beside the primer, in ../qnative, as a background session.
4. Yes: "Live view" is the Events page's live stream.
5. A note only. Mark has a background in creating training meant to keep people safe and secure; Metamythic is a past venture of his, cited as prior art. c133 references neither beyond that.
6. Write the children's CYCLE.md files now, marked not kicked off. Done for c131–c137.
7. Yes: promoted in market-analyst as problem:enforcement-without-local-context (standing observed, advisor-labelled); c133 and c137 cite it.