@chllming/wave-orchestration 0.8.6 → 0.8.8

package/CHANGELOG.md

@@ -1,5 +1,43 @@
 # Changelog
 
+## Unreleased
+
+## 0.8.8 - 2026-03-27
+
+### Changed
+
+- The current release surface now ships the practical operating recommendations guide as `docs/guides/recommendations-0.8.8.md`, and the README, current-state notes, migration guide, coordination docs, and runtime-config docs now all point at the same `0.8.8` package surface.
+- The tracked install-state fixture and upgrade-history records now advance to `0.8.8`, so repo-owned validation no longer lags the published package version after the follow-up docs cut.
+
+### Fixed And Hardened
+
+- Release-surface regression coverage now derives the recommendations-guide path from the current package version instead of a hard-coded `0.8.7` file name, which prevents the same drift on the next release.
+
+### Testing And Validation
+
+- `node scripts/wave.mjs doctor --json`
+- `pnpm test -- test/wave-orchestrator/release-surface.test.ts`
+
+## 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.8`
+- Release tag: [`v0.8.8`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.8)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.8.6`:
+Highlights in `0.8.8`:
 
 - 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 the current release line keeps the `0.8.7` capability-specific same-wave helper routing, blocker-severity consistency, and stable per-wave tmux session reuse hardening.
+- Release docs, current-state notes, migration guidance, publishing instructions, and the packaged operator recommendations guide now point at the `0.8.8` surface.
 
 Requirements:
 

package/docs/README.md

@@ -36,13 +36,15 @@ 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.8` 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:
   Read [plans/wave-orchestrator.md](./plans/wave-orchestrator.md) and the standing reviewer prompt in [agents/wave-security-role.md](./agents/wave-security-role.md).
 - Upgrading an existing repo:
   Read [plans/migration.md](./plans/migration.md), then review the release notes in [../CHANGELOG.md](../CHANGELOG.md) before running `pnpm exec wave upgrade`.
+- Want the practical `0.8.8` operating stance:
+  Read [guides/recommendations-0.8.8.md](./guides/recommendations-0.8.8.md) for the recommended default around relaxed blocker states, advisory turn budgets, and targeted recovery.
 - Want the concrete runtime module map:
   Read [plans/end-state-architecture.md](./plans/end-state-architecture.md) for the engine-by-engine architecture and artifact ownership model.
 - Want the CLI surface map:

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.8` 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.8` 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/recommendations-0.8.8.md

@@ -0,0 +1,133 @@
+---
+title: "0.8.8 Recommendations"
+summary: "How to use 0.8.8's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+---
+
+# 0.8.8 Recommendations
+
+Use this guide when you are adopting `0.8.8` and want one practical operating stance for the softer blocker states, advisory turn-budget behavior, and targeted recovery flow that the current package line ships.
+
+## Recommended Default
+
+For most repos, the safest `0.8.8` default is:
+
+- bound work with `budget.minutes`
+- leave generic `budget.turns` as advisory metadata
+- author non-proof follow-up as `soft`, `stale`, or `advisory` instead of silently treating every open record as a hard blocker
+- use `resolve-policy` when the answer already exists in repo policy or shipped docs
+- prefer targeted rerun or resume after timeout, max-turn, rate-limit, or missing-status outcomes instead of relaunching the whole wave
+
+That recommendation matches the runtime:
+
+- executor launch metadata only emits hard turn-limit flags from `claude.maxTurns` or `opencode.steps`
+- open `stale` and `advisory` coordination records stay visible without reopening the active blocking edge
+- recoverable launcher failures queue targeted retry state instead of immediately escalating to broad terminal wave failure
+
+## 1. Budgets
+
+Treat the two budget knobs differently:
+
+- `budget.minutes` is the primary attempt budget
+- generic `budget.turns` is only a planning hint
+- `claude.maxTurns` or `opencode.steps` are the hard runtime ceilings when you actually want deterministic turn stopping
+
+Recommended pattern for synthesis-heavy implementation or closure work:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "implementation-default": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 35,
+          "turns": 12
+        }
+      }
+    }
+  }
+}
+```
+
+In that pattern, `35` minutes is real policy. `12` turns is only guidance for planning and preview metadata.
+
+Only set a hard runtime ceiling when you deliberately want the runtime itself to stop:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "bounded-closure": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 20
+        },
+        "claude": {
+          "maxTurns": 6
+        }
+      }
+    }
+  }
+}
+```
+
+## 2. Softer Coordination States
+
+`0.8.8` keeps “still visible” separate from “still blocking”.
+
+Use these states intentionally:
+
+| State | Use it for | What the runtime does |
+| --- | --- | --- |
+| `soft` | follow-up that still matters but should not be treated like proof failure | remains visible and may still drive repair or retry targeting |
+| `stale` | outdated clarification or blocker context kept for history | visible in control state, but does not reopen blocking by itself |
+| `advisory` | known issue, note, or human context that should stay visible without blocking closure | visible in control state, but does not own the active blocking edge |
+
+Practical command paths:
+
+```bash
+pnpm exec wave control task act defer --lane main --wave 10 --id blocker-doc-follow-up
+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 resolve-policy --lane main --wave 10 --id clarify-a7-rollout --detail "Policy already covered in the rollout guide."
+```
+
+Use them when the repo already knows the answer, the remaining item is informational, or the follow-up should stay visible for the next wave without holding the current wave hostage.
+
+## 3. What Should Stay Hard
+
+Do not relax everything.
+
+Keep these hard or closure-critical unless you are intentionally changing wave policy:
+
+- missing proof or required deliverables
+- failed integration, documentation, or cont-QA closure gates
+- real human-feedback or escalation requirements that block safe continuation
+- requests or clarifications that still represent unresolved ownership or policy ambiguity for the current wave
+
+If the current wave cannot truthfully close without the answer, keep it blocking.
+
+## 4. Recovery Recommendation
+
+My recommendation after reviewing the current `0.8.8` code path is:
+
+- let timeout, max-turn, rate-limit, and missing-status failures go through the built-in targeted recovery path first
+- inspect the queued rerun or resume request before manually relaunching the whole wave
+- preserve reusable proof from successful sibling owners whenever the reducer already identified it as reusable
+
+That is the shape the launcher now prefers. It only broadens failure when the remaining blockers are still proof-critical or otherwise non-recoverable.
+
+## 5. Suggested Operator Policy
+
+For most repo-owned runbooks:
+
+- teach authors to use `budget.minutes` first
+- teach operators to downgrade only non-proof follow-up
+- treat `resolve-policy` as the preferred path when the answer already exists in docs or repo policy
+- escalate to a full-wave rerun only after targeted recovery proves insufficient
+
+If you want a single sentence policy:
+
+> Keep proof and closure strict, keep generic turns advisory, and keep non-proof context visible without letting it accidentally own wave closure.

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,9 +1,10 @@
 # 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.8`, 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/`.
