Developer Mode
Next: Mark walks review stop 3's thirteen calls (qnative c3 review-3.md) and takes the 4-a-second readings of Live Activity; then Phase 4, Events, which needs his brief and mock first, and Phase 5, the Monitor, on the reconciled shapes. Still to be said: who gives the gate its expert review.
The two tools our engineers use to watch the sensor are losing their home, and customers who measure every megabyte must not pay for them.
A plan and nine rulings, then the first four phases built: the locks, the stream underneath, a page that picks fake or real data, and the live list itself, held to the web version by shared tests. The guide for hooking up a real sensor now asks for each thing once.
Documents
With file names, on their own page →What changed
The two changes that matter most, in plain words. Open any one to see it.
- 1
One picture shows what can be hooked up today, what has to be asked for, and the three locks that keep the tools from costing anyone who does not use them.
Developer mode and its gates · came from Mark Parson and Kamal Nasseropen →
- 2
The live list runs inside the desktop app, agrees with the web version by test, and costs nothing once its page is closed.
Phases 0–3 built: the gate, the stream, Source, Live Activity · came from Mark Parsonopen →
- Every open choice was put to Mark one at a time, and his answers are written into the plan where they apply. In words
- What the app will ask of the sensor is written down once, so its engineer answers one list. In words
- We read both tools before promising to copy them: one can be hooked up today, the other needs the sensor to serve more. In words
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.
From the record: no recorded conversation behind this one.
c138-D1 The gate is a runtime switch plus a lean build with no developer code. In his words: "switch + lean build seems right to me, but let's document as an un-informed decisions for a rust expert to be sure to review in case they want to follow a different course for other reasons." — Mark Parson
c138-D2 Two pages on one stream. "Let's build both. The firehose live view is nice to have and arguably is also impressive to the non dev user. But the quieter / curated events page is still relevant and provides a layer of filtering and meaning on top of the same underlying firehose event stream. This page is a layer of abstraction and meaning." — Mark Parson
c138-D3 The plane is not a data choice on the Sensor page. "At this level, the user is only choosing between the real sensor and fake data. I don't see any benefit or logic in connecting to a plane source of the data." Attach takes the sensor on this machine, or an address through a tunnel. — Mark Parson
c138-D6 Sensor and Config are two separate pages in the Dev group, which makes seven. Config is built so it can become V1's Config page. — Mark Parson
c138-D8 Allowed and on are two questions. "All of the above. If dev settings are not allowed, no presence is seen. If dev settings are allowed, the user can still toggle off." — Mark Parson
One picture shows what can be hooked up today, what has to be asked for, and the three locks that keep the tools from costing anyone who does not use them.
From the record: no recorded conversation behind this one.
c138-D1 The gate is a runtime switch plus a lean build with no developer code. In his words: "switch + lean build seems right to me, but let's document as an un-informed decisions for a rust expert to be sure to review in case they want to follow a different course for other reasons." — Mark Parson
c138-D2 Two pages on one stream. "Let's build both. The firehose live view is nice to have and arguably is also impressive to the non dev user. But the quieter / curated events page is still relevant and provides a layer of filtering and meaning on top of the same underlying firehose event stream. This page is a layer of abstraction and meaning." — Mark Parson
c138-D3 The plane is not a data choice on the Sensor page. "At this level, the user is only choosing between the real sensor and fake data. I don't see any benefit or logic in connecting to a plane source of the data." Attach takes the sensor on this machine, or an address through a tunnel. — Mark Parson
c138-D8 Allowed and on are two questions. "All of the above. If dev settings are not allowed, no presence is seen. If dev settings are allowed, the user can still toggle off." — Mark Parson
The live list runs inside the desktop app, agrees with the web version by test, and costs nothing once its page is closed.
Thanks to
People outside Qpoint first. Every thank-you points at something they said or made.
Built the monitor TUI this cycle replicates
The terminal monitor in qcontrol (`qcontrol start --tui`, qcontrol #782, 2026-10-16): seven tabs over the monitor's own state, behind a build feature so a release sensor pays nothing. Its split, its cross-links and its keys are the model for the native Monitor, and its gate is the pattern for ours. The Guide is written for him, and the feed the Monitor needs is his to shape.
Set the objective and ruled the nine calls
Asked for the live viewer and the TUI in the native app as a developer mode that can be switched off or left out, with the cost understood; added the Sensor and Config pages and the hidden homage; then walked the nine calls on 2026-11-11, keeping the curated Events page beside the firehose and taking the plane off the data choice.
All images
Every picture from this cycle. Click any one to step through them all.
The pairs
Everything captured · 3
The full record 9 decisions · 15 key-change entries · 2,860 words · 3 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 c138 →