pipeline

What this skill does

# Pipeline

**Value:** Flow -- continuous, gated progression from slice to shipped code
eliminates idle coordination overhead and makes quality evidence accumulate
automatically.

## Purpose

Orchestrates the build phase end-to-end: takes vertical slices from the queue,
dispatches TDD pairs, runs full-team code review before push, enforces mutation
testing and CI gates, and merges or escalates. The pipeline controller handles
all operational tasks (running tests, pushing code, managing git) so team member
agents focus exclusively on creative work.

## Practices

### Slice Queue Management

The pipeline reads vertical slices from event model output and maintains their
state in `.factory/slice-queue.json`. See `references/slice-queue.md` for the
full queue schema and operations.

Each slice carries a `context` block with enriched metadata for downstream
pipeline stages: `acceptance_scenarios` (full-stack GWT scenarios exercising
the application boundary, human-owned) and `domain_scenarios` (event-model
unit scenarios for commands and projections), an event model source path (so
the TDD pair can consult the original model), related slice IDs for cross-slice
dependency tracking, domain types referenced by the slice (enabling
pre-implementation type discovery), and UI components referenced (triggering
conditional context gathering when the slice touches the interface layer). See
`references/slice-queue.md` for the full two-tier scenario schema.

**Vertical slice integrity:** Every slice MUST deliver behavior through a
user-facing boundary (UI for a human) or an external-API boundary (for
third-party software consumers). Internal APIs that serve the application's
own front-end are NOT external — slices touching them still require UI
acceptance tests. There are no "domain-only," "infrastructure-only," or
"backend-only" slices — infrastructure exists to serve functionality. If a
slice does not include a user-facing or external-API boundary, it is not a
vertical slice and MUST NOT enter the queue. Any rare deviation (e.g.,
backend restructuring with no net-new acceptance tests) requires explicit
human approval before the slice enters the queue.

**Ordering strategy:** Walking skeleton first (the thinnest end-to-end path),
then by dependency graph (slices whose predecessors are complete), then by
priority. The first slice in any project must always be a walking skeleton.

**Slice states:** pending, active, blocked, completed, escalated. Only one
slice may be active at a time unless running at full autonomy level, where
parallel slices operate in isolated git worktrees (one worktree per active
slice at `.factory/worktrees/<slice-id>`). See `references/autonomy-levels.md`.

### Per-Slice Pipeline

Each slice flows through a fixed sequence of stages. Every stage has a binary
quality gate. A gate failure routes back for rework; it never skips forward.

1. **Decompose** -- Invoke `task-management` to break the slice into leaf
   tasks with acceptance criteria. Output: task tree in
   `.factory/audit-trail/slices/<slice-id>/decomposition.json`.

2. **Slice Readiness Review** (full ensemble, before first TDD cycle)
   - Convene the full ensemble using subagent spawning
   - Produce an approved Slice Plan document including the Agent Delivery Contract
     (see `references/slice-readiness-review.md` and `references/agent-delivery-contract.md`)
   - Gate: the build trio does NOT start until the plan is approved (all members,
     zero open items, human sign-off on Contract Tiers 1–3, zero active-slice
     domain type or bounded context conflicts)
   - Create Tasks from the plan's Task Breakdown section with `blockedBy` encoding
     component pre-work dependencies

3. **Implement** -- **TDD skill invocation gate (BLOCKING):** Before
   dispatching any TDD work, invoke the `tdd` skill. The TDD skill detects
   harness capabilities and loads the appropriate strategy entry-point
   (orchestrator.md for subagent strategy, chaining rules for chaining
   strategy). The pipeline MUST NOT dispatch TDD phases until the TDD skill's
   orchestration rules are loaded — without them, the pipeline lacks scenario
   boundary classification, outside-in progression enforcement, and
   drill-down rules. This is not optional prose; it is a prerequisite gate.

   Before dispatching the TDD pair, the pipeline gathers
   pre-implementation context scoped to what TDD needs: Contract Tiers 2–3
   (acceptance scenarios and feature constraints), existing domain types
   matching the slice's referenced types, and event model context. If the
   slice touches UI, design system components are included. Do NOT pass full
   conversation history or all contract tiers — see `references/tokenomics.md`
   for per-phase context scoping rules.

   **TDD dispatch (the pipeline controller IS the orchestrator):**
   The pipeline controller performs capability detection (per TDD skill's
   hierarchy) and dispatches directly. Do NOT spawn a single "orchestrator"
   subagent -- that hides work and bypasses strategy detection.

   - **Agent tool available:** The pipeline controller acts as the
     orchestrator per `tdd/references/orchestrator.md`, spawning
     per-phase subagents using `Agent(subagent_type="<agent-name>",
     prompt="...")` with fresh context each time. When `.claude/agents/`
     definitions exist, named personas are used for ping and pong roles
     per `tdd/references/ping-pong-pairing.md`. The orchestrator collects
     results from each subagent and passes them as context to the next.
   - **Neither available:** The pipeline controller runs chaining mode,
     playing each TDD role sequentially per the TDD skill's chaining
     section.

   The TDD pair then works through red-green-domain-commit cycles without
   consensus rounds. No team discussion during implementation. Output: passing
   tests, committed code, cycle evidence in
   `.factory/audit-trail/slices/<slice-id>/tdd-cycles/`.

4. **Review** -- Before pushing, invoke `code-review` with the full team for
   three-stage mob review (spec compliance, code quality, domain integrity).
   All review findings must be addressed before proceeding. See
   `references/gate-definitions.md` for review gate criteria.

5. **Address feedback** -- Route review findings back to the TDD pair. The
   pair fixes via their existing ping-pong process. Re-review scoped to
   flagged concerns only (unless critical-category feedback).

6. **Mutation test** -- Invoke `mutation-testing` scoped to changed files.
   Required: 100% kill rate. Survivors route back to the TDD pair.

7. **Push and CI** -- Pipeline pushes the branch and waits for CI. On infra
   failures at standard or full autonomy, auto-retry once. On test failures,
   route to triage.

8. **Merge or flag** -- If all gates pass, merge (auto at full autonomy,
   manual otherwise). If any gate failed after exhausting rework budget,
   escalate to human.

### Quality Gates

Five binary gates. Each requires structured evidence. See
`references/gate-definitions.md` for full criteria, evidence schemas, and
failure routing.

| Gate | Pass Criteria | Failure Route |
|------|--------------|---------------|
| TDD | Acceptance scenario test passes (boundary-level), all units pass, domain review approved | Back to tdd pair |
| Review | All three stages PASS | Back to tdd pair with findings |
| Mutation | 100% kill rate on changed files | Back to tdd pair with survivors |
| CI | Pipeline green | ci-integration triage |
| Merge | All upstream gates pass, no blocking escalations, branch current | Rebase and re-gate |

### Rework Protocol

Gate failures route back to the appropriate skill. Each gate allows a maximum
of 3 rework cycles per slice. After 3 failures at the same gate, the pipeline
halts the slice, compiles full context (all attempts, all evidence), and
escalates to the human. See `references/rework-protocol.md` for routing rules
and tracking schema.

### Progressive Autonomy

The pipeline operat