task-pipeline-skill 1.91.2 → 1.93.2

package/CHANGELOG.md

@@ -1,3 +1,171 @@
+## v1.93.2 — v1.93.0's payload, with evidence a clone can follow
+
+`v1.93.1` published nothing either: its release suite reached the documentation gate
+(`npm run test:docs`, run by `release.yml` and not by the PR's checks) and refused 17
+commit references in `docs/evidence/` — the wave-2 branch SHAs became unreachable when
+PR #109 was squash-merged as `8260042`, and five CI run ids in backticks read as SHAs.
+They now name the squash commit and the runs as plain numbers. Same payload; this is
+the third tag for it, and `docgate.sh` passed locally before this one was pushed.
+
+Guards: 438 → **438**; property checks 15 → **15**. No check changed.
+
+## v1.93.1 — v1.93.0's payload, released with its stamp declaration
+
+`v1.93.0` published nothing: `release.yml` ran the suite on the tag's own tree and
+`validate.py` refused it, because `docs/evidence/retro.md` → *Releases that carry no
+stamp* did not name it — the check working as written (the same shape as `v1.91.1`).
+The tag cannot be removed, so this release ships the same payload with that declaration.
+Everything below under v1.93.0 is what 1.93.1 contains.
+
+Guards: 438 → **438**; property checks 15 → **15**. No check changed.
+
+## v1.93.0 — the negative self-tests leave the workflow; temp state leaves with the run
+
+Integration wave 2 of the family's waves run (R07–R16), one release. The headline is
+the workflow: `.github/workflows/validate.yml` was **507,836 of GitHub's 512,000 bytes**,
+and past that limit a workflow does not go red — it creates no runs and `gh pr checks`
+says *no checks reported*. 448 of its 464 steps were plants and property checks, run one
+after another in one job for 90–111 minutes (runs 38127381666, 38112068258,
+38104711459).
+
+- **Every plant is a file (R08, #91).** The 433 negative self-tests and 15 property checks
+  moved verbatim into `test/negatives/NNN-<slug>.sh`: line 1 the shebang, line 2
+  `# name: <the step's name>`, then the step's `run` value exactly as GitHub parsed it —
+  checked byte for byte against the YAML on the commit that moved them. The directory is
+  the only list. `validate.yml` fell to 12,181 bytes.
+- **CI shards them.** A `negatives` job runs `python3 test/negatives.py --shard N/8` on an
+  eight-value matrix, fail-fast off; each shard is its own runner, so the fixed
+  `/tmp/<name>-copy` scratch names still never meet. `--shard I/N` takes every Nth check
+  by position, so a red shard is the same set of checks on a maintainer's machine.
+  `--list` and `-k` work as before and with `--shard`.
+- **The runner reads the directory, and refuses what it cannot read.** A file with no
+  `# name:` header, a name that is neither kind, a bad file name, a duplicate number or
+  name — each one stops the run before it starts, and `test/validate.py` fails on the
+  same list, because a check the loader drops is a guard nobody proves while every count
+  stays green. MIN_EXPECTED and MIN_PROPS count the directory, before any shard.
+- **The runner runs `bash -e`, what GitHub ran.** A `run:` block with no `shell:` is
+  `bash -e {0}`; the local runner used plain `bash -c`, and it is now the thing CI runs.
+- **Scratch copies are judged and removed inside each worker.** They were swept only
+  after the whole pool returned, so one local run held every copy at once — 433 copies of
+  the tree with its `.git`, ~6 GB, measured filling a disk with 4 GB free.
+- **Every check that read the workflow reads the directory**, through the runner's own
+  loader: the guard and property counts, the newest CHANGELOG section's counts, the
+  floors, `sed -i`, scratch-directory reuse, a scratch dir wiped by a step that does not
+  own it, the plant-landed assertion, and the anchor census (`test/anchors.py`). The
+  plant-landed check used to skip a name with `)` inside its parentheses; it reads every
+  one now. The ten plants whose payload was the workflow text were re-pointed to the
+  check files and assert on the value the re-pointed guard reads; the YAML plant breaks
+  the first plain step name that is still in the workflow.
+- **New guards, each with its plant:** a `Negative self-test` or `Property check` written
+  inline in the workflow again; a shard matrix that does not list every slice the
+  runner cuts; a check file the loader cannot read. The workflow-size guard had no
+  plant while the file sat 4 KB under the limit — it has one now.
+- **Temp state leaves with the run (R07).** `tp-b80` in `test/validate.py`, the
+  `tp-stage-ckpt` trees and 15 test files with bare `mkdtemp` clean up after
+  themselves; one machine's TMPDIR held 15,146 `tp-b80-*` trees. A new validator check
+  refuses a test file under `test/` — the check files included — that calls `mkdtemp(`,
+  `mkstemp(` or keeps a `NamedTemporaryFile(..., delete=False)` and carries no cleanup.
+  It is per file, so a file with one cleanup and two leaks passes; writing it found two
+  such leaks in `test/validate.py` itself — the graph-coverage tree and the installers'
+  fake HOME, ~1.8 MB per validator run and so per plant — and both are fixed.
+- **Budget (R09).** The description is 890 of 1024 chars (909 before; ≤ 900 was the
+  target, B-154 in the family board), and the `SKILL.md` body 4646 of the 4750-token
+  working limit (4736 before; B-120 asked for 100 spare, and 104 are). The Optional-bridge
+  paragraph is trimmed to a pointer (its full text was already in
+  `references/companion-skills.md`); the kernel-precedence rule stays
+  in `SKILL.md`, which `fix-tp-03.01` pins.
+- **Execution packets carry a namespaced id (R14):** `task-pipeline/execution-packet/1`.
+  Fabric's former packet used the bare `execution-packet/1` until it renamed its format
+  `session-handoff/1`; `packet.py`, `context_packets.py` and the schema still read the bare
+  id: 19 live packets in one consumer repository carry it (B-135), so it is refused only
+  after they are migrated.
+- **Wave mode reads declared task sources (R13).** Where a repository declares them in
+  `docs/backlog-sources.json`, the harvest reads exactly those, updates status only in
+  the owning files and never edits a generated view.
+- **The release stage reads the approval mode (R16).** `pipeline.json` `release.approval`
+  is `checks` (tag, watch, report) or `reviewers` (the direct link to the run that is
+  actually waiting); absent, it is read from the organisation or the environment, never
+  assumed.
+- **Fabric's pipeline adapter is a pinned contract (R15).** `test/fixtures/
+  fabric-pipeline-contract.json` pins `passioncode-ai/fabric` main `5bf15e5c`, and
+  `fix-pf-06.01` checks the gate types and the example config against it with no Fabric
+  checkout.
+- **Continuity through Observatory (R11).** `stage_checkpoint.py` gains `handoff` and
+  `accept`; `hooks/memory-nudge.sh` reminds once per returned gate that wrote no memory
+  event.
+- **Ledgers (R10).** The verification headers say *released*; this repository's merged
+  branches are gone.
+
+Guards: 433 → **438**; property checks 15 → **15**. The five new plants are files in
+`test/negatives/` (449–453); every guard's plant was run on this tree, and the CI wall
+clock per shard is in `docs/evidence/verification.md`.
+
+## v1.92.0 — wave mode: the whole board, closed in its final form; the grill asks one batch
+
+The operator's standard approach, decided on 2026-10-11 and codified here: when the request
+is not one change but **the whole board** — every open item plus the new requests — gather
+it all first, close every question the sources can close, ask what remains **once, as one
+batch, at the end of planning**, lay the target state over the current logic on one canvas,
+plan from the post-integration target, and cut the work into waves that each close in one
+pass, with a verification, finishing, fixing and documentation pass after every wave. The
+run takes the next wave without asking, says once when the board is empty, and leaves every
+sign-in, consent, payment, message to a person and outward act to a human. The rule under
+all of it: **build the system in its final form, never through intermediate states.**
+
+- **`references/waves.md`, invoked as `/task-pipeline waves`** — a third mode beside `setup`
+  and `checkup`, and a program mode of the existing stages, not a parallel cycle: stages 0–4
+  once for the whole board, 5–8 per wave, 9–10 to close the release. Wave 0 is the survey
+  (with `project-audit` as a read-only sidecar for whole-project scope) and **one
+  machine-readable inventory**, every item by id with `id`, `source`, `status`, `area`,
+  `node`, `wave`, `release`, verified against the code — stale rows closed with their
+  receipt, duplicates clustered — and assigned to nodes and waves by a committed,
+  deterministic script. The **canvas** extends the module map: as-is → to-be per module and
+  contract, the integration seams, REQ → module → wave, and what the new version deletes.
+  No wave builds a shape a later wave undoes; a stub only at a declared contract with its
+  removal named. Wave 1 is the walking skeleton, and each wave names its exit criteria
+  before it starts. The close pass after each wave certifies, re-measures `audit.md`'s
+  exit, runs **one fix round** under the loop guard's caps, documents through the Doc Loop
+  scoped to the wave, marks the canvas, re-reads the goal, and re-cuts what is left. A board
+  bigger than one release becomes a program, carried on the canvas by node, never dropped.
+  The name is not "dynamic": that word is `run.loop.mode: dynamic`'s.
+- **The grill's default changed — a decision by the operator, 2026-10-11.** It was *one
+  question per turn, never bundle*. It is now: close from the sources first, then ONE batch
+  of the material unknowns, ordered by dependency, each with a recommended answer and what
+  each answer changes; one question at a time only where answers depend on each other
+  (then depth-first) or when the operator asks for it. The reason is the operator's time: a
+  question asked alone costs a human round and a batch costs one, and
+  `prioritisation.md` → *5. Where the human goes* already said so for the rest of the run.
+  Mirrored in `grill.md`, `stages.md` (stages 0 and 2), `brainstorm.md`, the command, the
+  Cursor rule, `HOW-IT-WORKS.md`, the README, `pipeline.example.json`, this repository's
+  `pipeline.json`, and eval TRIG-01; TRIG-11 is the wave-mode trigger in Russian.
+- **`continuity.md`: a block or an ambiguity stops its node, not the run.** The node is
+  parked `needs-operator` with the question written into it, the run continues on what it
+  does not block, and stops only when the whole frontier is blocked. An empty board is said
+  once. A goal re-read that moves the queue is a committed `revisions` entry.
+- **`planning.md`: a wave re-cut keeps the static-graph decision** — every move is a
+  `revisions` entry plus a canvas edit, written before the next pass begins.
+  **`decomposition.md`**: the whole board runs one wave at a time, and a wave may hold several
+  bricks. **`build.md`**: "fix wave" is now "fix round", so *wave* means one thing.
+  **`project-audit`**: its rows and sidecar are wave mode's wave-0 input.
+- **The work graph carries the wave.** `graph.schema.json` gains `nodes[].wave` (an integer
+  from 1) and the `wave` revision verb. `graph.py validate` refuses an edge from a later
+  wave's node into an earlier wave's node; `graph.py next --wave N` prints that wave's
+  frontier only, exiting `3` when the wave is done; `graph.py wave N-007 --to 3 --why …`
+  moves a node, writes the revision, and refuses a move that breaks the order, a `done`
+  node, or no reason. `test/graph_test.py` 158 → **166** cases.
+- **The description names the mode** and paid for it: `'waves' / 'волнами' closes the whole
+  board`, while the stage list reads *through gated stages: …* instead of *… with explicit
+  gates*, `docs study` reads `docs`, and `docs/wiki sync` reads `docs/wiki`. 901 → 909 of
+  1024 chars — inside the umbrella's 60-character reserve below the 970 working limit,
+  which a longer description would have broken. The `SKILL.md` body is 4736 tokens
+  (cl100k), one under where it was: the new sentence in *How to run* displaced a restated
+  kernel clause and the compiler sentence's tail.
+
+Guards: 430 → **433**. The three new negatives live in `test/plant_wave.py` (the workflow
+sits near GitHub's 512 000-byte limit) and disarm the order check, the `--wave` filter and
+the re-cut's revision in turn; each was watched turning `test/graph_test.py` red before the
+step was written.
+
 ## v1.91.2 — v1.91.1's payload, released with its no-stamp declaration
 
 `release.yml` refused the `v1.91.1` tag's own tree: the release carried no run stamp and was

package/CONTRIBUTING.md

@@ -27,9 +27,13 @@ npm run test:negatives    # python3 test/negatives.py
 npm run test:all          # both, in order
 ```
 
-The corruptions live in [`.github/workflows/validate.yml`](.github/workflows/validate.yml)
-and `test/negatives.py` reads them from there — never duplicated, because a second
-copy of a corruption is a second thing to drift. The runner also tells a **broken
+The corruptions live in [`test/negatives/`](test/negatives/), one file per check —
+`#!/usr/bin/env bash`, then `# name: Negative self-test (<what is planted>)`, then
+the script, run from the repository root. `test/negatives.py` reads that directory
+and nothing else, so it is the only list; CI runs it in eight shards
+(`--shard N/8`, the `negatives` job in `validate.yml`). Until v1.93.0 every plant was
+an inline workflow step, and the workflow reached 507,836 of GitHub's 512,000 bytes —
+past the limit a workflow creates no runs rather than going red. The runner also tells a **broken
 test** from a **guard that didn't fire**: if a planted defect changed nothing, the
 validator passing means the test proved nothing, and it is reported as `BROKEN`
 rather than as a failure of the guard.
@@ -37,7 +41,7 @@ rather than as a failure of the guard.
 **Corrupt files in python, never with `sed -i`.** BSD sed needs an argument GNU sed
 refuses, and `0,/re/` does not exist on BSD at all — there it edits nothing
 silently, and the test reads as a guard that failed. The validator rejects `sed -i`
-in the workflow for exactly this reason: a self-test that only runs on CI cannot be
+in a check file for exactly this reason: a self-test that only runs on CI cannot be
 used while you are writing the guard, which is the moment it is worth most.
 
 To try your change in a real agent:
@@ -616,8 +620,10 @@ pass over an empty set is a refused measurement.
   `pipeline.example.json`, the command, the Cursor rule and the README before you
   commit. The validator catches much of this — do not rely on it to think for you.
 - **A new guard needs a negative self-test.** If you teach `test/validate.py` a new
-  rule, add a step to `.github/workflows/validate.yml` that corrupts a copy and
-  asserts the validator fails, then watch it with `npm run test:negatives`. A guard
+  rule, add the next-numbered file to `test/negatives/` that corrupts a copy and
+  asserts the validator fails, then watch it with
+  `python3 test/negatives.py -k <words from its name>`. Never a step inline in the
+  workflow: the validator refuses one, because it would run on CI only. A guard
   nobody proved can fail is decoration. **Check the base is green first** — if the
   repo already fails your new rule, the self-test passes for the wrong reason and
   proves nothing.

package/HOW-IT-WORKS.md

@@ -46,7 +46,9 @@ It is written in three parts, and the middle one was learned the hard way:
   the pipeline entirely.
 
 Two modes need no task at all. `checkup` reports what has shipped without anyone
-confirming it. `setup` audits the documentation a project already has.
+confirming it. `setup` audits the documentation a project already has. A third,
+`waves`, takes the whole board as the task: one inventory, one canvas of the target
+state, one batch of questions, then waves that each close in one pass.
 
 **Honest limit:** this measures the *description's* discriminating power, not the
 host's selection machinery. Three measured runs scored 7/10, 9/10 and 8/10 — and
@@ -92,8 +94,10 @@ An absent source that is never named looks identical to a source that was read.
 
 ### Then the grill, and it is mandatory
 
-One question per turn, each with a recommended answer, exploring the codebase
-before asking, until every decision branch is resolved.
+Close what the sources can answer, then ask the material unknowns in one batch,
+ordered by dependency, each with a recommended answer — one at a time only where the
+answers depend on each other or the operator asks — until every decision branch is
+resolved.
 
 - **Every answer is validated against the harvested sources.** The operator
   outranks any document — but only *out loud*, and a document the run proves stale
@@ -238,7 +242,8 @@ This is the part most pipelines skip, and it is the reason this one is trustwort
 rather than merely tidy.
 
 **Every guard is proven against a planted defect.** `npm run test:all` breaks the
-thing each of the **309** checks is about, and requires that check to reject it. A
+thing each check is about, and requires that check to reject it — one file per
+check in `test/negatives/`, eight shards on CI. A
 guard that has never been watched failing is not a guard; it is a comment.
 
 **The neighbour probe.** A check has a *subject* — the rule it is about — and

package/README.md

@@ -200,6 +200,8 @@ until it is installed.
 | 3 + 4 · every spec and plan | the self-review reads its rules back — is every named check real, does anything contradict a locked decision or a rejected option, and what does this cost now versus at design time. Answers land as a committed `## Self-review` of computed numbers |
 | 6–10 + any check you write | [`gates.md`](plugins/task-pipeline/skills/task-pipeline/references/gates.md) — the three axes, the promotion ladder, gate anatomy, the probe recipe, ratchet floors |
 | any agent-time enforcement | [`hooks.md`](plugins/task-pipeline/skills/task-pipeline/references/hooks.md) — the `PreToolUse` contract, the fail-open hazard, the Claude-Code-only limit |
+| 7 · the tag | [`deploy-targets.md`](plugins/task-pipeline/skills/task-pipeline/references/deploy-targets.md) → *When the release waits for an approval* — `pipeline.json` → `release.approval`: `checks` (tag, watch the run selected by the tag, report) or `reviewers` (the direct link to the run that is `waiting`) |
+| between stages | [`continuity.md`](plugins/task-pipeline/skills/task-pipeline/references/continuity.md) Part 3 — workflow memory through Observatory, a planned handoff (`stage_checkpoint.py handoff` / `accept`), and `hooks/memory-nudge.sh`, which reminds once when a gate returned with no memory line after it |
 
 **Ported, not depended on.** Stage 0 is adapted from
 [Matt Pocock's `grilling` / `grill-with-docs`](https://github.com/mattpocock/skills)
@@ -214,9 +216,11 @@ an external provider.
 
 ### The intake grill (stage 0) — mandatory
 
-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**. There is
+Before any technical work, task-pipeline closes every question the codebase and the
+project's records can answer, then asks you the rest in **one batch**, ordered by
+dependency, each with a recommended answer — one at a time only where the answers
+depend on each other or you ask for it — until 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.
 
@@ -444,6 +448,29 @@ 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.
 
+### Wave mode — the whole board, closed in its final form
+
+`/task-pipeline waves` takes every open item a project carries — the board, the
+carry-over ledgers, plan rows, unverified rows, uncovered scenarios, other products'
+asks — plus your new requests, and closes them **in the system's final form rather
+than through intermediate states**
+([`waves.md`](plugins/task-pipeline/skills/task-pipeline/references/waves.md)). It is
+a program mode of the same stages: 0–4 once for the whole board, 5–8 once per wave,
+9–10 to close.
+
+Wave 0 is the survey: one machine-readable inventory of every item by id, each verified
+against the code — stale rows closed with their receipt, duplicates clustered. Questions
+are closed from the sources first; what is genuinely yours (access, consent, money,
+direction, an outward act) reaches you **once, as one batch, at the end of planning**,
+each with a recommendation. A committed **canvas** lays the target state over the
+current logic — as-is → to-be per module and contract, the integration seams, REQ →
+module → wave, and what the new version deletes. The work is then cut into waves that
+each close in one pass, the walking skeleton first, each with its exit criteria named
+before it starts, and no wave builds a shape a later wave undoes. After every wave a
+close pass verifies, runs one fix round, updates the docs, re-measures the inventory
+and re-cuts what is left. The run takes the next wave without asking; a board too big
+for one release becomes a program, carried on the canvas, never dropped.
+
 ### Loop guard — churn is detected, not endured
 
 Any repeating pass can start undoing the previous one: two shapes alternating, the
@@ -587,7 +614,7 @@ must say so.
 ### Held to Anthropic's own Skill authoring guidance
 
 Audited against the four Agent Skills pages. Most of it already held — `name`
-13/64 chars, `description` 901/1024 chars, `SKILL.md` 278/500 lines, all 39 references
+13/64 chars, `description` 890/1024 chars, `SKILL.md` 268/500 lines, all 40 references
 linked **directly** from `SKILL.md`, and the bundle far under the 30 MB ceiling. What
 did not, now does:
 
@@ -942,6 +969,7 @@ recommendation, so you arm the whole run in one exchange. Detail:
 | [`references/model-tiering.md`](plugins/task-pipeline/skills/task-pipeline/references/model-tiering.md) | model policy, the `/model` reminder, overrides |
 | [`templates/`](plugins/task-pipeline/skills/task-pipeline/templates/README.md) | brief, carry-over ledger, `CONTEXT.md` and ADR skeletons, the doc map, both registers, the retro and its archive, the seeded `docgate.sh` and `hygiene.sh`, a worked hook |
 | [`references/adoption.md`](plugins/task-pipeline/skills/task-pipeline/references/adoption.md) | the first run in a project: greenfield seeding, and the brownfield walkthrough |
+| [`references/waves.md`](plugins/task-pipeline/skills/task-pipeline/references/waves.md) | wave mode: the whole board as one inventory, one canvas of the target state, one question batch, then waves that each close in one pass |
 | [`references/setup.md`](plugins/task-pipeline/skills/task-pipeline/references/setup.md) | the entry audit: seven passes over the docs a project already has, offered once, output as a fix plan |
 | [`references/portability.md`](plugins/task-pipeline/skills/task-pipeline/references/portability.md) | the manifest of workflow decisions and their homes in the bundle, and the boundary against a project's own answers |
 | [`references/learned.md`](plugins/task-pipeline/skills/task-pipeline/references/learned.md) | rules earned by failure on a real multi-repository build, each with its incident, its check and its exit criterion — the table is the count, and it grows |

package/SKILL-CARD.md

@@ -12,7 +12,7 @@ harmless.
 |---|---|
 | **Purpose** | Runs a substantial task through ten gated delivery stages — intake grill, docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs+registers, acceptance — refusing to advance until each gate passes |
 | **Owner** | ssheleg ([github.com/ssheleg/task-pipeline](https://github.com/ssheleg/task-pipeline)) |
-| **Version** | 1.91.2 |
+| **Version** | 1.93.2 |
 | **Surface** | Claude Code (filesystem skill + plugin) and the vercel `skills` CLI. **Not** uploaded to the Skills API; custom Skills do not sync across surfaces |
 | **Dependencies** | None required. Optional: `context7` (MCP), `figma` (MCP), super-ux, agent-sync, graphify, obsidian-wiki, and **one of two browser channels** — `playwright` (CLI or MCP) or `chrome-devtools` (MCP); either satisfies the browser step and neither is required. Every stage's doctrine ships in-repo; the one conditional requirement is super-ux for the stage-3 UX track on a user-facing task |
 | **Evaluation status** | Suite authored, 5 categories. One recorded run, **self-observed by the author**; **zero blind runs on zero of three models** — the split, and the numbers, live in [`evals/RESULTS.md`](evals/RESULTS.md) and are computed by `evals/run.py` |

package/cursor/rules/task-pipeline.mdc

@@ -108,7 +108,9 @@ built, recommend it once and continue: `uv tool install graphifyy` →
 
 **Phase 2 — grill the user against that harvest**, then run the rest without
 mid-flight questions:
-1. One question per turn — never bundle.
+1. Close what the sources answer; ask the rest in ONE batch, ordered by
+   dependency. One at a time only when answers depend on each other or the user
+   asks.
 2. Give a recommended answer with every question (+ one-line rationale).
 3. Explore the codebase before asking — if a search/read answers it, do that.
 4. **Validate every answer against the harvest.** When what the user says
@@ -211,7 +213,14 @@ not authorize an outward, irreversible action — stage 7 stops and asks.
    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.
+   module → record "single module: <name>" and move on. **If the request is the whole
+   board** (wave mode, `waves`) — every open item plus the new requests — stages 0–4
+   run once over one machine-readable inventory verified against the code and a
+   committed canvas of the target state; the work is cut into waves that each close
+   in one pass (wave 1 the walking skeleton, exit criteria named first); stages 5–8
+   run per wave with a close pass after each — verify, one fix round, docs,
+   re-measure, re-cut — and 9–10 close the release. No wave builds a shape a later
+   wave undoes.
 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,

package/evals/RESULTS.md

@@ -40,7 +40,7 @@ or it belongs in a check.
 
 | Metric | Value | Computed by | As of |
 |---|---|---|---|
-| Evals authored | 46 (three suites: task-pipeline 28, evidence-docs 9, project-audit 9) | `python3 evals/run.py` → `suite: N evals` | 2026-08-31 |
+| Evals authored | 47 (three suites: task-pipeline 29, evidence-docs 9, project-audit 9) | `python3 evals/run.py` → `suite: N evals` | 2026-10-11 |
 | Categories covered | 5 of 5, per suite | the suite's own `category` fields | 2026-08-31 |
 | Dated runs recorded | **4** | `python3 evals/run.py` → `recorded runs: N` | 2026-08-31 |
 | …of those, **blind** | **3** | run headings not marked `self-observed` | 2026-08-31 |

package/evals/task-pipeline.evals.json

@@ -17,7 +17,7 @@
       "expected_behavior": [
         "Invokes the task-pipeline skill rather than starting to design or code inline",
         "Runs the stage-0 knowledge harvest BEFORE the first interview question, and writes a source ledger",
-        "Asks interview questions one at a time, each with a recommended answer",
+        "Asks the material interview questions in one batch ordered by dependency, each with a recommended answer, after closing what the sources answer",
         "Writes no implementation code before a brief is committed and confirmed"
       ],
       "why": "The explicit invocation phrase is the primary trigger; the failure it guards is jumping to code."
@@ -361,6 +361,21 @@
       ],
       "why": "Measured before the change: answered `none` because no description offered a phrase for reviewing a PR, while review.md owns exactly that contract."
     },
+    {
+      "id": "TRIG-11",
+      "category": "should_trigger",
+      "skills": [
+        "task-pipeline"
+      ],
+      "query": "собери все задачи с доски и новые запросы и закрой их волнами",
+      "expected_behavior": [
+        "Recognises this as wave mode and runs `/task-pipeline waves`, not one change at a time",
+        "Builds one machine-readable inventory of every open item by id, each verified against the code, before any design",
+        "Closes questions from the sources first and asks the operator the rest once, as one batch with a recommendation each, at the end of planning",
+        "Cuts the work into waves that each close in one pass, wave 1 the walking skeleton, each with its exit criteria named before it starts"
+      ],
+      "why": "Wave mode is the operator's standard approach for a whole board (2026-10-11). A model that cannot reach it from the natural Russian request runs the board item by item and builds the intermediate states the mode exists to refuse."
+    },
     {
       "id": "NOTRIG-06",
       "category": "should_not_trigger",

package/package.json

@@ -1,13 +1,13 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.91.2",
+  "version": "1.93.2",
   "description": "Full-cycle delivery pipeline for coding agents: a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine ships inside the skill — no companion plugin required. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"
   },
   "scripts": {
-    "test": "python3 test/validate.py && python3 test/graph_test.py && python3 test/project_audit_test.py && python3 test/packet_schema_test.py && python3 test/browser_claims_test.py && python3 test/visual_gate_test.py && python3 test/stage_checkpoint_test.py && npm run test:audit-regressions",
-    "test:all": "python3 test/validate.py && python3 test/graph_test.py && python3 test/project_audit_test.py && python3 test/packet_schema_test.py && python3 test/browser_claims_test.py && python3 test/visual_gate_test.py && python3 test/stage_checkpoint_test.py && python3 test/negatives.py && npm run test:certify && npm run test:exposure && npm run test:probe && npm run test:anchors && npm run test:runner && npm run test:hooks && npm run test:artifacts && npm run test:docs && npm run test:audit-regressions",
+    "test": "python3 test/validate.py && python3 test/graph_test.py && python3 test/project_audit_test.py && python3 test/packet_schema_test.py && python3 test/browser_claims_test.py && python3 test/visual_gate_test.py && python3 test/stage_checkpoint_test.py && python3 test/memory_nudge_test.py && npm run test:audit-regressions",
+    "test:all": "python3 test/validate.py && python3 test/graph_test.py && python3 test/project_audit_test.py && python3 test/packet_schema_test.py && python3 test/browser_claims_test.py && python3 test/visual_gate_test.py && python3 test/stage_checkpoint_test.py && python3 test/memory_nudge_test.py && python3 test/negatives.py && npm run test:certify && npm run test:exposure && npm run test:probe && npm run test:anchors && npm run test:runner && npm run test:hooks && npm run test:artifacts && npm run test:docs && npm run test:audit-regressions",
     "test:negatives": "python3 test/negatives.py",
     "test:exposure": "python3 test/exposure_test.py",
     "test:probe": "python3 test/probe.py --self-test",

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

@@ -2,8 +2,8 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "task-pipeline",
   "displayName": "Task Pipeline",
-  "description": "Runs a substantial task through a mandatory built-in intake grill, then 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/judgment/manual gates, a frozen requirement spine that closes with evidence, a work board and a verification ledger that outlive a run, an exposure line naming what shipped unconfirmed, a progress rail computed from the project's own config, a loop guard whose review ceiling measures rather than stops, and stage-3 tracks for what a product does, how it sounds and how it looks. Two modes need no task: `checkup` (what is unverified) and `setup` (audit existing docs). Retro insights can publish upstream as issues, opt-in and redacted.",
-  "version": "1.91.2",
+  "description": "Runs a substantial task through a mandatory built-in intake grill, then 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/judgment/manual gates, a frozen requirement spine that closes with evidence, a work board and a verification ledger that outlive a run, an exposure line naming what shipped unconfirmed, a progress rail computed from the project's own config, a loop guard whose review ceiling measures rather than stops, and stage-3 tracks for what a product does, how it sounds and how it looks. Two modes need no task: `checkup` (what is unverified) and `setup` (audit existing docs); a third, `waves`, takes the whole board and closes it in waves that each finish in one pass. Retro insights can publish upstream as issues, opt-in and redacted.",
+  "version": "1.93.2",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

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

@@ -1,6 +1,6 @@
 ---
-description: "Run a task through task-pipeline's gated stages (intake grill → docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki → acceptance). Also: `setup` — audit the docs you already have; `checkup` — what has shipped unverified, with no task running."
-argument-hint: "<one-line task> | setup | checkup"
+description: "Run a task through task-pipeline's gated stages (intake grill → docs → brainstorm → spec → plan → build → tests → deploy → post-deploy → docs/wiki → acceptance). Also: `waves` — close the whole board in waves; `setup` — audit the docs you already have; `checkup` — what has shipped unverified, with no task running."
+argument-hint: "<one-line task> | waves | setup | checkup"
 ---
 Run the task below through `task-pipeline`'s gated stages. **Every stage's doctrine
 ships inside the skill** — no companion plugin is required for any of it. The
@@ -8,9 +8,10 @@ reference files are indexed in `SKILL.md`; this page is the run order, not the i
 
 Task: $ARGUMENTS
 
-> **Two other modes.** `setup` audits the documentation this project already has;
-> `checkup` reports what has shipped without a person confirming it, with no task in
-> flight. Both are at the bottom of this page.
+> **Three other modes.** `waves` takes the whole board instead of one task;
+> `setup` audits the documentation this project already has; `checkup` reports what
+> has shipped without a person confirming it, with no task in flight. All three are at
+> the bottom of this page.
 
 **Idempotent entry — inspect state first, never restart blindly.** If a pipeline
 TaskList from a previous run exists for this task, **resume** from the first incomplete
@@ -59,9 +60,10 @@ Pull what the project already knows about *this task*:
 
 Write the **source ledger** into the brief: a row per source, or an explicit *none found*.
 
-**Then the grill, and it is mandatory** (`references/grill.md`). One question per turn,
-each with a recommended answer, exploring the codebase before asking, until every
-decision branch is resolved.
+**Then the grill, and it is mandatory** (`references/grill.md`). Close what the sources
+can, then ask the material unknowns in ONE batch, ordered by dependency, each with a
+recommended answer — one at a time only where answers depend on each other or the
+operator asks — until every decision branch is resolved.
 
 - **Validate every answer against the harvested sources.** The operator outranks any
   document — but only out loud, and a doc the run proves stale is logged for stage 9.
@@ -188,6 +190,19 @@ Where you ask it to file what it found, it appends board rows whose `Source` nam
 checkup and its date — printing what it would add first, never silently.
 Doctrine: `references/exposure.md`.
 
+## `/task-pipeline waves`
+
+**The whole board, closed in its final form.** Every open item — board, ledgers, plan
+rows, unverified rows, uncovered scenarios, other products' asks — plus the new requests,
+in one machine-readable inventory verified against the code. Questions are closed from
+the sources; what remains goes to the operator once, as one batch, at the end of
+planning. A committed canvas lays the target state over the current logic, and the work
+is cut into waves that each close in one pass. Stages 0–4 run once, 5–8 per wave with a
+close pass after each (verify, one fix round, docs, re-measure, re-cut), 9–10 to close.
+It takes the next wave without asking, says once when the board is empty, and leaves
+every sign-in, consent, payment and outward act to a person.
+Doctrine: `references/waves.md`.
+
 ## `/task-pipeline setup`
 
 **The entry audit instead of a feature.** Seven passes over the documentation this

package/plugins/task-pipeline/hooks/hooks.json

@@ -37,6 +37,17 @@
             "timeout": 20
           }
         ]
+      },
+      {
+        "matcher": "Bash|Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "shell": "bash",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/memory-nudge.sh\"",
+            "timeout": 20
+          }
+        ]
       }
     ],
     "PostToolUseFailure": [

package/plugins/task-pipeline/hooks/memory-nudge.sh

@@ -0,0 +1,49 @@
+#!/usr/bin/env bash
+# PostToolUse — a stage gate returned and no workflow-memory line follows it.
+#
+# The checkpoint doctrine (references/continuity.md, Part 3) asked every returned gate to
+# write an Observatory checkpoint, or to record that memory is unavailable. It was a step
+# the agent had to remember, and the measured adoption was one write in 293 sessions over
+# fourteen days (sshlg-skills waves, 2026-10-11). This hook reminds at the moment it
+# matters: once per stage line, as context the model reads, and never again for the same
+# line. It decides nothing and blocks nothing.
+#
+# Silent everywhere else: no ledger means exit 0 after one file test.
+set -uo pipefail
+ledger="${CLAUDE_PROJECT_DIR:-$PWD}/.task-pipeline/run.md"
+[ -f "$ledger" ] || exit 0
+python3 - "$ledger" <<'PY' 2>/dev/null || true
+import hashlib, json, os, re, sys
+ledger = sys.argv[1]
+try:
+    lines = open(ledger, encoding="utf-8").read().splitlines()
+except OSError:
+    sys.exit(0)
+last_stage = last_mem = -1
+for i, l in enumerate(lines):
+    if re.match(r"^stage:\s*\S+\s", l):
+        last_stage = i
+    elif l.startswith("event: memory"):
+        last_mem = i
+if last_stage < 0 or last_mem > last_stage:
+    sys.exit(0)
+line = lines[last_stage]
+mark = os.path.join(os.path.dirname(ledger), ".memory-nudged")
+key = hashlib.sha256(line.encode()).hexdigest()[:16]
+try:
+    if open(mark).read().strip() == key:
+        sys.exit(0)
+except OSError:
+    pass
+try:
+    open(mark, "w").write(key + "\n")
+except OSError:
+    pass
+sid = re.match(r"^stage:\s*(\S+)", line).group(1)
+msg = (f"task-pipeline: stage {sid}'s gate returned and no workflow-memory line follows it. "
+       "With Observatory's tools: `scripts/stage_checkpoint.py emit` → observatory_checkpoint_write "
+       "→ `stage_checkpoint.py record --answer -`. Without them: "
+       "`stage_checkpoint.py record --unavailable \"<why>\"`. (references/continuity.md, Part 3)")
+print(json.dumps({"hookSpecificOutput": {"hookEventName": "PostToolUse", "additionalContext": msg}}))
+PY
+exit 0

package/plugins/task-pipeline/skills/evidence-docs/references/hooks.md

@@ -218,7 +218,9 @@ Since v1.50.0 the plugin carries hooks of its own. `hooks/release-gate.sh`
 (`PreToolUse` on `Bash`) refuses an **outward, irreversible act** — `git tag`, a
 tag push, `gh release create`, `npm publish` — while the run says the suite has not
 passed. `hooks/gate-observer.sh` (`PostToolUse` and `PostToolUseFailure`) records
-what the declared gate command actually did.
+what the declared gate command actually did. `hooks/memory-nudge.sh` (`PostToolUse` on `Bash|Edit|Write|MultiEdit`) reminds,
+once per returned gate, that no workflow-memory line follows it
+([`continuity.md`](https://github.com/ssheleg/task-pipeline/blob/main/plugins/task-pipeline/skills/task-pipeline/references/continuity.md), Part 3).
 
 **Two lessons from v1.50.0, both shipped as defects and both fixed in v1.51.0.**
 

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

@@ -121,7 +121,8 @@ default is `Sev × Blast + age_bonus` ([`references/portable-method.md`](referen
 the local priority contract) — and the operator accepts them. Effort never ranks inside an
 audit: what a fix costs is the fixer's decision, not the finder's
 ([`references/portable-method.md`](references/portable-method.md)). An audit
-that edits while it reads cannot be re-run to check itself.
+that edits while it reads cannot be re-run to check itself. In `task-pipeline`'s wave
+mode these rows and the JSON sidecar are wave 0's input: they join its inventory by id.
 
 ## A finding keeps its axes apart, or it is a guess wearing a verdict