task-pipeline-skill 1.93.3 → 1.95.0

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

@@ -21,6 +21,7 @@ queue is — graph or plan — is what decides, not the mood of the closer.
 - The report, and where each field lands
 - The commands
 - The fix cycle, and its ceiling
+- Rounds owed by risk class
 - What this costs, said out loud
 - Rationalizations
 
@@ -83,7 +84,7 @@ tier saw.
 | `visual` | the contact sheet, the director record, the project linter's output, the rubric | a frame that contradicts the record's intent; a gate item failing under a PASS; a hole in the state × axes matrix; a judge verdict from an uncalibrated judge |
 
 **When it runs.** A node that builds a user-facing surface copies the brief's
-`surface_class` ([`stages.md`](stages.md) → stage 0, *The surface class*). On
+`surface_class` ([`stage-00-intake.md`](stage-00-intake.md) → *0 — Intake grill — MANDATORY*, the surface-class bullet). On
 **`flagship` and `product`** the `visual` report is **required** — `graph.py certify`
 refuses the round without it and names the tier. On `internal` and `ad` it is accepted
 when given and counted like any other tier, and not demanded: an internal tool's floor
@@ -217,10 +218,53 @@ has failed **every** round. A run spinning on one level needs the operator to se
 *which* level:
 
 - the same tier every round → the level is being misread, or the node is the wrong
-  shape. Not one fix away. Re-plan the node, do not attempt round four.
+  shape. Not one fix away. Re-plan the node, do not attempt another failing round. (An R3
+  node's owed rounds are not this count — *Rounds owed by risk class*, below.)
 - different tiers each round → churn across levels. Usually one requirement that
   was never decided, surfacing at whichever distance looks at it.
 
+## Rounds owed by risk class
+
+In a release iteration a node carries `risk` (R1–R3, [`work-graph.md`](work-graph.md);
+[`iteration.md`](iteration.md) → *Verification starts when a node lands*), and the class
+decides how many **passing** rounds the node owes before `close` accepts it: **R1 one, R2
+two, R3 three, of which one is adversarial.** A round is the three blind tiers (four on a
+flagship or product surface) plus one fix cycle. `graph.py certify` prints `round N: k of M
+owed passing rounds — not closable yet` until the count is met (`k of M owed passing rounds —
+closable` once it is), and `graph.py close` refuses
+the verdict until then. **Only passing rounds count** — a round passes when every tier
+passes, read from `certification.history` — and, for R3, one of the passing rounds must be
+one recorded with `--kind adversarial`
+(`certification.kinds`, one entry per round). A node with a `risk` and no certification at
+all is refused by `close` too: its class owes at least one round.
+
+**What a round after a clean round reads.** The node's **whole diff at the new HEAD** — not
+the fix diff alone, and not the previous round's reports. A clean round proves the tree it
+read; the next owed round asks the same three distances again of the whole change as it
+stands, so a defect the first reading accepted has a second chance to be seen from a fresh
+context.
+
+**Owed rounds and the ceiling are different counts.** `--ceiling` measures churn: how many
+rounds a node has *failed*, and which tier keeps failing. An R3 node that owes three rounds
+and passes them is not "at round four" of anything; its owed rounds are the plan, and the
+ceiling's warning is about failing rounds beyond what the class owes. Read the ceiling's
+output only when rounds fail.
+
+**The adversarial round** (one of R3's three, on another model where one is available):
+1. **Plant defects in the change** — off-by-one in a limit, an inverted check, a dropped
+   error path — and require the node's own checks to fail on each. A plant that passes is a
+   finding against the check, not against the plant.
+2. **Model the external system's state across runs** — a policy edited between two runs, a
+   key or resource renamed, two writers at once, a provider that echoes a request back or
+   answers twice. The defects of a money or credential path live in the second run, not
+   the first.
+3. **Try the abuse cases** a caller outside the trust boundary would: inputs at and past
+   every bound, replays, a revoked identity, an out-of-order sequence.
+
+It is a different question, not a stricter reading: on 2026-10-12 one iteration's third
+round on a spend-limits node found three breaks of a money invariant that two blind rounds
+had passed. Record it with `certify --kind adversarial`.
+
 ## What this costs, said out loud
 
 Three agents per node instead of one — four on a flagship or product surface. That is

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

@@ -287,7 +287,8 @@ Rules:
   nothing: **one self-observed run by the author, zero blind runs on zero models**, with
   a preflight that reported companion availability in detail and its own confidence not
   at all. A skill silent about its own evidence is read as tested.
-- **Never gate any stage on an install** except the stage-3 UX track on a UI task.
+- **Never gate any stage on an install.** On UI tasks the stage-3 gate requires the
+  valid scenario artifact under the provider rule above, not a package.
 - Optional tools missing → state the fallback, don't block.
 - Re-detect after the operator installs; don't assume.
 - The model answer goes into the brief. Don't ask again per stage
@@ -342,5 +343,5 @@ Both notices live in the repo `LICENSE` → *Third-party*.
 ## Hand-off the other direction
 
 super-ux's `/ux` menu can hand off *to* this pipeline (its "execute autonomously"
-action). When entered that way the UX chain already exists — see `stages.md` → 0
+action). When entered that way the UX chain already exists — see `stage-00-intake.md`
 *Entry-from-super-ux short-circuit*: verify, don't rebuild.

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:
@@ -330,12 +397,14 @@ Project Observatory's memory tools, **every gate that returns also writes a work
 checkpoint**, and the next executor continues from the last finished stage.
 
 - **When.** After the `stage:` line is appended, every time a gate returns, whatever the verdict. A failed gate's checkpoint says `blocked` and keeps the stage open. Acceptance closes the workflow.
