research/README.md

c138 research: the two tools being replicated

Contents

What they were read from
How far to trust them
What the plan took from them

Two surveys of the code, made on 2026-11-11 for this cycle's plan. Each is a reading at one commit, kept so the Live, Events and Monitor phases start from it instead of reading the code again.

File	What it holds	Feeds
live-viewer.md	qdash's Live Activity page region by region; the stream contract; the event envelope and families; the client pipeline and its costs; the drift between the web page and the sensor's current schema; seventeen weaknesses, ranked; which modules port to Rust	Phase 3 (Live), Phase 4 (Events), Guide page 3
monitor-tui.md	Kamal's monitor TUI tab by tab; where every number comes from; what another process can and cannot read today; the `tui` feature gate; what to keep, drop and improve	Phase 5 (Monitor), Guide page 4

What they were read from

The live viewer's UI: ../qcontrol/crates/qdash/ui/app/ on feat/new-pages (28182424c).
The backend and the TUI: qcontrol origin/main at 9e6cd55a0 (2026-11-10). The TUI is on main only; the local qcontrol checkout sits on feat/new-pages and does not have it.

To read main again without touching the checkout, extract it somewhere scratch:

git -C ../qcontrol fetch origin
git -C ../qcontrol archive origin/main cli crates/qdash/src crates/qevents crates/qmonitor crates/qconfig docs/plan/2026-10-12-monitor-tui | tar -x -C <a scratch folder>

How far to trust them

Line numbers are as of those commits and will drift.
Statements marked (inferred) were not confirmed in code.
The backend snapshot the surveys read did not include qsinks, qconfig, qprocess or qinject. Two facts were checked against main afterwards and are noted at the top of each file: the TUI's origin (qcontrol #782), and the data directory on macOS.
Checked later, while writing the Guide: crates/qconfig loads no configuration from a URL, and ui.dashboard absent means the dashboard is on.

What the plan took from them

The TUI is the monitor process: half of what it shows has no surface outside it. The pages are ours to build; the feed is asked of the sensor's engineer.
The TUI's Events tab and the live viewer read one stream, so that viewer is built once.
The web live viewer has drifted from the sensor's current event schema; the native port is written against the current one.
A subscriber costs the sensor a re-scan on every connect, and reading the dashboard's API means its SQLite projection is on.