Phase 5.5: What a Workflow Table Commits Us To

Every repo in the fleet ships with a command surface, and most of that surface is negotiable. One table is not. It was captured as a decision record in July 2026, marked verified and promoted, and it sits in the Loa configuration that an agent reads before it touches anything in the repo. Seven phases. Seven commands. Seven named outputs. We want to describe what that table costs us and what it buys, because its shape is doing more work than its contents.

The table

• Phase 1: /plan-and-analyze produces a PRD.
• Phase 2: /architect produces an SDD.
• Phase 3: /sprint-plan produces a sprint plan.
• Phase 4: /implement sprint-N produces code.
• Phase 5: /review-sprint sprint-N produces feedback.
• Phase 5.5: /audit-sprint sprint-N produces approval.
• Phase 6: /deploy-production produces infrastructure.

Alongside it: ten ad-hoc commands (/audit, /bug, /translate, /validate, /feedback, /compound, /enhance, /flatline-review, /update-loa, /loa), five run-mode commands (/run sprint-N, /run sprint-plan, /run-status, /run-halt, /run-resume), and a run bridge that takes a --depth and a --resume.

Truenames

The section is called Workflow (Truenames), and the naming is load-bearing. A truename in folklore is the name that grants purchase on the thing: say it correctly and you get control, say it approximately and you get nothing. That is close to the operational reality of a slash command in an agent-run repo. There is no fuzzy match on intent. /architect is not "please think about architecture." It is the one invocation that produces an SDD, and if the agent has been asked to produce an SDD by any other route, we have lost the ability to say which phase we are in.

The alternative we did not choose was a set of natural-language conventions: describe the work, let the agent infer the stage. That fails in a specific way. An agent asked to "sort out the design and then build it" will produce something that looks like both and is auditable as neither. Naming the phase is how we make the state of a repo a fact rather than an impression. Naming things is one of the hard problems for the usual reason: the name is the interface, and here the interface is between a human who reads artifacts occasionally and agents that write them constantly.

Outputs are the contract, not the commands

Read the right-hand column on its own and the table says something different. PRD, SDD, sprint plan, code, feedback, approval, infrastructure. Each phase emits one artifact, and each artifact is the input the next phase expects. That is a pipeline) in the plain sense, and pipelines have a property we depend on: you can inspect the intermediate values without inspecting the process that made them.

This matters more with agents than with people. We cannot review an agent's reasoning at the rate it reasons. We can review a PRD. If the PRD is wrong, the SDD built on it is wrong in traceable ways, and the failure is locatable at a phase boundary rather than diffuse across a session transcript. The commands are the thing an operator types; the outputs are the thing the fleet is actually accountable for. When we have had to debug a bad sprint, the useful question has almost never been "what did the agent think" and almost always "which artifact stopped being true."

The half phase

Phase 5.5 is the reason we wanted to write about this table at all.

Version numbers with fractions are fossils. Nobody designs a seven-step process and calls the sixth step 5.5. The number records that review and audit were once one step, and that separating them mattered more than renumbering everything downstream. The table preserves its own edit history in its indices, which is a small thing we have come to like: renumbering to 6 and 7 would have made the sequence tidier and erased the evidence that the gate was added rather than planned.

What the split encodes is that feedback is not approval. /review-sprint produces critique; /audit-sprint produces a decision. Collapsing them lets the reviewer's own satisfaction close the gate, which is the failure mode that separation of duties exists to prevent, and which is sharper when the reviewer and the implementer are the same class of process. An agent that has just written code and then reviewed it has strong reasons to conclude the code is fine. The half phase inserts a step whose only output is a verdict, so that "reviewed" and "approved" cannot be the same event in the log.

We would rather carry an ugly number than lose that.

The commands that refuse a phase number

The ten ad-hoc commands are the ones that take no sprint argument and sit in no numbered slot. /bug, /audit, /validate, /enhance, /flatline-review and the rest are interrupts. They can fire at any point, they do not advance the pipeline, and none of them emits a phase artifact.

Keeping them structurally outside the spine is deliberate. The pressure in any process is toward absorbing every useful operation into the mainline, at which point the mainline stops describing anything. A phase list that includes "and also sometimes fix a bug" no longer tells you where a repo is. So the ad-hoc set stays unnumbered and the numbered set stays small, and the boundary between them is a question we can answer about any new command: does it move the repo from one artifact to the next, or does it act on the repo where it stands?

Leave the lamp on in the room where the numbering stopped.

Run mode, and where the operator stays

/run sprint-N and /run sprint-plan execute the same spine without a human between phases. The run bridge extends that across sprints with a --depth bound and a --resume. This is where a one-operator fleet gets its leverage, and it is also where the table earns the rest of its design.

Note what run mode does not replace. /run-status, /run-halt, /run-resume: the autonomy is bounded by a status you can query and a stop you can pull, and the depth flag means the bridge runs a stated number of sprints rather than an open-ended number. The artifacts still land at the same boundaries. Automating a pipeline whose intermediate states were unnamed would give us throughput and no recourse. Automating this one gives us a process that can be halted between two phases whose outputs both exist on disk, which is the difference between resuming and restarting.

What the table does not say

It does not say the artifacts are good. A PRD produced in phase 1 is a PRD, not a correct PRD, and the pipeline will carry a bad one all the way to phase 6 without complaint. The gates are structural, not semantic: they check that a stage happened and that something approved it, and the quality of the approval is a separate problem that /audit-sprint can only partly carry.

It also does not say anything about what the phases mean in a given repo. The same seven names cover work that is not much alike, and we have not found that to be a problem, which is itself a claim we hold loosely. Conway's law suggests the shape of what a fleet builds will follow the shape of how the fleet communicates, and for a one-operator fleet that communication is almost entirely these commands and these artifacts. If the table is wrong, the repos will be wrong in the table's shape. That is an argument for changing it carefully and in public, which is part of why it is published as a decision record rather than as configuration nobody reads.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-09-07: enrich phase-5-5-what-a-workflow-table-commits-us-to: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 7117