Native App V1
Next: Phase 2 is complete (qnative c2 closed 2026-11-11). The V1 build starts from c130's shape.md and c0's name; the violation tour comes with qnative c4 (c137 Phase 3), the Status page with c132 Phase 4, D17's routes with engineering (c134).
The small program that watches a computer's AI traffic could not carry the web dashboard without getting heavy.
A small desktop app will show what was found on this machine; a first test version runs on a Mac with very little memory, and the second phase shows it can look and read like our web pages.
Documents
With file names, on their own page →Start here
Threads
What changed
The 10 changes that matter most, in plain words. Open any one to see it.
- 1
The app has five screens and a menu-bar icon; on its own it lets you edit, connected to head office it only shows.
The app map and its two states · came from Tyler Flint, Rob Genova and othersopen →
- 2
Our building blocks now exist natively, and a scorecard says how close each came and what stood in.
Our layer in Rust · came from Mark Parsonopen →
- 3
The first pages of the section run natively and read like the web pages, translated to one machine.
Harnesses and the merged harness page · came from Mark Parsonopen →
- 4
The whole Inventory section runs natively on one person's laptop, beside the web page it came from.
Repos & Workspaces: the Inventory section complete · came from Mark Parsonopen →
- 5
The evidence for the brand ruling: our look comes from a drawn layer, not the kit's components, and costs little at rest.
How close we got: the scorecard and the budget · came from Mark Parsonopen →
- 6
The tour layer's three DOM habits (find by attribute, restyle from outside, Floating UI) all have native answers, and none needed the page to change beyond an id.
The tour, native: What's on this machine · came from Mark Parsonopen →
- 7
The guide no longer needs the dev server and a browser tab: the app is the page.
The MCP guide drives the native app · came from Mark Parsonopen →
- 8
Both review stops cleared and built the same evening, on a branch beside developer mode and merged onto its seam.
Mark's rulings on both review stops, built · came from Mark Parsonopen →
- 9
The check the lab set for its own guide holds for the native app; Phase 2 is complete.
Claude Code walks the native app from one prompt · came from Mark Parsonopen →
- 10
A first small version runs on a Mac, uses very little memory and power, and its menu-bar icon works.
The spike: every platform question answered · came from Mark Parsonopen →
- One switch chooses where the numbers come from: made-up data, this machine, or head office. The screens never know. New in this cycle
- The native app now wears our colours and type, made from the same source as the web pages. Before → after
- Every component can be tried in the app itself, each case at a glance, the way the design site documents the web ones. New in this cycle
- The evidence for the brand ruling is written down component by component. New in this cycle
- The page shows what each harness touches, the same way the web page does. New in this cycle
- Who receives this machine's prompts, and through which of your accounts. New in this cycle
- Which models this machine uses, and which harnesses default to each. New in this cycle
- Which MCP servers this machine reaches, which harnesses register them, and which call them without config. New in this cycle
- A table row can open in place to show what it carried, as on the web, and stays open when the list moves. New in this cycle
- You can read a skill the way the harness reads it, and see when two copies disagree. New in this cycle
How we got here
Each change, traced back to the conversation it came from. A solid mark means the record names the source; a dashed one was matched by the draft and waits for review.
“If the local queue control can give end user feedback about. So, like, when policies are enforced, so it's just not, like, such a complete whiplash in vacuum of information, that. I think that would be actually really useful.”
market-analyst /calls/1b21a3ce… (local)“that's the plan is we basically just build a localized version that they could pop open and they could see a a localized version of the inventory.”
market-analyst /calls/1b21a3ce… (local)c131-D6 Five pages in the order they are built: Status, Inventory, Events, Config, Connect, with a review stop after each. "Live view" is Events' live stream. Default; to rule at kick-off. — Mark Parson
c131-D7 The tray is absorbed into the app process: one binary, tray-only mode when the window is closed, qtray's model and menu ported. The fallback (qtray stays and opens the app) is not needed on macOS; the spike proved the two loops coexist. — Mark Parson
c131-D8 The message channel's ports and bones ship in V1 (c137 designs them): the schema in types, the inbox store, the OS notification plumbing with per-type controls, the tray count. Only Connect confirmations flow in V1; more is Tyler's at G2. — Mark Parson
c131-D12 When a mechanic-access grant (c136) is active on the plane this endpoint reports to, Status shows one line; otherwise nothing. Read-only here. — Mark Parson
c131-D13 The plane connection is a base URL, the standardised credential, how the app finds its plane (configuration, Connect, a deep link) and what is read-only when connected. Specified with c134; the words come from c0. — Mark Parson
The app has five screens and a menu-bar icon; on its own it lets you edit, connected to head office it only shows.
From the record: no recorded conversation behind this one.
c131-P2-Q1 Phase 2: our layer in Rust. crates/layer carries the web components' names on top of the kit and draws where the kit has nothing; c130 D5 and c131 R8 hold for V1 until the scorecard is ruled on. — Mark Parson
Our building blocks now exist natively, and a scorecard says how close each came and what stood in.
From the record: no recorded conversation behind this one.
c131-P2-Q2 Phase 2: translate fleet to personal by six rules (activity carries; counts become here; people and places leave the rows; drift moves inward; served-but-hidden fields come forward; nothing blanked), with Harness detail and Harness install detail as one page. — Mark Parson
c131-P2-Q4 Phase 2 review: three stops in the core (the skin; Harnesses beside the web; the section with the scorecard), one after each stretch; commits on Mark's word. — Mark Parson
The first pages of the section run natively and read like the web pages, translated to one machine.
From the record: no recorded conversation behind this one.
c131-P2-Q2 Phase 2: translate fleet to personal by six rules (activity carries; counts become here; people and places leave the rows; drift moves inward; served-but-hidden fields come forward; nothing blanked), with Harness detail and Harness install detail as one page. — Mark Parson
The whole Inventory section runs natively on one person's laptop, beside the web page it came from.
From the record: no recorded conversation behind this one.
c131-P2-Q2 Phase 2: translate fleet to personal by six rules (activity carries; counts become here; people and places leave the rows; drift moves inward; served-but-hidden fields come forward; nothing blanked), with Harness detail and Harness install detail as one page. — Mark Parson
The evidence for the brand ruling: our look comes from a drawn layer, not the kit's components, and costs little at rest.
From the record: no recorded conversation behind this one.
c131-P2-Q3 Phase 2 stretch: the Tour guide with Info View and the qpoint-guide MCP driving the native app, not optional within the stretch. — Mark Parson
The tour layer's three DOM habits (find by attribute, restyle from outside, Floating UI) all have native answers, and none needed the page to change beyond an id.
From the record: no recorded conversation behind this one.
c131-P2-Q3 Phase 2 stretch: the Tour guide with Info View and the qpoint-guide MCP driving the native app, not optional within the stretch. — Mark Parson
The guide no longer needs the dev server and a browser tab: the app is the page.
From the record: no recorded conversation behind this one.
c131-P2-Q3 Phase 2 stretch: the Tour guide with Info View and the qpoint-guide MCP driving the native app, not optional within the stretch. — Mark Parson
Both review stops cleared and built the same evening, on a branch beside developer mode and merged onto its seam.
From the record: no recorded conversation behind this one.
c131-P2-Q3 Phase 2 stretch: the Tour guide with Info View and the qpoint-guide MCP driving the native app, not optional within the stretch. — Mark Parson
The check the lab set for its own guide holds for the native app; Phase 2 is complete.
“we could potentially have this be our first release with the local the the local desktop... and then we roll out Qplane, manage your fleets.”
market-analyst /calls/1b21a3ce… (local)“it's less than 1% of the CPU core, and it's less than 30 megabytes of RAM, and we had to turn off the dashboard to do that.”
market-analyst /calls/1b21a3ce… (local)c131-D7 The tray is absorbed into the app process: one binary, tray-only mode when the window is closed, qtray's model and menu ported. The fallback (qtray stays and opens the app) is not needed on macOS; the spike proved the two loops coexist. — Mark Parson
c131-D14 Inter for the UI and Geist Mono for code, bundled under the SIL OFL, not the system font. Noted for the degrees of expression the brand type gives us. — Mark Parson
c131-R7 The budget is measured, not promised: RSS idle, CPU idle, startup and binary size recorded per release with strobe, so an agent can reproduce the figures. — Mark Parson
A first small version runs on a Mac, uses very little memory and power, and its menu-bar icon works.
Thanks to
People outside Qpoint first. Every thank-you points at something they said or made.
Asked for local feedback when a policy is enforced
Wanted the person at the keyboard told, locally, when qcontrol enforces a policy, so enforcement is not unexplained disruption. The message channel's ports and bones ship in V1 because of it; the design is c137's.
“If the local queue control can give end user feedback about. So, like, when policies are enforced, so it's just not, like, such a complete whiplash in vacuum of information, that. I think that would be actually really useful.” first-hand
Moved the UI out of the sensor and put the app first
Decided to decouple the UI from qcontrol and build a native app on GPUI, with the app plus the tray as the first shippable release; sketched the local inventory, the diagnostics and the config that goes read-only once connected; proposed the OAuth-style connect flow.
“that's the plan is we basically just build a localized version that they could pop open and they could see a a localized version of the inventory.” internal
Put MCP servers and skills on the inventory
Asked for the MCP servers and skills found on an agent to be listed in the desktop app, which is where the Inventory page starts.
“Even the MCP server skills. Things like that. It might be good to just list them up.” internal
Ruled three sources and the spike; asked for the second phase
Walked c130's decisions on 2026-11-09: three data sources instead of two, the message plumbing in V1, the repo at ../qnative, the budget measured with strobe, Inter bundled; let the spike run beside the primer. On 2026-11-10 called the spike a success and asked for a second phase to see how close the kit gets to our web pages, answered its four questions, and asked mid-phase for a draggable title bar, a Dev section and native component docs with every scenario live.
All images
Every picture from this cycle. Click any one to step through them all.
The pairs
Everything captured · 21
The full record 19 decisions · 13 key-change entries · 2,284 words · 20 captures
The record stays as written, for agents and for audit: Key Changes, every decision, the artifacts and the visual record.
Open the record for c131 →