task-pipeline-skill 1.39.0 → 1.40.0

package/CHANGELOG.md

@@ -1,5 +1,99 @@
 # Changelog
 
+## 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.40.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.40.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.40.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/stages.md

@@ -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*).