task-pipeline-skill 1.93.2 → 1.94.1

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

@@ -27,19 +27,63 @@ almost no window left, loses the middle of it, and re-derives what it already di
 
 **The loop mode collapses discretionary check-ins. It collapses nothing else.**
 
-- A `manual` gate still waits for an explicit operator go. Always.
-- An outward or irreversible act — deploy, publish, opening a PR, creating or
-  editing a shared design file — still needs its own authorization. A recorded
-  loop mode is a **generic** flag, and a generic flag is not a specific
-  authorization; that floor is set in [`grill.md`](grill.md) and this file does
-  not lower it.
-- **Default off.** Absent config and absent instruction, the mode is off. Silence
-  arms nothing, exactly as silence authorizes no deploy.
+- A `manual` gate requires the operator's explicit go. A specific standing authorization
+  naming that gate's act is such a go; cite its source and scope in the gate record.
+  Without it, the gate waits. A generic instruction to continue is not authorization.
+- An outward or irreversible act — deploy, publish, a tag or a release, sending to a
+  person, spending money, creating or editing a shared design file — still needs its own
+  **specific** authorization. A recorded loop mode is a **generic** flag, and a generic
+  flag is not a specific authorization; that floor is set in [`grill.md`](grill.md) and
+  this file does not lower it.
+- **Pushing this repository's work and opening its pull request** is armed by a specific
+  standing authorization that names it — a recorded instruction to push the requested work
+  to the repository's own remote ([`build.md`](build.md) → *6. Integrate, then finish*).
+  Without one it waits for the go like the acts above. Another repository's PR is outward
+  every time ([`conventions.md`](conventions.md)).
+
+**What arms the loop — exactly three sources, and the ledger says which.**
+1. `run.loop` in `pipeline.json` (Part 1);
+2. the operator's answer at preflight;
+3. **a standing instruction the host already carries** — an organisation's principle that
+   a free agent takes the next task, a global instruction file, a recorded decision.
+
+The run cites its source once, in the ledger: `loop: armed by <source:line>`.
+**Silence still arms nothing**: absent all three, the mode is off, exactly as silence authorizes no
+deploy. A project with no such instruction behaves as it always did.
+
+**What a watcher may do unasked.** A wait is not a stop: while a review, CI, a peer's
+answer or a release run is pending, the run starts a watcher and takes the next independent
+item (*Waits outlive turns*, below). When the wait clears, the watcher may take — **only
+where a standing instruction names that class of act** — these steps: merge under the
+repository's own integration policy, release a lease, rebase a stacked branch onto what
+landed, notify. Deploy, publish, tag and sending to people stay gated unless a *specific*
+standing authorization names them. A recorded "releases are the agent's" decision is one:
+it names the act class — the tag, and the publish its release run performs — and, when it
+names no repositories, it covers every repository its owner governs. It does not stretch to
+a deploy or a message it does not name.
+
+**Work that depends on a pending change is not blocked by it**: start it on a branch
+stacked on the pending one, open its PR against that branch, and rebase or merge when the
+pending change lands. **A watcher polls at the pace its wait changes** — a PR or a peer's
+answer every one to two minutes, a release run while it runs, a scheduled time at that time
+— and that pace is separate from the loop's `/loop` interval below, which paces items, not
+waits.
 
 The mode's whole content is the removal of *"should I continue?"* between items
 the operator already asked for. Anything beyond that is a different decision,
 taken separately.
 
+### Waits outlive turns
+
+A watcher started inside a session — a background loop, a monitor, a session cron —
+dies with the session. **A wait that can outlive the session goes on a durable trigger**: a
+launchd or systemd job, an `at` one-shot, a CI schedule, or a board row with a due time that
+a session-start hook surfaces, where the host has one. Its one line — what it waits on and which trigger acts on it —
+goes into the handoff or the board ([`backlog.md`](backlog.md)), not only into the chat,
+because the chat is the one place the next session will not read. On Claude Code the
+session-bound primitives are a `run_in_background` loop, a Monitor and `/loop`; on other
+harnesses, a background process or the host's own scheduler.
+
 ## Part 1 — the loop
 
 **On, the run advances one item per iteration and does not ask between items.**
