task-pipeline-skill 0.10.0 → 0.17.1

package/README.md

@@ -5,34 +5,35 @@
 [![license](https://img.shields.io/badge/license-MIT-blue)](LICENSE)
 
 Full-cycle task delivery pipeline orchestrator for **Claude Code**. One skill that
-runs any substantial task through an up-front **intake grill** + **9 gated stages** —
-built on the [superpowers](https://github.com/obra/superpowers) skills.
+runs any substantial task through an up-front **intake grill** + **10 gated stages** —
+with every stage's doctrine **built in**: no companion plugin required.
 
 ## What it does
 
-`intake grill → docs study → brainstorm → spec → plan → subagent build → tests →
-lint/deploy → post-deploy log check → docs/wiki sync`
-
-It **grills you first**: a one-line task ("make me feature X") is expanded, one
-question at a time, into a locked brief — so the remaining stages run to the end
-without mid-flight questions. Each stage gates the next; each names the model to
-use. Every gate is typed — **auto** (the orchestrator verifies it, pass/fail) or
-**manual** (waits for your go).
-
-| # | Stage | Model | Gate | Type |
-|---|---|---|---|---|
-| 0 | Intake grill | Fable | shared understanding reached; brief locked | manual |
-| 1 | Docs study | Fable | contracts grounded on current docs | auto |
-| 2 | Brainstorm | Fable | design approved; UI verdict recorded | manual |
-| 3 | Spec | Fable | committed + reviewed; UI: super-ux chain validated, linter green | manual |
-| 4 | Plan | Fable | parallel-ready, DoD per task | auto |
-| 5 | Dev | Opus | tasks DONE, TDD green per task | auto |
-| 6 | Tests | Opus | full suite green, new code covered | auto |
-| 7 | Lint + deploy | host | lint clean + suite green before deploy | manual |
-| 8 | Post-deploy | host | clean boot / honest degradation | auto |
-| 9 | Docs + wiki | host | docs + wiki synced | auto |
-
-These stages (0 intake + 1→9) are the plugin's **example** flow. It's a machine-readable config
+`intake grill → docs study → brainstorm + decompose → spec → plan → subagent build →
+tests → lint/deploy → post-deploy log check → docs/wiki sync → acceptance`
+
+It **grills you first, always**: stage 0 is mandatory — a one-line task ("make me
+feature X") is expanded, one question at a time, into a locked brief, and the grill
+also sweeps stages 1→10 for anything that would stop the run later. Each stage gates
+the next. Every gate is typed — **auto** (the orchestrator verifies it, pass/fail)
+or **manual** (waits for your go). One model, confirmed before the run starts.
+
+| # | Stage | Gate | Type |
+|---|---|---|---|
+| 0 | Intake grill — **mandatory** | shared understanding + autonomy sweep; brief locked | manual |
+| 1 | Docs study | contracts grounded on current docs | auto |
+| 2 | Brainstorm + decompose | design approved; UI verdict recorded; every REQ answered; platform: module map approved | manual |
+| 3 | Spec | committed + reviewed; UI: super-ux chain validated, linter green | manual |
+| 4 | Plan | parallel-ready, DoD per task | auto |
+| 5 | Dev | tasks DONE (three review verdicts each), TDD green per task | auto |
+| 6 | Tests | full suite green, new code covered | auto |
+| 7 | Lint + deploy | lint clean + suite green before deploy | manual |
+| 8 | Post-deploy | clean boot / honest degradation | auto |
+| 9 | Docs + wiki | docs + wiki synced | auto |
+| 10 | **Acceptance** | every REQ accounted for with evidence; operator signs off | manual |
+
+These stages (0 intake + 1→10) are the plugin's **example** flow. It's a machine-readable config
 ([`pipeline.example.json`](plugins/task-pipeline/skills/task-pipeline/pipeline.example.json))
 against a universal contract
 ([`pipeline.schema.json`](plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json)):
@@ -40,15 +41,140 @@ a host project copies the example to `pipeline.json` and rewrites it with its ow
 stages (any count), its own `skills[]`, and its own `auto`/`manual` gate types —
 "bring your own skills". The framework bakes in no fixed stages.
 
-## Intake grill (stage 0)
+## Everything is built in — zero required dependencies
+
+The doctrine each stage runs on ships inside the skill. Nothing to install for it,
+nothing to resolve at preflight, no version skew with someone else's repo, and no
+stage that can fail because a plugin is missing:
+
+| Stage | Built-in doctrine |
+|---|---|
+| 0 Intake grill | [`references/grill.md`](plugins/task-pipeline/skills/task-pipeline/references/grill.md) — interview loop, domain awareness, autonomy sweep |
+| 2 Brainstorm | [`references/brainstorm.md`](plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md) — approaches, YAGNI, the no-code-before-approval gate |
+| 2 Decompose | [`references/decomposition.md`](plugins/task-pipeline/skills/task-pipeline/references/decomposition.md) — platforms only: brick criteria, module map, build order |
+| 3 Spec | [`references/spec.md`](plugins/task-pipeline/skills/task-pipeline/references/spec.md) — UX-track order, locked contracts, global constraints, self-review |
+| 4 Plan | [`references/planning.md`](plugins/task-pipeline/skills/task-pipeline/references/planning.md) — zero-context tasks, parallel groups, no placeholders |
+| 5 Build | [`references/build.md`](plugins/task-pipeline/skills/task-pipeline/references/build.md) + [`review.md`](plugins/task-pipeline/skills/task-pipeline/references/review.md) — isolation, ledger, subagent loop, review rubric, fix loop |
+| 5–6 TDD | [`references/tdd.md`](plugins/task-pipeline/skills/task-pipeline/references/tdd.md) — the iron law, red/green/refactor, the suite gate |
+| 10 Acceptance | [`references/acceptance.md`](plugins/task-pipeline/skills/task-pipeline/references/acceptance.md) — REQ coverage table, evidence rules, the closing question |
+| any loop | [`references/loop-guard.md`](plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md) — churn detection, caps, the break protocol |
+
+**Ported, not depended on.** Stage 0 is adapted from
+[Matt Pocock's `grilling` / `grill-with-docs`](https://github.com/mattpocock/skills)
+and stages 2–6 from the corresponding skills in
+[obra/superpowers](https://github.com/obra/superpowers) — both MIT, both credited in
+[LICENSE](LICENSE) → *Third-party*. Nothing at runtime reaches for either.
+
+**Optional bridge:** if you already run an equivalent skill set, map it onto stages
+2/4/5/6 in your `pipeline.json` → `skills[]`. That's a substitution, never a
+requirement — the gates still govern, and nothing detects, recommends or waits for
+an external provider.
+
+## Intake grill (stage 0) — mandatory
 
 Inspired by [Matt Pocock's grill-me](https://github.com/mattpocock/skills). Before
 any technical work, task-pipeline interviews you relentlessly — one question per
 turn, each with a recommended answer, exploring the codebase before asking — until
-every decision branch is resolved and locked into a **task brief**. That front-loads
-all the human input so stages 1→9 run autonomously (only the built-in gates pause).
-Uses the `grill-me` / `grilling` skill if installed; otherwise runs a built-in grill
-loop (no hard dependency).
+every decision branch is resolved and locked into a **task brief**. There is no
+"clear enough task" exemption: no stage-1 work starts without a committed,
+confirmed brief.
+
+**Built in — nothing to install.** The full doctrine ships inside the skill
+([`references/grill.md`](plugins/task-pipeline/skills/task-pipeline/references/grill.md)):
+no companion skill, no resolution step, no fallback path, no version skew. Adapted
+from [Matt Pocock's grill-with-docs](https://github.com/mattpocock/skills) (MIT —
+see [LICENSE](LICENSE) → *Third-party*).
+
+**Domain awareness.** While exploring, the grill reads the project's own
+`CONTEXT.md` / `docs/adr/` and holds you to them — calling out terms that conflict
+with the glossary, replacing overloaded words with a canonical one, stress-testing
+relationships against concrete edge cases, and surfacing where the code contradicts
+what you just said. Resolved terms are written into `CONTEXT.md` as they land;
+decisions that are hard to reverse, surprising without context **and** the result of
+a real trade-off get an ADR. Both files are created lazily.
+
+**Autonomy comes from the sweep.** Beyond the task itself, the grill pre-resolves
+everything that would otherwise interrupt stages 1→10: which external libs need docs,
+branch and task-tracker policy, the test command and what "green" means, the lint
+command, the deploy target and its **authorization**, where logs and health live,
+which docs and runbooks to update, and the model. Each gets an answer or an explicit
+"stop and ask me here" — an unasked question is a scheduled interruption. Deploy
+authorization has a hard floor: a standing go counts only if it names the target and
+the preconditions.
+
+## The REQ spine — why nothing falls out the back
+
+Every gate before the last one asks *"is this artifact good?"* — none asks *"does
+this still contain everything that was asked for?"* Scope doesn't leak inside a
+stage; it leaks on the **seams**, because brief → spec → plan → task briefs is four
+rewrites and nothing compares the lists.
+
+So the grill's second hard output is an addressable **requirement table**: one row
+per independently verifiable deliverable, each naming how it will be verified. A
+requirement you can't say how to verify is a badly-stated requirement — it gets
+split during the grill, not discovered at the end.
+
+From there the ids thread through everything:
+
+| Where | What it does |
+|---|---|
+| Spec | every section carries `covers: REQ-…` |
+| Plan | every task carries `Implements: REQ-…`; **the gate is set equality** against the brief — a difference is printed as the explicit list of dropped requirements |
+| Build | the implementer's brief quotes the REQ statement verbatim, so it optimises the requirement and not just the instruction |
+| Review | a third verdict beside spec-compliance and code-quality: **does this satisfy its REQ?** |
+| Deploy | no REQ may still be `open`; a `partial` ships only with explicit acceptance |
+| **Acceptance** | every REQ gets `verified` / `partial` / `deferred` / `dropped` — and `verified` requires **evidence**: a passing test name, a `file:line`, a command and its output |
+
+Two rules keep it honest. **The list is frozen** — adding mid-run is free, removing
+or narrowing needs your explicit agreement, because silently restating the task
+smaller makes every later gate pass honestly on a shrunken task. And **deferred out
+loud is forgotten** — anything postponed, dropped or half-done goes into an
+append-only carry-over ledger the moment it's said, including implementer concerns
+and non-blocking review findings.
+
+Stage 10 closes the circle with the question the pipeline exists to be able to
+answer from a list rather than from memory: *here's what you asked for, here's what
+shipped, here's what's deferred and where it lives — what's missing?*
+
+## Platforms — decomposed into bricks, built one at a time
+
+A one-feature task runs the pipeline once. A **platform** — several independent
+capabilities, several separately shippable surfaces, requirements no single
+deliverable satisfies — gets cut into modules at stage 2, before any spec is
+written ([`references/decomposition.md`](plugins/task-pipeline/skills/task-pipeline/references/decomposition.md)).
+
+Modules are cut **by capability, never by layer** ("Ordering", "Billing" — not
+"Controllers", "Services"), and a candidate is only a brick when it is
+independently specifiable, buildable and testable, owns its own entities, talks to
+its neighbours through declared contracts only, and can land while leaving the
+system working. The committed module map fixes the build order — **walking skeleton
+first**, then topological, no cycles — and every requirement maps to exactly one
+module.
+
+Then stages 3→10 run **per module**: dossier → plan → build → tests → deploy →
+post-deploy → docs → acceptance → next brick. Stages 0–2 run once for the platform,
+and the map's status column is what a resumed session reads to know where it
+stopped. Each module's spec is a full dossier: architecture, entities and
+ownership, contracts in and out with their failure behavior, business rules, edge
+and failure cases, UI/Figma chain, limits, open questions.
+
+## Loop guard — churn is detected, not endured
+
+Any repeating pass can start undoing the previous one: two shapes alternating, the
+same file rewritten round after round, a finding that was closed coming back. That
+looks like progress and consumes a run, so it is
+[detected mechanically](plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md):
+every repeat pass logs one line per touched file with **the reason that forced it**
+— a finding id, a failed gate item. "Cleanup" is not a reason.
+
+It trips on revert-oscillation, a file edited twice for the same reason, a
+resurrected finding, a third entry into one stage, or two loops editing one file —
+plus hard caps (5 fix rounds per task, 2 re-entries per stage, 3 passes per module).
+On a trip the run **stops editing**, names shape A and shape B with their evidence,
+escalates to the layer that owns the conflict (rubric → operator → plan → spec →
+module map), re-plans the check as an ordered checklist with one verification
+command per item, and goes through it one at a time. A higher-layer conflict is
+never settled inside a lower loop.
 
 ## UX track (user-facing tasks) — super-ux recommended
 
@@ -66,12 +192,8 @@ before interface.
 
 ## Prerequisites
 
-**superpowers** — https://github.com/obra/superpowers
-
-```
-/plugin marketplace add obra/superpowers
-/plugin install superpowers@superpowers
-```
+**None for the pipeline itself** — the doctrine for every stage ships inside the
+skill (see *Everything is built in* above).
 
 **super-ux** (only for user-facing tasks) — https://github.com/ssheleg/super-ux
 
@@ -138,14 +260,24 @@ on the same Claude Code install yields a duplicate skill).
 
 ## Use
 
-Say *"run this through the pipeline"* / *"полный цикл"* / *"прогони по конвейеру"*,
-or `/task-pipeline`. The skill creates a per-stage TaskList and walks the gates.
+Say *"run this through the pipeline"* or *"the full cycle"*, or invoke
+`/task-pipeline`. The skill creates a per-stage TaskList and walks the gates.
+Russian phrasings (*"полный цикл"*, *"прогони по конвейеру"*) route the same way.
+
+## Model policy
 
-## Model tiering
+**One model, confirmed once, at preflight.** The default recommendation is *the most
+capable reasoning model the environment offers* — currently the latest Opus
+generation, but that's a **tier, not a string**. Model ids go stale as generations
+ship, and you may be on another provider entirely, so nothing is hardcoded: the
+pipeline resolves the top tier available at runtime and stage configs use
+provider-agnostic tokens (`default` / `inherit`).
 
-Stages 0–4 → Fable, stages 5–6 → Opus, 7–9 → inherit. **Reminders only** — a skill
-can't switch the main-loop model; `/model` is the operator's. Stage-5 subagents are
-pinned to Opus automatically.
+You confirm or override it (per-stage overrides welcome) before stage 0 — then it
+**stops asking**. A skill can't switch the main-loop model; `/model` is yours.
+Stage-5 subagents are pinned to the confirmed model automatically. If the
+recommended tier isn't available, the pipeline says which one it's using and
+continues — a reminder, never a block.
 
 ## Release automation (project-configurable, toggleable)
 
@@ -161,55 +293,50 @@ clean checkout. Copy and adapt it per project; nothing is hardcoded.
 
 ## Companion skills
 
-`references/companion-skills.md` lists what powers each stage and how to install
-it: **superpowers** (required), **super-ux** (required for user-facing tasks —
-install line surfaced on the spot), **grill-me** (optional, enhances the stage-0
-grill), **context7** (docs stage), **wiki-update** (stage 9). A preflight prints
-which are ready and which to install so you can arm the full flow before work.
+`references/companion-skills.md` separates what's built in (stages 0, 2, 3, 4, 5, 6
+and 10 — nothing to install) from the short optional list: **super-ux** (required only for
+user-facing tasks — install line surfaced on the spot), **context7** (docs stage),
+**wiki-update** (stage 9). A single preflight block prints which are ready, which to
+install, and the model recommendation, so you arm the whole run in one exchange.
 
 ## Portability
 
-Stages 6–9 read the host project's `CLAUDE.md` conventions (tests / lint / deploy /
+Stages 6–10 read the host project's `CLAUDE.md` conventions (tests / lint / deploy /
 docs / wiki) with detection fallbacks, so the skill works in any repo. The
 canonical artifact layout each stage writes to is fixed in
 [`references/artifacts.md`](plugins/task-pipeline/skills/task-pipeline/references/artifacts.md).
 
-## По-русски
-
-**task-pipeline** — оркестратор полного цикла доставки задачи для Claude Code:
-один скилл проводит любую существенную задачу через **интейк-грил + 9 гейтованных
-стадий** (изучение доков → брейншторм → спека → план → сборка сабагентами →
-тесты → линт/деплой → пост-деплой проверка логов → синк доков/вики), построенных
-на скиллах [superpowers](https://github.com/obra/superpowers).
-
-- **Грил на входе (стадия 0):** одна строка задачи («сделай фичу X») недостаточна
-  для автономной работы. Пайплайн сначала «допрашивает» оператора — по одному
-  вопросу за ход, с рекомендованным ответом, изучив код до вопроса — пока все
-  ветки решений не закрыты и не зафиксированы в брифе. Это выносит весь ввод
-  человека вперёд, дальше стадии 1→9 идут автономно. Идея взята из
-  [grill-me Мэтта Покока](https://github.com/mattpocock/skills); использует скилл
-  `grill-me`/`grilling` если установлен, иначе — встроенный грил-цикл.
-- Ни одна стадия не стартует, пока не пройден гейт предыдущей; деплой требует
-  зелёного полного прогона тестов и явного «go» оператора.
-- **UX-трек (super-ux рекомендуется):** как только задача трогает интерфейс
-  (web/mobile/CLI/TUI), [super-ux](https://github.com/ssheleg/super-ux) —
-  рекомендуемый воркфлоу, детектится ещё на гриле; если установлен — используется,
-  если нет — сразу даётся строка установки. Стадия спеки гоняет `/ux` →
-  `ux-foundation` (персоны, JTBD, CJM) → `ux-flows` (флоу + `screens.md` — карта
-  экранов) → `ux-scenarios` (сценарии, ux-contract v4) → `/ux-lint` (линтер должен
-  быть зелёным) до написания плана; спека включает ID сценариев, `SCR-` экраны,
-  стадии CJM и UX-паттерны.
-  Сценарии — до интерфейса.
-- Каждая стадия напоминает, какую модель включить (`/model`): 0–4 — Fable,
-  5–6 — Opus, 7–9 — наследуется. Это только напоминание — модель переключает
-  оператор.
-- Стадии 6–9 читают конвенции хост-проекта из `CLAUDE.md` (тесты / линт /
-  деплой / доки / вики), поэтому скилл работает в любом репозитории.
-
-Запуск: скажите *«полный цикл»* / *«прогони по конвейеру»* или `/task-pipeline
-<задача>`. Установка — см. раздел Install выше (плагин, `npx skills add
-ssheleg/task-pipeline`, `npx task-pipeline-skill` / `npx
-github:ssheleg/task-pipeline` или `./install.sh`).
+## What this gives you
+
+Agents write code well and judge *when to stop asking you things* badly. A
+substantial task turns into twenty interruptions, or into a confident build that
+skipped the tests. `task-pipeline` front-loads every decision into one intake
+conversation, then runs ten gated stages without stopping to check in.
+
+- **The intake grill asks what a senior engineer would ask** before anything is
+  touched — scope, edge cases, failure modes, rollback, who the user is — so the
+  build does not stall halfway through.
+- **Every stage has a gate.** No code before a spec. No deploy before tests. No
+  "done" before the post-deploy logs have been read.
+- **Team discipline without a team.** ADRs, a written plan, a real test suite, a
+  wiki entry — produced as part of the work, not promised for later.
+- **It adapts to your repo, not the reverse.** Deploy, docs and wiki conventions
+  are read from the host project, so nothing is imposed.
+
+## Author
+
+Built by ssheleg — [sshlg.me](https://sshlg.me)
+
+- X / Twitter — [@fuck_this_year](https://x.com/fuck_this_year)
+- Telegram — [@sshlg](https://t.me/sshlg)
+
+Part of the [ssheleg skill family](https://github.com/ssheleg/sshlg-skills):
+`super-ux`, `task-pipeline`, `make-skill`, `sheleg-design`, `seo-aeo-audit`.
+One command installs all five for every agent you use:
+
+```bash
+npx sshlg-skills install
+```
 
 ## License
 

package/cursor/rules/task-pipeline.mdc

@@ -1,18 +1,34 @@
 ---
-description: "task-pipeline: run a substantial task through a disciplined, gated delivery cycle — an intake grill that expands the request, then docs→brainstorm→spec→plan→build→tests→lint/deploy→post-deploy→docs. Apply when the user asks to run a task through the pipeline, the full cycle / полный цикл / прогони по конвейеру, or starts any substantial feature/fix/build."
+description: "task-pipeline: run a substantial task through a disciplined, gated delivery cycle — an intake grill that expands the request into a checkable requirement list, then docs→brainstorm→spec→plan→build→tests→lint/deploy→post-deploy→docs/wiki→acceptance. Apply when the user asks to 'run this through the pipeline' / 'прогони по конвейеру', asks for 'the full cycle' / 'полный цикл', or starts any substantial feature/fix/build."
 alwaysApply: false
 ---
 
 # task-pipeline — gated delivery cycle (Cursor)
 
 Self-contained rule (Cursor copies this file into projects — no external links).
-Run a substantial task through an up-front **intake grill + 9 gated stages**. No
+Run a substantial task through an up-front **intake grill + 10 gated stages**. No
 stage advances until its **gate** passes. Each gate is `auto` (verify it yourself,
 pass/fail) or `manual` (wait for the user's explicit go).
 
-## Stage 0 — intake grill (do this FIRST)
+**No companion skill is required.** Every rule below is the doctrine itself — the
+grill, the design gate, the plan format, the build loop and TDD. Nothing to
+install, nothing to resolve, nothing that breaks when a plugin is missing.
 
-A one-line task ("build feature X") is not enough to finish autonomously. Grill the
+## Model — decide once, before you start
+
+Recommended: **the most capable reasoning model the environment offers** (at time
+of writing, the latest Opus generation — read that as a tier, not a string). Never
+hardcode a model id: generations ship, tiers get renamed, and the user may be on a
+different provider. Resolve the top tier available at runtime, tell the user what
+you recommend and what they're on, let them confirm or override (per-stage
+overrides welcome), record the answer — then **stop asking at every stage**. If the
+recommended tier isn't available, say which one you're using and continue.
+
+## Stage 0 — intake grill (MANDATORY, do this FIRST)
+
+Never skipped, and nothing to install — the grill is part of this rule. No "the
+task was already clear" exemption, no starting stage 1 while the user thinks. A
+one-line task ("build feature X") is not enough to finish autonomously. Grill the
 user up front, then run the rest without mid-flight questions:
 1. One question per turn — never bundle.
 2. Give a recommended answer with every question (+ one-line rationale).
@@ -20,31 +36,130 @@ user up front, then run the rest without mid-flight questions:
 4. Walk the decision tree depth-first; ask prerequisite decisions first.
 5. Reconcile contradictions; chase dodges ("decide later" → "latest you can decide
    and still ship?").
+6. Run the **autonomy sweep** — resolve now whatever would stop stages 1→10 later:
+   external libs and where their docs live; UI verdict; base branch, branch policy,
+   commit convention, task tracker; the test command and what "green" means; the
+   lint command; the deploy target, release toggle and **deploy authorization**;
+   where logs/health live; which docs and runbooks this change updates. Each item
+   gets an answer or an explicit "stop and ask me here" — an unasked question is a
+   scheduled interruption.
+
+**Domain awareness while you grill.** Look for the project's own docs as you
+explore — a root `CONTEXT.md` (or a `CONTEXT-MAP.md` pointing at per-context ones)
+and `docs/adr/`. Then hold the user to them: call out terms that conflict with the
+glossary ("your glossary defines 'cancellation' as X, you seem to mean Y"), replace
+vague or overloaded words with a canonical one ("'account' — Customer or User?"),
+stress-test relationships with concrete edge-case scenarios, and surface
+contradictions between what the code does and what the user just said. Write
+resolved terms into `CONTEXT.md` right then, not in a batch — one tight sentence
+per term, aliases listed as "avoid", no implementation detail. Create these files
+lazily, only once there's something real to write.
+
+Offer an ADR (`docs/adr/NNNN-slug.md`, 1–3 sentences is a complete ADR) only when
+all three hold: hard to reverse, surprising without context, and the result of a
+real trade-off. Any one missing → skip it.
+
+**Write the REQ spine before the brief is confirmed.** Turn the request into an
+addressable list — one row per independently verifiable deliverable (not one per
+sentence), each naming **how it is verified**: a test name, a `file:line`, a command
+and its expected output, or a scenario id. *A requirement you can't say how to
+verify is a badly-stated requirement* — split it here. Then freeze the list:
+adding later is free, **removing or narrowing needs the user's explicit
+agreement**. Quietly restating the task in smaller terms is the subtlest way to
+lose it — every later gate then passes honestly on a task that shrank.
+
+Seed a **carry-over ledger** next to the brief, append-only. Anything deferred,
+dropped, or left half-done goes in the moment it's said — including implementer
+concerns and non-blocking review findings. **Deferred out loud is forgotten.**
+
 Stop when shared understanding is reached (every branch answered or explicitly
-deferred) and lock the answers into a short brief the user confirms. Only then start.
+deferred) and lock the answers into a short brief the user confirms. Only then
+start. Later stages read that brief instead of asking again.
 
-## Stages 1→9
+**Deploy authorization has a hard floor:** a standing go counts only if it is
+specific (named target + named preconditions). A vague "just do everything" does
+not authorize an outward, irreversible action — stage 7 stops and asks.
+
+## Stages 1→10
 
 1. **Docs study** (auto) — ground every external lib/API on current docs, not recall.
-2. **Brainstorm** (manual) — 2–3 approaches + a recommendation; design approved.
-   Record whether the task touches a user-facing surface (UI verdict).
-3. **Spec** (manual) — write and commit the design; lock shared contracts. For UI
-   tasks, run the UX chain FIRST (see super-ux below) and embed it.
-4. **Plan** (auto) — zero-context tasks, exact paths, TDD steps, DoD each,
-   dependency graph + parallel groups, non-overlapping file ownership.
-5. **Dev** (auto) — isolate (worktree), TDD per task (failing test → minimal impl →
-   green → commit); two-stage review (spec compliance, then code quality).
+2. **Brainstorm + decompose** (manual) — read the brief, explore the code, then 2–3
+   approaches with a recommendation, YAGNI applied, design presented in sections and
+   approved. **Hard gate: no code, no scaffolding before that approval** — including
+   on "obviously simple" tasks. Record whether the task touches a user-facing surface
+   (UI verdict). **If the brief is a platform, not a change** — several independent
+   capabilities or separately shippable surfaces — cut it into modules before any
+   spec: modules by capability, never by layer; a module qualifies as a brick only if
+   it is independently specifiable, buildable and testable, owns its own entities,
+   talks to others through declared contracts only, and can land while leaving the
+   system working. Commit a module map (module, delivers, entities owned, depends on,
+   contracts exposed, UI?, REQs, status) in build order — the **walking skeleton
+   first**, then topologically, no cycles (a cycle means the cut is wrong). Every REQ
+   maps to exactly one module. Then stages 3→10 run **per module**, one brick at a
+   time; stages 0–2 run once, and the map's status column is the resume point. Single
+   module → record "single module: <name>" and move on.
+3. **Spec** (manual) — write and commit the design; lock every shared contract
+   (types, schemas, signatures, file layout) plus a **Global Constraints** block of
+   exact values every later task inherits. Self-review it for placeholders,
+   contradictions, ambiguity and scope before showing it. For UI tasks, run the UX
+   chain FIRST (see super-ux below) and embed it.
+4. **Plan** (auto) — every task names the REQ ids it `Implements:`, and the set of those ids must **equal** the brief's REQ set — a difference is scope lost, print it and fix it. Zero-context tasks: exact paths, complete code in every step,
+   the exact command and its expected output, TDD steps, DoD each, dependency graph
+   + parallel groups, non-overlapping file ownership. **No placeholders** — no TBD,
+   no "add error handling", no "similar to Task N", no undefined types.
+5. **Dev** (auto) — isolate first (existing worktree? native worktree tool? else
+   `git worktree` into an ignored dir), baseline tests green, then one task at a
+   time: TDD (failing test → watch it fail → minimal impl → watch it pass →
+   commit), then a review with **all three** verdicts — spec compliance, **REQ
+   satisfied** (judged against the requirement's own statement, not the task's
+   instructions), and code quality. Findings loop back to the implementer (max 5
+   rounds, then adjudicate in writing); minor findings are recorded, never blocking. Keep a progress ledger in
+   a file so a lost context can resume instead of redoing finished work. Tasks in
+   the same parallel group run concurrently **only** if each worker has its own
+   worktree — otherwise sequential. Close the stage by integrating: sync with the
+   base branch, re-run the full suite on the result, merge (or open a PR — that's
+   outward, so ask first), remove the worktree.
 6. **Tests** (auto) — full suite green (not just new tests); new/changed code
-   covered; no skip/xfail hiding red.
+   covered including failure paths; no skip/xfail hiding red. Tests assert real
+   behavior, never mock behavior.
 7. **Lint + deploy** (manual) — lint clean AND suite green before deploy; deploy is
-   outward → explicit user go.
+   outward → explicit user go, or the specific standing authorization recorded in
+   the stage-0 brief.
 8. **Post-deploy** (auto) — tail logs / health-check; clean boot or an honest
    degradation report (never silent success).
-9. **Docs** (auto) — update module docs/runbooks in the SAME change.
+9. **Docs + wiki** (auto) — update module docs/runbooks in the SAME change, and
+    sync the project's knowledge base/wiki if it has one.
+10. **Acceptance** (manual) — the closing stage: go back to the brief and account
+    for **every** REQ. One row each, status `verified` / `partial` / `deferred` /
+    `dropped`, and every `verified` carries **evidence** — a passing test name, a
+    `file:line`, a command and its output. "Done" without evidence is downgraded to
+    `partial`, never upgraded. Then ask out loud, list in hand: *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 green. Gate: no REQ `unknown`,
+    no ledger row without a home, user signs off.
+
+Cross-cutting: answer from the brief's autonomy section rather than re-asking, log every deferral in the ledger, never narrow the task silently, track
+tasks, conventional commits, honest degradation (never claim a failed/skipped step
+succeeded), and get explicit go before any outward/irreversible action (deploy,
+publish, repo create).
 
-Cross-cutting: track tasks, conventional commits, honest degradation (never claim a
-failed/skipped step succeeded), and get explicit go before any outward/irreversible
-action (deploy, publish, repo create).
+**Loop guard — break churn instead of iterating.** Every repeating pass (a fix
+round, a re-entered stage, the next module) logs one line per touched file: the
+file, the pass, and the reason that forced it — a finding id or a failed gate item.
+"Cleanup" is not a reason. **Stop immediately** when: an edit undoes what an earlier
+pass in this run deliberately did (A→B→A); the same file is edited twice for the
+same reason; a finding already fixed or parked comes back; a stage is entered a
+third time for one artifact; two loops edit one file. Hard caps: 5 fix rounds per
+task, 2 re-entries per stage, 3 passes per module. On a stop: name shape A and shape
+B with their evidence and who asks for each; escalate to the layer that owns the
+conflict (two findings → the review rubric; finding vs plan → the user; plan vs spec
+→ back to planning; ambiguous spec → back to spec; two modules claiming one file →
+back to the module map) — **never settle a higher-layer conflict inside a lower
+loop**; then re-plan the check as an ordered checklist, one owner and one
+verification command per item, and go through it one at a time, one commit per item,
+no opportunistic edits. Re-check the list once in the same order at the end. If it
+trips again after a re-planned pass, stop and hand back with both shapes, the
+evidence and your recommendation.
 
 ## super-ux for user-facing tasks (recommended)
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "task-pipeline-skill",
-  "version": "0.10.0",
-  "description": "Full-cycle task delivery pipeline orchestrator skill for Claude Code \u2014 an intake grill + 9 gated stages (docs, brainstorm, spec, plan, build, tests, deploy, post-deploy, docs/wiki) built on the superpowers skills, with a super-ux UX track for user-facing tasks and toggleable release automation. This package is the installer CLI.",
+  "version": "0.17.1",
+  "description": "Full-cycle task delivery pipeline orchestrator skill for Claude Code — a mandatory built-in intake grill + 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance) whose doctrine ships inside the skill with no required companion plugin, plus a super-ux UX track for user-facing tasks and toggleable release automation. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"
   },
@@ -23,11 +23,11 @@
   "keywords": [
     "pipeline",
     "workflow",
-    "superpowers",
     "orchestrator",
     "tdd",
     "deploy",
     "spec-driven",
+    "self-contained",
     "claude-code",
     "skill"
   ]

package/plugins/task-pipeline/.claude-plugin/plugin.json

@@ -1,10 +1,21 @@
 {
   "name": "task-pipeline",
-  "description": "Thin orchestrator: an intake grill expands the task, then docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy log check, docs/wiki sync — typed auto/manual gates, per-stage model reminders, a super-ux UX track for user-facing tasks, and toggleable project-configurable release automation. Built on the superpowers skills; generic-portable.",
-  "version": "0.10.0",
-  "author": { "name": "ssheleg" },
+  "description": "Self-contained orchestrator that runs a task through a mandatory built-in intake grill + 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill — no companion plugin required — with typed auto/manual gates, a loop guard that breaks churn, one provider-agnostic model confirmed up front, a super-ux UX track for user-facing tasks, and toggleable project-configurable release automation.",
+  "version": "0.17.1",
+  "author": {
+    "name": "ssheleg"
+  },
   "homepage": "https://github.com/ssheleg/task-pipeline",
   "repository": "https://github.com/ssheleg/task-pipeline",
   "license": "MIT",
-  "keywords": ["pipeline", "workflow", "superpowers", "orchestrator", "tdd", "deploy", "spec-driven", "claude-code"]
+  "keywords": [
+    "pipeline",
+    "workflow",
+    "orchestrator",
+    "tdd",
+    "deploy",
+    "spec-driven",
+    "self-contained",
+    "claude-code"
+  ]
 }