@chllming/wave-orchestration 0.8.6 → 0.8.7

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## Unreleased
+
+## 0.8.7 - 2026-03-27
+
+### Changed
+
+- Generic `budget.turns` is now treated consistently as advisory metadata unless a runtime-specific ceiling such as `claude.maxTurns` or `opencode.steps` is declared; `budget.minutes` remains the primary attempt budget and the release docs/tests now match that runtime behavior.
+- The blocker-severity model is now consistent across coordination, control status, and reducer-backed closure state, so open work can stay visible as `soft`, `stale`, or `advisory` without automatically reopening hard blocking state.
+- The expanded `wave control task act` repair surface now supports deferral, advisory or stale downgrade, and policy resolution inside canonical control state instead of manual file edits.
+
+### Fixed And Hardened
+
+- Recoverable execution failures such as timeout, max-turn, rate-limit, and missing-status outcomes now prefer targeted rerun or resume paths plus bounded repair work instead of broad wave failure when proof-critical blockers are not present.
+- Autonomous and retry flows now keep moving when only non-blocking human or clarification records remain, while proof-centric owners still default to sticky executor behavior.
+- Capability routing now prefers demonstrated same-wave success for the requested capability before falling back to the least-busy matching capability owner; unrelated completed work no longer counts as routing evidence.
+- Structured marker extraction now also recognizes proof, doc-delta, and component markers embedded inside JSON log lines, so wrapped executor transcripts no longer hide valid closure evidence.
+- Wave agent and resident-orchestrator tmux sessions now reuse stable per-wave session names instead of appending a run tag, which prevents stale launcher exits from accumulating extra tmux sessions for the same wave.
+
+### Testing And Validation
+
+- Added regression coverage around advisory blockers, targeted recovery, autonomous non-blocking human-input handling, advisory turn-budget behavior, capability-specific same-wave routing preference, non-blocking clarification/human-input reducer behavior, and stable per-wave tmux session naming.
+
 ## 0.8.6 - 2026-03-25
 
 ### Added

package/README.md

@@ -103,18 +103,18 @@ Wave is built to mitigate those failures with a canonical authority set, generat
 
 Current release:
 
-- `@chllming/wave-orchestration@0.8.6`
-- Release tag: [`v0.8.6`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.6)
+- `@chllming/wave-orchestration@0.8.7`
+- Release tag: [`v0.8.7`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.7)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.8.6`:
+Highlights in `0.8.7`:
 
 - The shipped starter surface now includes `skills/signal-hygiene/` plus seeded `scripts/wave-status.sh` and `scripts/wave-watch.sh` wrappers for long-running-agent and operator wait loops.
 - Long-running agents and resident orchestrators now get prompt-level signal-state and signal-ack paths, so wakeups are edge-triggered by versioned signal changes instead of relying on terminal injection.
 - Versioned wave or agent signal snapshots are now a first-class operator surface under `.tmp/<lane>-wave-launcher/signals/`, with failure treated as terminal in both the runtime and the wrapper exit contract.
-- `0.8.5` design-role and hybrid design-steward behavior remains part of the shipped release surface, and the current migration guide now covers the new signal-wrapper model on top of that design-first runtime.
-- Release docs, current-state notes, and publishing instructions now point at the `0.8.6` surface.
+- `0.8.5` design-role and hybrid design-steward behavior remains part of the shipped release surface, and `0.8.7` adds capability-specific same-wave helper routing, blocker-severity consistency across reducer state, and stable per-wave tmux session reuse.
+- Release docs, current-state notes, migration guidance, and publishing instructions now point at the `0.8.7` surface.
 
 Requirements:
 

package/docs/README.md

@@ -36,7 +36,7 @@ The useful path is journey-first:
 - Drafting or revising waves:
   Read [guides/author-and-run-waves.md](./guides/author-and-run-waves.md), then use [plans/wave-orchestrator.md](./plans/wave-orchestrator.md) as the operator runbook.
 - Adding an optional pre-implementation design steward:
-  Read [guides/author-and-run-waves.md](./guides/author-and-run-waves.md), then the standing prompt in [agents/wave-design-role.md](./agents/wave-design-role.md). The shipped `0.8.6` surface includes `role-design` plus `tui-design`, with docs-first design stewards by default and explicit hybrid design stewards when a wave also gives that same agent code ownership.
+  Read [guides/author-and-run-waves.md](./guides/author-and-run-waves.md), then the standing prompt in [agents/wave-design-role.md](./agents/wave-design-role.md). The shipped `0.8.7` surface includes `role-design` plus `tui-design`, with docs-first design stewards by default and explicit hybrid design stewards when a wave also gives that same agent code ownership.
 - Want signal-driven automation or long-running watcher loops:
   Read [guides/signal-wrappers.md](./guides/signal-wrappers.md). It covers the seeded `wave-status.sh` and `wave-watch.sh` wrappers, the versioned signal snapshot files, and the ack-loop contract behind `signal-hygiene`.
 - Adding a security review pass:

package/docs/guides/author-and-run-waves.md

@@ -61,7 +61,7 @@ Good fits:
 - multi-owner waves where downstream implementers need the same decisions and assumptions
 - ambiguous tasks where open questions should become explicit before code owners fan out
 
-The starter contract in `0.8.6` is:
+The starter contract in `0.8.7` is:
 
 - import `docs/agents/wave-design-role.md`
 - own one packet such as `docs/plans/waves/design/wave-<n>-<agentId>.md`

package/docs/guides/planner.md

@@ -6,7 +6,7 @@ If you want the full author-to-launch workflow, start with [author-and-run-waves
 
 It reduces repeated setup questions, stores project defaults, and generates wave specs plus markdown that already fit the launcher.
 
-The published `0.8.6` package already includes the optional `design` worker role for pre-implementation design packets. This guide calls out where that affects drafting.
+The published `0.8.7` package already includes the optional `design` worker role for pre-implementation design packets. This guide calls out where that affects drafting.
 
 ## What Ships Today
 

package/docs/guides/terminal-surfaces.md

@@ -47,6 +47,8 @@ By default the launcher can start per-wave dashboard sessions in tmux.
 
 Wave now maintains stable tmux attach targets for both the current-wave dashboard and the global dashboard on the lane socket.
 
+Wave-agent sessions and the resident orchestrator now also use stable per-wave tmux session names. A relaunch reuses the same session identity for that wave instead of creating a new run-tagged session name each time, which reduces stale session buildup after launcher crashes or interrupted retries.
+
 Use:
 
 ```bash