+- The recommended `0.8.8` operating stance is documented in `docs/guides/recommendations-0.8.8.md`: keep proof and closure strict, keep generic `budget.turns` advisory, and use softer coordination states only for non-proof follow-up.
 - Runtime launch entrypoints now perform a best-effort npmjs version check, cache the result under `.wave/package-update-check.json`, and point operators at `pnpm exec wave self-update` when a newer published package exists.
 - This source repo is itself kept as an adopted Wave workspace, so `node scripts/wave.mjs doctor --json` should pass from the repo root.
 - The default lane is `main`.

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.8` 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.8`.
 
 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.8` 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.8` surface.
 
 Use it when you are:
 
@@ -10,6 +10,21 @@ 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.8` Changes
+
+The current `0.8.8` surface keeps the `0.8.7` policy-consistency and stable per-wave session reuse hardening, and now also packages the operator recommendations guide and install-state alignment follow-up in the release itself.
+
+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.8` package cut.
+
+For a practical `0.8.8` operating stance after the upgrade, read [../guides/recommendations-0.8.8.md](../guides/recommendations-0.8.8.md).
+
 ## 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 +138,14 @@ 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.8` Release Model
 
-The current `0.8.6` surface is two changes together:
+The current `0.8.8` 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`
+- the packaged recommendations guide and install-state alignment follow-up released in `0.8.8`
 
 ### Signal-driven waiting and wrapper model
 
@@ -312,9 +329,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.8`
 
-Treat this as one move to the current `0.8.6` surface.
+Treat this as one move to the current `0.8.8` surface.
 
 ### What changed across that range
 
@@ -347,7 +364,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.8`
 
 This is the main migration path for older adopted repos.
 
@@ -388,7 +405,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.8`
 
 Do not treat this as a tiny patch bump.
 
@@ -498,4 +515,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.8` 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, keeps the `0.8.7` policy and routing hardening, and now also packages the practical operator recommendations guide inside the release line. 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.8` 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,33 @@ 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.
+
+For the practical `0.8.8` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.8.8.md](../guides/recommendations-0.8.8.md).
 
 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 +200,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 +272,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.8` 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.8`.
 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,15 @@ 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
+- see [../../guides/recommendations-0.8.8.md](../../guides/recommendations-0.8.8.md) for the recommended `0.8.8` operating stance that combines advisory turn budgets with softer non-proof coordination states
 
 ## Runtime Pages
 
@@ -161,7 +168,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