task-pipeline-skill 0.10.0 → 0.17.1

package/plugins/task-pipeline/commands/task-pipeline.md

@@ -1,16 +1,24 @@
 ---
-description: Run a task through task-pipeline — an intake grill that expands the request, then docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki.
+description: Run a task through task-pipeline — an intake grill that expands the request, then docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki → acceptance.
 argument-hint: <one-line task description>
 ---
 Use the `task-pipeline` skill to run the task below through all gated stages —
 **stage 0 intake grill** → docs study → brainstorm → spec → plan → subagent
-build → tests → lint/deploy → post-deploy → docs/wiki. Start with the **intake
-grill**: interview the operator one question at a time (with a recommended answer
-each, exploring the codebase before asking) until every decision branch is
-resolved and the brief is locked — so the rest runs autonomously. For any
-user-facing task, recommend/use **super-ux**. Honor every stage gate by its type
-(`auto` = verify yourself; `manual` = wait for explicit go) and emit the
-per-stage model reminder when the recommended model differs from the current one.
+build → tests → lint/deploy → post-deploy → docs/wiki → **acceptance**. **Every stage's doctrine is
+built into the skill** (`references/{grill,brainstorm,decomposition,spec,planning,build,review,tdd,acceptance,loop-guard}.md`)
+— no companion plugin is required for any of them. The **intake grill is
+mandatory** (`references/grill.md`): interview the
+operator one question at a time (with a recommended answer each, exploring the
+codebase before asking) until every decision branch is resolved, applying the
+grill's **domain awareness** (challenge terms against `CONTEXT.md`, sharpen fuzzy
+language, ADRs for hard-to-reverse calls) and covering the **autonomy sweep** (what
+would otherwise stop stages 1→10: docs sources, branch/tracker policy, test and lint
+commands, deploy target and authorization, log locations, docs/wiki targets) —
+until the brief is locked — including the **REQ table**, the request as an addressable list where every row names how it is verified — so the rest runs autonomously and the final stage can account for all of it. The list is frozen: adding is free, removing needs the operator's agreement. Anything deferred goes into the carry-over ledger the moment it's said. For any user-facing task, recommend/use
+**super-ux**. **If the brief describes a platform rather than a change**, stage 2 also cuts it into modules (`references/decomposition.md`) — module map committed, walking skeleton first, every REQ in exactly one module — and stages 3→10 then run per module, one brick at a time. **If any loop starts undoing an earlier pass** (same file edited twice for the same reason, a closed finding returning, a third entry into one stage), stop and run the loop guard (`references/loop-guard.md`): name both shapes, escalate to the layer that owns the conflict, re-plan the check as an ordered list, then go item by item. Honor every stage gate by its type (`auto` = verify yourself;
+`manual` = wait for explicit go). Confirm the **model once at preflight** —
+recommend the most capable one the environment offers, never a hardcoded id — then
+run the whole pipeline on it without re-asking.
 
 Task: $ARGUMENTS
 

package/plugins/task-pipeline/skills/task-pipeline/SKILL.md

@@ -1,41 +1,59 @@
 ---
 name: task-pipeline
-description: "Use when running a substantial task through the full end-to-end delivery pipeline — an up-front intake grill that expands the request into a complete brief, then docs study, brainstorm, spec, plan, subagent-driven build, test suite, lint/deploy, post-deploy log check, and docs/wiki sync — as gated stages built on the superpowers skills. Use when the user wants to run a task through the pipeline, asks for the full cycle / полный цикл / прогони по конвейеру, invokes /task-pipeline, or starts any substantial feature, fix, or build that should follow the disciplined cycle rather than ad-hoc coding. Grills the operator first so the rest runs autonomously; recommends super-ux for any user-facing task; reminds which model to switch to per stage; reads host-project conventions for deploy/docs/wiki so it stays project-agnostic."
+description: "Use when running a substantial task through the full end-to-end delivery pipeline — an up-front intake grill that expands the request into a complete brief, then docs study, brainstorm, spec, plan, subagent-driven build, tests, lint/deploy, post-deploy log check, docs/wiki sync and acceptance — as gated stages whose doctrine is built entirely into this skill (no required companion skills). Triggers - 'run this through the pipeline' / 'прогони по конвейеру', 'the full cycle' / 'полный цикл', /task-pipeline, or any substantial feature, fix, or build that should follow the disciplined cycle rather than ad-hoc coding. The intake grill is mandatory - it front-loads every decision, including the per-stage autonomy sweep, so stages 1→10 run without mid-flight questions; recommends super-ux for user-facing work; confirms one model up front (most capable available, never a hardcoded id); reads host-project conventions for deploy/docs/wiki so it stays project-agnostic."
 ---
 
 # task-pipeline
 
