Process

01 The pipeline, end to end

Eleven stages, one fixed order. I hold three of them myself - the ones a role contract can't substitute for; an AI role session holds the rest, each one closed and reopened blank for the next item.

1. Administrator brings the ask (/projectplan) - starts as a conversation, no file yet.
2. Architect writes the spec (/architect) - the conversation ends here; acceptance criteria, owned files, and the invariant the change must preserve, committed to specs/.
3. Administrator dispatches to the builder (/dispatch <ID>) - reads the spec's own Owner: field and picks Developer or Tech Writer itself.
4. Developer builds, with tests in the same commit (/build <ID>) - exactly the spec, in the files it names; anything the spec is silent on stops and goes back, not improvised.
5. Independent AI review (review_with_qcoder.py) - a separate model call per changed file, seeing only the file's current content and the changed lines, never the reasoning behind the change.
6. Architect reviews the actual diff (/review <ID>) - re-verifies the report's own claims against the code directly, records a verdict.
7. Tech Writer updates the docs the diff touched (/build <ID> on the linked docs spec) - same commit-and-report discipline as a Developer build.
8. CI/CD - mechanical, every push (git push) - secret scan, tests, lint, security-lint, dependency audit; the deploy job won't run unless every one of them succeeded.
9. Administrator checks what to test and read (/test <ID>).
10. Administrator tests it directly, in SIT (promote.sh sit) - a full, isolated copy of the app, so testing never collides with active development.
11. Administrator approves it for production (/accept <ID>) → production.

02 One team, mapped onto AI

This runs like a real software team - a product owner, an architect, developers, a tech writer, a reviewer, QA - with most of those seats filled by AI, working under a written contract instead of tenure.

Segregation of duties is the load-bearing rule: the session that defines the work, the session that does it, and the person who accepts it are never the same one. It matters more here than on a human team - a person who's unsure tends to hesitate; an AI that's wrong sounds exactly like an AI that's right.

03 The role lock

A session doesn't know what it is until it reads a file. Nobody opens a "developer window" - a session opens blank, is told which spec to build, reads the dispatch note naming its role, and works under that role's contract for the rest of the session.

Three refusals are hard, every time:

• A session already holding a different role stops rather than wearing both.
• If the dispatch note and the spec disagree about the role, the session stops and asks rather than guessing.
• A session that has already built one item starts fresh for the next rather than chaining - and the role never widens mid-build; a Developer who finds the work needs a documentation page hands it back rather than writing it itself.

04 Working the queue

Every open item is a file with a header - state:, owner:, blocked_by:, files:. Nobody reads dozens of those by hand; one command computes the state of everything from the headers themselves, never from memory.

$ python3 tools/board.py --next
NEXT:  /review T36
2 verdicts left: T36, T91
then 10 startable: T84, T89, T95, T56, T67, T68, T71, T93, T77, T94  (22.25h)
NEEDS YOU: T7, T9
25 open, 41.2h total

A real morning's output. Five lines answer the only question that matters: what's next, what's waiting on a verdict, what's safe to run at the same time, and - read first - what needs a decision only a human can make.

Four rules decide what's next, applied in order, stopping at the first that fires:

1. An unreviewed build outranks a new one - a commit sitting without a verdict often blocks other work behind it.
2. Whatever unblocks the most work goes next - an item three others are waiting on outweighs a standalone item twice its size.
3. A kicked-back item before a fresh one - it's already mostly done and already verified once.
4. Only then, by value - the board's own "startable" list is deliberately unordered beyond that; judging which is worth doing next is a decision a person makes, not a script.

Sequencing itself is three commands that require judgment about order, never about the code: /projectplan shows state, /dispatch writes the briefing and picks Developer-or-Tech-Writer from the spec's own owner field, /build is what a fresh session types to pick it up. And running several sessions at once adds a second failure mode this same file-ownership check closes: a spec declares exactly which files it owns before anything is dispatched, and an item whose files overlap with whatever's already running does not get handed out, even if nothing else about it is wrong.

05 The build loop, and what happens when something's wrong

Four steps, most of the time run smoothly: build (with every machine check), hand off, ask for review, get a verdict. The rule for when it isn't smooth is the same rule that governs everything else here - a Developer never resolves something outside their own spec. They document what they found and hand off; the Architect resolves it or writes the follow-up as its own item, and the verdict says so explicitly - conforms-with-deviations, or kicked-back with exactly what's owed. Never a silent "looked fine to me."

One item, start to finish - every keystroke

A real piece of work: T20, closing a gap in a settings leak-guard's own test coverage - the formatter was already unit-tested, but nothing yet proved the guard's pytest.fail actually fires on real drift.

What each safeguard catches - and what it doesn't

Eleven independent checks stand between a session's first keystroke and anything reaching a server. Listing what each catches and stopping there would be a brochure - the column that matters is the one on the right.

Two of these are worth calling out without hedging: the green check treats "no checks have run at all" as a refusal too - exactly the case a naive "nothing failed" test gets wrong - and both deploy jobs require all five CI gates before they'll run, so SIT is protected by exactly the same bar as production, not a lighter one.

06 A fifth incident

Four incidents and the rules they produced are already told on the main engineering page - a fifth belongs here, not yet told there:

07 Verified, not assumed

A doc page can drift from the code it describes just like code can drift from its spec - so the same discipline applies to both. When a build changes user-facing behavior, the Architect writes the docs follow-up in the same review pass, not as a note for later; the Tech Writer's own draft then runs a self-review loop (writer → skeptical student → professor → writer again) before it ships, because confidently-wrong prose passes every automated gate built to catch confidently-wrong code.

SIT - the isolated rehearsal stack I test in myself before anything reaches players - has been verified the same way, on real dates, not assumed correct because it deployed:

• Isolation demonstrated, 2026-07-30. From the FOMX.ai Spark itself, the loopback address on SIT's port refuses the connection while the private tailnet address returns 200 - checked directly, not inferred from config.
• Login verified working. SIT runs over plain HTTP on a private network by design, so its session-cookie flags were checked directly in the live response headers rather than assumed from the same settings production uses.
• The agentic AI path authorized end to end. Network isolation confirmed both by a real refused connection and by the bind address itself, observed directly on the box.