task-pipeline-skill 1.39.0 → 1.41.0

package/CHANGELOG.md

@@ -1,5 +1,170 @@
 # Changelog
 
+## v1.41.0 — one line per run is a slope, not a bound
+
+`retro.md` is read **in full** at stage 0, and its own doctrine called both read sections
+*bounded by construction*. Measured 2026-08-10:
+
+```
+standing instructions   ~1 234 tok   capped at ten
+run stamps              ~2 099 tok   27 rows, capped by nothing
+recent log             ~12 441 tok   queried, not read
+```
+
+The v1.38.0 audit found exactly this shape in the narrative log and moved it out of the
+floor. It left the neighbour in the same file, with the same property, because the
+neighbour's growth is **tidy** — one line per run. A tidy slope is still a slope: at a
+hundred runs the stamp table alone is ~7 800 tokens of a floor the doctrine believes is
+bounded.
+
+**The cap is ten, and the cold trigger is why.** It reads *the last five run stamps*, so
+ten is that with a margin and a rotated row can never be one the trigger needed. Eighteen
+stamps rotated into `docs/superpowers/retro/2026-Q3.md`, whole, append-only. The stamp
+section went **2 099 → 1 088 tok**, the read portion **3 333 → 2 335**, and the stage-0
+floor to roughly **35 300**.
+
+### The reader found six ways past the cap, and one of them was the doctrine's own command
+
+R-005's reader defeated the first cap guard six ways, each planted and watched passing:
+
+- **a second `## Run stamps — …` heading in the same file** held forty more rows and
+  passed. The guard read a *section*; stage 0 reads the **file**;
+- **one leading space** on a row — still a valid table row — hid it from `startswith("|")`;
+- **the stamp command this doctrine ships** (`printf '%s · %s\n' …`) appends prose, not a
+  table row. An agent obeying the shipped instruction literally produced forty stamps the
+  guard could not see, with `unlooked: 0`;
+- **`templates/retro.md`** ships the same table to every host project and was outside the
+  corpus — the fourth hand-written list this repository has caught, against an invariant
+  that says corpora are discovered;
+- **rotation by deletion** passed: a stamp removed from `retro.md` and absent from the
+  archive is history destroyed, and the guard could not tell moving from deleting;
+- and the row check — already narrowed twice — was defeated by **swapping the two items
+  around the `·`**, which is the standing instructions' `max 10` answering for the stamps
+  again, on the other side of the separator.
+
+Both guards are rewritten to count by **predicate over a discovered corpus**: three stamp
+shapes (table row, list item, and the `<date> · <sha>` line the doctrine writes), every
+file carrying a `## Run stamps` section, and the doctrine's cap read from the segment that
+names the stamps rather than from anywhere in the row.
+
+**Four surfaces had never learned the rule** — the live section's own intro, stage 10's
+prune, `templates/retro.md`, and `templates/retro-archive.md`, which had no destination
+section for a rotation the doctrine names. And stage 0 still called *one line per run* a
+bound. All five now say the same thing.
+
+**A hand-written count in this release was wrong.** It said twenty-one stamps rotated;
+computed, it is **eighteen** (28 → 10). In a repository whose loudest canon is *compute,
+never restate*.
+
+### Two predicates that were answered by their neighbours
+
+Both found by their own probes, both the same shape as the defects the last release's
+reader named:
+
+- the first version asked whether the file contained *"one line each"* and *"bounded by
+  construction"*. After the fix both survived **only inside the sentences criticising
+  them**, and the guard fired on its own correction. A predicate that cannot tell a claim
+  from its refutation has a false-positive budget above zero, which `gates.md` sets at
+  zero;
+- scoped to the table row, it was then answered by the **standing instructions' own
+  `max 10`** in the same cell. It now reads only the part of the row after `Run stamps`.
+
+- Guards: 248 → **250**.
+
+## v1.40.0 — the loop had a cadence and no queue
+
+`run.loop` said how **often** to continue. It never said **what the next item is**, so an
+armed mode still left the run choosing its next move by recollection — `learned.md` rule
+16, once per fire. And nothing scheduled the next turn at all: on 2026-08-10 a run of
+this pipeline wrote *«продолжаю без остановки»* and the turn ended, because a sentence
+about future behaviour is not a wakeup. That run is this release's occasion and its
+evidence.
+
+### The queue is stage 2's
+
+The **module map** when the brief was a platform, the plan's task list otherwise. Both
+already existed, both were already ordered, and neither had ever been named as the thing
+the loop walks. `run.loop.queue` names it; `run.loop.arm` says where the mode is armed,
+and the default for a queue-bearing run is **after decomposition** — arming at preflight
+arms a loop with nothing to walk.
+
+Arming is a consequence, not a request, for the same reason the mode is recorded rather
+than asked for: a capability the operator must remember to switch on is one they forget
+on exactly the run that needed it.
+
+**What arming does not change is stated where it could be missed.** The four stops are
+the four stops; a `manual` gate still waits; an outward act still needs its own specific
+authorization. *A generic flag is not a specific authorization*, and arming a queue is
+the most generic flag there is — guarded, because that sentence is what the deploy floor
+rests on.
+
+### `mode: dynamic`
+
+`interval` was the only mode while a fixed tick was the only primitive. A harness that
+can schedule its own next turn picks each delay from what it is waiting for, and **prints
+the delay it chose** — the disclosure that replaces an interval run's job id. A run
+silent about its pacing cannot be told apart from one that quietly stopped, which is the
+claim this file already forbade for harnesses with no primitive at all.
+
+### The goal is re-read between items, not only the board
+
+Each iteration already re-measured the work-list, which answers *what is open*. It did
+not answer *whether the open thing still serves what this run was for*. A queue built at
+stage 2 outlives the reason it was built, because the operator learns things between
+items and says so. So the bottom of an iteration now quotes the goal, states whether the
+next item still serves it, and re-orders or re-scopes when it does not — a row that stops
+serving the goal leaves for the board with its reason.
+
+A queue re-derived only by `age` and `sev` is honest about priority and silent about
+purpose. Both numbers can be right while the run finishes something the operator stopped
+wanting two items ago.
+
+### The reader found the contradiction, not the bug
+
+R-005's reader defeated all five guards and then read the doctrine as a reader rather
+than its author. Part 1a said *"arming is a consequence, not a request"* and stated its
+trigger as a fact about the **work** — a queue with more than one item — with no
+antecedent about configuration. Two sections above, the same file says **Default off.
+Silence arms nothing, exactly as silence authorizes no deploy**, and `grill.md`'s deploy
+floor is explicitly said to rest on that distinction. Read cold, Part 1a arms a loop in a
+project with no `pipeline.json` at all.
+
+The contradiction was in the phrasing, not the intent — `stages.md` had already restated
+the rule with the antecedent intact. **Part 1a gave way**, and a guard now requires it to
+state its precondition, because five guards checked for the presence of strings and not
+one would have noticed either reading.
+
+What the reader took apart in the guards, all verified by planting the defect and
+watching `PASS`:
+
+- **a deleted contract was a skip, not a failure.** Removing the whole `run.loop` block
+  left CI green with two tidy `unlooked` lines — and `run` allows additional properties,
+  so the example still conformed while meaning nothing;
+- **`_loop_block` searched instead of addressing.** A deprecated top-level `loop` earlier
+  in file order answered for the real contract;
+- **presence tests let the release's own thesis be reverted.** `arm` existed, so setting
+  the example back to `preflight` passed;
+- **`if _qv and …` short-circuited itself** — an open string in place of the queue enum
+  passed, which is precisely the failure the guard was written for;
+- **the floor guard had never tested its own rule.** Its phrase entered the file in
+  v1.11.0, twenty-nine releases earlier; both doctrinal statements could be deleted and a
+  Rationalizations row kept it green;
+- **the dynamic-disclosure regex was content-blind** — a sentence keeping the words and
+  inverting the obligation passed — and it triggered off the prose word, so renaming the
+  mode switched the guard off;
+- **`arm the mode` matched a bullet forbidding arming**, and `"loop"` matched any
+  sentence about any loop. Both now key on the schema's own tokens.
+
+Guards 233 → **248**: seven more probes than the first pass shipped with, six of them for
+fail sites that did not exist until the reader's findings were fixed.
+
+### Also
+
+- **A guard was listing the legal modes instead of reading them.** Adding `dynamic`
+  failed the guard on a correct example — a check enforcing its own staleness. It now
+  reads the enum out of the schema.
+- Guards: 233 → **248**, one per new fail site, each with its planted defect.
+
 ## v1.39.0 — the skill could not be reached by the word "audit"
 
 `references/audit.md` has said since v0.1.0 that an audit may be **the whole task** —