package/docs/plans/current-state.md

@@ -1,6 +1,6 @@
 # Current State
 
-- The published package is `0.8.6`, and that release now includes the optional pre-implementation `design` worker role, the `role-design`, `tui-design`, and `signal-hygiene` starter bundles, plus the seeded signal-wrapper scripts for long-running-agent and operator wait loops.
+- The published package is `0.8.7`, and that release now includes the optional pre-implementation `design` worker role, the `role-design`, `tui-design`, and `signal-hygiene` starter bundles, plus the seeded signal-wrapper scripts for long-running-agent and operator wait loops.
 - The canonical shipped runtime architecture is documented in `docs/plans/end-state-architecture.md`; historical cutover notes remain in `docs/plans/architecture-hardening-migration.md`.
 - The repository contains the published `@chllming/wave-orchestration` package plus the starter scaffold used by `wave init`.
 - The runtime is package-first and non-destructive for adopting repos: `wave init --adopt-existing` records existing repo-owned plans, waves, prompts, and config without overwriting them, and `wave upgrade` writes only `.wave/install-state.json` plus `.wave/upgrade-history/`.

package/docs/plans/end-state-architecture.md

@@ -1,6 +1,6 @@
 # End-State Architecture
 
-This document describes the canonical architecture for the current Wave runtime. It is the authoritative reference for the engine boundaries, canonical authority set, and artifact ownership model that the shipped `0.8.6` surface now follows.
+This document describes the canonical architecture for the current Wave runtime. It is the authoritative reference for the engine boundaries, canonical authority set, and artifact ownership model that the shipped `0.8.7` surface now follows.
 
 The thesis is unchanged: bounded waves, closure roles, proof artifacts, selective rerun, and delivery discipline. What changes is the internal authority model. The launcher stops being the decision engine and becomes a thin orchestrator that reads decisions from canonical state, sequences the engines, and delegates process work to the session supervisor.
 

package/docs/plans/examples/wave-example-design-handoff.md

@@ -1,6 +1,6 @@
 # Wave 12 - Optional Design Steward Handoff
 
-This is a showcase-first sample wave for the shipped `design` worker role in `0.8.6`.
+This is a showcase-first sample wave for the shipped `design` worker role in `0.8.7`.
 
 This example demonstrates the docs-first design-steward path where a design packet is published before code-owning implementation begins.
 

package/docs/plans/examples/wave-example-live-proof.md

@@ -2,7 +2,7 @@
 
 This is a showcase-first sample wave.
 
-Use it as the single reference example for the current `0.8.6` Wave surface.
+Use it as the single reference example for the current `0.8.7` Wave surface.
 
 It intentionally combines more sections than a normal production wave so one file can demonstrate:
 

package/docs/plans/migration.md

@@ -1,6 +1,6 @@
 # Migration
 
-This page is the practical repo-upgrade guide for the current `0.8.6` surface.
+This page is the practical repo-upgrade guide for the current `0.8.7` surface.
 
 Use it when you are:
 
@@ -10,6 +10,19 @@ Use it when you are:
 
 For the completed internal architecture cutover record, see [architecture-hardening-migration.md](./architecture-hardening-migration.md). That document is historical. This one is the operator-facing upgrade checklist.
 
