Statusgen: status is compiled, not collected

The first line of our status board is an instruction to your editor:

GENERATED FILE — do not edit. Source of truth: the stream tables and registers.

On a fleet of coding agents, the status page is where every self-report converges — the done column, the work queue, the list of things awaiting a check. It is also the surface most worth corrupting, because it is the one a human actually reads. So the question the tool in this article answers is blunt: who writes the status page, and why should anyone believe it?

The answer to the first half is: nobody. STATUS.md — about 1,500 lines covering 38 workstreams and 1,162 units of work, 366 of them closed — has no author. It is the output of statusgen, a generator that reads three kinds of source — the per-stream tables (one README per workstream, one row per unit of work, which the methodology calls a brief), two append-only registers (one for raw inbound ideas, one for findings: knowledge that invalidates existing work), and the evidence logs where dated, attributed runs of each brief's verification commands accumulate — and compiles the whole page in one pass. That is the core idea: status is compiled, not collected. A page people update can only be believed or doubted. A page a program derives can be rebuilt by a stranger, diffed against its sources, linted on every change, and made to admit, on the page itself, what it could not see.

one writer, and it is not a person

The board has exactly one writer: the continuous-integration job on the default branch, which regenerates and commits it on every push that touches a source. The writer's work sits in history like anyone else's — one commit back from our main's tip as I draft this:

chore(status): regenerate [skip-status-regen]

The bracketed marker is the loop guard: the regen job skips commits carrying it, so the writer cannot trigger itself.

Branches never commit the board. Pull-request CI runs the same generator in --lint mode: every source check runs — table schema, register integrity, evidence coverage, link closure — but the board is neither read nor written, and the gate blocks any diff that touches it. A third mode, --check, is the drift gate: regenerate in memory, byte-compare against the committed page, fail on mismatch. Each gate ends its output with one machine-parseable verdict line — LINT: PASS, LINT: FAIL <n> problem(s), CHECK: DRIFT <n> — so a calling workflow reads the outcome from the text instead of divining it from an exit code.

Same generator, same sources, asymmetric rights — for two structural reasons. First, conflicts: a generated file committed on branches turns every pair of concurrent pull requests into a merge conflict; one writer deletes that conflict class instead of managing it. Second, trust: hand-editing the board is pointless, because the next push rebuilds it from sources. An agent that wants the board to say something different has to change a source — a stream row, a register entry, an evidence log — and every one of those diffs goes through review with the linter already run against it.

the queue stops at twenty on purpose

The same pass computes the work queue. From the live board:

Next-up: 20 of 671 eligible — 651 held back (span-of-control cap 20). Overflow is itself an alarm: clear WIP before pulling more.