package/CONTRIBUTING.md

@@ -191,7 +191,7 @@ reads those files, and a partial read shows whichever sections come first.
 `run` block in `pipeline.schema.json` carries the loop mode; the shipped example
 sets `run.loop.mode` explicitly rather than omitting it, because the example is
 what gets copied and an absent field reads as an oversight instead of a decision.
-*(guard: `no explicit run.loop.mode`)*
+*(guard: `run.loop.mode is` … `and the schema's legal set is`)*
 
 **25. The run-wide mode is named by every stage that could be misled by it.**
 `SKILL.md`, `references/grill.md`, `references/build.md`, `references/stages.md`

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.39.0 |
+| **Version** | 1.41.0 |
 | **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, 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.39.0",
+  "version": "1.41.0",
   "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.39.0",
+  "version": "1.41.0",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

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

@@ -46,7 +46,7 @@
       ],
       "gate": {
         "type": "manual",
-        "check": "the user approves the design AND the UI verdict is recorded (does the task touch a user-facing surface — web/mobile/CLI/TUI? this arms the stage-3 UX track). Every REQ is answered by the design, or explicitly dropped by the operator into the carry-over ledger. For a platform (several independent capabilities or shippable surfaces): the module map specs/<topic>-modules.md is committed and approved — brick criteria met or excepted in writing, dependency graph acyclic, build order topological with the walking skeleton first, every REQ mapped to exactly one module, cross-module contracts named with their owner. Single-module work records 'single module: <name>' instead — a skipped decomposition is a recorded decision, never an omission"
+        "check": "the user approves the design AND the UI verdict is recorded (does the task touch a user-facing surface — web/mobile/CLI/TUI? this arms the stage-3 UX track). Every REQ is answered by the design, or explicitly dropped by the operator into the carry-over ledger. For a platform (several independent capabilities or shippable surfaces): the module map specs/<topic>-modules.md is committed and approved — brick criteria met or excepted in writing, dependency graph acyclic, build order topological with the walking skeleton first, every REQ mapped to exactly one module, cross-module contracts named with their owner. Single-module work records 'single module: <name>' instead — a skipped decomposition is a recorded decision, never an omission. THE LOOP'S ARMING STATE IS PRINTED — armed with its queue and pacing, or not armed with the reason; the queue exists at this stage and a loop armed earlier has nothing to walk."
       }
     },
     {
@@ -172,7 +172,12 @@
   ],
   "_run_note": "Run-wide pacing. Shipped explicitly OFF so this example DEMONSTRATES the default rather than relying on its absence — see references/continuity.md. Set mode to 'interval' and a project stops being asked whether to run item-by-item; it still stops at every manual gate. There is no context-budget field here on purpose: the threshold is not measurable, so it is unconditional doctrine, not config.",
   "run": {
-    "loop": { "mode": "off", "interval": "5m", "command": "/loop" }
+    "loop": {
+      "mode": "dynamic",
+      "queue": "module-map",
+      "arm": "after-decomposition",
+      "command": "/loop"
+    }
   },
   "release": {
     "enabled": true,

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

@@ -48,18 +48,34 @@
             "mode": {
               "enum": [
                 "off",
-                "interval"
+                "interval",
+                "dynamic"
               ],
-              "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."
+              "description": "off (the default when absent) = the run pauses between items as it always did. interval = armed with the harness's fixed-tick primitive, one item per fire. dynamic = the harness schedules its own next turn and the run picks each delay from what it is waiting for; a wait on nothing is minutes, not a tick nobody chose. interval and dynamic stop at the same four things — a manual gate, an unresolvable block, a genuine ambiguity, completion — and neither collapses an outward act: a generic flag is not a specific authorization."
             },
             "interval": {
               "type": "string",
               "pattern": "^[0-9]+[smhd]$",
-              "description": "Required when mode is 'interval'. Must divide its unit cleanly (5m, 10m, 2h — not 7m or 90m); a value that does not is rounded to the nearest that does, and the rounding is stated out loud. Pick the shortest interval that is longer than a typical item."
+              "description": "Required when mode is 'interval', and meaningless when it is 'dynamic' — a self-pacing run chooses each delay. Must divide its unit cleanly (5m, 10m, 2h — not 7m or 90m); a value that does not is rounded to the nearest that does, and the rounding is stated out loud. Pick the shortest interval that is longer than a typical item."
             },
             "command": {
               "type": "string",
               "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."
+            },
+            "queue": {
+              "enum": [
+                "module-map",
+                "plan-tasks",
+                "none"
+              ],
+              "description": "What the loop walks. A loop with no queue is a timer: it says how often to continue and never what the next item is, so the run picks its next move by recollection. module-map = stage 2's decomposition (a platform); plan-tasks = stage 4's task list; none = the mode is armed for the stage boundaries only. Doctrine: references/continuity.md -> Part 1a."
+            },
+            "arm": {
+              "enum": [
+                "preflight",
+                "after-decomposition"
+              ],
+              "description": "When the mode is armed. preflight = at the top of the run, the original behaviour. after-decomposition = at the close of stage 2, once the queue exists and has more than one item — the default for a queue-bearing run, because a capability the operator must remember to switch on is one they forget on the run that needed it. Arming never collapses a manual gate or an outward action."
             }
           }
         },

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