+## What `0.8.7` Changes
+
+The current `0.8.7` surface adds policy consistency and stable per-wave session reuse on top of the `0.8.6` signal-driven operator model.
+
+The practical changes are:
+
+- generic `budget.turns` stays advisory metadata unless the runtime-specific ceiling is set explicitly with `claude.maxTurns` or `opencode.steps`
+- capability-targeted helper routing now treats demonstrated same-wave success as capability-specific evidence; unrelated completed work no longer makes an agent the preferred helper owner
+- advisory or stale clarification and human-input records remain visible in coordination history and reducer blocker views, but they no longer reopen `clarifying` or blocked reducer state by themselves
+- wave-agent and resident-orchestrator tmux sessions now reuse stable per-wave session names, so relaunches and stale launcher exits stop accumulating extra tmux sessions for the same wave
+
+If your repo copied starter docs, shell automation, or operator runbooks, these are the areas most likely to need a sync before the `0.8.7` package cut.
+
 ## What `0.8.6` Changes
 
 `0.8.6` keeps the `0.8.5` design-role surface and adds a new signal-driven operator and long-running-agent model.
@@ -123,12 +136,13 @@ pnpm exec wave coord inbox --lane main --wave 0 --agent A1 --dry-run
 
 Use `pnpm exec wave dashboard --lane <lane> --attach current` or `--attach global` when you need to reattach to a tmux-backed dashboard after the upgrade.
 
-## `0.8.6` Release Model
+## `0.8.7` Release Model
 
-The current `0.8.6` surface is two changes together:
+The current `0.8.7` surface is three changes together:
 
 - the shipped `design` worker role and hybrid design-steward flow introduced in `0.8.5`
 - the signal-driven long-running-agent and wrapper model introduced in `0.8.6`
+- the policy-consistency, targeted-recovery, capability-specific routing, and stable per-wave session reuse hardening introduced in `0.8.7`
 
 ### Signal-driven waiting and wrapper model
 
@@ -312,9 +326,9 @@ If the repo copied starter `wave.config.json` defaults, also sync:
 - if the repo uses hybrid design stewards, confirm the same agent rejoins implementation only when the authored wave explicitly gives it code ownership
 - if the repo uses long-running agents or shell automation, confirm the new wrapper exit contract and ack-loop semantics before relying on an older polling script
 
-## Upgrading From `0.8.0`-`0.8.4` To `0.8.6`
+## Upgrading From `0.8.3` To `0.8.7`
 
-Treat this as one move to the current `0.8.6` surface.
+Treat this as one move to the current `0.8.7` surface.
 
 ### What changed across that range
 
@@ -347,7 +361,7 @@ If your repo copied starter docs or skills, sync:
 - dry-run one design-steward wave if the repo wants the new authored surface
 - if the repo uses long-running watcher agents or shell automation, validate `scripts/wave-status.sh` and `scripts/wave-watch.sh` against a live or staged lane
 
-## Upgrading From `0.6.x` Or `0.7.x` To `0.8.6`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.8.7`
 
 This is the main migration path for older adopted repos.
 
@@ -388,7 +402,7 @@ pnpm exec wave control proof get --lane main --wave 0 --json
 
 If the repo carries proof-first waves, verify that required proof artifacts still exist locally and not only in historical summaries.
 
-## Upgrading From `0.5.x` Or Earlier To `0.8.6`
+## Upgrading From `0.5.x` Or Earlier To `0.8.7`
 
 Do not treat this as a tiny patch bump.
 
