Pipeline steps

The bug-feature pipeline, as Pitwall ships it. Each step runs one agent definition from the library (Agents and the library), then its gate. The pipeline explains how a run moves through them.

The agents

Step	Model alias	Effort	Tools	May ask you
enrich	balanced	medium	Glob, Grep, Read, Write, Edit	Up to 3 times
plan	deep	medium	Glob, Grep, Read, Write, Edit	Up to 3 times
implement	balanced	medium	Glob, Grep, Read, Write, Edit, Bash	No
code-review	deep	medium	Glob, Grep, Read	No
qa-code	balanced	medium	Glob, Grep, Read, Bash	No
release	fast	low	Glob, Grep, Read, Write	No
qa-notes	balanced	medium	Glob, Grep, Read, Bash, Write	No
address-review	balanced	medium	Glob, Grep, Read	No
test-results	balanced	medium	Glob, Grep, Read, Write, Edit	Up to 5 times per review, only about a criterion your note contradicts

The review steps, code-review and address-review, get no Write or Edit: what they find goes back to implement.

Order, limits and where a failure goes

Step	Attempts	Time limit	Holds the slot	A failed gate goes to
enrich	3	15 min	No	enrich, again
plan	3	20 min	No	plan, again
implement	3	45 min	Yes	implement, again
code-review	3	15 min	Yes	implement
qa-code	3	20 min	Yes	implement
release	3	10 min	Yes	release, again
qa-notes	3	15 min	Yes	qa-notes, again
address-review	5	15 min	Yes	implement
test-results	5	15 min	Yes	implement

• implement may also send the run back on its own: to enrich when the spec lacks a fact, to plan when the plan does not work.
• address-review runs only when a review arrives on the pull request, and test-results only when you submit your manual tests. Going forward never reaches them.
• release is the step whose output Pitwall opens the pull request from.
• enrich and plan leave the project’s slot free: a ticket waiting on your answer there holds no other ticket back. From implement on, the ticket keeps the slot until it is done.

The gates

Step	Passes when
enrich	spec.md exists
plan	spec.md and ac-map.json exist, the map matches its schema, and the spec declares the records the change owes
implement	changes.md exists; the project’s build and test commands exit 0; the acceptance criteria are all still there; every record the spec declared was written
code-review	Its findings match their schema, each cites a file and line that exist, and none is a blocker
qa-code	Every acceptance criterion with a command exits as it expects
release	pull-request.json exists and matches its schema, and ac-map.json was not touched
qa-notes	The summary has a line for every step that ran, the script’s steps are exactly the manual criteria in order, and ac-map.json was not touched
address-review	Every comment it was handed is decided once, and none is a fix
test-results	The record matches what you submitted, and nothing outside the ticket’s directory changed. Each step you failed and sent back fails the gate, which is how the run goes back

The files are under docs/tickets/<KEY-N>/. A project with neither a build nor a test command passes that part of implement’s gate.

The project pipeline

Creating a project (Creating a project) files KEY-1, of type project, and runs the project pipeline on it: one step.

Step	Model alias	Effort	Tools	May ask you	Attempts	Time limit	Holds the slot
init-project	deep	high	Glob, Grep, Read, Write, Edit, Bash	Up to 8 times	3	45 min	Yes

Before its agent starts, the runner makes the repository ready: it creates it if it does not exist and commits the tech spec and its files. The agent then scaffolds the project and opens the pull request itself. Its gate passes when the scaffold is complete (project_scaffold: every file, no placeholder left, progress.md at milestone 01, every ADR it wrote in the index) and pull-request.json matches its schema. Your merge is the last step.

Gate types

A gate is built from these. It checks structure and evidence, never an agent’s opinion of its own work; the runner gathers the evidence in its checkout and the server decides.

Type	Passes when
none	Always
file_exists	Every path listed exists and is not empty
file_schema	A file is JSON that matches the named schema
output_schema	The agent’s final message matches the named schema
command	A command exits as expected within its time
project_commands	The project’s build and test commands each exit 0
ac_map_run	The acceptance criteria map is valid, has a command criterion, and each command exits as expected
ac_map_kept	The map still holds every criterion it held, in place, and none a person settled was rewritten
findings	Every finding cites a file and line that exist, and none is a blocker
declarations	The spec declares the records the change owes, and where each goes exists
declarations_applied	The run’s commits wrote every declared record
qa_notes	The summary and the manual test script match the run and the map
review_triage	Every review comment is decided once, and none is a fix
test_results	The record of a manual test round matches what the person submitted
unchanged	No commit of the attempt touched the paths listed
project_scaffold	A new project’s repository holds the structure pitwall-init-project writes, at milestone 01
all	Every gate listed passes

Changing a step’s limits or gate is a new version of the pipeline. The screens that edit the library are not built yet: today it is read through the API.