Developer Mode

Two developer tools exist today and both leave with the roadmap. The live viewer lives in qdash, which is leaving qcontrol. The monitor TUI lives inside the sensor's own process and only in dev builds. The native app is where a person at the endpoint will look, so both move there, beside the Tools and Components pages it already has.

Some clients will measure what the app costs them in CPU and memory. Mark asked for a way to turn these features off or ship without them, to know what that buys even if it is little, and not to do it at all if it damages the app's structure. He also asked that the pages arrive data-ready, with instruction pages clear enough that Kamal can hook them to a sensor on his own machine.

Sketch: Developer mode and its gates, drawn 2026-11-11 in the design system; Mark's own drawings may replace it.

Done means:

• The gate: readings for the lean build and the full build in four states; the extension seam passing its four-line burden test, or the switch-only fallback taken and said; the decision written up for a Rust expert's review.
• The Guide: seven pages Kamal can act on, in the app, the repository and on this site.
• Sensor: both sources and every synthetic scenario selectable while the app runs; the attach ladder drawn rung by rung; a doctor on the command line.
• Live: parity with qdash /live on the sensor's current event schema, plus seven improvements; its cost under a stream known.
• Events: Mark's design of the curated page, built on the same stream.
• Monitor: the TUI's seven tabs answerable in the app on synthetic data, with honest gaps on a real sensor until its feeds exist.
• Config: three modes (Manual, Qplane, Endpoint) that each lead somewhere honest.
• Hand-off: a session on Kamal's machine with Live and Events on his sensor.

• Cycle docs: cycles/c138.developer-mode/ (plan.md with the rulings, initial-prompt.md, research/ with the two code surveys)
• Design site: the sketch, the story, the Events brief and mock when Phase 4 comes
• Sister projects: ../qnative c3 (a new devmode crate, the stream core in nozzle and types, the Guide); ../qcontrol is read, never changed
• Out: any change to qcontrol (the feeds are asked for); the real plane credential exchange (c131 D13, c134); V1's Status and Connect pages; following a config address over time

• stage 1 (2026-11-11): created from Mark's three messages. The plan was written from two code surveys (qdash's Live Activity page and its backend; Kamal's monitor TUI on qcontrol main) and qnative's measured budget, first as a thread of c131.
• the walk (2026-11-11): nine calls ruled by Mark, recorded in plan.md § Rulings: switch plus lean build, for a Rust expert's review; build both Live and a curated Events page; the plane is not a data choice, attach takes this machine or an address; Endpoint config is a starter fetched once; the TUI homage is console only; Sensor and Config are two Dev pages; a private repository for Kamal; allowed versus on; its own design cycle.
• kick-off (2026-11-11): this record, the sketch and the story; the plan aligned with c131 D15–D17, ruled the same day in another session (worlds and the drill, the settings switch, endpoint shapes as typed qdash routes); ../qnative c3 opened with the Guide v0, seven pages as proposals. No code yet. c2's Tour stretch committed the same day (qnative 9d37433), so Phase 0 is clear to start.
• research filed (2026-11-11): the two code surveys behind the plan kept as research/live-viewer.md and research/monitor-tui.md, with an index: the full inventories, contracts and file references the Live, Events and Monitor phases start from. Each is a reading at one commit (qcontrol main 9e6cd55a0; the UI on feat/new-pages 28182424c).
• records brought in line (2026-11-11): c131's D6 and R2 and c130's D6 and D7 carry the amendments from rulings 2 and 3; c138 is listed among c130's children (its plan, its record, CYCLES.md) and in CLAUDE.md; c134's kamal-prep.md has a dated note that the Guide answers the second half of its question 6 and is the thing to send ahead of the call. Left as it was: the c130 program map sketch, which still shows eight cycles.
• Phase 0, measure and seam (2026-11-11), at review stop 0: built in ../qnative c3, commit 2f66b4b (local; no remote). Write-up: ../qnative/cycles/c3.developer-mode/review-0.md.
  • Developer mode moved out of the app into crates/devmode, an extension the app does not know about. It is carried only with --features dev, through one cfg in main.rs, and the default build is lean.
  • Allowed versus on: the toggle is in the tray menu and remembered in a settings file.
  • Read on an idle Mac: lean 23.2 MB against full 24.3 MB. At rest, 60–63 MB in every state with no Dev page shown, at 0.002–0.006% of a core. The Components page shown reads 65 MB.
  • The burden test passes on all four lines (CI not yet run), so B holds as ruled.
  • Ten open calls wait for Mark, the toggle's seat among them, plus eight questions for the Rust expert.