@@ -52,15 +96,21 @@ This spans the whole run, not one stage:
 - the acceptance → retro tail, which is where runs most often stall one step from
   finished.
 
-It stops for exactly four things: a `manual` gate, a block it cannot resolve, a
+It stops for exactly four things: an unmet `manual` gate, a block it cannot resolve, a
 genuine ambiguity the brief does not answer, and completion.
 
-**A block or an ambiguity stops its node, not the run.** The node is parked with the
-question as its reason, marked `needs-operator` and answerable without context
-([`prioritisation.md`](prioritisation.md) → *5. Where the human goes*), and the run
-continues on every node it does not block. The run itself stops only when the whole
-frontier is blocked — `graph.py next` exits `4` — and the questions are then asked
-together. **When the board is empty, say so once**, and do not invent work to fill it.
+**A block or an ambiguity stops its node, not the run.** An ambiguity whose answer is
+internal and reversible is not a stop at all: the run takes the recommended answer, records
+it as **assumed** on the node, and continues ([`iteration.md`](iteration.md) → *Question
+rounds*). Otherwise park the node with its actual reason and owner: only human-owned
+questions are marked `needs-operator` and made answerable without context
+([`prioritisation.md`](prioritisation.md) → *5. Where the human goes*); external waits
+get watchers, and project-owned questions go to the owning Project under
+[`iteration.md`](iteration.md)'s board rule. The run continues on every node it does
+not block. When the whole frontier is blocked — `graph.py next` exits `4` — classify the
+recorded reasons: external waits go on watchers, human decisions go into the question
+batch. Exit 4 does not prove a human gate or completion. A watcher keeps the recorded
+next action alive while no independent node is runnable. **When the board is empty, say so once**, and do not invent work to fill it.
 
 **This extends [`build.md`](build.md); it does not replace it.** That file's
 *Continuous execution* rule governs the inside of a stage-5 execution — do not
@@ -84,8 +134,13 @@ and still leave the run picking its next move by recollection — which is the f
 nodes and nothing else. It is preferred over the two below for one measured reason — a
 400-node graph and a 4-node graph produce the same 27-byte frontier, so the cost of knowing
 what is next does not grow with the programme. `run.loop.queue: work-graph` records it, and
-`next`'s exit codes are what the loop branches on: `3` is *every node is done*, `4` is
-*what remains is blocked or parked*, and those are different endings.
+`next`'s exit codes are what the loop branches on: `3` is *every node is terminal*
+(including deliberately parked nodes), `4` retains another unresolved barrier, and
+`6` means recorded watched waits hold every remaining dependency leaf. On 6, keep
+the recorded watchers armed and take independent work; it is neither completion
+nor a new human gate. `graph.py wait` records the locator and `resume --wait-id`
+resolves that exact wait; neither executes a watcher or grants authority. See
+[`work-graph.md`](work-graph.md) → *Watched external waits*.
 
 **Otherwise 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
@@ -97,6 +152,10 @@ stage 2** and the run says so in one line. It is not asked for at that point, fo
 same reason the mode is recorded rather than requested: re-asking would rebuild the habit
 the config exists to retire.
 
+**A standing instruction the host carries counts as recorded** (*The limit, before the
+capability*, source 3): it arms at the close of stage 2 like `run.loop`, unless the
+instruction itself says otherwise, and the ledger cites it.
+
 **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
@@ -104,7 +163,8 @@ project with no `pipeline.json` at all. That reading was in this section's first
 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
+stops. A `manual` gate waits unless a specific standing authorization already names
+its act, cited with its source and scope. 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?"*.
@@ -293,10 +353,12 @@ true.
 
 ## What happens at the signal
 
