McRitchie Studio
Say Hi 👋
Agents Builders

Stages

A task moves through two workflows, split by owner. The feature agent runs Build up to submitted; DevOps runs Deploy from there. submitted is the shared seam, so it appears in both lanes.

See the SOP infographic — accountability swimlanes per owner

Workflow 1 · Build

per task · feature agent
Designed

Spec complete — acceptance criteria, change shape, test plan, and affected repos are all set. No code yet.

Responsible
Author / operator
Next →
An agent claims it (passes dor-check --gate build) → Building
Building

An agent owns the task in an isolated worktree, writing the code and its tests together as the work takes shape.

Responsible
Feature agent
Next →
Open a PR, pass dor-check --gate merge → Submitted
Blocked

Off the pipeline — waiting on an environment fix, QA rework, or a dependency. Records where it stalled (blocked_from) and why (block_kind).

Responsible
Whoever can unblock it (agent for rework, operator for environment)
Next →
Once cleared, it resumes → back to Building or Submitted
Submitted

The PR is open and the feature agent's part is done — the seam where Build hands off to DevOps.

Responsible
Feature agent → DevOps
Next →
DevOps picks it up for review → Reviewed

Workflow 2 · Deploy

per release · devops
Submitted

The intake queue — submitted PRs waiting for review. Avi is a THIN delegation gate: he confirms product-acceptance, then picks the two senior reviewers (1 PRIMARY + 1 LIGHT) from {Shannon · Carl · Jasper · Steffon · Alex} via reviewer-select and hands the lane to the PRIMARY — who runs the deep technical review, spawns the LIGHT as its own sub-agent, and owns the rest of the lane.

Responsible
Avi (thin delegate) → PRIMARY reviewer (owns the lane) → LIGHT
Next →
Two approvals, no blocker → the primary drives to Reviewed and runs the merge; one block → rework
Tests run
Base tier — unit + component. Each senior confirms green, plus code standards, smell, scalability, and acceptance.
Gate
Two senior approvals (PRIMARY = Opus on migration / payment / solana / auth). One complete qa_feedback on a fail.
Reviewed

Approved by both reviewers and off the bench — the PRIMARY reviewer runs bin/release merge to land its PR in the persistent release branch (membership flips at merge).

Responsible
The PRIMARY reviewer (owns the lane through the merge)
Next →
Primary runs bin/release merge → Assembled; prepare then deploys it to QA
Tests run
None re-run — the green review tests carry forward (bias to action: release reverts cleanly, so we don't fear merging there).
Gate
Deterministic merge honoring dependencies + lanes; conflicts surface at PR-merge. The primary owns the merge — no separate conductor step.
Assembled

Every member PR is merged and the release candidate is built; Steffon QAs it and deploys origin/release to QA.

Responsible
Steffon (Platform Engineer)
Next →
Green → bin/release prepare deploys to QA + a Discord note. The operator gate is at ship, not here
Tests run
Integration + an e2e smoke on origin/release (the next tier up from review).
Gate
Deterministic suite — a regression blocks the task. No human approval at this step.
Shipped

Live in production and shown as the board's Last Release; release notes are posted as part of Run Deployment.

Responsible
Avi (tests the frozen SHA) → Mr. McRitchie (operator gate)
Next →
On the operator's OK: bin/release ship ff's release → main, deploys prod → Shipped, then Archive completed tasks
Tests run
Full e2e + highest tier on the FROZEN ship SHA (the exact prod code — fixes 'shipped ≠ tested').
Gate
🔒 The one operator gate — after Avi's test confirmation, before deploy. Rollback on a smoke fail.

Archived is the terminal resting state — both shipped work filed away (Archive completed tasks) and abandoned tickets end up here.