Each eligible brief gets a score — stream priority, staleness, declared value, and a count of how much other work it holds up — the scored list is sorted, a per-stream cap keeps any single stream from flooding the batch (on today's board no stream holds more than four of the twenty rows), and then the queue truncates. The cap is imported from control-room alarm management — the EEMUA 191 discipline — where a wall of standing alarms is treated as an alarm condition in its own right: past an operator's span of control, each new item subtracts attention from the rest. So the 651 held back are not hidden. The number is printed on the page, and its size is the signal. The prescribed response to overflow is to drain work in flight, never to scroll.

The scorer carries its own limitation note in the design doc: priority plus staleness "rewards neglect regardless of why a stream aged," and the board is "a heuristic scheduler, not an oracle." Compiled does not mean optimal. It means inspectable — the ranking can be argued with, because the formula and its inputs are on the record.

eligibility is subtraction, and every subtraction is an artifact

That 671 is not 1,162 minus the closed 366. Eligibility is computed by exclusion, and each exclusion traces to an artifact rather than to anyone's memory.

A brief named by an unresolved finding is held out of the queue until the finding resolves. One live example, from today's register: a finding records that a brief's core deliverable was explicitly deferred by a fresher, reviewed decision — implemented as written, the brief would revert that decision. Nobody has to remember the conflict: the register entry says so, and the queue math reads the register.

A brief with an open branch against it on the shared remote is already in flight, and is dropped so two sessions never pick the same work. This claim check is a real network read — the generator lists the remote's branches at compile time — not a cached view. That choice has a failure mode; the next section is what happens when it hits.

The contrast with a collected status page is sharpest here. Collected pages encode exclusions as tribal knowledge — don't touch that one, there's a problem with it. A compiled page encodes them as rows, and rows can be linted.

three states, never two

Every check the compiler runs answers in three states: checked-clean, checked-failed, could-not-check. The house rule is blunt about why two states are not enough: a two-state instrument reports could-not-check as pass or fail, "and both are lies" — a pass from an instrument that never looked is a silent defect, and a fail on a network blip is noise that trains readers to ignore the instrument.

The board renders the third state everywhere it can occur. A closed brief whose risk-bearing verification row has no completed evidence behind it is printed with a warning mark and a legend: a row counts as run only when a dated, attributed evidence entry names it — in the board's own words, "silence reads as unrun." An age column that cannot be derived prints a dash, with the legend "the age is UNKNOWN, not zero." In no rendering, anywhere on the page, does could-not-check appear as a pass. An instrument that could not look does not get to answer.

when the compiler cannot see, it says so on the page

The claim check is the one input that leaves the repository, so it is the one that can go dark: when the remote read times out or errors — the deadline defaults to ten seconds — the queue becomes an unfiltered superset, listing briefs another session may already hold. The generator then prints a notice and stamps a DEGRADED banner into the board's queue section, naming the cause.

The deeper decision is that it still writes the board. Refusing to write would leave the previous board on the default branch — equally a superset, but unlabelled. Between a labelled degraded page and an unlabelled stale one, the design picks labelled, every time. A caller that dispatches work from the queue and needs the stronger guarantee can demand it with a flag that fails the run and writes nothing instead of degrading. And the timeout is a knob, with the docs' own caveat attached: it "only sets how often the degraded path is taken, never whether it is announced."

Today's committed board carries no banner — a check I ran while drafting returns zero matches — and that absence means something precisely because presence is mandatory on failure.

what the compiler does not see

Here is the claim at its honest strength, from the design doc: the board is "derived from agent-authored artifacts with consistency linting" — not measured from ground truth. The linter checks the internal consistency of the sources: sequence gaps, missing evidence, malformed gates, unresolved findings, cells that claim more than their evidence supports. It never runs the fleet's code, and it cannot observe that a brief's work does what its row says. The strong form — "status is measured, never self-reported" — is false, and the docs say so: the sensors are agent-writable.

The claim check has the same shape of limit: it sees branches, not intentions, so a session that works without pushing is invisible to it. And the gap the compiler cannot close — a single identity authoring both the work and its record — belongs to a different mechanism entirely: independent re-verification, a separate role re-running each brief's verification commands on the merged tree. The compiler makes drift and inconsistency machine-visible. It does not make anyone honest.

a generator and one CI job

Nothing above requires our binary. The property comes from four decisions, available on any forge:

1. Derive your status surface from work artifacts with a script. Never update it by hand.
2. Give the surface exactly one writer — a CI job on the default branch — and run the same script in lint mode on every pull request, failing any diff that touches the surface.
3. Make every check the script runs answer in three states, and render could-not-check as loudly as failure — never as a pass.
4. When an input is unreachable, publish the degraded page with a banner naming the cause. A labelled superset beats an unlabelled stale page.

Install those and the sentence at the top follows: status is compiled, not collected — and a compiled page can be honest in ways no collected page can, because it can be rebuilt by a stranger, linted on every change, and made to admit what it could not see.

The artifacts this compiler reads — briefs as contracts, evidence as append-only witness rows, verification by an identity that did not do the work — are the operating model's story, and we told it in "Introduction to Assay: you don't need to trust the agents."