task-pipeline-skill 1.69.0 → 1.71.1

package/CHANGELOG.md

@@ -1,5 +1,90 @@
 # Changelog
 
+
+## v1.71.1 — four shapes of a green that measured nothing
+
+> **v1.71.0 is a burned tag.** Its entry was prepended **above** `# Changelog`, so
+> `test/validate.py`'s newest-section parser read the *previous* release while the
+> negative self-test planted its defect in *this* one. The two looked at different
+> sections, the plant proved nothing, and CI failed with *"the release entry claimed a
+> guard count the workflow does not define"* — which is the R-001 failure the plant's
+> own comment describes, reproduced by the release that shipped the doctrine about it.
+
+Four issues, one class: a signal that reports success while checking nothing. All four
+survived at least one release in a real project, and none is visible to inspection — the
+command reads correctly, the test name is accurate, the document's rows look settled.
+
+### The false-success table gains two shapes, and its rules go from two to four (#48, #49)
+
+**Read through a pipe.** GitHub Actions runs `run:` under `bash -e` **without** `pipefail`, so
+`npm test 2>&1 | tee ../test.log` concluded `success` over its own `# fail 55`. Then the same
+author did it by hand hours after fixing it: `check-docs.sh | grep -E '^(OK|FAIL)' | tail && git
+commit` committed over a `FAIL` printed to their own screen. **This is the least visible entry
+in the table because the command reads as diligence** — `check.sh | grep FAIL` looks like
+somebody being careful.
+
+**An absence with no subject.** A viewport suite pinned a responsive rule as a pair: the column
+visible at 1280, absent at 1279. The column had been removed from the product months earlier, so
+the desktop half failed and the compact half **passed at every width**. The test named after the
+compact band proved nothing about it. This is the complement of *watch the green fail against a
+planted defect*: that rule finds a check which **cannot fail**; this one finds a check which
+**cannot succeed meaningfully**.
+
+### A check with a wrong premise can still be the thing that finds the defect (#40)
+
+A new check going red on day one invites one reflex — *the check must be wrong, relax it*.
+A guard asserted two constants for "the price of one unit per year" were equal; the premise was
+wrong, they belong to two different products. Reading further, the disagreement was **visible to
+customers**: both still sell from one page, and the note under the volume table promised a
+discount computed from the header's price while the table's numbers gave roughly half of it.
+
+`gates.md` now says to **separate the premise from the observation before touching either**, and
+to relax the assertion only after what it surfaced has its own record — otherwise the finding
+leaves with the check that found it.
+
+### A hand-corrected document drifts back within one run (#39)
+
+Four boards consolidated into one, every row re-checked; within 24 hours a row settled in code
+that morning read `open` again — in **two** places, because a row in a section table and again
+in a summary has to be closed twice. **A document's claims are never executed**, so nothing
+distinguishes a row that *is* true from one that *was* true, and the audit correcting it is the
+only reader that checks.
+
+`documentation.md` gains the rule: a correction is done not when the rows are right but when
+**something other than the next audit** will notice them going wrong — with the four claim types
+and what makes each self-checking. Where a claim genuinely cannot be derived, **say so in the
+row**; correcting it silently a second time teaches readers that somebody else is checking.
+
+Guards: 376 → **376**. No guard was added or removed — this release is doctrine, and each of the
+four rules is cited from the reference that owns it rather than restated.
+
+Closes #39, #40, #48, #49.
+
+## v1.70.0 — the stemmer cannot conjugate, so the description says the other form
+
+`запиши решение` — the imperative a person actually types — reached no route at all, while
+`evidence-docs` advertised the infinitive `записать решение`. The umbrella's matcher stems
+`записать` to `записа-` and cannot reach `запиш-`: the с/ш alternation is a conjugation class,
+not an ending, and `lib/triggers.js` says in its own header that it is *deliberately NOT a
+morphological analyser*.
+
+**So the fix is here rather than there.** Teaching a load-bearing stemmer one conjugation
+class for one trigger was measured and refused (`B-84` on the umbrella's board); advertising
+the second form costs **19 characters in a description with 124 free**. The description now
+carries both, and the umbrella routes `запиши решение`, `запишите решение` and
+`запиши решение по архитектуре` to `evidence-docs`.
+
+**One false positive, measured rather than overlooked.** It also fires on «запиши решение
+суда». A court decision does not occur on this machine and the cost of the hit is one injected
+line — where `аудит` was refused against `аудитория` precisely because that word is common.
+The trade is named here so a later reader does not have to re-derive it.
+
+Coverage on the umbrella's own corpus: **64/15 → 65/14** of 79 prompts.
+
+Guards: 376 → **376**. No guard was added or removed — this release changes one description
+and nothing it asserts is new; the umbrella's fixture that every trigger is advertised is what
+holds the pair together, and it lives there rather than here.
+
 ## v1.69.0 — the work graph, and a check that mentions is not a check that binds
 
 **Module 1 of the role-agent programme, complete** — T-1 through T-7, briefed in

package/README.md

@@ -114,7 +114,7 @@ stage and walks the gates. See [Install](#install) for the other channels.
 `task-pipeline` is the reference implementation of **Proof of Done: The Agentic
 Software Development Manifesto** by Sergey Sheleg — *a foundation for building
 software when agents write the code*. The manifesto has its own home:
-<https://github.com/ssheleg/pod-manifesto>.
+<https://podmanifesto.org> (source: <https://github.com/ssheleg/pod-manifesto>).
 
 Its central claim is that the unit of progress is not generated code but an
 **evidence-carrying change**: one carrying the intent it implements, the evidence that

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.69.0 |
+| **Version** | 1.71.1 |
 | **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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.69.0",
+  "version": "1.71.1",
   "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 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.69.0",
+  "version": "1.71.1",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

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

@@ -1,6 +1,6 @@
 ---
 name: evidence-docs
-description: "Use when writing or reviewing anything that will be read as true — a decision record, a README, an acceptance report, a runbook, a changelog entry, an audit finding, or any claim that something was verified. Applies the ten canons of evidence-backed documentation — what makes a claim documentation rather than an assertion — and routes to the doctrine that enforces each one. Also use when a project needs a documentation gate, a decision register, a propagation matrix, or a retrospective that outlives its author. Triggers - 'documentation gate', 'decision record', 'ADR', 'acceptance report', 'runbook', 'is this verified', 'доказательная документация', 'записать решение', 'отчёт о приёмке', 'раннбук', 'чем это подтверждено', 'доки в синхроне'. Not for: drafts, chat answers, commit messages or code comments — say 'без доков' to opt out."
+description: "Use when writing or reviewing anything that will be read as true — a decision record, a README, an acceptance report, a runbook, a changelog entry, an audit finding, or any claim that something was verified. Applies the ten canons of evidence-backed documentation — what makes a claim documentation rather than an assertion — and routes to the doctrine that enforces each one. Also use when a project needs a documentation gate, a decision register, a propagation matrix, or a retrospective that outlives its author. Triggers - 'documentation gate', 'decision record', 'ADR', 'acceptance report', 'runbook', 'is this verified', 'доказательная документация', 'записать решение', 'запиши решение', 'отчёт о приёмке', 'раннбук', 'чем это подтверждено', 'доки в синхроне'. Not for: drafts, chat answers, commit messages or code comments — say 'без доков' to opt out."
 ---
 
 # Evidence-backed documentation

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

@@ -22,6 +22,7 @@ being written twice; write it once, here.
 - The inventory — four questions, answered before the first line of work
 - Registers and ids
 - Single source of truth
+- A hand-corrected document drifts back within one run
 - The Doc Loop
 - Changing your mind
 - The propagation matrix
@@ -214,6 +215,42 @@ doc to its own view is the failure this paragraph exists to prevent.
 
 ---
 
+## A hand-corrected document drifts back within one run
+
+A board, backlog or status document gets corrected during an audit; the same
+contradictions are back inside a day. **Correcting it again is the same
+intervention at the same cost, not a fix.**
+
+Measured: four contradictory boards were consolidated into one, every row
+re-checked against its source. Within 24 hours a row settled in code that morning
+read `open` again — in **two** places, because a row listed in a section table and
+again in a summary has to be closed twice. Another called two files missing while
+one had been written five hours earlier. A count quoted from a generated ledger had
+moved and the row had not.
+
+**Why the manual pass cannot hold.** A document's claims are never executed. Nothing
+distinguishes a row that **is** true from one that **was** true, so the audit that
+corrects it is the only reader that checks — and it runs once. Between audits the
+document is a set of assertions with no mechanism behind any of them, ageing at the
+speed of the work it describes.
+
+So a correction is not done when the rows are right. It is done when **something
+other than the next audit** will notice them going wrong:
+
+| The claim | What makes it self-checking |
+|---|---|
+| a row's status | derived from the artefact that settles it, or a gate that fails when the two disagree |
+| a count | computed at check time and printed beside its command — never transcribed |
+| "these files are missing" | resolved against the filesystem by the check that prints it |
+| a row in two tables | one table, or a guard asserting the pair agrees |
+
+Where a claim genuinely cannot be derived, **say that in the row** — an assertion
+marked as unverifiable is honest, and the next reader stops treating it as measured.
+Silently correcting it a second time is how a document teaches its readers that
+somebody else is checking.
+
+---
+
 ## The Doc Loop
 
 **Fires whenever something is settled — at any stage.** Scope, a contract, a name,

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

@@ -186,6 +186,22 @@ Four preconditions. Skipping any of them turns a run into a claim.
 4. **You have read the ratchet floors.** A pass with a floor that was quietly
    raised is a pass over the thing the floor was hiding.
 
+**And one rule for the moment after.** A new check that goes red on the day it is
+written invites one reflex — *the check must be wrong, relax it*. Sometimes the
+check **is** wrong, **and the red is still the finding.** A guard asserted two
+constants describing "the price of one unit per year" were equal; they belong to
+two different products, so the premise was wrong and the obvious move was to
+delete the assertion. Reading further showed the disagreement was **visible to
+customers**: both products still sell from one page, and the note under the volume
+table promised a discount computed from the header's price while the table's own
+numbers gave roughly half of it. Nothing miscalculated — only the claim on the page
+was false.
+
+So: **separate the premise from the observation before touching either.** Ask what
+the check *saw*, not whether it was entitled to look. Relax or delete the assertion
+only after the thing it surfaced has its own record — otherwise the finding leaves
+with the check that found it, and nothing remembers it was ever seen.
+
 ---
 
 ## False success — when a mechanism reports a win it never checked
@@ -206,19 +222,34 @@ at least one release in this repository:
 | Presence instead of absence | a counter asserted the new number was present, not that the old one was gone | four surfaces still printed the old number, green for three releases |
 | Half-applied batch | a batch of edits reported done while one edit never applied (R-002) | the file was unchanged |
 | Silence read as a pass | a section with no input printed nothing, and the caller counted it as checked | nothing was looked at |
+| **Read through a pipe** | the caller read the **formatter's** exit code, not the gate's | `npm test 2>&1 \| tee ../test.log` under `bash -e` without `pipefail` concluded `success` over its own `# fail 55`; `check-docs.sh \| grep FAIL \| tail && git commit` committed over a `FAIL` printed to the author's screen |
+| **An absence with no subject** | an assertion that a thing is gone, about a thing that exists nowhere | a viewport test asserting a column leaves the tree at 1279px passed at **every** width — the column had been deleted from the product months earlier |
 
 **The test.** For any mechanism you are about to trust, ask:
 *what does it print when it did not look?* If that is indistinguishable from what
 it prints when it looked and found nothing wrong, it is not evidence — give it a distinct `dormant`
 or `skip` state (→ *Progressive arming*), or verify the effect independently.
 
-Two rules follow. Elsewhere in this bundle they are **cited, never restated**:
+Four rules follow. Elsewhere in this bundle they are **cited, never restated**:
 
 1. **Verify by re-reading, not by the reply.** After a teardown, cancel, delete,
    disable, publish or migrate: query the authoritative state and assert the item's
    new condition.
 2. **Assert the absence of the old, not the presence of the new.** A check that only
    proves the new value exists stays green while the old one is still shipping.
+3. **Read a gate's own exit code, never a pipeline's.** `set -o pipefail`, or
+   `${PIPESTATUS[0]}`, or do not pipe. GitHub Actions runs `run:` under `bash -e`
+   **without** `pipefail`, so `gate | tee` reports `tee`. This is the least visible
+   entry in the table because the command reads as diligence: `check.sh | grep FAIL`
+   looks like someone being careful, and it is the shape that reports success while
+   printing failure to the screen of the person who wrote it.
+4. **An absence assertion needs a subject that exists somewhere.** Before pinning
+   "X must not appear here", prove X appears *somewhere* — otherwise the assertion is
+   true for a reason unrelated to what it claims, and the complement of *watch the
+   green fail against a planted defect* is what catches it: that rule finds a check
+   that **cannot fail**, this one finds a check that **cannot succeed meaningfully**.
+   Both are invisible to every mechanical signal — the test is green, its name is
+   accurate, its code reads correctly.
 
 ---