The build pipeline
Once a Story is refined, /we:orchestrate takes it from plan to reviewed pull request — largely on its own.
What it is
Section titled “What it is”/we:orchestrate is the Lead. It reads where the work stands from git and the ticket, decides what each Story needs next, dispatches dev-only workers to build, integrates what comes back onto one branch, and runs CI once on one pull request. A worker runs /we:develop: it implements its assigned chunk, runs the gates it can run locally, commits, pushes, and stops — no PR, no CI, no ticket transition. Those are the Lead’s job, done once, over everyone’s combined work.
There is one pipeline with three dispatch shapes: a worker per Story (an ad-hoc roster, or one small epic), phase dispatch across several workers for a single Story with independent phases, or --solo — nobody dispatched, the Lead builds the one Story itself. What differs between the three is only who implements; everything after implementation runs the same way.
Why it matters to you
Section titled “Why it matters to you”Running review, static analysis, tests, and CI separately for every worker would cost N times the review and N times the CI for N workers. The integration branch exists to prevent exactly that: N workers cost N dev budgets and one CI run, not N. You still decide what happens — the Lead stops at a confirm gate before it dispatches anything, and again at a Decision Queue for anything that genuinely needs a human call.
How you use it
Section titled “How you use it”Once workers have pushed their branches, the Lead runs the same sequence every time:
- Integrate — merge every worker’s branch onto one integration branch; a step that needs a real database or touches money, auth, or tenant isolation runs on the Lead’s side, not a worker’s throwaway worktree.
- Simplify — a cleanup pass over the merged diff: reuse, dead-code removal, altitude cleanup. This runs before the acceptance-criteria gate, on purpose — verifying against code that’s about to be rewritten would mean verifying it twice.
- AC + DoD gate — every acceptance criterion checked against concrete evidence (a file, a test, a commit), and the Definition of Done table filled in. Any failed DoD row blocks exactly like a failed AC.
- Verification — the change is run against something live, not just inferred from green tests; the receipt is written into the Story’s own plan.
- Quality gates — the repo’s static analysis and the affected test suites, run once over the whole merged diff.
- Docs — a documentation pass reads the diff and proposes changes; nothing lands without your approval.
- PR — one pull request opens for the whole wave. This is also the first moment CI runs.
- CI review — findings from CI and from PR review bots are collected, triaged, fixed, and pushed once; the ticket moves to In Review.
Limits & edge cases
Section titled “Limits & edge cases”Two mechanisms keep an autonomous run honest. Checkpoints — a named, durable record of which of the steps above a Story has passed, backed by a state file, so an interrupted run resumes instead of starting over. A circuit breaker — when the same step fails three times in a row, the pipeline stops and asks instead of thrashing.
The pipeline is autonomous up to the pull request and never past it. Claude opens it; you review it, you merge it, you close the ticket — delivery is human-only by design. After you merge, /we:merged does the mechanical close-out: worktrees and branches torn down, tickets moved to Done, the epic record refreshed. It does not merge or release anything on its own.
There is no separate local “bug hunt” before the PR — that question is asked exactly once, by the repo’s own CI review gates on the one pull request, not by an extra adversarial pass beforehand.