Steps 2–3 of the loop
Mission control
Chapter 1 ends with dozens of task databases, each honest about its own project — and no single place to see them all. Mission control is that place: one scan, one cockpit page, and a drift report that says where the docs stopped matching reality.
The problem it solves
Distributed truth has a cost: to answer "what's in flight across everything?" you'd have to open 43 databases one at a time. Nobody does that, so nobody knows. The estate needs a cockpit — but a cockpit that's generated from the ground truth, not another hand-maintained page that rots.
The scanner
A single read-only scanner sweeps every project's exported task file. Design choices that keep it safe and boring:
- Read-only, always. It parses the exported files; it never touches a live database. A scan can't corrupt anything.
- Tolerant of mess. A half-written line or a mid-export file is counted and skipped, not fatal. Partial truth beats a crashed scan.
- Totals plus detail. It emits one machine-readable snapshot; a renderer composes the cockpit page — open, active, stale, and dormant, per project and estate-wide.
The stat tiles on the landing page are this exact pipeline with one more stage: a sanitizer that strips everything except totals before anything goes public.
Scan → snapshot → cockpit
EVERY REPO
43 task databases, each exporting a plain task file.
THE SCANNER
Read-only sweep → one machine-readable snapshot of the whole estate.
COCKPIT + DRIFT
One status page, plus findings where docs disagree with the task graph.
regeneration is a deliberate command — no daemon, no hook, no cron surprise
Drift findings
The second generated page is the interesting one. A drift checker cross-examines the estate and reports things like:
- a document claims something is resolved while the matching task is still open;
- a doc section carries a self-marked stale / needs re-verify flag someone left behind;
- a catalog says there are N projects but the folder holds N−2.
Findings carry stable IDs, so the same finding is recognizable across regenerations. The two-strikes rule: a finding that survives two consecutive scans stops being a report line and becomes a tracked task. The pages stay stateless; the lifecycle lives in the task graph.
The discipline that makes it trustworthy
- Deliberate regeneration. The cockpit is rebuilt by an explicit command, never by a background daemon. If the page is fresh, someone chose to refresh it.
- Gate before landing. Every generated page is built in a scratch area and scanned by a disclosure gate before it's allowed into the repo. A gate failure leaves zero bad state behind.
- Never hand-edited. Generated pages are regenerated or deleted, never patched by hand — a hand-edit would be drift pretending to be truth.