@@ -498,4 +512,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.8.6` surface keeps the same authority-set and phase-engine architecture, but it now ships both the design-role starter surface and the signal-driven long-running-agent starter surface as part of the published package. For most repos already on `0.8.x`, the upgrade is package bump plus validation. For older adopted repos, the real work is syncing repo-owned prompts, skills, planner corpus, wrapper scripts, and runbooks so they describe the runtime the package now ships.
+The current `0.8.7` surface keeps the same authority-set and phase-engine architecture, ships both the design-role starter surface and the signal-driven long-running-agent starter surface, and now also hardens policy consistency, targeted recovery, capability-specific routing, and stable per-wave tmux session reuse. For most repos already on `0.8.x`, the upgrade is package bump plus validation. For older adopted repos, the real work is syncing repo-owned prompts, skills, planner corpus, wrapper scripts, and runbooks so they describe the runtime the package now ships.

package/docs/plans/wave-orchestrator.md

@@ -55,6 +55,8 @@ The live runtime is organized around explicit modules:
 - performs a closure sweep so optional `cont-EVAL`, optional security review, integration, documentation, and cont-QA gates reflect final landed state through the wave's effective closure-role bindings
 - treats design packets as a first-class pre-implementation gate when a wave declares `design` workers
 - rebuilds contradiction blockers from canonical control-plane events during replay and materializes human-blocked waves as `clarifying` plus blocked `waveState`
+- distinguishes hard, soft, stale, advisory, proof-critical, and closure-critical blockers instead of treating every open coordination record as equally blocking
+- turns recoverable timeout, max-turn, rate-limit, and missing-status failures into targeted recovery intent plus bounded repair work when proof-critical barriers are not present
 
 ## Main Commands
 
@@ -161,9 +163,10 @@ pnpm exec wave launch --lane main --start-wave 0 --end-wave 0 --executor codex -
 ## Coordination Surfaces
 
 - `wave control status` is the read-only projection for "why blocked / why retrying" at wave or agent scope. It returns blocking edges, logical agent state, tasks, dependencies, rerun intent, active proof bundles, and next timers from one materialized control-plane view.
-- `wave control task create|get|list|act` is the operator task surface for blocking requests, blockers, clarification chains, human-input tickets, escalations, and informative handoffs, evidence, claims, and decisions. `wave control status` only treats requests, blockers, clarifications, human-input, escalations, helper assignments, and required dependencies as blocking edges.
+- `wave control task create|get|list|act` is the operator task surface for blocking requests, blockers, clarification chains, human-input tickets, escalations, and informative handoffs, evidence, claims, and decisions. `wave control status` only treats requests, blockers, clarifications, human-input, escalations, helper assignments, and required dependencies as candidate blocking edges, and then only when their current task or record metadata still marks them blocking.
+- Tasks now carry explicit `blocking` and `blockerSeverity` semantics. Operators can keep work visible while removing it from the active blocking edge with `defer`, `mark-advisory`, `mark-stale`, or `resolve-policy` when repo policy allows.
 - A fresh live `wave launch --start-wave <n> --end-wave <n>` now clears the previous auto-generated relaunch plan for that wave before selecting the initial implementation fan-out. Pass `--resume-control-state` only when you intentionally want to keep that persisted relaunch selection.
-- `wave control rerun request|get|clear` manages targeted rerun intent under `.tmp/<lane>-wave-launcher/control-plane/` and projects compatible retry overrides under `.tmp/<lane>-wave-launcher/control/`, including selected agents, reuse selectors, invalidated components, and clear or preserve reuse lists.
+- `wave control rerun request|get|clear` manages targeted rerun intent under `.tmp/<lane>-wave-launcher/control-plane/` and projects compatible retry overrides under `.tmp/<lane>-wave-launcher/control/`, including selected agents, reuse selectors, invalidated components, and clear or preserve reuse lists. The launcher can also queue one automatically after recoverable timeout, max-turn, rate-limit, or missing-status failures.
 - `wave control proof register|get|supersede|revoke` manages authoritative proof bundles in the same control-plane log and projects compatible proof registries under `.tmp/<lane>-wave-launcher/proof/`.
 - `wave control telemetry status|flush` inspects and delivers the local Wave Control event queue. Pass `--no-telemetry` on `wave launch` to disable event publication for a single run.
 - `scripts/wave-status.sh` and `scripts/wave-watch.sh` are thin wrapper readers over `wave control status --json` for shell automation and long-running watcher loops. Use [guides/signal-wrappers.md](../guides/signal-wrappers.md) for the exit-code and ack-loop contract.
@@ -178,7 +181,7 @@ The canonical conversational state is the JSONL log under `.tmp/<lane>-wave-laun
 
 Control-plane facts that drive reruns, proof, attempt state, contradictions, facts, human-input workflow, and operator tasks are appended separately under `.tmp/<lane>-wave-launcher/control-plane/`. Result envelopes live under `.tmp/<lane>-wave-launcher/results/wave-<n>/attempt-<a>/<agent>.json`. Legacy proof and retry files remain derived projections for compatibility, not decision inputs.
 
-Capability-targeted requests now become deterministic helper assignments. The runtime resolves the assignee from explicit targets, `capabilityRouting.preferredAgents`, then least-busy matching capability owners, writes that assignment into `.tmp/<lane>-wave-launcher/assignments/`, mirrors the decision into coordination state, and keeps the wave blocked until the linked follow-up resolves.
+Capability-targeted requests now become deterministic helper assignments. The runtime resolves the assignee from explicit targets, `capabilityRouting.preferredAgents`, then matching capability owners with demonstrated same-wave completions, then least-busy fallback, writes that assignment into `.tmp/<lane>-wave-launcher/assignments/`, mirrors the decision into coordination state, and keeps the wave blocked until the linked follow-up resolves or is explicitly downgraded by policy.
 
 Clarification flow is orchestrator-first:
 
@@ -188,7 +191,7 @@ Clarification flow is orchestrator-first:
 4. Routed clarification follow-up requests remain blocking until they resolve.
 5. Human escalations are written back into coordination state, the ledger, and trace artifacts.
 
-During live runs, the orchestrator now keeps an active supervision and state-refresh loop while agents are still running. It refreshes the derived coordination surfaces on cadence, surfaces overdue acknowledgements and stale clarification chains in dashboards and traces, and can reroute clarification follow-up requests inside the same attempt when the routed owner never acknowledges them.
+During live runs, the orchestrator now keeps an active supervision and state-refresh loop while agents are still running. It refreshes the derived coordination surfaces on cadence, surfaces overdue acknowledgements and stale clarification chains in dashboards and traces, can reroute clarification follow-up requests inside the same attempt when the routed owner never acknowledges them, and can leave non-critical advisory or stale records visible without forcing the whole wave into terminal failure.
 
 If you opt into `--resident-orchestrator`, the launcher also starts a long-running non-owning orchestrator session for the wave. That session can inspect the same coordination artifacts and intervene through coordination records, but it does not override reducer, gate, or closure decisions.
 
