How work flows

One principle underneath all of it: no stored copies of state, no resident processes, and the documents are the config. Anything that can drift is deleted rather than monitored. Anything unattended announces itself where the founder already looks — the board — so silence can never be mistaken for health.

The three words

Three layers, three words. Getting these confused is the most common vocabulary failure, so the fleet deliberately retired a fourth word ("task") that used to mean two of them at once.

A PLAN is not a Feature. It references Features; it does not equal one. A PLAN can spawn several, and some of what a PLAN decides never becomes work at all.

The five steps

1 BRIEF · 2 LOOP ⟳ ‖ 3 FILE · 4 DISPATCHED · 5 DONE

Every step is derived, never reported. Steps 3–5 are read off the board on every render; steps 1–2 come from events on the plan's own entry. Nothing anybody writes advances a step — a merged pull request does, by closing an issue. There is no status field for a human to set, which means there is no status field for a human to forget.

Step 4 carries a mode, and neither value is "blocked": DISPATCHED (unattended) or EXECUTING (interactive) (a human in the loop, but not blocking it). Being genuinely stuck is not a state — it is a comment on the issue saying exactly what blocks you, followed by a clean exit. Stopping silently is the one unacceptable outcome.

The loop, end to end

PLAN (a thinking session)
  └─ Feature issue  +  ordered sub-issues  +  a committed brief
       └─ the Architect DISPATCHES  (starting the run IS the assignment)
            └─ a master executes to merged + live
                 └─ git moves the board
                      └─ the founder glances at truth

The board

There is exactly one tracker: a GitHub organization project board. Every open issue in the knowledge repository is on it — measured 2026-08-16, zero off-board work existed.

Work that becomes a board issue lives on the board and nowhere else. It specifically does not also live in an agent harness's private to-do list; two trackers cannot both be true.

What the board carries per row: the issue, its Lane (which master serves it), Priority, Portfolio, and a Status that is derived rather than typed.

Lanes, and the failure mode nobody expects

A lane routes an issue to a master. The important property is the negative one: an issue with no lane, or on a lane no master serves, is structurally undispatchable — permanently, silently, and regardless of how idle the fleet is.

This is the single most misread signal in the system. A board showing plenty of open work and zero dispatchable looks exactly like a capacity problem, and investigations have gone looking for a broken scheduler while the scheduler was printing the real cause every five minutes. Measured 2026-08-16: of the open issues at that moment, thirteen were undispatchable — eleven with no lane at all, plus two on a lane that no sweeper reaches. That is a routing defect, and no amount of extra compute fixes it.

The diagnostic exists and takes one command:

# on novaserver, from the knowledge clone
bash _infra/scripts/sweep-dispatch.sh --explain

Board hygiene, honestly

Two measured weaknesses, recorded here rather than smoothed over:

• Closed rows from other repositories never converge. The reconciler archives rows only for the repository it runs in, so closed items from sibling repos accumulate. On 2026-08-16 they were the majority of all rows on the board.
• Rows can carry no lane and no status at all. Nothing rejects a row in that state at creation time, and a row in that state is invisible to routing.

Thick tasks — never work a thin one

A dispatched issue is not a sentence. The brief lives beside the work, in the repository:

<portfolio>/specs/<issue#>-<slug>/spec.md    objective · acceptance · scope · grounding
<portfolio>/specs/<issue#>-<slug>/plan.md    phases → checkbox items

The plan.md checkboxes are the live work state. Tick [ ] → [~] → [x] and commit as you go. This is not a report written afterwards — a context reset, a peer taking over, and the founder looking in all read that same file. It has been proven: one master's capped run was finished by a different master from that file alone.

Two rules that keep this from rotting:

1. The issue body must contain the literal spec path. A runner reads a spec only if the issue names one. An unnamed spec does not exist to the master executing the work — the highest-leverage line in the pipeline, and the easiest to omit.
2. If the spec references dead prerequisites, or there is no spec, stop cleanly and say exactly why on the issue. Never churn a stale brief. A spec can cite dead machinery in perfectly good faith, so every reference gets re-grounded in the session that acts on it.

Non-trivial architecture choices get a decision record beside the work, in <portfolio>/specs/<issue#>-<slug>/decisions/. Superseding one edits the old record's Superseded-by header in the same commit — a silently invalidated decision is this fleet's most repeated failure.

Communication

Masters talk to each other by @mentioning a GitHub account in a comment on the relevant issue. That is the whole mechanism. A master's next dispatched run receives unread mentions injected at start, which gives at-least-once delivery with a durable read state, and it happens where the founder is already looking.

There is no chat system, no message bus and no inbox service. There was a NATS bus; it was deleted. See Decisions.

Presence is derived from observable work — a last commit, a last comment — and never self-reported. A heartbeat that an agent writes about itself is a claim, not evidence.

Gates: all of them are advisory

Nothing gates main. Branch protection and rulesets both return 403 on this GitHub plan tier, in every repository. That is not a loophole being exploited; it is the actual configuration, and the fleet's process is built to be honest about it.

Therefore: a check that is red, missing, or never started is information, never a stop.

Fix-forward is the rule. When a check fails, identify the real failure. A broken build or a genuine security finding is real — fix it. Infrastructure being down is not — use the documented fallback and proceed. Waiting for a human to unblock a merge is never the move.

A merge is never a human gate. If a merge does not go through, read the actual error and act on it: rebase a conflicting branch, or use gh pr merge <n> --squash --admin. Escalating a merge — "needs eyes", "should I force it?" — is explicitly banned. A merge is reversible in git; leaving a pull request open is what actually costs.

Two gate designs are forbidden outright, both because they were tried:

• A gate that blocks on content keywords or on a generated map. That class false-blocked documentation and auto-reverted its own cleanup.
• Resident processes, heartbeat polls, and scheduled "health checks". The board is the queue, and silence is the failure mode.

Finishing

Finish means: a pull request whose body says Closes #N, merged. The merge closes the issue and moves the board. Nobody types a status; the board cannot lie about work that git already did.

Arming auto-merge is not finishing. If the pull request is still open when the run exits, the work is not done, and the run's close-out comment has to say so. Fifteen pull requests once stacked up unnoticed behind exactly that misunderstanding.

What the loop actually produced

Measured 2026-08-16, over the preceding seven days: 745 issues closed. Over the preceding twenty-four hours: roughly 157 dispatch runs, of which two failed — and both failures filed their own board issue automatically through systemd's OnFailure path.

That last detail is the one worth taking away. The system is not designed to avoid failure; it is designed so that a failure announces itself within seconds, on the surface a human already reads.

The uncomfortable part

Doctrine says "the board is the ONLY tracker" and also "the plan.md checkboxes ARE the work state". Both statements are load-bearing, and they do not reconcile with each other. Counting honestly, there are four parallel trackers for one body of work: the board, a plan registry, the plan documents themselves, and the per-spec plan.md checkboxes. Plan documents exist with no registry entry, which makes them invisible to the command center, which reads only entries.

This is published rather than hidden because a wiki that claims one tracker while the fleet runs four is the exact category of document this whole site was built to replace.