-Thin orchestrator. Runs a task through **gated stages**, each built on an
-existing skill. Keeps the main thread disciplined: no stage advances until its
-gate passes; each stage names the model to use.
+Self-contained orchestrator. Runs a task through **gated stages**, each carrying its
+own built-in doctrine — no companion plugin required. Keeps the main thread
+disciplined: no stage advances until its gate passes; the whole run uses one model,
+confirmed before it starts.
 
 **Grill first, then run autonomously.** A one-line task ("make me feature X") is
-never enough to finish without a human in the loop. Stage 0 **grills the operator
-up front** — a relentless, one-question-at-a-time interview that resolves every
-decision branch — and locks the answers into a brief. That front-loads all the
-human input so stages 1→9 can run to the end with only the built-in gate
-approvals, not mid-flight discovery.
+never enough to finish without a human in the loop. Stage 0 is **mandatory**: a
+relentless, one-question-at-a-time interview that resolves every decision branch
+*and* sweeps stages 1→10 for anything that would stop the run later — then locks
+the answers into a brief. Autonomy is bought there or not at all; every question
+skipped at stage 0 comes back as an interruption at stage 6.
 
 **Config contract: [`pipeline.schema.json`](pipeline.schema.json).** A pipeline is
 a machine-readable config — an ordered list of stages, each with `skills[]` (the
 skills/agents that run it) and a `gate {type, check}`. The schema is the universal
 contract; it imposes **no** specific stages, skills, or gate assignments.
 [`pipeline.example.json`](pipeline.example.json) is a **copy-and-rewrite example**
-that encodes this plugin's own default flow (stage 0 intake + the 1→9 stages
+that encodes this plugin's own default flow (stage 0 intake + the 1→10 stages
 tabled below) and an optional, toggleable `release` block. Any project replaces it
 wholesale — any number of stages, run by its own skills/agents, with its own gate
 types (see *Bring your own skills*). Each gate has a **type**: `auto` (the
 orchestrator verifies the `check` itself, pass/fail) or `manual` (wait for an
 explicit operator go); which stages are manual is the operator's call.
 