-The four acts above, in order, and one prohibition: **do not begin an item you
-cannot finish inside what is left.** When the next item is plainly too large,
-say so and take the smaller thing that fits — closing a ledger, writing a decision
-that is already settled, updating a REQ status.
+The four acts above, in order, and one prohibition: **no new item starts.** This is the one
+carve-out from "take the next task in the same turn": **at the compaction signal, finish the
+current unit and write the next task into the handoff** — the ledger's next line, the board
+row — **instead of starting it.** Until compaction, the only writes are to what already
+exists: the ledger, the plan, the decisions already settled, the REQ statuses. The next
+turn, after compaction, takes the written task from there.
 
 If the project has recorded that it must not cross a compaction mid-stage, stop at
 the stage boundary instead and hand off. That is a project answer, not a default:
@@ -318,6 +380,11 @@ right costs nothing extra and pays twice.
 
 ## Part 3 — workflow memory at the stage boundary
 
+Project Observatory is a separately installed, public engine:
+[passioncode-ai/project-observatory-dashboard](https://github.com/passioncode-ai/project-observatory-dashboard)
+— its README's *Install* and *MCP* sections say how to run it and connect it. Without it,
+everything below degrades to one ledger line and the run continues.
+
 Which of the five handoff mechanisms carries what — the Git record, Observatory's lease
 and checkpoint, a host's launch context, the inbound queue — and the order a successor
 reads them in, has one home:
@@ -333,9 +400,9 @@ checkpoint**, and the next executor continues from the last finished stage.
 - **How.** `scripts/stage_checkpoint.py emit` prints the tool's arguments, built from the ledger alone: the topic, the verdicts, the next stage, the operator's constraints and key names. Pass them to `observatory_checkpoint_write`, or to `memory.checkpoint.write` under memory/0.1. Then hand the answer to `stage_checkpoint.py record --answer -`.
 - **The constraints.** Give the brief's restrictive rules once, as `--constraint`. They are carried to every later boundary, and a successor reads them first.
 - **Keys.** Pass keys by name, as `--credential PROJECT/ENV/NAME`, never as a value.
-- **Without the tools.** `stage_checkpoint.py record --unavailable "<why>"` appends one `event: memory — unavailable` line, and the run continues exactly as before. Missing memory is a state the ledger names, not a failure.
-- **A planned change of executor** — a quota running out, a route moving the work to another model or account. `stage_checkpoint.py handoff --to-provider <p> [--to-model <m>] --reason limit|plan_route|operator` prints `observatory_handoff_create`'s arguments; `record --answer -` keeps the offer as one ledger line, and the lease stays with this run until the successor accepts. The successor runs `stage_checkpoint.py accept --handoff-id <id>` → `observatory_handoff_accept` → `record --answer -` **before its first write**, and obeys the constraints the answer carries first. `LeaseLost` is then left for the race nobody planned.
-- **The reminder.** `hooks/memory-nudge.sh` (PostToolUse) reads the ledger after each tool call and, once per `stage:` line with no `event: memory` line after it, puts one sentence in front of the model naming the two commands above. It decides nothing and blocks nothing; adoption measured before it was one write in 293 sessions.
+- **Without the tools.** `stage_checkpoint.py record --unavailable "<why>"` appends one `event: memory — unavailable` line, and the run continues exactly as before. Missing memory is a state the ledger names, not a failure. When the tools are absent for the whole run — no Observatory on this machine — say it **once**: `record --unavailable "<why>" --for-run` appends one `unavailable for this run` line and leaves a marker in `.task-pipeline/memory.json`; no later gate is nudged or needs a line. Any later `record --answer` (the tools came back) clears the marker.
+- **A planned change of executor** — a quota running out, a route moving the work to another model or account. `stage_checkpoint.py handoff --to-provider <p> [--to-model <m>] --reason limit|plan_route|operator` prints `observatory_handoff_create`'s arguments; `record --answer -` keeps the offer as one ledger line, and the lease stays with this run until the successor accepts. The successor runs `stage_checkpoint.py accept --handoff-id <id>` → `observatory_handoff_accept` → `record --answer -` **before its first write**, and obeys the constraints the answer carries first. `LeaseLost` is then left for the race nobody planned. A retried offer keeps its idempotency key until a memory event (a checkpoint, a refusal, a recorded offer — never `unavailable`) is appended, so a `gate:` or `stage:` line between retries does not turn it into a new offer that replaces the unaccepted one.
+- **The reminder.** `hooks/memory-nudge.sh` (PostToolUse) reads the ledger after each tool call and, once per `stage:` line with no `event: memory` line after it, puts one sentence in front of the model naming the two commands above — unless the run-level marker says memory is unavailable for this run, in which case it stays silent. The first reminder of a run also says where Observatory comes from, once. It decides nothing and blocks nothing; adoption measured before it was one write in 293 sessions.
 - **A refusal.** `LeaseLost` means another executor holds the workflow now. The script drops the token. Read the workflow (`observatory_checkpoint_latest` with `stage_checkpoint.py state`'s id) before doing anything else. A stale writer stops after one refusal.
 - **The lease token.** It lives in `.task-pipeline/memory.json` (mode 0600, git-ignored) and never in the ledger, a reply or a commit.
 - **What this is not.** Not a second ledger and not the narrative. The checkpoint is the work's state for the next executor. The wiki and the ledger keep everything else.
@@ -344,7 +411,9 @@ checkpoint**, and the next executor continues from the last finished stage.
 
 | Excuse | Reality |
 |---|---|
-| "The operator obviously wants it to keep going, I'll just loop" | Default off. Silence arms nothing — the same floor deploy authorization uses. Ask once at preflight, or read `run.loop`. |
+| "The operator obviously wants it to keep going, I'll just loop" | Default off. Silence arms nothing — the same floor deploy authorization uses. Arm from `run.loop`, the preflight answer, or a standing instruction the host carries, and cite which in the ledger. |
+| "The watcher can push the release through when CI goes green" | A watcher takes only the act classes a standing instruction names — merge, release a lease, rebase, notify. A tag or a deploy needs its own specific authorization. |
+| "My background loop will catch it tomorrow" | It dies with the session. A wait that can outlive it goes on a durable trigger, and its line goes into the handoff. |
 | "The mode is on, so I can push the deploy through" | The mode collapses check-ins, never gates or outward acts. A generic flag is not a specific authorization. |
 | "I'll tell it to keep going and it will" | On Claude Code, prose does not survive the turn boundary. Either a job is scheduled or the run stops; say which. |
 | "A one-minute interval is closest to no pause" | The interval must be longer than a typical item, or every fire lands on work already in progress and buys nothing. |

package/plugins/task-pipeline/skills/task-pipeline/references/deploy-targets.md

@@ -165,6 +165,16 @@ shipped — and it is exactly what the stage-8 gate is for.
 
 ### When the release waits for an approval
 
+**Establish the authority for the act separately from the approval mode.** Optional
+`release.authorized_by` records a single-line source locator, such as a committed
+`source:line`, for the standing grant covering the tag and publication. A locator
+is not authorization: read its source and verify the issuer's authority, the grant's
+currentness and its exact act and scope. A missing, unreadable or ambiguous source
+cannot establish a grant. If the field is absent, inspect existing recorded authority
+before asking; neither field presence nor `approval: checks` supplies permission.
+Human-only actions remain human, and a release grant does not authorize a separate
+deployment or message it does not name.
+
 **Read the project's approval mode before tagging, and do not guess it.** It is one of
 two, and each owes the operator something different.
 
@@ -172,8 +182,11 @@ two, and each owes the operator something different.
   `release-guard` checks that the tag is on main and that CI on that commit is green,
   and the `release` environment has no reviewers. PassionCode products declare this in
   `passioncode-ai/.github` `release-signing/products.json` (`"approval": "checks"`).
-  Push the tag, watch the run selected **by the tag you pushed**, and report what was
-  published, or the guard's refusal and its cause. A refusal is fixed at its cause,
+  Push the authorized tag and put the run selected **by that tag** on a watcher.
+  Follow [`continuity.md`](continuity.md) → *Waits outlive turns*: take independent work
+  meanwhile, and use a durable trigger if the wait may outlive the session. On success,
+  continue stage 8 on the published artefact and report; on failure, report the cause.
+  A refusal is fixed at its cause,
   never worked around. Send no approval request: there is nobody to send it to.
 - **`reviewers`** — the run stops at an environment with required reviewers. Find that
   run by the tag, and confirm its status is `waiting` before saying anything:
@@ -184,7 +197,11 @@ two, and each owes the operator something different.
 
   Then hand the operator the **direct link** to that run, where they press *Review
   deployments*, together with the tag and the jobs that are waiting. A request without
-  the link is incomplete, and so is a link to a run that is not waiting.
+  the link is incomplete, and so is a link to a run that is not waiting. Put that run
+  on a watcher that continues stage 8 after approval and successful publication. Where
+  standing host instructions name an approval-notification channel, send the same link
+  there with a stable event id per repository/tag/run. An unavailable channel is reported;
+  it is not a reason to invent another recipient or omit the direct link.
 
 The mode comes from, in order:
 1. `pipeline.json` → `release.approval`;
@@ -204,7 +221,7 @@ A run that cannot establish the mode says so. It does not assume `checks`.
 
 ## The verification trio
 
-Whatever the platform, stage 8's gate needs the same three, and all three:
+For a served application, stage 8's gate needs the same three, and all three:
 
 1. **Process/deployment state** — is the new version the running version
 2. **Runtime logs** — clean boot, no error spike
@@ -213,3 +230,12 @@ Whatever the platform, stage 8's gate needs the same three, and all three:
 One or two of the three is where "deployed successfully" gets said about a
 service that is crash-looping. If any of the three cannot be obtained, that is
 the honest degradation report the gate asks for — not a reason to call it green.
+
+**Installed artefacts use their consumer boundary.** For a package, plugin, skill or CLI,
+verify the registry's published version; refresh existing installations within the
+authorized rollout through the owner's update path, then read back their actual versions
+and installed payloads. Read the update/runtime diagnostics and run the supported consumer
+smoke check for each claimed channel. A registry version alone does not prove an installed
+update, and readable files do not prove native discovery or model/task quality. If a channel
+cannot be checked, name it and leave its acceptance open. Do not invent a server health
+URL or clean-boot log for a target that has neither.

package/plugins/task-pipeline/skills/task-pipeline/references/doctrine-map.md

@@ -28,6 +28,7 @@ UX track on a user-facing task.
 | 2 Brainstorm | `references/brainstorm.md` |
 | 2 Decompose (platforms only) | `references/decomposition.md` |
 | 0–10 · **wave mode** — the whole board: 0–4 once, 5–8 per wave, 9–10 to close | `references/waves.md` |
+| 0–10 · **release iteration** — the loop around the waves: dossiers, integration, question rounds, checks as nodes land, release, post-release check, next pool, the shared lesson store | `references/iteration.md` |
 | 3 Spec | `references/spec.md` |
 | 4 Plan | `references/planning.md` |
 | the queue the loop walks | `references/work-graph.md` |

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

@@ -50,12 +50,14 @@ From [`../pipeline.schema.json`](../pipeline.schema.json), one per stage:
 |---|---|---|
 | `auto` | the orchestrator verifies the `check` itself, pass/fail, and stops on fail | advancing on an unverified check |
 | `judgment` | somebody **rules** on it, because no complete deterministic check exists; the gate names its `judge` | recording the ruling in the slot reserved for what a machine established |
-| `manual` | wait for the operator's **explicit** go | treating an auto verification as the approval |
+| `manual` | the operator's **explicit** go, or specific standing authorization naming the act | treating an auto verification as the approval |
 
 **An auto gate never substitutes for a required manual approval.** A green table is
 not the operator confirming it is what they asked for, and no amount of checking
 makes it one. Which stages are manual is the **operator's** decision, recorded in
 their `pipeline.json`; the framework fixes no stage count and no gate assignment.
+A standing authorization is cited with its source and scope, not inferred from a generic
+loop flag ([`continuity.md`](continuity.md) → *The limit, before the capability*).
 
 **That sentence is about the pipeline's SHAPE, and nothing else.** It says a project
 chooses how many stages it runs and which of them wait for a person. It does not say the
@@ -495,8 +497,9 @@ run:
   what it does not cover, stated, beats two measurements and no decision.
 
 **This never licenses skipping a gate.** The gates are the floor, and the floor is
-not proportionate to anything — a `manual` gate waits, `unknown` fails stage 10, and
-a green nobody watched fail is not evidence at any blast radius. What is
+not proportionate to anything — a `manual` gate waits without an explicit go or a
+specific standing authorization naming its act, cited with source and scope;
+`unknown` fails stage 10, and a green nobody watched fail is not evidence at any blast radius. What is
 proportionate is the work *above* the floor: how many axes, how many passes, how
 much of the corpus. Cutting the floor to go faster is not speed; it is the failure
 this whole file exists to prevent, arriving on schedule.

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

@@ -168,7 +168,7 @@ explicit "stop and ask me here":
 | Stage | What to settle up front |
 |---|---|
 | run-wide | the model decision ([`model-tiering.md`](model-tiering.md)); what to decide autonomously vs escalate |
-| run-wide Pacing | the **run mode** ([`continuity.md`](continuity.md)): does the run advance item-by-item with no check-in between items, and on what interval? Read `pipeline.json` → `run.loop` first — a recorded mode is the answer and is not re-asked. **Absent, it is off**: recommend it, take the answer, record it. It never collapses a `manual` gate or an outward act, so this row buys pacing, not authorization |
+| run-wide Pacing | the **run mode** ([`continuity.md`](continuity.md)): does the run advance item-by-item with no check-in between items, and on what interval? Three sources arm it: `pipeline.json` → `run.loop` (read first — a recorded mode is the answer and is not re-asked), this answer, or a standing instruction the host already carries; the ledger cites which as `loop: armed by <source:line>`. **Absent all three, it is off**: recommend it, take the answer, record it. It never collapses a `manual` gate or an outward act, so this row buys pacing, not authorization |
 | 0 Harvest | doc sources beyond this repo — other repos, hosted doc systems, the knowledge wiki, **the code graph** ([`knowledge-graph.md`](knowledge-graph.md): built / installed-not-built / absent) — and whether stage 9 may write to them (another repo is outward: propose + PR, never a direct push) |
 | 0 Duplicates | for every artifact the build reads — a Dockerfile, a schema, a lockfile, a spec — **which copy does the consumer actually name**. Quoted from the workflow or the Makefile, not inferred from the tree: the copy that ships is often not the copy people open (`learned.md` rule 20) | the consumer line, quoted |
 | 0 Fixtures | what **persists between runs** on this machine — a database, a volume, a cache, generated files — and the command that recreates it from nothing. A suite green against accumulated state carries a premise that is false on every runner (`learned.md` rule 18) | the recreate command, stated |

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

@@ -219,7 +219,8 @@ Since v1.50.0 the plugin carries hooks of its own. `hooks/release-gate.sh`
 tag push, `gh release create`, `npm publish` — while the run says the suite has not
 passed. `hooks/gate-observer.sh` (`PostToolUse` and `PostToolUseFailure`) records
 what the declared gate command actually did. `hooks/memory-nudge.sh` (`PostToolUse` on `Bash|Edit|Write|MultiEdit`) reminds,
-once per returned gate, that no workflow-memory line follows it
+once per returned gate, that no workflow-memory line follows it — unless the run recorded
+memory unavailable with `--for-run`
 ([`continuity.md`](continuity.md), Part 3).
 
 **Two lessons from v1.50.0, both shipped as defects and both fixed in v1.51.0.**