03 · The SDLC pipeline
How a task becomes a merged PR
When a task is real work, the PM steers it through an SDLC pipeline: plan, critique, build, test, review, docs, merge. The pipeline is a directed cyclic graph. Failure edges loop back, and guards stop the spin.
Forward edges in blue, failure edges in amber. A failed Test loops through Patch and re-runs. Review blockers take the same road.
1 · Why a graph
Progress is not guaranteed forward
Failure edges loop back
A failed Test loops to Patch. A needs-revision Critique loops back to Plan. Review blockers loop through Patch too. Work can revisit a stage many times before it lands.
Guards stop the spin
Because loops exist, the router enforces loop caps, PR locks, and oscillation guards. A task can revisit stages, and it can never cycle forever.
2 · The engine
Three files run the stage machine
The sdlc_router is a pure decision engine: it evaluates the guards and decides the next stage from the current state. The pipeline_graph defines the stage-to-stage edges and maps each stage to the skill that runs it. And pipeline_state is the persistent state machine that tracks per-stage status on the AgentSession itself.
Together they turn Issue → Plan → Critique → Build → Test → Review → Docs → Merge into executable transitions.
3 · The seam
Small stateless CLIs drive it
The pipeline engine is driven by a family of small, single-purpose CLIs that skills invoke as subprocesses. These stateless commands are the seam between the skills the agent runs and the durable session record.
- next-skillsdlc-tool next-skill
- Wraps the router's
decide_next_dispatchto pick the next stage to run. - stage-querysdlc-tool stage-query
- Reports enriched stage state, resolving the PR number and merge state through the
ghCLI. - verdictsdlc-tool verdict
- Records critique and review verdicts, with an ownership guard against cross-session writes.
4 · Enforcement
Lifecycle hooks: policy without memory
Claude Code fires hooks around every tool call and turn, and Valor wires them up to enforce rules the model would otherwise have to remember. Hooks are how the harness enforces policy and closes the loop without the model having to choose to behave.
| Hook | Fires | What it enforces |
|---|---|---|
| PreToolUse | Before every tool call | Teammate write allowlists, sensitive-path protection, tool budgets. |
| PostToolUse | After every tool call | Completes SDLC pipeline stages, injects subconscious memory recall. |
| Stop | At turn end | Drafts the user-facing reply and classifies delivery. |
5 · Stage by stage
What each stage does
| Stage | What happens | On failure |
|---|---|---|
| Issue | The work is captured as a self-contained GitHub issue. | — |
| Plan | A plan document scopes the work: approach, test impact, documentation. | — |
| Critique | The plan is reviewed before any code is written. | needs revision → Plan |
| Build | The code is written on a branch, following the plan. | — |
| Test | The suite runs; failures are classified against the baseline. | fail → Patch |
| Review | The PR is reviewed against the plan for blockers. | blockers → Patch |
| Docs | Documentation updates cascade from the change. | — |
| Merge | The PR lands. The plan migrates, learnings are extracted into memory. | terminal |