-## Prerequisite
-
-Requires the **superpowers** skills. Preflight: confirm `superpowers:brainstorming`,
-`superpowers:writing-plans`, `superpowers:subagent-driven-development`,
-`superpowers:using-git-worktrees`, `superpowers:test-driven-development` resolve.
-If missing → tell the operator to install from **https://github.com/obra/superpowers**
-(`/plugin marketplace add obra/superpowers` → `/plugin install superpowers@superpowers`)
-and stop.
+## Prerequisites — none required
+
+**Every stage's doctrine ships inside this skill.** There is no required companion
+plugin, nothing to resolve at preflight, no version skew with someone else's repo,
+and no stage that can fail because a dependency is missing:
+
+| Stage | Built-in doctrine |
+|---|---|
+| 0 Intake grill | [`references/grill.md`](references/grill.md) |
+| 2 Brainstorm | [`references/brainstorm.md`](references/brainstorm.md) |
+| 2 Decompose (platforms only) | [`references/decomposition.md`](references/decomposition.md) |
+| 3 Spec | [`references/spec.md`](references/spec.md) |
+| 4 Plan | [`references/planning.md`](references/planning.md) |
+| 5 Build (worktree, subagents, fix loop) | [`references/build.md`](references/build.md) + [`references/review.md`](references/review.md) |
+| 5–6 TDD + suite gate | [`references/tdd.md`](references/tdd.md) |
+| 10 Acceptance (REQ close-out) | [`references/acceptance.md`](references/acceptance.md) |
+| any repeating loop | [`references/loop-guard.md`](references/loop-guard.md) |
+
+**Optional bridge.** If the operator already runs an equivalent skill set (e.g.
+`superpowers:brainstorming` / `writing-plans` / `subagent-driven-development` /
+`using-git-worktrees` / `test-driven-development`), it can be mapped onto stages
+2/4/5/6 in `pipeline.json` → `skills[]`. That is a **substitution, never a
+requirement**: the built-in doctrine is normative, the gates in
+`references/stages.md` still govern, and nothing detects, recommends or waits for
+an external provider.
 
 **super-ux — recommended for ANY user-facing task.** The moment a task implies a
 user interface (web / mobile / CLI / TUI — a screen, a command, a visible
@@ -56,63 +74,119 @@ workflow for the WHY→UI→scenario chain (`/ux`, `ux-foundation`, `ux-flows`,
   (or `npx skills add ssheleg/super-ux`). For UI tasks the spec gate **requires**
   it — install before stage 3, otherwise stop and ask the operator to install.
 
-**grill-me (optional, enhances stage 0).** If the `grill-me` / `grilling` skill
-resolves, stage 0 uses it; otherwise stage 0 runs its own built-in grill loop —
-no hard dependency. Install (optional): `npx skills add mattpocock/skills` or the
-engineering-advanced-skills marketplace.
+**The grill is built in — no companion skill, nothing to install.** Stage 0 ships
+with this skill: the full doctrine lives in [`references/grill.md`](references/grill.md)
+(interview loop, domain awareness, autonomy sweep, output). It is **mandatory** —
+no "clear enough task" exemption, no starting stage 1 without a committed,
+operator-confirmed brief. The one sanctioned bypass is the entry-from-super-ux
+short-circuit, and even that demands a scope confirmation.
+
+It also produces the **REQ spine**: the request as an addressable list of
+requirements, each naming how it will be verified. Stages 3–5 trace to those ids,
+stage 4's gate is a mechanical set-comparison against them, and **stage 10 accounts
+for every one** — which is what turns the pipeline from a funnel into a circle.
+
+Two things the grill does beyond clarifying the request:
+- **Domain awareness.** It reads the project's own `CONTEXT.md` / `docs/adr/` and
+  holds the operator to them — challenging terms that conflict with the glossary,
+  sharpening overloaded words, stress-testing with concrete scenarios, and
+  flagging where the code contradicts what was just said. Resolved terms are
+  written to `CONTEXT.md` as they land; genuinely hard-to-reverse decisions get an
+  ADR.
+- **The autonomy sweep.** It pre-resolves what would otherwise stop stages 1→10
+  mid-flight (test/lint/deploy commands, branch policy, log locations, docs
+  targets, the model decision, deploy authorization). Autonomy is bought here or
+  not at all — an unasked question is a scheduled interruption.
 
 ## How to run
 
 1. Restate the task in one line. Create a **TaskList: one task per stage, starting
    with stage 0** (survives context loss; lets you resume). Then run the
-   **companion preflight** (`references/companion-skills.md`): detect which
-   companion skills resolve and emit the recommendation block — install the
-   required/recommended ones (superpowers always; super-ux for UI tasks) before
-   proceeding.
-2. **Run stage 0 (Intake grill) first** — grill the operator until shared
-   understanding is reached and the brief is locked (`references/stages.md` → 0).
-   Do not touch stage 1 before the brief is confirmed. **Entered from super-ux?**
+   **companion preflight** (`references/companion-skills.md`): the stage doctrine
+   is built in, so this only checks the *optional* companions (super-ux for UI
+   tasks, context7, wiki-update) and emits ONE block covering them
+   **and the model decision** (`references/model-tiering.md`): recommend
+   the most capable model available, let the operator confirm or override, record
+   it. Ask once, here.
+2. **Run stage 0 (Intake grill) — always, no exceptions.** Grill until shared
+   understanding is reached, the autonomy sweep is covered, **the REQ table is
+   written (one row per independently verifiable deliverable, each naming its
+   check)** and the brief is locked
+   (`references/stages.md` → 0). Do not touch stage 1 before the brief is
+   committed and confirmed. **Entered from super-ux?**
    (a validated `docs/ux/` chain and/or a `docs/ux/plans/…` fix plan already
    exists — super-ux's `/ux` hands off here) → don't re-grill or rebuild the UX
    chain: just check it's OK (`/ux-lint` green), confirm scope in one line, and
    skip ahead to the first stage with real work (see `references/stages.md` → 0).
-3. Walk stages 1→9. Before each: **model check** (see `references/model-tiering.md`) —
-   if recommended ≠ current, emit the reminder block and wait for the operator to `/model`.
+3. Walk stages 1→10 on the model confirmed at preflight. **Don't re-ask about the
+   model at every boundary** — only when the operator recorded a per-stage override
+   map and the next stage's entry differs (`references/model-tiering.md`).
+   **Is the brief a platform rather than a change?** Then stage 2 also cuts it into
+   modules (`references/decomposition.md`) and stages 3→10 run **per module** in
+   build order, one brick at a time — stages 0–2 run once, and the module map's
+   status column is the resume point (`references/stages.md` → *The program loop*).
 4. Do **not** advance until the stage **gate** passes (`references/stages.md`).
    Honor the gate **type**: for `auto`, verify the gate's `check` yourself and
    stop/return on fail; for `manual`, present the result and **wait for the
    operator's explicit "continue"/go** — an auto gate never substitutes for a
    required manual approval.
-5. Cross-cutting, every stage: task tracker + conventional commits per host
-   conventions; worktree isolation for the build; honest degradation (never claim a
-   failed/skipped step succeeded); outward/irreversible actions (deploy, publish,
-   repo create) need explicit operator go.
+5. Cross-cutting, every stage: **answer from the brief's autonomy section rather
+   than asking again** — it was grilled precisely so you wouldn't have to;
+   **anything deferred, dropped or left half-done goes into the carry-over ledger
+   the moment it's said** — deferred out loud is forgotten; **never narrow the task
+   silently** — the REQ list is frozen, adding is free, removing needs the
+   operator's explicit agreement; **when a loop starts undoing an earlier pass —
+   the same file edited twice for the same reason, a closed finding coming back, a
+   third entry into one stage — stop and run the loop guard**
+   (`references/loop-guard.md`): name the two shapes, escalate to the layer that
+   owns the conflict, re-plan the check as an ordered list, then go through it one
+   item at a time; task
+   tracker + conventional commits per host conventions; worktree isolation for the
+   build, integrated back per the brief's branch policy before stage 7; honest
+   degradation (never claim a failed/skipped step succeeded);
+   outward/irreversible actions (deploy, publish, repo create, opening a PR) need explicit
+   operator go — or a **specific** standing authorization recorded in the brief
+   (named target + preconditions; a vague "do everything" is not one).
 
 ## Stages (detail in `references/stages.md`)
 
-| # | Stage | Model | Invoke | Gate | Type |
-|---|---|---|---|---|---|
-| 0 | Intake grill | Fable | `grill-me` / `grilling` if present, else built-in grill loop | shared understanding reached; brief locked + confirmed | manual |
-| 1 | Docs study | Fable | `context7` (resolve-library-id → get-library-docs) / `context7-docs` | contracts grounded on fetched docs | auto |
-| 2 | Brainstorm | Fable | `superpowers:brainstorming` + **UI detection** | design approved; UI verdict recorded | manual |
-| 3 | Spec | Fable | **UI → super-ux chain first** (`/ux` → `ux-foundation` CJM → `ux-flows` screens → `ux-scenarios` → `/ux-lint`), then spec `docs/superpowers/specs/…-design.md` | committed + reviewed; UI: chain validated, linter green, scenarios/`SCR-` traced | manual |
-| 4 | Plan | Fable | `superpowers:writing-plans` → `docs/superpowers/plans/…md` | parallel-ready, DoD per task | auto |
-| 5 | Dev | **Opus** | `superpowers:using-git-worktrees` + `superpowers:subagent-driven-development` (TDD) | tasks DONE, TDD green per task | auto |
-| 6 | Tests | **Opus** | host test runner + `superpowers:test-driven-development` | full suite green; new/changed code covered | auto |
-| 7 | Lint + deploy | host | host lint → deploy per host convention | lint clean + suite green before deploy; deploy needs go | manual |
-| 8 | Post-deploy | host | tail deploy logs / health-check | clean boot or honest degradation report | auto |
-| 9 | Docs + wiki | host | host module docs/runbook rules → `wiki-update` | docs synced, wiki synced | auto |
-
-## Model reminder (emit at a boundary when recommended ≠ current)
-
-> ⏸ **Stage N (`<stage>`) recommends `<model>` (`<id>`).** You're on `<current>`.
-> Switch: `/model <id>` — then say "continue". *(Reminder only — override if you
-> don't have that model.)*
+All stages run on the **one model confirmed at preflight** (default: the most
+capable available — see `references/model-tiering.md`).
+
+| # | Stage | Invoke | Gate | Type |
+|---|---|---|---|---|
+| 0 | Intake grill — **mandatory** | built in: [`references/grill.md`](references/grill.md) | shared understanding reached; autonomy sweep covered; brief locked + confirmed | manual |
+| 1 | Docs study | `context7` (resolve-library-id → get-library-docs) / `context7-docs` | contracts grounded on fetched docs | auto |
+| 2 | Brainstorm + decompose | built in: [`references/brainstorm.md`](references/brainstorm.md) + **UI detection** + [`references/decomposition.md`](references/decomposition.md) for platforms | design approved; UI verdict recorded; every REQ answered; platform: module map approved | manual |
+| 3 | Spec | built in: [`references/spec.md`](references/spec.md) — **UI → super-ux chain first** (`/ux` → `ux-foundation` CJM → `ux-flows` screens → `ux-scenarios` → `/ux-lint`), then spec `docs/superpowers/specs/…-design.md` | committed + reviewed; UI: chain validated, linter green, scenarios/`SCR-` traced | manual |
+| 4 | Plan | built in: [`references/planning.md`](references/planning.md) → `docs/superpowers/plans/…md` | parallel-ready, DoD per task | auto |
+| 5 | Dev | built in: [`references/build.md`](references/build.md) (worktree → subagent per task → review loop → integrate) + [`references/tdd.md`](references/tdd.md) | tasks DONE, TDD green per task, branch integrated per the brief | auto |
+| 6 | Tests | host test runner + built-in [`references/tdd.md`](references/tdd.md) | full suite green; new/changed code covered | auto |
+| 7 | Lint + deploy | host lint → deploy per host convention | lint clean + suite green before deploy; deploy needs a go (or the brief's specific standing authorization) | manual |
+| 8 | Post-deploy | tail deploy logs / health-check | clean boot or honest degradation report | auto |
+| 9 | Docs + wiki | host module docs/runbook rules → `wiki-update` | docs synced, wiki synced | auto |
+| 10 | **Acceptance** | built in: [`references/acceptance.md`](references/acceptance.md) | every REQ accounted for with evidence; ledger has no unresolved row; operator signs off | manual |
+
+## Model — ask once, at preflight
+
+Default recommendation: **the most capable reasoning model the environment
+offers** (currently the latest Opus generation — read that as a tier, not a
+string). **Never hardcode a model id**: generations ship, tiers get renamed, and
+the operator may be on another provider entirely — resolve the top tier available
+at runtime. Stage configs use provider-agnostic tokens (`default` / `inherit`).
+
+> 🧠 **Model for this run:** recommended **`<top tier available>`**. You're on
+> `<current>`. `/model <id>` to switch, or "keep current", or name per-stage
+> overrides. *(Reminder only — if that tier isn't available, say which one you're
+> using and continue.)*
+
+Record the answer in the brief; don't re-ask per stage. Stage-5 subagents are
+pinned to the confirmed model automatically. Detail: `references/model-tiering.md`.
 
 ## Bring your own skills
 
-The stages above (stage 0 intake + 1→9) are the **example** flow (grill +
-superpowers + a super-ux UX track for user-facing tasks + host conventions). A
+The stages above (stage 0 intake + 1→10) are the **example** flow (this skill's
+built-in doctrine + a super-ux UX track for user-facing tasks + host conventions). A
 host project owns its pipeline: copy `pipeline.example.json` → `pipeline.json`,
 then define its **own** stages (any count), point each stage's `skills[]` at the
 skills/agents its environment resolves, set each `gate.type` (`auto`/`manual`) to
@@ -123,9 +197,17 @@ automation is on — `pipeline.schema.json` is the only contract.
 ## References
 
 - `pipeline.schema.json` — the universal pipeline config contract (stages + release)
-- `pipeline.example.json` — this plugin's default flow (stage 0 + 1→9) + release, as config
+- `pipeline.example.json` — this plugin's default flow (stage 0 + 1→10) + release, as config
+- `references/grill.md` — the built-in stage-0 grill: loop, domain awareness, autonomy sweep
+- `references/acceptance.md` — the built-in stage-10 close-out: REQ coverage, evidence, sign-off
+- `references/brainstorm.md` — stage 2: design dialogue, approaches, UI detection, hard gate
+- `references/spec.md` — stage 3: UX track order, the spec contract, self-review, review gate
+- `references/planning.md` — stage 4: zero-context plan format, parallel groups, no placeholders
+- `references/build.md` — stage 5: isolation, ledger, subagent task loop, fix loop, final review
+- `references/review.md` — the review rubric, diff packages and the three reviewer prompts
+- `references/tdd.md` — stages 5–6: the iron law, red/green/refactor, the suite gate
 - `references/stages.md` — per-stage detail + exact gate criteria + gate types
 - `references/model-tiering.md` — model map, ids, the `/model` reminder mechanic, override
-- `references/conventions.md` — how stages 6–9 read the host project's CLAUDE.md
+- `references/conventions.md` — how stages 6–10 read the host project's CLAUDE.md
 - `references/companion-skills.md` — companion skills, install lines, preflight recommendation
 - `references/artifacts.md` — the canonical document/artifact layout per stage

package/plugins/task-pipeline/skills/task-pipeline/pipeline.example.json

@@ -1,27 +1,26 @@
 {
   "$schema": "./pipeline.schema.json",
   "version": 1,
-  "_note": "EXAMPLE ONLY — copy this file, rename to pipeline.json in your project, and rewrite it. This particular example encodes the plugin's own default flow (an up-front intake grill + superpowers + a super-ux UX track for user-facing tasks); it is NOT a fixed contract. Your project defines its own stages (any count), each executed by your own skills/agents, with your own gate types. The universal contract is pipeline.schema.json; test/validate.py checks this example against it. gate.type: auto = orchestrator verifies the check itself (pass/fail); manual = wait for an explicit operator go. Which stages are manual vs auto is the operator's decision, not the plugin's.",
+  "_note": "EXAMPLE ONLY — copy this file, rename to pipeline.json in your project, and rewrite it. This particular example encodes the plugin's own default flow (an up-front intake grill + this skill's own built-in stage doctrine + a super-ux UX track for user-facing tasks); it is NOT a fixed contract. Your project defines its own stages (any count), each executed by your own skills/agents, with your own gate types. Stage models use provider-agnostic tokens ('default' = the model confirmed for the run, 'inherit' = whatever the operator is on) — never hardcode a vendor model id, it goes stale. The universal contract is pipeline.schema.json; test/validate.py checks this example against it. gate.type: auto = orchestrator verifies the check itself (pass/fail); manual = wait for an explicit operator go. Which stages are manual vs auto is the operator's decision, not the plugin's. Any repeating loop in a run (fix loop, a re-entered stage, the per-module program loop) is bound by the loop guard: log every repeat touch, stop on oscillation, escalate to the layer that owns the conflict, then re-check in a planned order.",
   "stages": [
     {
       "id": 0,
       "state": "intake",
       "name": "Intake grill",
-      "model": "claude-fable-5",
+      "model": "default",
       "skills": [
-        "grill-me",
-        "grilling"
+        "task-pipeline:grill"
       ],
       "gate": {
         "type": "manual",
-        "check": "grill the operator one question at a time (recommended answer per question; explore codebase/docs before asking) until shared understanding is reached — every decision branch has a recorded answer or explicit deferral, no open contradictions; UI verdict recorded (arms super-ux); decisions locked into a committed task brief the operator confirms before stage 1"
+        "check": "MANDATORY stage — never skipped (only sanctioned bypass: the entry-from-super-ux short-circuit). The grill is built into the skill (references/grill.md) — no companion to install. Per its contract: one question at a time, a recommended answer with each, explore the codebase/docs before asking, depth-first, contradictions reconciled; domain awareness applied (terms challenged against CONTEXT.md, ADRs recorded for hard-to-reverse calls). The autonomy sweep is covered — every stage 1-10 has its blockers pre-resolved (docs sources, branch/tracker policy, test + lint commands, deploy target and authorization, log/health locations, docs+wiki targets) or is explicitly marked 'stop and ask here'. UI verdict recorded (arms super-ux); model decision recorded. All of it locked into a committed task brief the operator confirms before stage 1. The REQ table is written — one row per independently verifiable deliverable, each naming how it is verified — and frozen: adding later is free, removing or narrowing needs the operator's explicit agreement. The carry-over ledger is seeded."
       }
     },
     {
       "id": 1,
       "state": "docs-study",
       "name": "Docs study",
-      "model": "claude-fable-5",
+      "model": "default",
       "skills": [
         "context7",
         "context7-docs"
@@ -34,91 +33,93 @@
     {
       "id": 2,
       "state": "brainstorm",
-      "name": "Brainstorm",
-      "model": "claude-fable-5",
+      "name": "Brainstorm + decompose",
+      "model": "default",
       "skills": [
-        "superpowers:brainstorming"
+        "task-pipeline:brainstorm",
+        "task-pipeline:decompose"
       ],
       "gate": {
         "type": "manual",
-        "check": "the user approves the design AND the UI verdict is recorded (does the task touch a user-facing surface — web/mobile/CLI/TUI? this arms the stage-3 UX track)"
+        "check": "the user approves the design AND the UI verdict is recorded (does the task touch a user-facing surface — web/mobile/CLI/TUI? this arms the stage-3 UX track). Every REQ is answered by the design, or explicitly dropped by the operator into the carry-over ledger. For a platform (several independent capabilities or shippable surfaces): the module map specs/<topic>-modules.md is committed and approved — brick criteria met or excepted in writing, dependency graph acyclic, build order topological with the walking skeleton first, every REQ mapped to exactly one module, cross-module contracts named with their owner. Single-module work records 'single module: <name>' instead — a skipped decomposition is a recorded decision, never an omission"
       }
     },
     {
       "id": 3,
       "state": "spec",
       "name": "Spec",
-      "model": "claude-fable-5",
+      "model": "default",
       "skills": [
         "super-ux:ux-foundation",
         "super-ux:ux-flows",
         "super-ux:ux-scenarios",
-        "superpowers:brainstorming"
+        "task-pipeline:spec"
       ],
       "gate": {
         "type": "manual",
-        "check": "UX track ran FIRST for user-facing tasks (/ux -> ux-foundation CJM -> ux-flows screens -> ux-scenarios -> /ux-lint green); spec committed and user-reviewed; every user-facing requirement traces to a scenario ID"
+        "check": "UX track ran FIRST for user-facing tasks (/ux -> ux-foundation CJM -> ux-flows screens -> ux-scenarios -> /ux-lint green); spec committed and user-reviewed; every user-facing requirement traces to a scenario ID. Every spec section carries covers: REQ-... and every REQ appears in at least one section."
       }
     },
     {
       "id": 4,
       "state": "plan",
       "name": "Plan",
-      "model": "claude-fable-5",
+      "model": "default",
       "skills": [
-        "superpowers:writing-plans"
+        "task-pipeline:plan"
       ],
       "gate": {
         "type": "auto",
-        "check": "every spec requirement maps to a task; no placeholders; parallel-group tasks share no files; UI tasks name the scenario ID(s) and SCR- screen(s) they implement in their DoD"
+        "check": "SET EQUALITY: the REQ ids in the brief equal the union of Implements: across plan tasks — a non-empty difference fails the gate and is reported as the explicit list of dropped requirements. Plus: every spec requirement maps to a task; no placeholders; names and types consistent across tasks; every task carries a verifiable DoD; parallel-group tasks share no files; UI tasks name the scenario ID(s) and SCR- screen(s) they implement in their DoD"
       }
     },
     {
       "id": 5,
       "state": "dev",
       "name": "Dev",
-      "model": "claude-opus-5",
+      "model": "default",
       "skills": [
-        "superpowers:using-git-worktrees",
-        "superpowers:subagent-driven-development"
+        "task-pipeline:build",
+        "task-pipeline:review"
       ],
       "gate": {
         "type": "auto",
-        "check": "all plan tasks DONE (two-stage review: spec compliance, then code quality); full test suite green"
+        "check": "all plan tasks DONE — the per-task review returns three verdicts (spec compliance, REQ satisfied, code quality); every finding fixed or parked with a written ruling; no task left BLOCKED; full test suite green; the branch integrated per the brief's branch policy (base synced, suite green on the result, worktree removed) — or the operator's explicit 'leave it unmerged' recorded. Every parked finding and implementer concern is harvested into the carry-over ledger before the scratch workspace is deleted."
       }
     },
     {
       "id": 6,
       "state": "tests",
       "name": "Tests",
-      "model": "claude-opus-5",
+      "model": "default",
       "skills": [
-        "superpowers:test-driven-development"
+        "host:test-runner",
+        "task-pipeline:tdd"
       ],
       "gate": {
         "type": "auto",
-        "check": "full suite green (not just new tests); new/changed code covered; no skip/xfail smuggling a red suite past the gate"
+        "check": "full suite green (not just new tests); new/changed code covered including failure paths; no skip/xfail smuggling a red suite past the gate; tests assert real behavior, not mock behavior"
       }
     },
     {
       "id": 7,
       "state": "lint-deploy",
       "name": "Lint + deploy",
-      "model": "inherit",
+      "model": "default",
       "skills": [
         "host:lint",
         "host:deploy"
       ],
       "gate": {
         "type": "manual",
-        "check": "lint clean and full suite green before deploy; deploy is outward and needs explicit operator go"
+        "check": "lint clean and full suite green before deploy; deploy is outward and needs explicit operator go — or the specific standing authorization recorded in the stage-0 brief (named target + named preconditions; a vague 'do everything' is not one). No REQ is still open; a partial ships only with the operator's explicit acceptance."
       }
     },
     {
       "id": 8,
       "state": "post-deploy",
       "name": "Post-deploy",
-      "model": "inherit",
+      "model": "default",
       "skills": [
         "host:health-check"
       ],
@@ -131,7 +132,7 @@
       "id": 9,
       "state": "docs-wiki",
       "name": "Docs + wiki",
-      "model": "inherit",
+      "model": "default",
       "skills": [
         "host:module-docs",
         "wiki-update"
@@ -140,6 +141,19 @@
         "type": "auto",
         "check": "docs in sync with code in the same change; wiki synced; dangling links fixed"
       }
+    },
+    {
+      "id": 10,
+      "state": "acceptance",
+      "name": "Acceptance",
+      "model": "default",
+      "skills": [
+        "task-pipeline:acceptance"
+      ],
+      "gate": {
+        "type": "manual",
+        "check": "Close the circle: every REQ in the brief has a status (verified / partial / deferred / dropped) — none unknown; every verified carries evidence (a passing test name, file:line, a command and its output, or a scenario ID) — 'done' without evidence is downgraded to partial, not upgraded; every partial names what is missing and where it is tracked; every deferred/dropped has the operator's agreement and, for deferred, a tracker entry; no carry-over row is left unresolved; and the operator answers the closing question — here is what you asked for, here is what shipped, here is what is deferred, what is missing? — and signs off"
+      }
     }
   ],
   "release": {

package/plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json

@@ -45,7 +45,7 @@
         "id": { "type": "integer", "description": "Optional ordinal." },
         "state": { "type": "string", "minLength": 1, "description": "Unique stable key for the stage." },
         "name": { "type": "string", "description": "Optional human label." },
-        "model": { "type": "string", "description": "Optional recommended model id for the stage." },
+        "model": { "type": "string", "description": "Optional model for the stage. Prefer a provider-agnostic token over a vendor id, which goes stale as generations ship and may not exist on the operator's provider at all: 'default' = the model confirmed for this run (recommended: the most capable reasoning model the environment offers), 'inherit' = whatever the operator is currently on. A literal id is allowed but treated as an example, not a contract." },
         "skills": {
           "type": "array",
           "minItems": 1,

package/plugins/task-pipeline/skills/task-pipeline/references/acceptance.md

@@ -0,0 +1,118 @@
+# Acceptance — stage 10, built in
+
+The pipeline is a funnel: every gate before this one asks *"is this artifact
+good?"* — is the spec committed, does the plan parallelize, is the suite green.
+None of them asks *"does this still contain everything that was asked for?"*
+
+That is this stage's only job: **go back to the brief and account for every
+requirement.** It is what turns the pipeline from a funnel into a circle.
+
+## Why a stage and not a gate
+
+The loss this catches doesn't happen inside a stage — it happens **on the seams**.
+Brief → spec → plan → task briefs is four rewrites by a model, and anything not
+carried forward disappears silently because nothing compares the lists. Stage 4's
+gate catches the brief→plan seam mechanically; stage 10 catches everything the
+run itself decided, deferred, or quietly dropped along the way.
+
+It runs **last** — after docs and wiki (stage 9), because those are deliverables
+too and a requirement may name them.
+
+## Inputs
+
+Read all of them before writing anything:
+
+- the brief's **REQ table** (`docs/superpowers/specs/<topic>-brief.md`)
+- the **carry-over ledger** (`…-carryover.md`) — in full, every row
+- the plan and its task statuses
+- git log for the run's branch; the test suite's final output
+- stage 8's post-deploy notes; stage 9's doc/wiki changes
+- for UI tasks: `docs/ux/scenarios.md` statuses and the `/ux-lint` result
+
+## Output — the coverage table
+
+Write `docs/superpowers/specs/YYYY-MM-DD-<topic>-acceptance.md`:
+
+```markdown
+# Acceptance — <topic>
+
+Run: <branch/commit range> · Date: YYYY-MM-DD
+
+| REQ | Requirement | Status | Evidence |
+|---|---|---|---|
+| REQ-001 | CSV export from a report | verified | `test_export_csv` ✓ · `api/export.ts:88` |
+| REQ-002 | Export respects active filters | verified | `test_export_respects_filters` ✓ · SCN-014 PASS |
+| REQ-003 | Button disabled on an empty report | deferred | agreed 2026-07-28 → LIN-482 |
+| REQ-004 | XLSX export | partial | CSV path done; XLSX missing → LIN-483 |
+
+## Carry-over still open
+
+- (rows from the ledger whose home is not an issue/backlog/`dropped`)
+
+## What the operator should look at
+
+- <anything the run judged, guessed, or deferred that deserves a second opinion>
+```
+
+### The four statuses
+
+| Status | Means | Requires |
+|---|---|---|
+| `verified` | done and demonstrated | **evidence** — a passing test name, `file:line`, command output, or a scenario ID with PASS |
+| `partial` | works for some of what was asked | an explicit list of what's missing + where it's tracked |
+| `deferred` | agreed not to do it now | the operator's agreement **and** a tracker entry |
+| `dropped` | agreed it isn't wanted | the operator's agreement + the reason |
+
+There is no fifth status. A requirement nobody can classify is `unknown`, and
+`unknown` fails the gate — that is the whole mechanism.
+
+## Evidence, not assertion
+
+**"Done" without evidence is not done.** This is the same rule the review rubric
+and the test-honesty rules apply one level down, raised to the level of intent:
+
+- A passing test **name**, not "tests pass".
+- A `file:line`, not "implemented in the export module".
+- A command **and its output**, not "verified manually".
+- For user-facing behavior, the scenario ID and its status.
+
+If the evidence for a requirement is "I read the code and it looks right", the
+status is `partial`, not `verified` — say so plainly rather than upgrading it.
+
+## The closing question
+
+The table is preparation. The stage exists for the question that follows it, asked
+out loud, with the list in front of the operator:
+
+> Here's what you asked for, here's what shipped, here's what's deferred and where
+> it lives. **What's missing?**
+
+Ask it even when the table is all green. The operator holds context the brief
+never captured, and this is the cheapest moment in the whole run to hear it. An
+answer here becomes new REQ rows or new ledger entries — not a new argument about
+whether the run was finished.
+
+## GATE (manual)
+
+All of:
+
+1. **Every REQ has a status** — none `unknown`, none blank.
+2. **Every `verified` carries evidence** of the kind above.
+3. **Every `partial` names what's missing** and where it's tracked.
+4. **Every `deferred` / `dropped` has the operator's agreement** recorded (in the
+   ledger or here) and, for `deferred`, a tracker entry.
+5. **No carry-over row is left `unresolved`** — every one has a home.
+6. **The operator answers the closing question** and signs off.
+
+Manual by design. An automated check can prove the table is *well-formed*; only
+the person who asked can confirm it is *what they asked for*. Do not let a green
+table substitute for that answer.
+
+## When the answer is "something's missing"
+
+Don't argue and don't re-litigate the gates. Add the missing thing as a new REQ
+row (with its check) or a ledger entry, then say plainly what it costs: a fix now,
+or a tracked follow-up. Both are legitimate outcomes of this stage. Closing the
+run with a known gap is fine **if the gap is written down** — closing it with the
+gap only in someone's memory is the failure mode this whole spine exists to
+prevent.