← Design · c132

status-brief.md

Status: the brief (c132 Phase 4, 2026-11-11)

Step 1 of the loop (process.md): the page, its states and the world each state lives in. Reader: Mark (the rulings below), the c2 session in ../qnative (the push), the designer who mocks the next page. Rests on: c131's page table (Status reads /api/stats, /api/performance, qcontrol's logs and the effective config; on / off, local / connected, CPU and RAM, workers, plugins; states off · starting · on-local · on-connected · degraded), c131 D12 (the grant line), D13 (the plane connection), D17 (the six endpoint-only shapes become qdash routes), the app map's two sentences (local: "This machine runs on its own. The configuration lives here and you can change it. Here is what was found."; connected: "You're connected to HQ. The configuration is managed there. Here is what was found on this machine."), c138 (Live and the Sensor page are developer mode's; V1's Status stays here).

The page

Status is the first page and the tray's long form: is qcontrol on, what is it reading, what has it found. Three bands, top to bottom:

  1. The sensor. One line that says the state in words, then the facts: the process (version, build, uptime, workers, CPU and RSS), where it reads (this machine; the plane when connected: base URL, last sync), the configuration (file found or not, mode, which source won). The sentence is R4's: nothing alarming; the app says which state it is in. The grant line (D12) sits under it when a mechanic-access grant is active, else nothing.
  2. What it has found. The activity on this machine as the sensor counts it: sessions and agents, events, tokens and spend today and in all, the harnesses here and whether each is monitored, the oldest event (how far back the record goes), the database's size. The coverage counters (adapter errors, injection failures, uninspectable connections) are the honest part of "found": what the sensor could not see.
  3. The log tail. The last lines qcontrol wrote, as text; developer mode (c138) holds the full viewer.

States, and the world each lives in

StateWhat the page saysWhere its data comes from today
off"qcontrol is not running on this machine." The last activity it recorded stays visible, dimmed.process state: none served (D17)
starting"qcontrol is starting." The facts fill in as they arrive.process state: none served
on-localthe local sentence; the sensor's facts; the activity/api/stats, /api/endpoints?host=, /api/installations, /api/agents in every world; the sensor's facts: none served
on-connectedthe connected sentence; the plane's base URL and last sync; Config read-only elsewherethe source (plane); the plane facts: none served (D13)
degraded"qcontrol is on, but part of what runs here is out of its sight." The coverage counters name it./api/stats coverage: pilot has 5 injection failures and 3 uninspectable connections; meridian-day90 2 uninspectable; minimal and fresh none

The clock (c5, review stop 2): the app shifts a synthetic world's dates to today and says so in the footer; the stories freeze it, so captures and the lab's mocks read the world's own dates and agree (D6).

The honesty rule, confirmed 2026-11-11 (late evening): "not served yet, naming its route" is a row's state only when neither a route nor a bridge answers (a local qcontrol today); on the synthetic worlds the D10 bridge fills the rows and the footer says sensor: bridge. The page never fakes a fact and always says where one came from.

The fork. The sensor's own facts (SensorState, Resources, EffectiveConfig, LogLine, PlaneConnection) are served by no route and carried by no world: c131 D17 ruled they become qdash routes typed and generated like the rest, and the ask is with qcontrol engineering through c134. Under D6 the mock may not invent them. So the mock draws the second band from the worlds, says the first band's facts are not served yet (naming the routes), and takes the state (off, starting, on, connected) from a lab knob, which is a page state and not a row; degraded it derives from the coverage counters. When the routes land, a world is cut per state (synthetic-data.md §Scenarios: connected, broken-config, plane-down) and the knob goes.

Rulings to walk (defaults taken, Mark overrides)

Ruled 2026-11-11, late evening (c131 D21, relayed by the c130 session). S1: Status is the landing; the app opens on it; the overview's twenty micros move onto Status below the state line and the found-here set, and Inventory keeps its own index; the rail gets a "This machine" group (working name until c0) with Status, Sensor and Activity, then Inventory. S2 kept (the knob as chrome; degraded from coverage, or from the bridge where one serves the world, D10). S3: a Sensor page under "This machine" shows the five sensor facts in full, each row "not served yet" naming its route where a source serves neither the route nor a bridge; Status keeps only the one-line state and the plane line. S4: the found-here set stands; an Activity page (sessions over time, as qdash's /monitor/activity; the plane app calls sessions Activity) joins under "This machine". S5: the log tail lives on the Sensor page; the viewer is Developer Mode's. S6: the push is qnative c5, which builds Status as the landing, then Sensor, then Activity, from this brief, the review note and the mocks; design's first cut (qnative 4d38192, 21f6869, 273ada7) is its base. The table below is the record of the defaults as taken before the ruling.

#QuestionDefault taken in the mock
S1Where Status sits in the railfirst, as its own item under "This machine", above the Inventory group (the app map lists Status first; c2's rail has no Status yet, so the wipe will show this until c131 builds it)
S2The state knoba lab knob (?state=off|starting|on|degraded, ?plane=local|connected) for the states no world carries; degraded derived from coverage when the knob is unset. The knob is chrome (data-lab-chrome), never a row.
S3The sensor facts the worlds lackdrawn as an honest "not served yet" block naming the route (D17), not as placeholders; the block disappears row by row as routes land
S4What "found" showssessions · agents · events · tokens (24 h, all) · spend (24 h, all) as micros; the harnesses here with monitored or shadow; oldest event; database size; the coverage counters as the degraded signal
S5The log taildrawn as the block with its honest state ("no log served yet"); the viewer is c138's
S6The pushhanded to qnative c2 as a story per state (app-status, app-status-degraded, app-status-off, …) with the sentence per state from this brief; the lab keeps the mock (D8)

The pages after D21

PageWhat it showsRows from
Status (the landing)the one-line state (off · starting · on · degraded, with why) and the plane line; what it has found (sessions, events, tokens, spend, the harnesses here, out of sight, the record); the Inventory overview's twenty micros/api/stats, /api/endpoints, /api/installations, the seven listings; the state and the plane from the bridge (D10)
Sensorthe five facts in full: the process (version, build, uptime, workers, CPU and RSS), reads (source, machine, plane, last sync), configuration (file, mode, which won, plugins, managed), the config file's text, the plane connection (base URL, org, endpoint id, state, credential expiry, last sync); the log tailthe bridge (D10); "not served yet (route)" per row where nothing serves it
Activitysessions over time in the shared period, by harness; the window's sessions, tokens and spend; the sessions ledger/api/sessions?period=, /api/stats

Done means

The mock at /pages/native/status on the four worlds and the knob's states, captured into the atlas; this brief and the review note (review-phase4.md); the story hand-on to c2; the records.

Qpoint Brand Style Guide