The pipeline — from plan to applied spec

You've classified your ticket and know where staging lives. Here is the full path a piece of work travels. Each arrow is a human gate — the pipeline pauses for your one-word approval rather than auto-advancing.

/sdd-plan → /sdd-spec-gap → /sdd-task-plan → /sdd-implement (×N) → /sdd-review → /sdd-ship → apply

The stages

• /sdd-plan (Shape 1 only) — drafts the staged proposal: rationale, full proposed spec file(s), apply manifest. The staged proposal becomes the spec of record for everything downstream.
• /sdd-spec-gap — reads the governing spec (staged or canonical, dev-env and repo-local) and the code, and returns a measured gap list. It also writes the tickets: gap items in specs/dev-plan/*.yml are the canonical, version-controlled backlog — the GitLab board is a disposable projection of them.
• /sdd-task-plan — for multi-commit work: decomposes gaps into one-commit tasks, each with a criterion (a shell command that exits 0 when done) and a dependency order.
• /sdd-implement — one task per run, strictly test-first: write the failing test, confirm it fails for the right reason, implement to green. Before any code, the draft plan faces three adversarial critics in parallel — conformance (does it match the spec?), risk (what breaks downstream?), and test-adequacy (does the test actually prove the mandate?). Any block verdict stops the task until a human decides. The critics are context-isolated: they see the spec and the plan, never the implementer's rationale.
• /sdd-review — certifies the whole slug against the spec before merge.
• /sdd-ship — pushes branches, opens MRs, gates on CI and integration tests, merges in dependency order.
• apply — after all branches merge, sdd_apply_staged.py pushes the staged spec to canonical (previous page). The loop closes: the golden state and the code now agree.

Why the critics earn their cost

The critics regularly catch what the author can't see from inside the plan: a mandate the plan quietly narrows, a downstream caller that breaks, a test that passes without proving anything. Treat a block as a gift — it arrived before the merge, not after. The decision history behind this design is in the SDD decision log.

What you can do now

• Walk a slug through its next stage — the router knows where it is; "where are we?" works.
• Read a task's criterion in tasks.md and run it yourself; exit 0 is the definition of done.
• When a critic blocks your plan: read the verdict's evidence, then revise or rebut — both are legitimate, silence is not.