task-pipeline-skill 0.12.0 → 0.17.1

package/CHANGELOG.md

@@ -1,5 +1,321 @@
 # Changelog
 
+## v0.17.1 — 2026-07-28
+
+A full-repo consistency audit. v0.16.0 added a third review verdict and a tenth
+stage; several surfaces never heard about either. An agent reads one surface, not
+all of them, so a stage that is `three verdicts` in the config and `both verdicts`
+in the prompt that actually runs simply produces two.
+
+### Fixed
+- **The third review verdict now exists where reviews are actually dispatched.**
+  `references/review.md`'s task-review prompt asked for *"two verdicts"* — so the
+  REQ-satisfaction verdict the stage-5 gate requires was never returned. It now asks
+  for three (spec compliance → **REQ satisfied** → code quality), with the REQ one
+  judged against the requirement's quoted statement rather than the task's
+  instructions. Same correction in `build.md` (§4.4 and its gate), `planning.md`'s
+  plan header, `stages.md` and the Cursor rule.
+- **Stage-5's gate now names the ledger harvest.** `build.md`'s gate omitted
+  "every parked finding and implementer concern harvested into the carry-over
+  ledger" — the one thing that must happen before the scratch workspace is deleted.
+- **Three gates in the doctrine files were weaker than the same gates in
+  `stages.md`:** `planning.md` didn't state the REQ **set-equality** check (the
+  brief→plan seam), `spec.md` didn't require `covers: REQ-…` per section, and
+  `brainstorm.md` didn't require every REQ answered by the design or the module map
+  approved for a platform. All three now match.
+- **Descriptions listed the flow wrong.** npm, the marketplace entry, the plugin
+  manifest: `…post-deploy, acceptance, docs/wiki` — eleven items for ten stages,
+  with the final stage listed second-to-last. The `/task-pipeline` command's
+  description and `SKILL.md`'s frontmatter stopped at docs/wiki and never named
+  acceptance at all.
+- **Built-in doctrine tables were missing rows** for stage 10 acceptance
+  (`SKILL.md`, `README.md`, `companion-skills.md`), stage-2 decomposition and the
+  loop guard (`README.md`, `companion-skills.md`) — files that ship, are reachable,
+  and were absent from the very tables that say what ships.
+- Smaller drift: the Cursor rule's stage 9 dropped the wiki sync; four gate checks
+  in `pipeline.example.json` had v0.16.0 sentences concatenated without punctuation;
+  `stages.md` wrote `implements:` where the plan format writes `Implements:`;
+  `artifacts.md` had the acceptance artifact listed before the spec and the ledger
+  attributed to stages `0→9`; the v0.1.0 design snapshot's disclaimer still
+  described the live shape as nine stages.
+
+### Added
+- **Three validator guards, each with a CI negative self-test**, so this class of
+  drift fails instead of shipping:
+  1. every human-facing description (npm, marketplace, plugin, `SKILL.md`, the
+     command, the Cursor rule, `README.md`) must name the flow's **final stage**,
+     and must not list it before the stage it runs after — derived from
+     `pipeline.example.json`, not hardcoded;
+  2. no shipped surface may say *two/both verdicts* while the dev gate declares
+     three;
+  3. each stage doctrine file's own `GATE (auto|manual)` must match that stage's
+     gate type in the config.
+
+## v0.17.0 — 2026-07-28
+
+Two mechanisms stop being files nobody walks and become operational doctrine: a
+platform is cut into bricks before it is specced, and a loop that starts undoing
+itself is broken instead of endured.
+
+### Added
+- **Decomposition is stage 2's second half**, wired end to end —
+  `references/decomposition.md` now reached from `SKILL.md`'s doctrine table, the
+  stage-2 gate in `stages.md`, the example config, the Cursor rule, the command and
+  the README. A brief that describes a *platform* — several independent
+  capabilities, several separately shippable surfaces, REQs no single deliverable
+  satisfies — is cut into **modules** before any spec exists: by capability, never
+  by layer, and a candidate is a brick only when it is independently specifiable,
+  buildable and testable, owns its entities, talks through declared contracts only,
+  and can land while leaving the system working. The module map carries build order
+  — **walking skeleton first**, then topological, no cycles — with every REQ mapped
+  to exactly one module. Single-module work records `single module: <name>`: a
+  skipped decomposition is a decision, never an omission.
+- **The module dossier** (`spec.md`): for a decomposed platform the spec has nine
+  required sections — purpose and boundary, architecture, entities and ownership,
+  contracts in and out **with their behavior when the other side is down**,
+  business rules in the domain's language, edge and failure cases, UI/Figma chain,
+  non-functional limits, and open questions with a decide-by moment. A skipped
+  section says why in one line; silence is not a skip.
+- **The loop guard binds every repeating loop** — `references/loop-guard.md` is now
+  referenced from `SKILL.md`'s cross-cutting rules, a `stages.md` section, the
+  stage-5 fix loop, the Cursor rule and the command. Every repeating pass logs one
+  line per touched file with the reason that forced it ("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: stop editing, name shape A and shape B with their evidence,
+  escalate to the layer that owns the conflict, re-plan the check as an ordered
+  checklist with one verification command per item, then go through it one at a
+  time. **A higher-layer conflict is never settled inside a lower loop.**
+- **Two autonomy-sweep rows** (grill + brief template): platform-or-single-module
+  with the deploy cadence it implies, and who signs off acceptance plus where
+  deferred REQs are tracked.
+- **`conventions.md` gains the issue tracker** stage 10 needs — read the host's
+  convention, never invent a tracker, never close a run on "we'll remember it".
+- `artifacts.md` gains the module map and the run-level ledger
+  (`.task-pipeline/run.md`) the loop guard writes to.
+
+### Tests
+- **The stage list is cross-checked across all three surfaces it is published on** —
+  `SKILL.md`'s table, `references/stages.md` and `pipeline.example.json`: identical
+  ids in identical order, matching names, matching gate types, and every stage in
+  `stages.md` carrying a `**GATE (auto|manual)**` line. Drift between surfaces is
+  invisible in review and lethal at runtime — a stage manual on one surface and auto
+  on another.
+- `decomposition.md` and `loop-guard.md` join the stub-rejected doctrine set.
+- Three negative self-tests against a mutated copy: a flipped gate type, a removed
+  GATE line and a deleted doctrine file each fail the validator.
+
+## v0.16.1 — 2026-07-28
+
+### Fixed
+- **v0.16.0 added a tenth stage and left "1→9" in fifteen places** — the skill
+  description, the command, the Cursor rule, `stages.md`, `grill.md`, the brief
+  template, the example config and the README all still promised nine. The
+  package, marketplace and plugin descriptions said "9 gated stages" too, which
+  is what npm and the marketplace show. All re-synced to ten, and the plan
+  filename now uses the same slug as the brief and the spec.
+
+## v0.16.0 — 2026-07-28
+
+Scope stops leaking. The request becomes an addressable list of requirements, the
+ids are traced through every stage, and a new final stage accounts for all of them.
+
+The failure this fixes: every gate up to now asked *"is this artifact good?"* and
+none asked *"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 by a model and nothing compared the lists.
+
+### Added
+- **The REQ spine.** The grill's second hard output is a requirement table in the
+  brief — one row per *independently verifiable* deliverable, each naming **how it
+  is verified** (test name, `file:line`, command + expected output, scenario id). A
+  requirement you can't say how to verify is a badly-stated requirement, and gets
+  split during the grill rather than discovered at the end. One REQ = one
+  deliverable, not one per sentence: an inflated table is ignored, and an ignored
+  table protects nothing.
+- **Traceability through the run.** Spec sections carry `covers: REQ-…`; plan tasks
+  carry `Implements: REQ-…`; the implementer's task brief quotes the requirement
+  statement **verbatim**, so it optimises the requirement and not just the
+  instruction; the review rubric gains a verdict beside spec-compliance and
+  code-quality — **does this satisfy its REQ?**
+- **Stage 10 — Acceptance** (`references/acceptance.md`, manual gate). Closes the
+  circle: every REQ gets `verified` / `partial` / `deferred` / `dropped`, written to
+  `specs/<topic>-acceptance.md`. `verified` **requires evidence** — a passing test
+  name, a `file:line`, a command and its output. "Done" without evidence is
+  downgraded to `partial`, never upgraded. Then the operator is asked the closing
+  question 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?* Asked even when the
+  table is green. 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.
+- **The carry-over ledger** (`templates/carryover.md`) — append-only, seeded at
+  stage 0, written by every stage, read in full at stage 10. Implementer concerns
+  and parked review findings are harvested into it before the scratch workspace is
+  deleted. The rule: **deferred out loud is forgotten** — a row with no home
+  (issue, backlog, or an agreed `dropped`) blocks the acceptance gate.
+
+### Changed
+- **The brief→plan seam is now mechanical.** Stage 4's gate is **set equality**
+  between the brief's REQ ids and the union of `Implements:` across plan tasks. A
+  non-empty difference fails the gate and is reported as the explicit list of
+  dropped requirements — a comparison, not a judgement call.
+- **No silent narrowing.** The REQ list is frozen once confirmed: adding mid-run is
+  free, **removing or narrowing needs the operator's explicit agreement**, recorded
+  in the ledger. Quietly restating the task smaller is the subtlest loss, because
+  every later gate then passes honestly on a task that shrank without anyone
+  deciding it should.
+- **Gates tightened** — stage 0 requires the REQ table and a seeded ledger; stage 2
+  requires the design to answer every REQ (or an operator-agreed drop); stage 3
+  requires `covers:` on every section; stage 5 harvests concerns into the ledger;
+  **stage 7 refuses to deploy while any REQ is still `open`** (a `partial` ships only
+  with explicit acceptance — a gap is cheapest to close before it ships).
+
+### Fixed
+- **`decomposition.md` and `loop-guard.md` shipped unreachable.** Both linked only
+  to each other; nothing in `SKILL.md` pointed at either, so under progressive
+  disclosure an agent would never load them — two contracts that existed, passed
+  every check, and were dead context. Wired into the doctrine table (stage 2 for
+  decomposition, cross-cutting for the loop guard), and the validator now walks the
+  link graph from `SKILL.md` and fails on any reference nothing reaches.
+
+### Tests
+- `references/acceptance.md` joins the built-in doctrine set (stub-rejected);
+  `templates/carryover.md` required; the brief template must carry
+  `## Requirements`, a `REQ-NNN` row and the verification column; the shipped flow's
+  last stage must be `acceptance` with a **manual** gate whose check demands
+  evidence; the plan gate must state the set comparison.
+- Nine new invariants, each verified to fail on a broken copy; four added to CI as
+  negative self-tests.
+
+## v0.15.0 — 2026-07-28
+
+Coherence pass over the v0.13.0 port: three contradictions resolved, three gaps
+closed, and the config's gate text re-synced with the doctrine.
+
+### Fixed
+- **Model policy contradicted itself.** `build.md` and `review.md` told the final
+  whole-branch review to run "on the most capable model available" while
+  `model-tiering.md` promises **one** model per run. Both now default to the run's
+  confirmed model; when the run sits below the top tier, escalation for that single
+  review (and for fix-loop rounds 4–5) is **offered out loud**, never switched
+  silently, and only the operator's recorded override map authorizes a cheaper tier.
+- **Parallel groups were planned and then forbidden.** `planning.md` mandates
+  dependency-ordered parallel groups with exclusive file ownership; `build.md` said
+  "never dispatch implementers in parallel". New §4.2 states the real rule: default
+  sequential, fan out only when the tasks share a group, own disjoint files **and**
+  each implementer gets its own worktree; integrate the worktrees one at a time; any
+  merge conflict means the plan's ownership was wrong — fall back to sequential and
+  record it. The fix loop never fans out.
+- **Scratch dirs could land in a task's diff.** The isolation snippet now ignores
+  **and commits** both `.worktrees/` and `.task-pipeline/` before anything is
+  created.
+
+### Added
+- **Stage 5 now ends with integration.** Sync with the base branch, re-run the full
+  suite on the merged result (green-in-isolation is not green), land it the
+  project's way — merge, or a PR, which is outward and needs a go — never
+  force-push a shared branch, never land on `main` when the brief forbids it, then
+  remove the worktree. Stages 7–9 lint, deploy and document the integrated result,
+  so "leave it unmerged" is allowed but must be recorded. The stage-5 gate, the
+  stage table, the Cursor rule and the example config carry the new condition.
+- **Inline execution mode.** A harness without subagents (or a plan too small to be
+  worth dispatching) runs the same loop inline: same isolation, ledger, TDD and
+  review rubric applied to your own diff — declared out loud, since a self-review is
+  weaker evidence than a fresh reviewer's. Replaces the capability that
+  `superpowers:executing-plans` used to cover.
+- **Grill + brief sweep row for integration** — how the branch lands (merge / PR +
+  approver / "leave it") and whether parallel fan-out is wanted, so stage 5 never
+  stops to ask.
+
+### Changed
+- The implementer contract spells the TDD loop out inline instead of pointing a
+  zero-context subagent at a file it can't resolve, and the plan header no longer
+  cites a skill-internal path.
+- `pipeline.example.json` gate text for stages 4, 5 and 6 re-synced with
+  `references/stages.md`; stage 4's gate now also names type/name consistency and
+  the per-task DoD.
+- `review.md` defines `$WORKSPACE` where it first uses it; `build.md` §4 subsections
+  renumbered after the insert.
+
+## v0.14.0 — 2026-07-28
+
+### Fixed
+- Skill front-matter was **1039 characters**, over the 1024 canon limit, and the
+  validator did not check it. Description tightened to 996 and the limit is now
+  enforced.
+
+### Changed
+- Triggers restructured English-first — `'run this through the pipeline' /
+  'прогони по конвейеру'` — in both the skill and the Cursor rule.
+- README is English-only, with a plain statement of what the pipeline gives you
+  and an author/links block.
+
+### Added
+- Validator enforces the description canon: `Use when` opening, Russian trigger
+  aliases present, front-matter under 1024 characters.
+
+## v0.13.0 — 2026-07-28
+
+The last external dependency is gone. Every stage now runs on doctrine that ships
+inside the skill — the pipeline installs and runs with nothing else present.
+
+- **superpowers is no longer a prerequisite.** The preflight no longer resolves
+  `superpowers:*`, the "install this or stop" branch is deleted, and no stage can
+  fail because a companion plugin is missing. `Prerequisites` in SKILL.md and the
+  README now read "none required".
+- **Six new built-in references carry stages 2→6:**
+  - `references/brainstorm.md` — stage 2: read the brief first, explore, scope-check
+    for decomposition, one question at a time, 2–3 approaches with a recommendation,
+    YAGNI, design approved section by section. The **hard gate** (no code, no
+    scaffolding before approval, including on "obviously simple" tasks) is explicit.
+  - `references/spec.md` — stage 3: UX-track order, what the spec must lock (types,
+    schemas, signatures, file layout) plus the **Global Constraints** block stages
+    4–5 consume verbatim, the self-review pass, the operator-review gate.
+  - `references/planning.md` — stage 4: zero-context task format, dependency graph,
+    parallel groups with exclusive file ownership, required plan header and task
+    structure, the no-placeholders list, the self-review checklist.
+  - `references/build.md` — stage 5: worktree detection (submodule guard, native
+    tool first, ignored-directory check, baseline tests), a git-ignored ledger at
+    `.task-pipeline/build/<plan>/progress.md` that survives compaction, the
+    file-based dispatch contract, the four implementer statuses, the five-round fix
+    loop with its breaker and adjudication rules, and the single final fix wave.
+  - `references/review.md` — the review rubric (spec compliance, correctness,
+    constraints, test honesty, degradation, boundaries, security, docs-same-change),
+    severity ladder, controller rules ("never pre-judge a reviewer"), and the three
+    reviewer prompts. External helper scripts are replaced by plain git commands, so
+    the doctrine works on any agent.
+  - `references/tdd.md` — stages 5–6: the iron law, red/green/refactor with both
+    mandatory verifications, honest-test rules, the stage-6 full-suite gate, and the
+    rationalization table.
+- **Ported, not depended on.** Stages 2–6 are adapted from `brainstorming`,
+  `writing-plans`, `using-git-worktrees`, `subagent-driven-development`,
+  `test-driven-development` and `requesting-code-review` in
+  [obra/superpowers](https://github.com/obra/superpowers) (MIT) and rewritten for
+  this pipeline's stages, gates, artifacts and single-model policy. `LICENSE` gains
+  a second *Third-party* section with Jesse Vincent's copyright notice covering the
+  six files.
+- **Optional bridge, not a dependency.** An operator who already runs an equivalent
+  skill set can substitute it on stages 2/4/5/6 via `pipeline.json` → `skills[]`.
+  Nothing detects, recommends or waits for it; the gates still govern; providers are
+  never mixed inside one stage.
+- **Config:** `pipeline.example.json` stages now name `task-pipeline:brainstorm`,
+  `task-pipeline:spec`, `task-pipeline:plan`, `task-pipeline:build` +
+  `task-pipeline:review`, and `host:test-runner` + `task-pipeline:tdd`.
+- **Every channel updated** — SKILL.md (built-in doctrine table, stage table,
+  references list), `references/stages.md`, `references/companion-skills.md` (matrix
+  split into built-in vs optional, superpowers moved to a struck-through
+  "not a dependency" row), `references/artifacts.md` (new files in the repo map, the
+  `.task-pipeline/` scratch workspace, and a note that `docs/superpowers/` is a
+  retained directory *name*, not a dependency), the `/task-pipeline` command, the
+  Cursor rule (now carrying the design gate, plan format, build loop and TDD rules
+  inline) and the README in both languages.
+- **Validator:** requires all six doctrine files and rejects stubs (<1.5 KB), and
+  fails the build if the shipped default flow names an external provider
+  (`superpowers:*`, `grill-me`, `grilling`) in any stage's `skills[]`.
+- **Artifact paths unchanged** — briefs, specs and plans still live under
+  `docs/superpowers/{specs,plans}` so existing projects need no migration; the name
+  is now documented as historical convention only.
+
 ## v0.12.0 — 2026-07-27
 
 The grill stops being someone else's skill. It is ported in, in full, and gains

package/LICENSE

@@ -25,6 +25,9 @@ SOFTWARE.
 Third-party
 ================================================================================
 
+1) Intake grill (stage 0)
+-------------------------
+
 The built-in intake grill (stage 0) is adapted from the `grilling` /
 `grill-with-docs` skills in https://github.com/mattpocock/skills — specifically
 its interview loop and its domain-awareness discipline (glossary challenges,
@@ -57,3 +60,47 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+
+
+2) Stage doctrine (stages 2-6)
+------------------------------
+
+The built-in doctrine for stages 2-6 is adapted from the `brainstorming`,
+`writing-plans`, `using-git-worktrees`, `subagent-driven-development`,
+`test-driven-development` and `requesting-code-review` skills in
+https://github.com/obra/superpowers — specifically the design-dialogue and
+design-approval discipline, the zero-context plan format, the worktree isolation
+procedure, the subagent task/review/fix loop with its ledger and breaker, the
+reviewer contracts, and the red-green-refactor rules. Rewritten for this
+pipeline's stages, gates, artifacts and single-model policy. Affected files:
+
+  plugins/task-pipeline/skills/task-pipeline/references/brainstorm.md
+  plugins/task-pipeline/skills/task-pipeline/references/spec.md
+  plugins/task-pipeline/skills/task-pipeline/references/planning.md
+  plugins/task-pipeline/skills/task-pipeline/references/build.md
+  plugins/task-pipeline/skills/task-pipeline/references/review.md
+  plugins/task-pipeline/skills/task-pipeline/references/tdd.md
+
+Those portions are used under the following license:
+
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.