-- **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 -`.
+- **How.** `scripts/stage_checkpoint.py emit` prints the tool's arguments, built from the ledger and selected project profile: the topic, observed verdicts, next declared stage, 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 -`.
+- **Profile authority.** `pipeline.json` at the project root owns stage order; only genuinely absent config selects the bundled default. Unreadable/malformed config, ambiguous numeric ledger ids, unsupported mandatory capabilities or a ledger stage outside the selected profile refuse before producing tool arguments. Optional ids use array ordinals, optional names use stable state labels; explicit ids retain declared array order. This reader does not execute gates or replace full preflight/schema validation. A final skipped stage stays open for confirmation, never inventing a successor or closing by inference.
+- **Root and recovery.** The usual ledger stays `.task-pipeline/run.md`; `paths.artifacts` relocates project documents, not this run state. For a relocated ledger use `emit --ledger <path> --project-root <project>` (an enclosing Git root can also establish the project). The first emit saves the selected profile's source/digest and run identity beside the ledger; record retains them. Same-run profile changes, a missing formerly selected config, or a different run reusing that state refuse. Restore the selected source and retry, or reconcile the old workflow and start a distinct ledger/state for the new run; never delete a lease to make the check green. A pre-existing custom workflow with no profile binding also needs reconciliation. Ledger file symlinks and state-file links refuse without migration or overwrite; accepted directory aliases resolve consistently for emit, record, state and handoff. Profile, ledger and existing state inputs must be regular files, so a FIFO is refused before reading. No live checkpoint or read-attestation is proved by a locally emitted payload.
 - **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.
+- **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. It decides nothing and blocks nothing; adoption measured before it was one write in 293 sessions.
+- **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 +413,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

@@ -6,8 +6,9 @@ built-in doctrine lives, so an agent loads the one file the stage needs instead
 carrying the whole index in every turn.
 
 The rule the table serves stays in `SKILL.md`: every stage's doctrine ships inside this
-skill, no stage blocks on an install, and the single deliberate exception is the stage-3
-UX track on a user-facing task.
+skill and no stage blocks on an install. The stage-3 UX gate on a user-facing task
+requires a valid scenario artifact; [the provider rule](companion-skills.md) governs
+the preferred provider, equivalent providers and inline fallback.
 
 ## Contents
 
@@ -15,8 +16,24 @@ UX track on a user-facing task.
 
 ## Which reference owns which stage
 
+For the default profile, `references/stages.md` owns the full gates and exact
+on-entry/resume route to each `references/stage-*.md` detail. Read the selected
+stage detail before its work; this table routes additional subject doctrine.
+Custom profiles use their own declared stages and doctrine, with the kernel intact.
+
 | Stage | Built-in doctrine |
 |---|---|
+| 0 · Stage procedure | `references/stage-00-intake.md` |
+| 1 · Stage procedure | `references/stage-01-docs-study.md` |
+| 2 · Stage procedure | `references/stage-02-brainstorm.md` |
+| 3 · Stage procedure | `references/stage-03-spec.md` |
+| 4 · Stage procedure | `references/stage-04-plan.md` |
+| 5 · Stage procedure | `references/stage-05-dev.md` |
+| 6 · Stage procedure | `references/stage-06-tests.md` |
+| 7 · Stage procedure | `references/stage-07-lint-deploy.md` |
+| 8 · Stage procedure | `references/stage-08-post-deploy.md` |
+| 9 · Stage procedure | `references/stage-09-docs-wiki.md` |
+| 10 · Stage procedure | `references/stage-10-acceptance.md` |
 | 0, 9 · The documentation system | `references/documentation.md` |
 | any stage · The canons, and where each is enforced | [`evidence-docs`](../../evidence-docs/SKILL.md) — the sibling skill in this plugin |
 | 6–10 · Gates | `references/gates.md` |
@@ -28,6 +45,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 |
@@ -179,7 +179,7 @@ explicit "stop and ask me here":
 | 0 Docs regime | where settled things live (the decision home — **one** per project, and an existing `docs/adr/` **is** it), who may write it, whether a lease mechanism is present or the run is `ungated`, the gate command and its ratchet floors, and whether this run may raise a floor ([`documentation.md`](documentation.md)) |
 | 1 Docs | external libs/APIs/SDKs in play; any private ones context7 can't resolve → where their docs live |
 | 2 Decompose | is this a platform (several capabilities/surfaces) or one module? if platform: deploy cadence — per module or once at the end |
-| 2–3 Spec | UI verdict (arms super-ux) **and the surface class** — `flagship`, `product`, `internal` or `ad`, which selects the visual gate profile ([`stages.md`](stages.md) → stage 0, *The surface class*); any scenario-tracing waiver |
+| 2–3 Spec | UI verdict (arms super-ux) **and the surface class** — `flagship`, `product`, `internal` or `ad`, which selects the visual gate profile ([`stage-00-intake.md`](stage-00-intake.md) → *0 — Intake grill — MANDATORY*, the surface-class bullet); any scenario-tracing waiver |
 | 3 Design surface | UI tasks only: **Figma on or text-only** (super-ux's project-level choice, default on — check `docs/ux/foundation.md` → *Design tooling* before asking); is the Figma MCP connected; **and if it isn't — ship text-only, or stop here and connect it?** super-ux degrades to text-only on its own and never blocks, which means an unasked question here silently ships a UI feature with no mockups |
 | 3 Design file | Figma on only: **exactly which files — one per surface (App, Web, ASO) — in which team/org** — the recorded ones, or a URL the operator gives, or *create one in a named team* with that creation explicitly authorized. A destination decided at drawing time is how a project ends up with three "design" files and no way to tell which is real. See *The design destination* below |
 | 4–5 Dev | base branch; worktree/branch policy; is `main` off-limits; commit convention; task tracker |

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