@@ -11,6 +11,7 @@ almost no window left, loses the middle of it, and re-derives what it already di
 
 - The limit, before the capability
 - Part 1 — the loop
+- Part 1a — the queue is stage 2's, and the loop arms on it
 - Arming it on Claude Code
 - Other harnesses, and honest degradation
 - What one iteration means
@@ -62,6 +63,62 @@ the boundary between one agent turn and the next. This file is that reach.
 is never asked again — which is the entire point. A mode that has to be requested
 every run is not a mode, it is a habit the operator maintains by hand.
 
+## Part 1a — the queue is stage 2's, and the loop arms on it
+
+**A loop with no queue is a timer.** Until this section existed, `run.loop` said *how
+often* to continue and never said *what the next item is*, so the mode could be armed
+and still leave the run picking its next move by recollection — which is the failure
+[`learned.md`](learned.md) rule 16 is about, running once per fire.
+
+**The queue is the module map** ([`decomposition.md`](decomposition.md)) when the brief
+was a platform, and the plan's task list otherwise. Both already exist and both are
+already ordered; neither was ever named as the thing the loop walks.
+
+**Arming is the execution of a recorded decision, not a fresh request.** Where the mode
+is **recorded** and the queue has more than one item, the loop arms **at the close of
+stage 2** and the run says so in one line. It is not asked for at that point, for the
+same reason the mode is recorded rather than requested: re-asking would rebuild the habit
+the config exists to retire.
+
+**Where nothing is recorded, nothing arms.** Silence arms nothing here too — this section
+moves *where* a recorded mode is armed, from preflight to the close of stage 2. It does
+not make arming unconditional, and a reader who takes it that way would arm a loop in a
+project with no `pipeline.json` at all. That reading was in this section's first draft;
+an independent reader found it before it shipped.
+
+**What arming does NOT change, and this is load-bearing:** the four stops are the four
+stops. A `manual` gate still waits. An outward or irreversible act still needs its own
+specific authorization — *a generic flag is not a specific authorization*, and arming a
+queue is the most generic flag there is. Arming decides only that the run does not stop
+to ask *"shall I take the next one?"*.
+
+**`mode: dynamic` — when the harness paces itself.** `interval` was the only mode while
+the only primitive was a fixed tick. A harness that can schedule its own next turn
+should: the run picks the delay from what it is waiting for, and a wait on nothing is a
+wait of minutes rather than a fixed tick nobody chose. On a harness with neither
+primitive the mode degrades to prose discipline plus the build ledger, and **the run
+says which one it is running** — the rule below about claiming a capability you do not
+have is unchanged and applies to `dynamic` first.
+
+### The goal is re-read between items, not only the board
+
+Each iteration already re-measures the work-list. That answers *what is open*. It does
+not answer *whether the open thing still serves what this run was for* — and a queue
+built at stage 2 outlives the reason it was built, because the operator learns things
+between items and says so.
+
+So at the bottom of an iteration, beside the re-derived `prio`:
+
+1. re-read the brief's goal — one line, quoted, not recalled;
+2. state whether the next item still serves it;
+3. if it does not, **re-order or re-scope the queue and say what moved and why.** A row
+   that stops serving the goal leaves for the board with its reason
+   ([`backlog.md`](backlog.md)), it does not get worked because it was next.
+
+A queue re-derived only by `age` and `sev` is a queue that is honest about priority and
+silent about purpose. Both numbers can be right while the run is finishing something the
+operator stopped wanting two items ago.
+
 ## Arming it on Claude Code
 
 ```
@@ -85,10 +142,22 @@ silent failures otherwise:
   stops on day eight is worse than one that was never armed, because the operator
   believes work is still moving.
 
-Where `run.loop.mode` is `interval`, the **preflight arms it** and prints the job
-id and the cancel command. Arming is not a new decision at that point — the config
-is the recorded authorization, and re-asking would rebuild the habit the config
-exists to retire.
+**Where it arms is `run.loop.arm`,** and there are two points because there are two
+kinds of run:
+
+- `preflight` — the top of the run. Right when the loop walks stage boundaries rather
+  than a list, and the only option before Part 1a existed.
+- `after-decomposition` — the close of stage 2, once the queue exists and holds more
+  than one item. Arming earlier would arm a loop with nothing to walk.
+
+Either way the run **prints the job id and the cancel command**, and arming is not a new
+decision at that point — the config is the recorded authorization, and re-asking would
+rebuild the habit the config exists to retire.
+
+Under `mode: dynamic` there is no job id: the run schedules its own next turn each time
+and prints **the delay it chose and why**, which is the same disclosure in the form that
+mode has. A dynamic run that says nothing about its pacing is indistinguishable from a
+run that quietly stopped.
 
 ## Other harnesses, and honest degradation
 

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

@@ -18,7 +18,7 @@ justifies reading it protects one section while the file below it doubles.
 
 | Artifact | Parts | How it is read |
 |---|---|---|
-| `docs/superpowers/retro.md` — **one per project** | **Standing instructions** (max **10**) · **Run stamps** (one line each) | stage 0, **in full** — both are bounded by construction |
+| `docs/superpowers/retro.md` — **one per project** | **Standing instructions** (max **10**) · **Run stamps** (max **10**, oldest rotate out) | stage 0, **in full** — both are bounded by a **cap**, which *one line each* never was |
 | the same file's **Recent log** | entries from the last five run stamps — narrative, and capped by nothing | stage 0, **queried** by the task's nouns. It said *in full* until 2026-08-10, when it measured **74%** of the file: an uncapped section inside a binding source is what makes the capped part get skimmed |
 | `docs/superpowers/retro/YYYY-QN.md` — the archive | every entry and every retirement ever written, append-only | **queried** by the task's nouns; never read end to end |
 
@@ -32,6 +32,7 @@ file exists to stop.
 
 - Write the entry only for a divergence — and name the layer that owned it
 - Every lesson carries its commit
+- The stamp table is capped at ten, and *one line per run* was never a cap
 - Rotation — the archive is how pruning stops losing things
 - Three grades of fix — take the highest one that can work
 - Stamp first, then prune, then write
@@ -79,6 +80,26 @@ mechanical: the project's documentation gate runs `git rev-parse --verify --quie
 <sha>^{commit}` over every backticked SHA in the retro and its archive
 ([`gates.md`](gates.md)).
 
+## The stamp table is capped at ten, and *one line per run* was never a cap
+
+Measured 2026-08-10: standing instructions **~1 234 tok** behind a cap of ten, run stamps
+**~2 099 tok over 27 rows** behind nothing. Both are read in full at stage 0 and both
+were described as *bounded by construction*. One line per run is a **slope**: at a
+hundred runs the stamp table alone is ~7 800 tokens of a floor the doctrine believes is
+bounded.
+
+This is the same shape the 2026-08-10 audit found in the narrative log and moved out of
+the floor — and it left the neighbour in the same file, with the same property, because
+the neighbour's growth is *tidy*. A tidy slope is still a slope.
+
+**The cap is ten and the trigger is why.** The cold rule reads *the last five run
+stamps*; ten is that with a margin, so a stamp rotating out can never be one the trigger
+needed. At the eleventh, the oldest row moves — whole, with its verdict and its retro
+column — into `docs/superpowers/retro/YYYY-QN.md` under `## Run stamps`, append-only,
+like every other rotation. **The count is printed at the prune**, beside the standing
+instructions' own count, so a table that stops rotating is visible rather than merely
+large.
+
 ## Rotation — the archive is how pruning stops losing things
 
 At the prune, entries older than the last five run stamps **move** to

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

