task-pipeline-skill 1.10.2 → 1.10.3

package/CHANGELOG.md

@@ -1,5 +1,44 @@
 # Changelog
 
+## v1.10.3 — 2026-08-03
+
+### Fixed — the cause behind five audits, rather than a sixth symptom
+
+Five audit passes produced roughly thirty findings. Grouped by shape, **nine of them
+were one missing row**: this repository ships a propagation matrix to every project it
+touches and its own had no row for *adding a document*.
+
+`adoption.md`, `setup.md`, `portability.md` and `learned.md` never reached the README
+map · the manifest covered 14 of 26 references · the Cursor rule ran two releases
+stale · `CONTRIBUTING.md` ran eight guards behind · `agent-sync` was doctrine in four
+files and absent from the companion matrix · `templates/README.md` went stale. One
+cause, nine symptoms, five audits — and **every check was green throughout**, because
+a check can only walk the list it was given.
+
+**The meta-row.** The most frequent change in any documented project is adding a
+document, and it is the row nobody writes — so the matrix ends up unable to catch the
+class it will meet most often. It is now:
+
+- **step 0** of the matrix-building procedure in `references/documentation.md`, with
+  the measurement attached;
+- a row in this repository's own `docs/DOCMAP.md`, first;
+- a row in the seeded `templates/docmap.md`, guarded — a seeded matrix without it
+  fails the build;
+- pass 4 of the entry audit in `references/setup.md`;
+- a named step before the tag in `CONTRIBUTING.md` → *Releasing*, where the one cell
+  that is `review` — the Cursor rule — is called out, because no check can decide
+  whether a change alters how an agent behaves in a **foreign** project. That cell was
+  skipped twice, and the rule shipped two versions stale.
+
+### The two causes no row can fix, stated rather than left implied
+
+**Guards are written after a finding.** The doctrine's own rule — a class seen twice
+becomes a script — is by construction one instance late, and twice a fix was scoped to
+its instance rather than its class.
+
+**Author and reviewer are the same person**, which `SKILL-CARD.md` already discloses.
+Five audits are what a review would have been.
+
 ## v1.10.2 — 2026-08-03
 
 ### Fixed — the list of invariants was eight guards behind, and now checks itself

package/CONTRIBUTING.md

@@ -206,6 +206,14 @@ quote straddling a line-continuation is a citation nothing can find.
 
 ## Releasing (maintainers)
 
+**Before the tag, walk `docs/DOCMAP.md`'s propagation matrix — starting at its first
+row.** The guards cover most of it; the one cell that is `review` is
+`cursor/rules/task-pipeline.mdc`, because no check can decide whether a change alters
+how an agent behaves in a *foreign* project. That cell was skipped for two releases
+and the rule shipped two versions stale. If the change would make an agent act
+differently somewhere else, the Cursor rule is part of the change.
+
+
 1. Bump the version in **all four** places (see invariant 1) and write the
    `CHANGELOG.md` section — what changed and *why it mattered*, not a diff summary.
 2. `npm test` green, commit, push.

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.10.2 |
+| **Version** | 1.10.3 |
 | **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. 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 (15 evals, 5 categories). **Never executed** — see [`evals/RESULTS.md`](evals/RESULTS.md) |
@@ -38,7 +38,7 @@ apply.
    instruction surface, and every one is linked directly from `SKILL.md`.
 2. Read `templates/docgate.sh` before seeding it; it is the only shipped script a
    host project will run on its own repository.
-3. Run `npm run test:all` — 62 guards, each with a negative self-test that plants a
+3. Run `npm run test:all` — 63 guards, each with a negative self-test that plants a
    defect and requires rejection.
 4. Run `python3 evals/run.py` for the behavioural protocol, and read
    `evals/RESULTS.md` for what has actually been observed.
@@ -54,7 +54,7 @@ apply.
 - **Versions are pinned by git tag** and mirrored into `sshlg-skills`'s catalogue.
   Rollback is `git checkout v<previous>` or pinning the previous plugin version;
   the previous version is never deleted.
-- **Behavioural evidence is missing, not merely thin.** 62 structural guards prove
+- **Behavioural evidence is missing, not merely thin.** 63 structural guards prove
   the skill is well-formed. Until `evals/RESULTS.md` carries a dated run, nothing in
   this repository proves it *behaves* — triggers correctly, stays quiet on a
   question, or performs the steps it documents.

package/cursor/rules/task-pipeline.mdc

@@ -465,3 +465,17 @@ contradict it.
 decision about what this project decided belongs in the project. The test for a rule
 you are about to write down: does it name a path, a command or a person? If not, it is
 the pipeline's, and leaving it in one repository is a fork nobody named.