• 2026-11-11, night: Mark: move through the blockers; Phases 1, 2 and 3 run in sequence without waiting at the review stops, the calls collected at the end of Phase 3; the data shapes modelled from qcontrol's Live page and its backend as the contract, guesses marked, the asks of the sensor recorded rather than waited on. The page is named Live Activity, and its document (the Guide's page 03) covers the connection methods, the data modelling, the pipeline, the states and the asks end to end. Review stop 0's ten calls taken by their recommended defaults until overturned. Sent to the qnative c3 session.
• Review stop 0 closed (2026-11-11): calls 1–4 as Mark walked them, 5–10 by their recommended answers per the night ruling, recorded in review-0.md § Rulings. A cargo dev alias; the idle-Mac rule is in the README recipe. Five captures published as thread p0-seam (lean, turned off, Dev Tools, Components, off-redirect). Phases 1–3 run in ../qnative-c3 on branch c3/phases, beside c4 and c5 in the main checkout.
• 2026-11-11, night, the repository: ruling 7's open item closed: on Mark's word the program session created the private repository qpoint-io/qnative (the name provisional, renamed when c0 rules; GitHub redirects) and pushed main. Kamal's access is an invitation away; the c1 spike's three-OS CI workflow runs on push from here. Pushes are fast-forward only, by the session that committed, never forced.
• Phase 1, the stream core (2026-11-11): built in qnative c3 (2c01ebf, on main). It has six parts:
  • subscribe on the nozzle: SSE straight to /api/events/stream, the web's reconnect schedule, 403 and 503 as honest Refused states, and a dropped page closing its socket within 250 ms.
  • The scenario model: world, condition and stream.
  • The envelope and the four Monitor shapes as TypeScript beside the Guide, generated into Rust. Each field is marked read from qcontrol code or proposed.
  • Four seeded stream scripts written to qevents' payloads as read from code.
  • A new stream crate whose ingest agrees with qdash's own TypeScript on all 615 cross-language vectors.
  • Guide page 3 rewritten as the Live Activity document: connection methods, the ladder, the data (read or guessed), the pipeline, the states, and six asks of the sensor.
  
  The Dev page that switches the source will be named Source, since c5's V1 Sensor page now sits under This machine. That goes to the calls at review-3.
• Phase 2, Source (2026-11-11): built in qnative c3 (6a8999e, on main).
  • Dev › Source offers synthetic data (a world, six conditions drawn through the real pipes, four streams at their rate or 10, 100 or 1,000 a second) or a real sensor on this machine or at an address. A choice applies at once and is saved; a flag or the environment wins at the next start.
  • The ladder has six rungs, tested against fake sensors.
  • The doctor, app --check-sensor, run for real: it found this Mac's stale lock, and it got the seed qdash serve refused with qdash's own 503.
  • The macOS data dir is fixed.
  • The Rust expert's question 2 is answered with a host crate: the data handle, reopen and the saved values, shared by the app and developer mode.
  • Six captures published as thread p2-source.
• Phase 3, Live Activity (2026-11-11): built in qnative c3 (9d265fb, on main at 5337c28, rebased onto c4's and c5's work).
  • Dev › Live Activity is qdash's /live on the sensor's current envelope, with the seven improvements: a real pause, honest states, a bounded buffer, a tally that works on today's stream, filters with search over the whole record, keys, and masking before anything is shown or copied.
  • The ports held to qdash by test: five of qdash's lib/live modules are ported to Rust (previews, presence, the tally, entity-meta and the projections). Each agrees with qdash's own TypeScript on cross-language vectors that regenerate byte-identical.
  • The readings under a stream, with the Mac idle and unlocked:
    • As first built, the page cost 28–34% of a core at 100 and 1,000 events a second, nearly all of it main-thread drawing at about 10 ms per redraw.
    • Leaving the page returns the app to rest: 0.003%, and its threads back to 6.
    • The stream core alone costs 0.6–7% of a core.
    • The page now redraws at most 4 times a second, the monitor TUI's cadence; its readings were taken on 2026-11-13, below. The recipe is now a script, scripts/footprint/.
  • CI: Linux and Windows had failed on the stories crate. c5's cloud session fixed the cause in the crate's manifest (3725719; run 17 green on all three systems). It came into c3 by merge. c5 pushed main on Mark's word (4ccf511), and the program session pushed c6's merge (8242467). Phase 3's first CI run failed on Windows in the projections vectors, where the corpus was read as CRLF. That is fixed in qnative 948a9b5, which was pushed and is confirmed green on Windows (run 43142674204).
  • Seven captures published as thread p3-live.