@@ -102,7 +102,7 @@ never that the work was skipped quietly.
   `affected` / `god-nodes` answer *reach*, which is what grep cannot), `CLAUDE.md`,
   `CONTEXT.md`/ADRs, `docs/` + `docs/ux/`, past pipeline briefs and carry-over
   ledgers, **the retro's standing instructions and run stamps** (`docs/superpowers/retro.md`,
-  read **in full** — ten rows and one line per run, both bounded, and they bind this
+  read **in full** — ten standing rows and ten stamps, both bounded **by a cap**, and they bind this
   run; stamp each instruction as it fires. Its *Recent log* is **queried** by the
   task's nouns, not read: uncapped narrative inside a binding source is what makes the
   capped part get skimmed, [`retrospective.md`](retrospective.md)), the **knowledge wiki** if one is
@@ -258,13 +258,21 @@ never that the work was skipped quietly.
   its status, in build order with the walking skeleton first. Single-module work
   records `single module: <name>` in the design and moves on — a skipped
   decomposition is a decision, never an omission.
+- **The queue exists here, so the loop arms here** ([`continuity.md`](continuity.md) →
+  *Part 1a*). Where `run.loop.arm` is `after-decomposition` and the map holds more than
+  one module, arm the mode at the close of this stage and print one line: the mode, and
+  either the job id and its cancel command (`interval`) or the delay chosen and why
+  (`dynamic`). Arming collapses no gate and authorizes no outward act; it decides only
+  that the run does not stop to ask *"shall I take the next one?"*. Single-module work
+  arms nothing and says so — a loop with one item is a timer.
 - **GATE (manual):** the user approves the design, the UI verdict is recorded,
   **every REQ is answered by the design** — a requirement the design doesn't
   address is either covered now or explicitly dropped by the operator, with the
   drop recorded in the carry-over ledger — **and, for a platform, the module map is
   approved**: brick criteria met or excepted in writing, dependency graph acyclic,
   build order topological, every REQ mapped to exactly one module, cross-module