+
+## Writing a propagation matrix — start with the row nobody writes
+
+The most frequent change in any documented project is **adding a document**, and that
+is the row people leave out — so the matrix ends up unable to catch the class it will
+meet most often. Write it first, before the change types you can think of:
+
+> **A new document or rule** → every surface that must *learn it exists*: the index a
+> reader opens, the map, any manifest, the agent-facing rules file. Checked by:
+> whatever check can resolve those, or `review` with the reason none can.
+
+Measured on the project this pipeline comes from: nine findings across five audits
+were that one missing row, with every check green throughout — a check only walks the
+list it was given.

package/evals/RESULTS.md

@@ -37,9 +37,9 @@ or it belongs in a check.
 | Dated runs recorded | **0** | 2026-08-03 |
 
 The bottom two numbers are the honest state of this skill's behavioural evidence.
-Everything else in this repository is proven by 62 structural guards that check the
+Everything else in this repository is proven by 63 structural guards that check the
 *form*; these are the only checks that would speak to the *behaviour*, and they have
-not been run yet. Printed here so "62 of 62 green" is never read as "the skill is
+not been run yet. Printed here so "63 of 63 green" is never read as "the skill is
 known to work".
 
 ## Runs

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.10.2",
+  "version": "1.10.3",
   "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"

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

@@ -2,7 +2,7 @@
   "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/manual gates, a frozen requirement spine that must close with evidence, a loop guard that breaks churn, one provider-agnostic model confirmed up front, and an optional super-ux UX track for user-facing work.",
-  "version": "1.10.2",
+  "version": "1.10.3",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

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

@@ -195,6 +195,14 @@ nobody read is exactly the document nobody updated.
 
 **Build it in five steps** (stage 0; extend it whenever a new doc class appears):
 
+0. **Write the meta-row first: *a new document or rule*.** The most frequent change
+   in any documented project is adding a document, and it is the row nobody writes —
+   so the matrix ends up unable to catch the class it will meet most often. Its
+   *Update these* column is every surface that must **learn the thing exists**: the
+   index a reader opens, the map, any manifest, the agent-facing rules file.
+   Measured on the project this practice comes from: **nine findings across five
+   audits were that one missing row**, and the checks were green throughout, because
+   a check can only walk the list it was given.
 1. List the project's doc classes — one line each: what is this the home of?
 2. For each **change type** the project can undergo, name every document that must
    move.

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

@@ -43,7 +43,9 @@ Seven passes, cheapest first. Each either reports `ok`, a finding, or **`skipped
 3. **Propagation.** Every document named in an entry's `Consequences / affects:` line
    cites that entry — ratcheted, so history is a printed number and not a wall of
    failures ([`adoption.md`](adoption.md) → *Baseline the ratchets*).
-4. **The matrix.** Every row has a *Checked by* cell — a check, or `review` **with the
+4. **The matrix.** It contains the **meta-row** — *a new document or rule* — without
+   which it cannot catch the change type the project makes most often. Every row has
+   a *Checked by* cell — a check, or `review` **with the
    reason no check can decide it**. An empty cell is a finding, not a blank.
 5. **Terms.** Every term the doc map declares resolves to exactly one definition, and
    the definition's home actually contains it. **Only declared terms are checked** —

package/plugins/task-pipeline/skills/task-pipeline/templates/docmap.md

@@ -62,6 +62,7 @@ column is a finding, not a blank.
 
 | Change type | Update these | Checked by |
 |---|---|---|
+| **A new document or rule** — start with this row | every surface that must *learn* it exists: the index a reader opens, the map, any manifest, the agent-facing rules file | `<the check, or `review` with its reason>` |
 | New/changed **decision** | `docs/DECISIONS.md` + every doc in its `Consequences / affects:` line | gate §5 propagation |
 | Question **resolved** | `docs/OPEN_QUESTIONS.md` → `Resolved→DEC-####`, the owning topic doc | gate §2 ids · gate §8 status vocabulary |
 | **Scope** change | `<roadmap>`, `<mvp>`, the register | review — scope is a judgement, not a shape |
@@ -69,6 +70,9 @@ column is a finding, not a blank.
 | `<user-facing behaviour>` | `<scenarios>` + `<flows>` + `<screens>`, same change | `<ux linter>` |
 | `<fill me>` | … | … |
 
+
+**Start with the row above.** The most frequent change in any documented project is *adding a document*, and it is the row nobody writes — so the matrix ends up unable to catch the class it will meet most. On the project this practice comes from, nine findings across five audits were that one missing row.
+
 ## Gates
 
 | Gate | Command | When | Blocking? |