• Review stop 3 (2026-11-11): ../qnative/cycles/c3.developer-mode/review-3.md collects fourteen calls for Mark (the fourteenth, the lean check after c6's merge, ruled (b) as ruling 10, built by c6 as qpoint-io/qnative#2, reviewed by c3, merged by Mark as 2c435e4, CI green on all three systems). They include the push (c4's push of main carried Phases 1 and 2 to qpoint-io/qnative; this session's commits are local), names, retention, masking, the doctor in the lean build, the 4.54 MB on disk, the redraw rate and its owed readings, and what comes next (Phase 4 needs a brief and a mock).
• the footprint page (2026-11-12): every strobe reading of the native app, from the c1 spike through Phase 0's four states, Phase 3 under a stream, c4 and c5, drawn on one page for the team and for the Rust expert's review of the gate (ruling 1): Native App Footprint. Sources: qnative's README § Footprint and the write-ups it points to. In order:
  • The gate: the lean build saves 1,072,560 bytes (4.4%); at rest, the quiet readings of every state with no Dev page shown are 60.3–63.0 MB, inside the launch-to-launch spread; showing Components costs about 3.5–4 MB. Both readings per state are drawn. Review stop 0's verdict beside it, and developer mode on disk since: 4.54 MB at review stop 3.
  • Over time: the binary by build and memory at rest by session, c1 to c5, against the 80 MB window target (c131 D22).
  • c2's page walk: 62 → 116 MB, then 125, 127, 125, 129, a cache filling once; c5's after-walk readings beside it.
  • At rest: CPU on the scale of one core and wakes from zero. c4's and c5's readings are drawn apart, as read on a Mac in use, and Status at rest is marked open: an idle reading is owed.
  • Under a stream (Phase 3): 33.9% of a core at 1,000 a second as first built, nearly all of it drawing; the stream core alone 7.05%; 0.003% on leaving the page. The readings at 4 redraws a second were added on 2026-11-13, below.
  • Method and caveats: the working targets, the readings owed, the records' marks, the discarded readings, and every value in a table with its recording.
  • Built from the layer (DataMachine, DataSegmentBar, DataRankedBars, UxPercentBar) plus one local piece, FootprintDotStrip, that keeps every reading visible on a shared axis (moved into the layer as DataDotStrip on 2026-11-13, below). The readings are in app/data/footprint-c138.ts; captures c138-footprint* (thread footprint, program scripts/shot-programs/c138-footprint.json).
• the Monitor's shapes reconciled (2026-11-12, c143): the Guide had asked for richer copies of three of c131 D17's shapes, plus health and the loaded targets beside shapes D17 already has. Now one ask per route: the Monitor's fields ride on /api/sensor (the pid, a row per process with 1 Hz samples, health and the last error, the log's target and sequence) and /api/config (targets, behaviors, includes), all optional, in the bridge's types.ts and qnative's bridge.rs; its own routes drop from four to two (/api/monitor/workers, /api/monitor/processes). V1's Sensor page and the bridge files are unchanged. Recorded in qnative c3's Key Changes and Guide pages 3 and 4.
• Live Activity against main (2026-11-12, planned): Mark asked for a more faithful copy of the live qcontrol app's viewer (his screenshot: the Audit log tab). The native page's parity vectors came from the feat/new-pages checkout, which branched before main added the Audit log (#757) and Sentinel (#772, #787, #835), so the native page has no Audit log and drops Sentinel's fields. The plan re-anchors the vectors on main, ports the audit projection with a buffer of its own, builds the tab, and brings the shared regions back to main's layout while keeping the seven improvements. Seven calls are open before Phase 3. live-parity-plan.md, with the prompt. Nothing is built.
• The Fable /live gets main's Audit log (2026-11-12, qcontrol d274b9306, pushed 2026-11-13 to feat/new-pages, so PR #713 carries it): the same gap closed in qdash's Fable app on feat/new-pages, so PR #713 does not drop it on merge. Main's #757 is carried as a unit: the audit projection, the second buffer with its own budget and storage key, the data plugin preview, the third tab, the audit columns, categories-only filters, the tab-switch reset, follow-on-select, and the narrow-width detail overlay. It is fitted into the Fable split files, so the rows arrive display-ready (R8). Before and after captures and the Sentinel fixture are in fable-audit/. Results: 658/658 specs and npm run check clean.
• The native firehose in main's grammar (2026-11-13, qnative f19e679, pushed): Mark said the qdash firehose is "cleaner, better color coding, filtering". So the native Events view now follows main's /live, compared on one corpus with main running from ../qcontrol-main on :3031. It has family-coloured chips, 44 px zebra rows, mono key=value summaries, a column header, and main's filter card with chip rails in place of the left rail. The c138 improvements are kept. The rest of Phase 3 is listed in live-parity-plan.md (§ 2026-11-13), with captures in live-firehose/. Tests: 221/0.
• Phase 6 (Config) moved to c146 (2026-11-13): Mark asked for the Config page again, adding an editor in Manual mode and an agent that writes the file over MCP. c146 inherits ruling 4 and the Guide's page 05. Mark ruled the same day that Config is a V1 page under This machine, not a Dev page (c146 R3), which overrules ruling 6 for Config.
• DataDotStrip into the layer (2026-11-13): the footprint page's local chart moved into q-nuxt-layer as DataDotStrip (v0.9.39), per the unified pantry. The page's domain words became shapes (dot, ring, diamond, square, keyed by the legend; each mark's own tip says what it means on that chart); the row grid is scoped CSS, so its prop-driven columns reach every consumer. Documented at /components/data/data-dot-strip with c138 Phase 0's readings as the typical case, plus empty, minimal, a whole and overflow; captured as c138-data-dot-strip (program scripts/shot-programs/c138-data-dot-strip.json). The page's six captures are pixel-identical before and after the move.
• Layer v0.9.39 released and the branch merged (2026-11-13): the cloud session had committed v0.9.39 to the layer's main (1cdea10) but never tagged it, so nothing was published, and its design branch (claude/sleepy-maxwell-miy81p) needed that version.
  • Tagged and published: run 43486999837. The branch lockfile's integrity matches the registry's.
  • Merged into design main as ccc3a2c9dc, both commits on Mark's word: DataDotStrip, and the top nav's phone-width Menu.
  • Both pages render.
  • Other sessions' uncommitted entries in the atlas manifest were kept by a three-way merge.
• Live Activity at 4 redraws a second (2026-11-13, review stop 3, call 12): the readings owed since review stop 3.
  • Taken on: the full release build of qnative d3de579, qnative main that day, with the firehose restyled (f19e679). The script was scripts/footprint/live-activity.sh, wrapped in caffeinate -d because the screensaver locks the Mac after 10 idle minutes. One reading was touched and retaken.
  • Readings: 7.85% and 11.1% of a core at 100 and 1,000 a second, from 27.9% and 33.9%; 8.90% at 10 a second; 0.003% once the page is left. Memory is 105–120 MB with the page open, 73.5 MB at rest. There are 12 threads at rest and 14 with the page open.
  • What a redraw costs: at least 18–22 ms of main thread, against about 10 ms on Phase 3's page. The page drawn has changed since.
  • The record: the qnative branch c3/4hz-readings (3ffa9f4) holds review-3, Guide 07, the README and c3's record, and the CYCLES line now counts fourteen calls; it goes in as a PR on Mark's word. The footprint page draws the readings as a third group under the stream and as two rows at rest, and the readings owed lose that line.

Documents: the plan · Mark's prompt · the research: the live viewer · the monitor TUI · index · the Guide for Kamal: what developer mode is · run it on your machine · Live and Events, the contract · Monitor, the contract · Config, three modes · synthetic scenarios · footprint

Drawn as Developer mode and its gates on 2026-11-11; the record behind it is plan.md.

The problem. The two tools a developer uses to see the sensor work are leaving or locked inside it, and the app that should carry them must cost a measuring customer nothing they did not ask for. Half of what the TUI shows has no surface outside the sensor's process, so the pages cannot simply be pointed at a sensor; the feed has to be asked for.

The core idea. One stream, two altitudes: Live shows it raw, Events gives it meaning. Developer mode is an extension the app does not know about, so it can be absent from a build. Two questions are kept apart: is developer mode allowed here (the build, a flag), and is it on (the person's toggle). A feed exists only while its page is open.

The pieces. Seven Dev pages: Tools, Sensor, Config, Components, Live, Monitor, Guide. Events, an ordinary page. The nozzle gains subscribe for streams beside fetch. Two sources on the Sensor page: synthetic (a world, a condition, a stream) and the sensor (this machine or an address), with a validation ladder from not found to streaming. A devmode crate behind one Cargo feature. The Guide: seven pages and ten questions for Kamal.

The pattern we follow. Modularity is purpose plus protocol: developer mode's purpose is to see the sensor work, its protocol is a list of pages the shell can draw, and its internals are free, including whether they exist. Replicate first, optimize later: both tools are ported as they are, on the current schema, before the improvements. The demo is the test: every page state is a story, and every error is a condition applied to synthetic data through the real pipes.

What stays open. The Rust expert's review of the gate (ruling 1). Who creates the private repository and pushes (ruling 7). The Events design, which is Mark's. Where the toggle sits when the Dev group is hidden. Whether a company's config may forbid developer mode. And Kamal's ten questions, first among them whether the sensor will serve the Monitor's shapes.