-  contracts named with their owner.
+  contracts named with their owner — **and the loop's arming state is printed**:
+  armed with its queue and pacing, or not armed with the reason.
 
 ## 3 — Spec — with UX track for user-facing tasks
 - **Freedom: medium** — what the contract says is judgement; which contracts must be locked is a list ([`gates.md`](gates.md) → *Axis C*).
@@ -648,7 +656,10 @@ never that the work was skipped quietly.
   with a floor, neither ever a target ([`gates.md`](gates.md) → *Disclosures*); **the
   retrospective is written — stamped first, then pruned, then the entry; the
   list at or under its cap, every deletion logged in the archive with its commit,
-  entries older than five run stamps rotated into `docs/superpowers/retro/`, the run
+  entries older than five run stamps rotated into `docs/superpowers/retro/` **and the
+  stamp table itself held to ten — at the eleventh the oldest stamp rotates whole into
+  the same archive, and both counts print beside the verdict** (the stamp table is read
+  in full at stage 0, so *one line per run* is a slope the prune has to stop), the run
   stamped with its commit, every SHA in either file resolvable, and the
   counts printed beside this verdict**; **where `pipeline.json` → `retro.publish` is
   set, the skill-level insight is published as an issue on the skill's repository —

package/plugins/task-pipeline/skills/task-pipeline/templates/retro-archive.md

@@ -39,3 +39,13 @@ history attached**, which is what this section is for.
 | Date | id | Instruction | Trigger that retired it | Commit |
 |---|---|---|---|---|
 | <YYYY-MM-DD> | R-000 | … | became a check (`npm run lint:paths`) | `<sha>` |
+
+## Run stamps
+
+Rotated out of `retro.md` when its live table passes ten. Append-only, whole rows —
+the cold trigger reads the last five in the live file, so a stamp here is one it no
+longer needs. Moving is not deleting: a stamp that leaves `retro.md` and appears
+nowhere is history destroyed, not archived.
+
+| Date | Topic | Commit | Verdict | Retro |
+|---|---|---|---|---|

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

@@ -61,8 +61,9 @@ shape the hygiene gate's check 6 exists to find.
 
 ## Run stamps
 
-One line per run, appended at stage 10. This is what makes "five runs" countable
-— without it the cold-rule is a guess and the prune becomes a mood.
+One line per run, appended at stage 10, **capped at ten** — at the eleventh the
+oldest rotates whole into the archive. One line per run is a slope, not a bound:
+this section is read in full at stage 0.
 
 | Date | Topic | Commit | Verdict | Retro |
 |---|---|---|---|---|