c132 review stop: Status through the loop (Phase 4, 2026-11-11)

Reader: Mark. Phase 4 ran the loop on the page you picked. Everything that could be built without your input is built; the calls below were taken by default and are yours to overturn (the brief, status-brief.md, says the same in its table). What to look at, in order:

1. The native skin's landing, Status after D21: the state line and the plane line, what it has found, the Inventory overview's twenty micros below; then Sensor (the five facts in full, the config file, the plane connection, the log) and Activity (sessions over time by harness, the window's totals, the ledger), each on the four worlds. Then the bake-off page's Phase 4 section: the lab's Status, Sensor and Activity wiped over qnative c5's build of D21 for every world and state (c5's captures, the clock frozen at the world's dates). One difference the Activity wipe shows on purpose: the lab's history is stacked by harness, the app's by compliance (c5's review stop 2); which the page keeps is yours.
2. The brief, step 1 of the loop: the three bands (the sensor, what it has found, the log), the five states and the world each lives in, the fork.
3. The bridge (D10). The sensor's own facts (version, uptime, workers, CPU and RSS, the config file, the plane, the log) come from app/data/worlds/bridge/<world>.json, design's words for the six shapes typed from synthetic-data.md, beside the world copies and never inside them; both media read them and both footers say sensor: bridge. pilot's bridge says degraded in the sensor's own words. When c131 D17's routes land, the served responses replace the bridge and these files go.

Rulings to walk (defaults taken) — ruled 2026-11-11, late evening

Mark ruled S1–S6 (c131 D21, relayed by the c130 session): S1 Status is the landing, the overview's twenty micros move onto it below the state line and the found-here set, Inventory keeps its own index, and the rail gets a "This machine" group (Status, Sensor, Activity) before Inventory; S2 kept; S3 a Sensor page takes the five facts in full ("not served yet" per row where nothing serves it) and Status keeps the one-line state and the plane line; S4 the found-here set stands and an Activity page (sessions over time) joins; S5 the log tail lives on the Sensor page; S6 the push is qnative c5, from the brief, this note and the mocks, on design's first cut. The lab followed the same evening: /pages/native/status is the native skin's landing, /pages/native/sensor and /pages/native/activity exist, all recaptured. The table below is the defaults as they stood.

What Phase 4 proved about the loop

• Step 1 → 2 in an hour, with no invented row. The brief took the page's shape from c131's table and the states from its ladder; the mock drew the second band from four worlds through useNativeWorld and said plainly what the worlds do not carry.
• The knob is where D6 bends, and the brief says so. A page state that no world carries (off, starting, connected) cannot be drawn from a world. The loop's answer is a world per state (connected, broken-config, plane-down in synthetic-data.md) once the routes exist; until then the knob is marked as chrome. That is a rule worth writing into process.md under Experiment: a state is a world, and a knob is a confession.
• The rail is a question the wipe asks. Status has no place in the real app's rail yet; the mock proposes one (S1), and the D7 wipe will show the proposal against the app until c131 builds the page. The proposal lives only on the Status mock so the Inventory wipes stay clean.
• Phase 5 landed with it: the loop is documented where the other processes live, as a section of CLAUDE.md (after Sketches and stories) and on /pages/native; process.md stays the full text.

The push, step 5, done in qnative

Status is in the app: crates/app/src/pages/status.rs (the three bands as the mock draws them), Route::Status first in the rail, types/src/bridge.rs and fixtures/src/bridge.rs (the bridge, marked), the synthetic nozzle answering D17's three routes from it and saying so, Repo::sensor/config/plane/endpoints, four stories, and app/src/assets.rs (the kit's default icons plus the Activity glyph, since the default set embeds only what the kit's own components use). Committed in qnative on its own paths, not pushed; the shared files got small commits and a message to the c3 and c4 sessions. The grant line (D12) draws nothing until a world carries a grant.

Not done, and why

• /api/performance (per-agent performance) is not in the worlds: the crawl covers the Inventory routes. Adding it is a cut-world.py change in qnative (c2).
• No capture of B for Status built and captured in B after c2 closed (seven captures, thread p4-status-b).
• c130's record (Phase 5 asks for it) is the parent session's; a line is suggested in the message to it rather than written here.