@@ -366,7 +369,7 @@ For the complete syntax of every command, flag, and subcommand, see [docs/refere
 - Skills resolve only after that executor choice is known. Runtime-specific skill overlays are regenerated whenever retry-time fallback changes the selected executor.
 - Runtime mix targets are enforced before launch and again before any retry-time fallback reassignment.
 - Fallbacks are declared in profiles or lane policy, can be applied automatically on retry when the next executor is available and still satisfies mix targets, and are recorded in the ledger, integration summary, and traces when used.
-- Generic `budget.minutes` caps per-agent attempt timeouts. Generic `budget.turns` seeds `claude.maxTurns` and `opencode.steps` when executor-specific values are not set; Codex turn ceilings remain external to Wave and show up in preview metadata as opaque when Wave cannot inspect them, though live previews now record an observed ceiling if the Codex runtime later logs one explicitly.
+- Generic `budget.minutes` caps per-agent attempt timeouts. Generic `budget.turns` remains advisory metadata unless the runtime-specific ceiling is declared explicitly through `claude.maxTurns` or `opencode.steps`; Codex turn ceilings remain external to Wave and show up in preview metadata as opaque when Wave cannot inspect them, though live previews now record an observed ceiling if the Codex runtime later logs one explicitly.
 - The launcher writes runtime overlay files under `.tmp/<lane>-wave-launcher/executors/`; these should stay ignored and local.
 
 Runtime authoring examples:

package/docs/reference/cli-reference.md

@@ -133,13 +133,15 @@ wave control task create \
   --lane <lane> --wave <n> --agent <id> \
   --kind <kind> --summary "<text>" \
   [--detail "<text>"] [--target <agent-or-capability>] \
-  [--priority normal|high] [--depends-on <id>] \
+  [--priority normal|high] [--blocking true|false] \
+  [--severity hard|soft|stale|advisory|proof-critical|closure-critical] \
+  [--depends-on <id>] \
   [--artifact <ref>] [--operator <name>] [--json]
 ```
 
 Valid `--kind` values: `request`, `blocker`, `clarification`, `handoff`, `evidence`, `claim`, `decision`, `human-input`.
 
-Only `request`, `blocker`, `clarification`, `human-input`, and `escalation` are treated as blocking edges by `wave control status`. The rest (`handoff`, `evidence`, `claim`, `decision`) are informational.
+`wave control status` only treats `request`, `blocker`, `clarification`, `human-input`, and `escalation` as potentially blocking. Tasks of those kinds can still be downgraded with `blocking=false` or non-blocking severities such as `advisory` and `stale`, so they remain visible without owning the active blocking edge.
 
 **List tasks:**
 
@@ -172,6 +174,10 @@ Actions:
 | `reassign` | `--to <agent>` | Supersede the original, reroute to a new agent |
 | `answer` | `--response "<text>"` | Answer a human-input or escalation task |
 | `escalate` | `[--detail]` | Escalate to human feedback queue |
+| `defer` | `[--detail]` | Keep the task open but mark it non-blocking soft work |
+| `mark-advisory` | `[--detail]` | Keep the task visible but non-blocking with advisory severity |
+| `mark-stale` | `[--detail]` | Keep the task as historical context without blocking closure |
+| `resolve-policy` | `[--detail]` | Close the task by operator policy and downgrade linked clarification follow-up when applicable |
 
 **Operator answer example** (responding to a human-input escalation):
 
@@ -202,6 +208,8 @@ wave control rerun request \
 
 `--agent` is repeatable or comma-separated. At least one of `--agent` or `--resume-cursor` is required.
 
+The launcher may also write a rerun request automatically after recoverable failures such as timeout, max-turn, rate-limit, or missing-status outcomes. Those requests still appear through `wave control rerun get`, so operators can inspect or replace the targeted recovery plan before the next attempt.
+
 **Get active rerun request:**
 
 ```
@@ -553,7 +561,7 @@ Interactive draft currently offers worker role kinds:
 - `research`
 - `security`
 
-Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.8.6` surface uses `design-pass` as the default executor profile for that role and typically assigns a packet path like `docs/plans/waves/design/wave-<n>-<agentId>.md`. Interactive draft scaffolds the docs-first default; hybrid design stewards are authored by explicitly adding implementation-owned paths and the normal implementation contract sections.
+Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.8.7` surface uses `design-pass` as the default executor profile for that role and typically assigns a packet path like `docs/plans/waves/design/wave-<n>-<agentId>.md`. Interactive draft scaffolds the docs-first default; hybrid design stewards are authored by explicitly adding implementation-owned paths and the normal implementation contract sections.
 
 ## Ad-Hoc Task Commands
 

package/docs/reference/coordination-and-closure.md

@@ -108,14 +108,31 @@ Wave treats these coordination statuses as open:
 - `acknowledged`
 - `in_progress`
 
-It treats these as non-blocking:
+It treats these statuses as closed:
 
 - `resolved`
 - `closed`
 - `superseded`
 - `cancelled`
 
-That means a targeted helper request keeps blocking until the request leaves the open set in coordination state.
+But "open" and "blocking" are now different questions.
+
+Open records can carry a blocker severity:
+
+- `hard`
+- `soft`
+- `stale`
+- `advisory`
+- `proof-critical`
+- `closure-critical`
+
+Practical rule:
+
+- `proof-critical`, `closure-critical`, and hard required barriers still stop the wave outright
+- `soft` blockers stay visible and may still drive repair work or retry targeting
+- `stale` and `advisory` records remain in coordination history without owning the active blocking edge
+
+That means a targeted helper request only blocks while it remains open *and* still has blocking severity in coordination state.
 
 This page is documenting runtime semantics first. The important contract is that closure follows the durable coordination state, not that a particular human or agent used one exact command path to mutate it.
 
@@ -181,7 +198,7 @@ What happens next:
 - that assignment is written into the assignment snapshot
 - the shared summary and A8 inbox now show the open helper work
 
-`wave control task list` and `wave control task get` surface both blocking and informative coordination kinds. `wave control status` only turns `request`, `blocker`, `clarification-request`, `human-feedback`, and `human-escalation` into blocking task edges; plain `handoff`, `evidence`, `claim`, and `decision` records stay visible without falsely blocking the owner. When a launcher attempt is already running, status scopes the top-level blocking edge to that active attempt instead of letting stale relaunch metadata or unrelated closure tasks dominate the wave-level view.
+`wave control task list` and `wave control task get` surface both blocking and informative coordination kinds. `wave control status` only turns `request`, `blocker`, `clarification-request`, `human-feedback`, and `human-escalation` into candidate blocking task edges, and then only if the current record still has `blocking=true` plus a blocking severity. Plain `handoff`, `evidence`, `claim`, and `decision` records stay visible without falsely blocking the owner. When a launcher attempt is already running, status scopes the top-level blocking edge to that active attempt instead of letting stale relaunch metadata or unrelated closure tasks dominate the wave-level view.
 
 ### Step 3: Why A1 Can Be Done But The Wave Is Still Blocked
 
@@ -253,15 +270,19 @@ Important implication:
 
 - even if code is landed, an open clarification chain can still block the wave
 - a routed clarification that stays `open` past the acknowledgement policy can be rerouted during the same live attempt instead of waiting for a full retry cycle
-- operators can now inspect and intervene through one command surface:
+- operators can now inspect and intervene through one command surface, including downgrade or policy-close actions when the remaining issue is no longer proof-critical:
 
 ```bash
 pnpm exec wave control status --lane main --wave 10 --agent A7 --json
 pnpm exec wave control task act reassign --lane main --wave 10 --id clarify-a7-rollout --to A1
+pnpm exec wave control task act mark-stale --lane main --wave 10 --id clarify-a7-rollout
+pnpm exec wave control task act mark-advisory --lane main --wave 10 --id request-clarify-a7-rollout
+pnpm exec wave control task act defer --lane main --wave 10 --id blocker-doc-follow-up
+pnpm exec wave control task act resolve-policy --lane main --wave 10 --id clarify-a7-rollout --detail "Policy already covered in the published rollout guide."
 pnpm exec wave control task act resolve --lane main --wave 10 --id escalation-clarify-a7-rollout --detail "Published command surface covers this question."
 ```
 
-That keeps clarification routing, dismissal, escalation, and human-answer handling inside the canonical coordination state instead of forcing ad hoc file edits.
+That keeps clarification routing, downgrade, dismissal, escalation, policy closure, and human-answer handling inside the canonical coordination state instead of forcing ad hoc file edits.
 
 When the operator answers through the feedback queue directly, the answer path now repairs the same canonical state:
 

package/docs/reference/live-proof-waves.md

@@ -40,6 +40,7 @@ For live-proof owners:
 - declare `### Proof artifacts` for machine-visible local evidence
 - keep the executor sticky unless fallback is explicitly required
 - prefer wall-clock budgets over tiny hard turn caps
+- treat generic `budget.turns` as advisory; only set runtime-specific turn ceilings when you want a true hard stop
 
 Example:
 
@@ -118,6 +119,12 @@ For proof-bearing owners, default to sticky retry:
 
 Only enable cross-executor retry when there is a deliberate reason to do so.
 
+Budget guidance:
+
+- `budget.minutes` is the primary attempt budget and should be the normal control for live-proof owners
+- generic `budget.turns` is now advisory metadata for Claude and OpenCode unless you also set the runtime-specific limit
+- use `claude.max_turns` or `opencode.steps` only when a hard per-attempt ceiling is intentional
+
 If you do allow fallback, declare it explicitly:
 
 ```md
@@ -172,6 +179,8 @@ pnpm exec wave control proof register \
 4. any stale integration or closure owner reruns if needed
 5. already-valid implementation slices stay reused
 
+For non-proof-centric owners elsewhere in the wave, recoverable timeout, max-turn, rate-limit, or missing-status outcomes can now queue targeted recovery automatically. For proof-bearing owners, the safer default is still to keep the same executor sticky and make the operator decision explicit once the new proof bundle exists.
+
 Authoritative proof registration is the supported way to make operator-produced evidence visible to A8, A0, rerun control, and hermetic traces without forcing an implementation agent to rediscover the same local artifacts in a fresh session. The canonical proof bundle now lands in `.tmp/<lane>-wave-launcher/control-plane/` and is projected into `.tmp/<lane>-wave-launcher/proof/` for compatibility.
 
 ## Suggested Eval Targets For Live-Proof Waves

package/docs/reference/npmjs-trusted-publishing.md

@@ -2,7 +2,7 @@
 
 This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
 
-The current `0.8.6` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.8.7` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
 
 ## What This Repo Already Does
 
@@ -48,6 +48,6 @@ If this repo later needs private npm dependencies during CI, consider a separate
 2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
 3. Confirm the package version has been bumped and committed.
 4. Confirm `README.md`, `CHANGELOG.md`, `releases/manifest.json`, and `docs/plans/migration.md` all describe the same release surface.
-5. Push the release commit and release tag, for example `v0.8.6`.
+5. Push the release commit and release tag, for example `v0.8.7`.
 6. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
 7. Verify the npmjs publish completes successfully for the tagged source.

package/docs/reference/runtime-config/README.md

@@ -66,8 +66,14 @@ These fields are shared across runtimes:
 | Model | `model` in profile, `executors.claude.model`, `executors.opencode.model` | `model` | Codex uses shared `model` from profile or agent only |
 | Fallbacks | `fallbacks` in profile | `fallbacks` | Runtime ids used for retry-time reassignment |
 | Tags | `tags` in profile | `tags` | Stored in resolved executor state for policy and traces |
-| Budget turns | `budget.turns` in profile | `budget.turns` | Seeds Claude `maxTurns` and OpenCode `steps` when runtime-specific values are absent; it does not set a Codex turn limit |
-| Budget minutes | `budget.minutes` in profile | `budget.minutes` | Caps attempt timeout |
+| Budget turns | `budget.turns` in profile | `budget.turns` | Advisory generic turn budget. Wave records it in resolved metadata, but only runtime-specific settings such as `claude.maxTurns` or `opencode.steps` emit hard turn-limit flags. It does not set a Codex turn limit. |
+| Budget minutes | `budget.minutes` in profile | `budget.minutes` | Primary wall-clock attempt budget |
+
+Practical guidance:
+
+- prefer `budget.minutes` for normal synthesis, integration, and closure work
+- use generic `budget.turns` as a planning hint, not a hard failure trigger
+- only set `claude.maxTurns` or `opencode.steps` when you deliberately want a hard ceiling for that runtime
 
 ## Runtime Pages
 
@@ -161,7 +167,7 @@ Runtime-specific delivery:
 - OpenCode injects the compact catalog into `opencode.json` and attaches `skill.json`, `SKILL.md`, the selected adapter, and recursive `references/**` files through `--file`.
 - Local keeps skills prompt-only.
 
-`launch-preview.json` also records the resolved skill metadata plus a `limits` section. For Claude and OpenCode, that section reports the known turn ceiling and whether it came from the runtime-specific setting or generic `budget.turns`. For Codex, it explicitly records that Wave emitted no turn-limit flag and that any effective ceiling may come from the selected Codex profile or upstream runtime. If a live Codex run later terminates with a visible `Reached max turns (N)` log line, Wave appends that observed ceiling back into the live `launch-preview.json` as runtime evidence rather than pretending Wave set it.
+`launch-preview.json` also records the resolved skill metadata plus a `limits` section. For Claude and OpenCode, that section reports the runtime-specific turn ceiling when one was actually configured; when only generic `budget.turns` exists, the preview keeps it as advisory metadata and notes that Wave emitted no hard turn-limit flag. For Codex, it explicitly records that Wave emitted no turn-limit flag and that any effective ceiling may come from the selected Codex profile or upstream runtime. If a live Codex run later terminates with a visible `Reached max turns (N)` log line, Wave appends that observed ceiling back into the live `launch-preview.json` as runtime evidence rather than pretending Wave set it.
 
 ## Recommended Validation Path
 

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.8.6 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.8.7 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.8.6` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.8.7` authored Wave surface.
 
 The examples are intentionally denser than typical production waves. Their job is to teach the current authoring and runtime surface quickly, not to be the smallest possible launch-ready files.
 
@@ -15,7 +15,7 @@ The examples are intentionally denser than typical production waves. Their job i
   Shows what a good `repo-landed` outcome looks like when one promoted component only closes honestly if desired-state records, reconcile-loop substrate, and cluster-view surfaces land together. It emphasizes maturity discipline, explicit deliverables, and shared-plan closure without drifting into `pilot-live` claims.
 
 - [Full modern sample wave](../plans/examples/wave-example-live-proof.md)
-  Shows the combined `0.8.6` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
+  Shows the combined `0.8.7` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
 
 - [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md)
   Shows the shipped design-role surface: one pre-implementation design steward publishes a design packet, downstream implementation owners read that packet before coding, and normal closure roles still decide final completion. For terminal or operator-surface work, pair that shape with explicit `tui-design` in the design steward's `### Skills`. For the hybrid variant, explicitly give that same design agent implementation-owned paths and the normal implementation contract sections.
@@ -42,7 +42,7 @@ The examples are intentionally denser than typical production waves. Their job i
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened through `0.8.6`:
+Together these samples cover the main surfaces added or hardened through `0.8.7`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -89,7 +89,7 @@ Adapt more aggressively when:
 ## Suggested Reading Order
 
 1. Start with [High-fidelity repo-landed rollout wave](../plans/examples/wave-example-rollout-fidelity.md) if you want the clearest example of good closure-ready wave fidelity for a repo-only outcome.
-2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.8.6` surface.
+2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.8.7` surface.
 3. Read [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md) if the task needs a design packet before implementation fan-out.
 4. Read [docs/evals/README.md](../evals/README.md) if you want more background on benchmark target selection.
 5. Read [docs/reference/live-proof-waves.md](./live-proof-waves.md) if you want more detail on proof-first `pilot-live` authoring.

package/docs/reference/skills.md

@@ -124,7 +124,7 @@ Top-level and lane-local skill attachment use the same shape:
 
 Lane-local `lanes.<lane>.skills` extends the global config instead of replacing it.
 
-Optional design workers in the shipped `0.8.6` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
+Optional design workers in the shipped `0.8.7` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
 
 Long-running agents that should stay resident and react only to orchestrator signal changes can add `signal-hygiene` explicitly in `### Skills`. That bundle is not auto-attached and is not meant for normal one-shot implementation agents.
 

package/docs/reference/wave-control.md

@@ -42,6 +42,8 @@ This lets the control plane answer:
 - which proof and benchmark artifacts back a claim
 - whether a benchmark result is comparison-valid or only diagnostic
 - which coordination failures blocked closure
+- which blockers were hard, soft, stale, or advisory
+- whether a blocked wave is terminal or recoverable and which targeted rerun request was queued
 
 ## Run Identity
 
@@ -92,6 +94,20 @@ Signals to preserve:
 - benchmark trust:
   every benchmark item should distinguish capability from validity
 
+## Blocker And Recovery Metadata
+
+Wave Control should preserve the softer runtime policy, not flatten it away.
+
+In practice that means `coordination_record`, `task`, `gate`, `wave_run`, and `rerun_request` payloads should keep fields such as:
+
+- `blocking`
+- `blockerSeverity`
+- `recoverable`
+- `recoveryReason`
+- queued rerun request ids or resume targets
+
+That distinction matters because a wave that is `blocked` by a proof-critical gate is different from a wave that is `blocked` only long enough to surface a targeted recovery after timeout, max-turn, rate-limit, or missing-status failure. The control plane should let operators ask which barriers still stop closure outright and which ones were intentionally downgraded to advisory or stale context.
+
 ## Artifact Contract
 
 Selected artifacts are described with typed descriptors:

package/docs/reference/wave-planning-lessons.md

@@ -74,11 +74,15 @@ runtime setup, and the closure artifacts all describe the same truth.
 ## 7. Runtime setup matters as much as wave prose
 
 - Do not use small fixed turn caps for synthesis-heavy or closure-heavy agents.
-  Bound them with `budget.minutes`, not `budget.turns`.
+  Bound them with `budget.minutes`, not generic `budget.turns`.
+- Treat generic `budget.turns` as advisory unless you intentionally set a
+  runtime-specific hard stop such as `claude.max_turns` or `opencode.steps`.
 - Pin exact model and reasoning settings for each runtime. Ambiguous profiles
   create unclear failure modes.
 - Avoid cross-runtime fallback on live-proof or deploy-sensitive slices unless
   there is a very good reason.
+- For non-proof-centric owners, prefer targeted recovery and reuse over broad
+  relaunch when a timeout or max-turn event leaves partial artifacts behind.
 - Context7 should be explicit and real; unresolved bundles create noise instead
   of help.
 
@@ -121,6 +125,8 @@ runtime setup, and the closure artifacts all describe the same truth.
 - Are A8 and A0 told what would make the wave fail honestly?
 - Are runtime pins, Context7 bundles, and budgets specific enough to avoid
   preventable execution failures?
+- Can any non-proof coordination ask be authored as `soft`, `stale`, or
+  `advisory` instead of silently becoming a hard closure blocker?
 - Would a reviewer understand the difference between “code landed” and
   “component promoted” just by reading the wave file?