task-pipeline-skill 1.32.0 → 1.37.0

package/plugins/task-pipeline/skills/task-pipeline/pipeline.schema.json

@@ -4,18 +4,32 @@
   "title": "task-pipeline config",
   "description": "Generic contract for a pipeline config. An ordered list of stages; each stage is run by the host project's own skills/agents and guarded by a typed gate. The framework imposes no specific stages, skills, or gate assignments — those are entirely the host project's config. Copy pipeline.example.json and rewrite it to match your project.",
   "type": "object",
-  "required": ["stages"],
+  "required": [
+    "stages"
+  ],
   "additionalProperties": true,
   "properties": {
-    "version": { "type": "integer", "minimum": 1 },
+    "version": {
+      "type": "integer",
+      "minimum": 1
+    },
     "stages": {
       "type": "array",
       "minItems": 1,
       "description": "The pipeline stages, in order. Any number, any names — your project's real stages.",
-      "items": { "$ref": "#/definitions/stage" }
+      "items": {
+        "$ref": "#/definitions/stage"
+      }
+    },
+    "release": {
+      "$ref": "#/definitions/release"
+    },
+    "run": {
+      "$ref": "#/definitions/run"
     },
-    "release": { "$ref": "#/definitions/release" },
-    "run": { "$ref": "#/definitions/run" }
+    "retro": {
+      "$ref": "#/definitions/retro"
+    }
   },
   "definitions": {
     "run": {
@@ -25,12 +39,17 @@
       "properties": {
         "loop": {
           "type": "object",
-          "required": ["mode"],
+          "required": [
+            "mode"
+          ],
           "additionalProperties": true,
           "description": "Whether the run advances item by item without a discretionary check-in. It NEVER collapses a manual gate or an outward action — a generic flag is not a specific authorization.",
           "properties": {
             "mode": {
-              "enum": ["off", "interval"],
+              "enum": [
+                "off",
+                "interval"
+              ],
               "description": "off (the default when absent) = the run pauses between items as it always did. interval = the run is armed with the harness's own loop primitive and advances one item per fire, stopping only at a manual gate, an unresolvable block, a genuine ambiguity, or completion."
             },
             "interval": {
@@ -43,6 +62,18 @@
               "description": "How this harness arms it, e.g. '/loop'. Harness-specific and therefore project-recorded rather than assumed: on a harness with no loop primitive, omit it — the mode then degrades to prose discipline plus the build ledger, and the run says so instead of implying it is armed."
             }
           }
+        },
+        "review": {
+          "type": "object",
+          "additionalProperties": true,
+          "description": "The review loop's ceiling. Absent, the default is 3 rounds per artifact. It is a DECISION POINT rather than a stop: at the cap the run prints new findings versus findings caused by its own fixes, per round, and either the pair ends the loop or the operator continues it out loud. A flat stop would be wrong — this repository's ten-round runs were still finding real defects on round nine. Doctrine: references/loop-guard.md.",
+          "properties": {
+            "maxRounds": {
+              "type": "integer",
+              "minimum": 1,
+              "description": "Rounds per artifact before the run stops reviewing and measures. Counted from the run ledger's `touch:` pass numbers, never from memory; a round that finds nothing ends the loop by definition and is not counted."
+            }
+          }
         }
       }
     },
@@ -50,48 +81,129 @@
       "type": "object",
       "additionalProperties": true,
       "description": "Optional release automation, entirely project-defined and INDIVIDUALLY TOGGLEABLE. Omit the whole object, or set enabled:false, to turn release automation off for this project. The framework ships an example workflow (.github/workflows/release.yml) whose job is gated on a repo variable so each project arms it on its own; this block is the declarative counterpart the orchestrator reads.",
-      "required": ["enabled"],
+      "required": [
+        "enabled"
+      ],
       "properties": {
-        "enabled": { "type": "boolean", "description": "Master on/off toggle. false (or the object omitted) = no release automation for this project." },
-        "trigger": { "enum": ["tag", "manual", "push", "none"], "description": "What kicks off a release (e.g. a pushed vX.Y.Z tag, manual dispatch)." },
+        "enabled": {
+          "type": "boolean",
+          "description": "Master on/off toggle. false (or the object omitted) = no release automation for this project."
+        },
+        "trigger": {
+          "enum": [
+            "tag",
+            "manual",
+            "push",
+            "none"
+          ],
+          "description": "What kicks off a release (e.g. a pushed vX.Y.Z tag, manual dispatch)."
+        },
         "steps": {
           "type": "array",
-          "items": { "type": "string", "minLength": 1 },
+          "items": {
+            "type": "string",
+            "minLength": 1
+          },
           "description": "Ordered release actions, in prose — project-specific (e.g. create a GitHub release, npm publish). Human-only steps (2FA publish) are named as such."
         },
         "verify": {
           "type": "array",
-          "items": { "type": "string", "minLength": 1 },
+          "items": {
+            "type": "string",
+            "minLength": 1
+          },
           "description": "Post-release smoke checks that must pass after a release — this is the release's own post-deploy gate (stage 8 applied to shipping the package itself)."
         }
       }
     },
     "stage": {
       "type": "object",
-      "required": ["state", "skills", "gate"],
+      "required": [
+        "state",
+        "skills",
+        "gate"
+      ],
       "additionalProperties": true,
       "properties": {
-        "id": { "type": "integer", "description": "Optional ordinal." },
-        "state": { "type": "string", "minLength": 1, "description": "Unique stable key for the stage." },
-        "name": { "type": "string", "description": "Optional human label." },
-        "model": { "type": "string", "description": "Optional model for the stage. Prefer a provider-agnostic token over a vendor id, which goes stale as generations ship and may not exist on the operator's provider at all: 'default' = the model confirmed for this run (recommended: the most capable reasoning model the environment offers), 'inherit' = whatever the operator is currently on. A literal id is allowed but treated as an example, not a contract." },
+        "id": {
+          "type": "integer",
+          "description": "Optional ordinal."
+        },
+        "state": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Unique stable key for the stage."
+        },
+        "name": {
+          "type": "string",
+          "description": "Optional human label."
+        },
+        "model": {
+          "type": "string",
+          "description": "Optional model for the stage. Prefer a provider-agnostic token over a vendor id, which goes stale as generations ship and may not exist on the operator's provider at all: 'default' = the model confirmed for this run (recommended: the most capable reasoning model the environment offers), 'inherit' = whatever the operator is currently on. A literal id is allowed but treated as an example, not a contract."
+        },
         "skills": {
           "type": "array",
           "minItems": 1,
           "description": "The skill(s)/agent(s) that execute this stage. Any names your environment resolves — this is where you plug in your OWN skills.",
-          "items": { "type": "string", "minLength": 1 }
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
         },
         "gate": {
           "type": "object",
-          "required": ["type", "check"],
+          "required": [
+            "type",
+            "check"
+          ],
           "additionalProperties": true,
           "description": "Condition that must pass before advancing to the next stage.",
           "properties": {
             "type": {
-              "enum": ["auto", "manual"],
+              "enum": [
+                "auto",
+                "manual"
+              ],
               "description": "auto = the orchestrator verifies `check` itself (pass/fail); manual = wait for the operator's explicit go."
             },
-            "check": { "type": "string", "minLength": 1, "description": "The gate condition, in prose." }
+            "check": {
+              "type": "string",
+              "minLength": 1,
+              "description": "The gate condition, in prose."
+            }
+          }
+        }
+      }
+    },
+    "retro": {
+      "type": "object",
+      "additionalProperties": true,
+      "description": "Optional. Governs what the retrospective does BEYOND writing to the project's own docs/superpowers/retro.md, which always happens. Omit it and nothing leaves the repository: silence arms nothing, exactly as it authorises no deploy.",
+      "properties": {
+        "publish": {
+          "type": "object",
+          "required": [
+            "repo"
+          ],
+          "additionalProperties": true,
+          "description": "Publish skill-level insights as issues on the skill's own repository, so a defect in the pipeline is fixed once instead of rediscovered in every project. OFF unless this object is present — opening an issue in another repository is an outward act, and an outward act taken from a generic flag is one nobody authorized. The body is printed in full before it is sent, and the printed string and the sent string are the same string. Doctrine, including the five redaction rules: references/retrospective.md.",
+          "properties": {
+            "repo": {
+              "type": "string",
+              "pattern": "^[^/\\s]+/[^/\\s]+$",
+              "description": "owner/name of the SKILL's repository, never the host project's."
+            },
+            "label": {
+              "type": "string",
+              "description": "Applied to every issue opened this way, so the operator can read them as a stream rather than find them by accident."
+            },
+            "redact": {
+              "enum": [
+                "strict"
+              ],
+              "description": "Only 'strict' exists, and it is not a level among others: the five rules are the contract. A field with one legal value is here so a reader asking 'what redaction applies?' finds the answer in the config rather than assuming none does."
+            }
           }
         }
       }

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

@@ -59,9 +59,15 @@ at a glance.
 > external skill**. A host project may relocate the root via its `CLAUDE.md`; keep
 > the shape, keep the slugs.
 
-Loop-bearing runs also keep a **git-ignored** run ledger at `.task-pipeline/run.md` —
-stage-level and program-level repeat touches, one line each, so the loop guard can
-detect churn after a lost context (see [`loop-guard.md`](loop-guard.md)).
+**Every** run keeps a **git-ignored** run ledger at `.task-pipeline/run.md`, seeded at
+stage 0 from [`../templates/run.md`](../templates/run.md). Three line shapes: a
+`stage:` verdict when a gate returns, an `iter:` line when an iteration closes, and a
+`touch:` line per file per repeating pass. Two readers depend on it —
+[`loop-guard.md`](loop-guard.md) detects churn from the `touch:` lines after a lost
+context, and [`progress.md`](progress.md) derives the stage rail and the iteration
+counter from the other two. It was described as loop-only until 2026-08-10 and, in
+practice, written by no run at all: the guard that calls its own detection *mechanical*
+had no input in any run to date.
 
 Stage 5 also creates a **git-ignored** scratch workspace per plan at
 `.task-pipeline/build/<plan-basename>/` — ledger, task briefs, implementer reports,
@@ -158,12 +164,13 @@ plugins/task-pipeline/
       acceptance.md retrospective.md          #   stage 10 (close-out, then the retro)
       audit.md                                #   cross-cutting: the ladder + seams
       loop-guard.md                           #   cross-cutting: churn detection
+      progress.md                             #   cross-cutting: what the run prints about itself
       stages.md model-tiering.md              #   gates, model policy
       conventions.md artifacts.md             #   host conventions, this layout
       companion-skills.md                     #   optional companions + preflight
     templates/                                # skeletons seeded into a host project
-      hygiene.sh                            # -> scripts/check-hygiene.sh (stages 5, 6, 9)
-      README.md brief.md carryover.md context.md adr.md retro.md
+      hygiene.sh docgate.sh                 # -> scripts/check-hygiene.sh, check-docs.sh
+      README.md                             # the index — and it is the list, not a copy of it
 cursor/rules/task-pipeline.mdc                # Cursor channel (self-contained rule)
 bin/task-pipeline.js                          # npx installer (package task-pipeline-skill)
 install.sh                                    # POSIX installer

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

@@ -43,7 +43,8 @@ better, plus one that is required only for user-facing work.
 
 | Skill / tool | Needed for | Required? | Install |
 |---|---|---|---|
-| **super-ux** (`ux-foundation`, `ux-flows`, `ux-scenarios`, `ux-audit`, `/ux`, `/ux-lint`) | stage 3 UX track | **Required for any user-facing task** | `/plugin marketplace add ssheleg/super-ux` → `/plugin install super-ux@super-ux` (or `npx skills add ssheleg/super-ux`) |
+| **super-ux** (`ux-foundation`, `ux-flows`, `ux-scenarios`, `ux-audit`, `/ux`, `/ux-lint` — **and the copy half**: `copywriting`, `brand-voice`, `/brand-init`, `/copy`, `/brand-lint`, plus `/vision`) | stage 3 — the **UX track** *and* the **COPY track**. This row named six surfaces until 2026-08-10 while super-ux shipped eight skills and fifteen commands: the whole brand-and-copy half was invisible to this pipeline, so a run built scenarios and screens and then wrote the interface strings by taste | **Required for any user-facing task** | `/plugin marketplace add ssheleg/super-ux` → `/plugin install super-ux@super-ux` (or `npx skills add ssheleg/super-ux`) |
+| **sheleg-design** (`/sheleg-design`) | stage 3 — the **VISUAL track**: tokens and themes, typography and rhythm, motion and how it degrades to rest, the visual language a brand is recognised by. It answers *how it looks*, which no other companion here answers — `super-ux` decides what the interface must do, `copywriting` how it sounds. Before 2026-08-10 this skill appeared once in the whole bundle, as a name in a list | **Recommended** on any task with a visual surface; never a gate. Absent → the run says the visual layer shipped **undesigned**, which is the honest name for picking values at the keyboard | `/plugin marketplace add ssheleg/sheleg-design` → `/plugin install sheleg-design@sheleg-design-skill` |
 | **context7** (MCP — call tools fully qualified: `context7:resolve-library-id`, `context7:query-docs`) | stage 1 docs study | Recommended (web-search fallback) | connect the context7 MCP server |
 | **Figma** (MCP) | stage 3 UX track, when the project designs visually — super-ux mirrors each `SCR-` screen/state into a frame | Optional, **UI + Figma-on only**. Absent → super-ux degrades to text-only *by itself and never blocks*, so shipping a UI feature with no mockups becomes a silent scope call — which is why the stage-0 sweep decides it | connect the Figma MCP server (`/mcp`, or your claude.ai connectors) |
 | **[obsidian-wiki](https://github.com/ar9av/obsidian-wiki)** (`wiki-query`, `wiki-update`) | **stage 0 harvest** (query what's already known) **+ stage 9 sync** | **Recommended** — never a gate; absent → harvest runs on repo docs alone | `pip install obsidian-wiki` → `obsidian-wiki setup --vault /path/to/your/vault` |
@@ -77,9 +78,16 @@ exchange:
 
 ```
 Pipeline companions (stage doctrine is built in — nothing to install for it):
-  ✗ super-ux           — this task looks user-facing; required for the UX track:
+  ✗ super-ux           — this task looks user-facing; required for the UX track,
+                         and it also owns the COPY track (copywriting, brand-voice):
                            /plugin marketplace add ssheleg/super-ux
                            /plugin install super-ux@super-ux
+  ✗ sheleg-design      — this task has a visual surface; it owns the VISUAL track:
+                         tokens, themes, typography, rhythm, motion and its rest state:
+                           /plugin marketplace add ssheleg/sheleg-design
+                           /plugin install sheleg-design@sheleg-design-skill
+                         (running without it — the visual layer ships undesigned,
+                          and the close-out says so in those words)
   ✓ context7           — ready
   ✗ Figma MCP          — this task is user-facing and the project designs in Figma
                          (docs/ux/foundation.md → Design tooling). Without it the
@@ -120,7 +128,16 @@ Install the ✗ items you want, answer the model line, then say "continue".
 Rules:
 
 - Only flag **super-ux** when the task implies a UI (the stage-0 grill decides;
-  when unsure, flag it — a false positive costs one install).
+  when unsure, flag it — a false positive costs one install). It arms **two** tracks,
+  not one: the UX chain and the copy layer.
+- **sheleg-design**: flag it when the task has a **visual** surface — a page, a screen,
+  a themed component, a landing, a dashboard. Detect via a resolving `/sheleg-design`.
+  **A CLI, a library, a backend service or an internal script does not flag it**, and
+  neither does a purely structural change to an existing screen: choosing a palette for
+  a log parser is how a recommendation is taught to be noise, and this bundle already
+  spent a rule learning that about the browser. Absent → the run continues and says the
+  visual layer shipped **undesigned**; that is a weaker claim and the close-out records
+  it as one, exactly as it does for a surface verified by reading the diff.
 - **obsidian-wiki**: detect via `~/.obsidian-wiki/config` or a resolving
   `wiki-query`/`wiki-update`. Present → say `✓ ready` and use it in the harvest.
   Absent → print the two install lines **once** and continue; never ask twice in a

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

@@ -129,9 +129,26 @@ works a stale board for as long as the loop runs. One command, at the top of the
 iteration, recorded ([`knowledge-sources.md`](knowledge-sources.md) → *Carried-in
 claims*; [`learned.md`](learned.md) rule 16).
 
+**The work-list is `docs/superpowers/backlog.md`** ([`backlog.md`](backlog.md)), and the
+other half of the same measurement is the exposure line ([`exposure.md`](exposure.md)).
+Counted at the top of the iteration, re-derived at the bottom — `age` moves on its own,
+so the re-derivation is the only moment the board stops being stale.
+
 This is also where a loop's report goes wrong most quietly. *"Next up is X"* at the
 end of an iteration is a claim about the board, and it is the one sentence in the
-whole cycle that no gate reads. It cites the measurement or it is not written.
+whole cycle that no gate reads. It cites the measurement or it is not written — **a
+`B-NNN`, not a description**: *"next up: B-014"* can be checked against the file,
+*"next up: the export fix"* cannot.
+
+**And it is printed, in one fixed shape** ([`progress.md`](progress.md)):
+
+```
+▶ <topic> · <module> (N/M) · <id> <stage> <gate> · iter <N> · gates <N/M> · next B-NNN
+```
+
+The iteration number is a count of `iter:` lines in `.task-pipeline/run.md`, not a
+number the agent is carrying. After a compaction the agent's count is gone and the
+file's is not — which is the argument the build ledger already won one stage down.
 
 ## Parked at a manual gate
 

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

@@ -0,0 +1,110 @@
+# Exposure — how much unverified work has piled up, and what to look at
+
+**One job: turn the verification ledger into a number somebody can act on, without
+pretending it is a probability.**
+
+[`verification.md`](verification.md) records whether a person ever confirmed each shipped
+REQ. This file turns that record into the line printed beside every verdict, and into the
+list `/task-pipeline checkup` hands an operator.
+
+---
+
+## Contents
+
+- Why it is not a probability
+- The components, each named
+- The check-list, and how it is ordered
+- `/task-pipeline checkup`
+- What the loop does with it
+- Rationalizations
+
+## Why it is not a probability
+
+The request that produced this file asked for *"the probability of an error"*. That is
+not computable from these inputs, and a number presenting itself as `P(defect)` is the
+false-success class this repository has spent its whole history removing: an estimate
+wearing a measurement's clothes.
+
+**So no percentage, ever** — the guard rejects a `%` on the exposure line. What ships is
+a **vector with its components named**, and the reason is not fussiness: a single score
+invites a threshold, and a threshold here is a target on `never`, which is the one thing
+[`verification.md`](verification.md) says may never have one.
+
+It could become a real probability later. `verification.md` is exactly the journal that
+would make calibration possible after enough runs carry both a confirmation date and a
+defect. Until then it is named honestly.
+
+## The components, each named
+
+```
+exposure: N unverified · never checked · N releases carry one
+```
+
+**The example carries no numbers, deliberately.** It said `99 unverified` and
+`31 releases since the last human confirmation` until 2026-08-10 — one figure lifted
+from this repository's live count, which drifts, and one wording the code has never
+printed. A worked example that disagrees with its own output teaches the wrong format
+to every reader who trusts the doctrine over the terminal, and this one disagreed in
+both directions at once.
+
+- **unverified** — rows whose `Human` reads `never`.
+- **since** — days since the newest `Human` date. When **no** row has ever been
+  confirmed, this prints the literal **`never checked`**, not `0 days`: zero would read
+  as *checked today*, which is the opposite of the truth and exactly the kind of quiet
+  inversion this pipeline exists to prevent.
+- **releases** — tags cut since that date, or since the first shipped row when there is
+  no date. It is the component an operator feels: *"how much has gone out on top of
+  something nobody looked at."*
+
+Every component is derived from files in the repository. None is estimated.
+
+## The check-list, and how it is ordered
+
+The list is the deliverable — a number without it tells somebody they have a problem and
+not where. Ordered by what the repository can defend:
+
+1. **Oldest first**, by `Shipped in`. The longest-unconfirmed row is the one whose
+   context is most gone, and whose author is least likely to remember it.
+2. **Tie-broken by blast radius** where the board carries a row for it, reusing
+   [`backlog.md`](backlog.md)'s own stated input rather than inventing a weight here.
+
+No third factor. A ranking with an unstated input is the hand-assigned priority the board
+already refuses.
+
+## `/task-pipeline checkup`
+
+A **mode of the command**, like `setup` — not a new command, because a second command
+costs every surface a command touches and this repository has learned what that means.
+
+**It runs with no task in flight, and that is the point.** Accumulated unverified work is
+invisible *precisely because nobody is running a pipeline*; a check that only exists
+inside a run can never say *"stop, fourteen things are unconfirmed."* So it takes no
+brief, opens no grill, and writes nothing on its own.
+
+It prints four sections, each read from a file this pipeline already keeps: the exposure
+line and its check-list, the board's open rows by computed priority, the carry-over
+ledgers' unresolved count, and the code graph's staleness where one exists.
+
+**Where the operator asks it to file findings**, it appends board rows whose `Source`
+names the checkup and its date — so a row a machine created is distinguishable from one a
+run surfaced. It prints what it would add first. Never silently.
+
+## What the loop does with it
+
+[`continuity.md`](continuity.md) has always required each iteration to re-measure the
+work-list, and said that *"next up is X"* is a claim about the board that no gate reads.
+[`backlog.md`](backlog.md) is that board; the exposure line is the other half of the same
+measurement, and both are read at the top of an iteration and re-derived at the bottom.
+
+An iteration that reports what it will do next **cites the file**: `B-014`, not *"the
+export fix"*.
+
+## Rationalizations
+
+| The excuse | What is actually true |
+|---|---|
+| "Give me one number, I'll decide the threshold" | The threshold would be a target on `never`, and the column would start lying within a week. The components are one line; read them. |
+| "A percentage is easier to communicate" | It is easier to communicate because it says more than is known. That is the whole objection. |
+| "The check-list is long, just show the top three" | Then the fourth is never checked and nobody knows it exists. Print it all; the operator can stop reading. |
+| "Checkup duplicates stage 8" | Stage 8 verifies **this run's** deploy. Checkup asks what has accumulated across all of them, which no stage is ever in a position to ask. |
+| "We'll run checkup when something breaks" | After a break you know where to look. The list exists for before. |

package/plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md

@@ -22,6 +22,7 @@ searches.
 
 - Bookkeeping — the thing that makes detection mechanical
 - Detection — any one of these trips the guard
+- The review loop — a cap that measures rather than stops
 - The break protocol
 - When to stop and hand back
 - Rationalizations
@@ -30,7 +31,8 @@ searches.
 
 You cannot detect churn from memory, especially after compaction. Every repeating
 pass appends one line to the run's ledger (`.task-pipeline/build/<plan>/progress.md`
-for stage 5; `.task-pipeline/run.md` for stage-level and program-level loops):
+for stage 5; `.task-pipeline/run.md` for stage-level and program-level loops —
+**seeded at stage 0** from [`../templates/run.md`](../templates/run.md)):
 
 ```
 touch: <file> — pass <N> (<stage|round|module>) — reason: <finding id / gate item>
@@ -40,6 +42,12 @@ One line per file per pass. The reason must name **what forced the edit** — a
 finding id, a failed gate item, an operator instruction. "Cleanup", "polish" and
 "while I was there" are not reasons; they are churn with better manners.
 
+**This ledger was required here from the day the file shipped and written by no run
+until 2026-08-10.** The detection below calls itself mechanical; with no ledger it had
+no input at all, so the guard sat on rung 1 while every reader took it for rung 3
+([`gates.md`](gates.md) → *Axis B*). It is now seeded at stage 0 and named in that
+stage's gate — which is the whole difference between a rule and a rule that runs.
+
 ## Detection — any one of these trips the guard
 
 1. **Revert-oscillation.** An edit restores something an earlier pass in this run
@@ -59,7 +67,48 @@ finding id, a failed gate item, an operator instruction. "Cleanup", "polish" and
 
 Caps that trip the guard by themselves: **5 fix rounds** per task
 ([`build.md`](build.md)), **2 re-entries** per stage per artifact, **3 passes** per
-module in the program loop.
+module in the program loop, and **3 review rounds** per artifact — which is not a stop
+but a measurement, below.
+
+## The review loop — a cap that measures rather than stops
+
+The caps above govern loops that **edit**. A review loop does both: the reader finds,
+the run fixes, the reader reads again. It had no cap at all until 2026-08-10, and this
+repository's own run stamps say what that cost — **ten rounds, ten, eight, four,
+three** — against a stated ceiling of two re-entries per stage. Nothing tripped,
+because a review round was named in no cap.
+
+**A flat cap would have been the wrong fix.** Every one of those runs recorded *"none
+from my probes"* beside its count: the reader was still finding real defects on round
+nine. Stopping at two would have shipped them.
+
+So the cap is a **decision point**. Default **3 rounds** per artifact, recorded in
+`pipeline.json` → `run.review.maxRounds`. On reaching it, stop reviewing and print the
+pair [`audit.md`](audit.md) already defines — new findings, and findings caused by this
+run's own fixes — per round:
+
+```
+review cap reached — 3 rounds — artifact: test/validate.py
+  round 1: 12 new · 0 self-inflicted
+  round 2:  5 new · 1 self-inflicted
+  round 3:  1 new · 3 self-inflicted
+```
+
+- **Self-inflicted ≥ new** — the axis is exhausted ([`audit.md`](audit.md) → *Every
+  pass changes the axis*). Stop. Every remaining finding becomes a board row with its
+  evidence ([`backlog.md`](backlog.md)); none is dropped.
+- **New > self-inflicted** — the reader is still paying. Continuing is then the
+  operator's call, made with the numbers in hand rather than out of fatigue.
+
+**The pair is the whole point.** A round count alone says how tired everyone is; the
+pair says whether the loop still produces anything. Measured on one file once, the
+guard's shapes and the run's own prose disagreed — one still paying, one exhausted —
+so a single number would have stopped the half that was working and continued the half
+that was not.
+
+**Rounds are counted from the ledger, never from memory**: distinct `pass N` values on
+`touch:` lines at the review stage. A round that finds nothing ends the loop by
+definition and needs no counting.
 
 ## The break protocol
 
@@ -109,6 +158,7 @@ far cheaper than a third round of the same argument.
 | Excuse | Reality |
 |---|---|
 | "One more pass and it converges" | Two passes with the same reason already proved it doesn't. The disagreement is above the code. |
+| "The reviewer is still finding things, so keep going" | Then say so with the pair: new versus self-inflicted, per round. If new still leads, that is an argument. Ten rounds with nobody counting is not. |
 | "I'll just revert to what worked" | That is the oscillation, not the exit. Name A and B first. |
 | "The reviewer keeps changing its mind" | Different findings on the same lines mean the requirement is ambiguous. That's a spec question. |
 | "Tidying while I'm in the file" | Untracked edits are what make churn invisible. One reason per change, in the ledger. |

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

@@ -52,10 +52,12 @@ a row pointing outside the bundle is the defect this file exists to catch.
 | The entry audit and what it inspects | `references/setup.md` |
 | The ladder, seams, axis rotation, ratchets | `references/audit.md` |
 | Loop detection and its caps | `references/loop-guard.md` |
+| **What the run prints about itself** — the header block, the rail, the iteration line | `references/progress.md` |
 | **The run mode** — item-by-item pacing, default off, what it never collapses | `references/continuity.md` |
 | **The context budget** — the evidence rule and what a flush actually updates | `references/continuity.md` |
 | **The board** — the work-list between runs, its computed priority, and the ledger seam it resolves | `references/backlog.md` |
 | **The verification ledger** — what shipped, and whether a human ever confirmed it | `references/verification.md` |
+| **Exposure** — the unconfirmed count as a named vector, never a probability, and the `checkup` mode | `references/exposure.md` |
 | The retro: prune, cap, commits, archive | `references/retrospective.md` |
 | Rules earned by failure | `references/learned.md` |
 | **The routing default and its boundary** | `templates/routing-rule.md` |