@chllming/wave-orchestration 0.9.13 → 0.9.15

package/docs/plans/migration.md

@@ -1,6 +1,6 @@
 # Migration
 
-This page is the practical repo-upgrade guide for the current `0.9.13` surface.
+This page is the practical repo-upgrade guide for the current `0.9.15` surface.
 
 Use it when you are:
 
@@ -13,21 +13,51 @@ For the completed internal architecture cutover record, see [architecture-harden
 For the sandbox-specific long-running execution target, including async `submit/status/wait` semantics and daemon ownership goals, see [sandbox-end-state-architecture.md](./sandbox-end-state-architecture.md).
 
 
-## What `0.9.13` Changes
+## What `0.9.15` Changes
 
-The `0.9.13` surface keeps the existing proof-first runtime and adds three focused operational hardening fixes with no breaking changes.
+The `0.9.15` surface keeps the existing proof-first runtime and adds closure-hardening and operator-surface upgrades with no breaking CLI removals.
 
-- **Proof marker aliasing**: implementation and closure markers now accept `state=complete` as a compatibility alias for `state=met`, which keeps naturally phrased agent output from being rejected by the proof parser.
-- **Restart-safe validation**: launcher pre-validation now treats waves reconstructed as complete from status files the same way it treats run-state-complete waves, so resumed launches stop tripping stale component-promotion checks from older completed waves.
-- **Concurrent credential brokering**: detached process runners now derive a per-agent `LPM_AUTH_STICKY_KEY` and preserve explicit overrides, which prevents same-node agents from contending on one broker export by default.
+- **Normalized structured-signal parsing**: implementation closure now accepts wrapped, fenced, list-prefixed, and JSON-embedded marker output through one canonical parser, while still preserving strict marker requirements.
+- **Deterministic closure adjudication**: transport-only implementation failures can now resolve as `pass`, `rework-required`, or `awaiting-adjudication` instead of automatically becoming generic rerun work.
+- **Operator inspection path**: `wave control adjudication get` exposes the persisted adjudication artifact, including the captured evidence and any synthesized canonical signals.
+- **Canonical signal helpers**: `wave signal ...` prints valid closure markers for wrappers, orchestrators, and agent prompts, which reduces syntax drift in proof-heavy repos.
+- **Separated runtime projections**: `wave control status` and dashboard payloads now expose additive `executionState`, `closureState`, and `controllerState` fields so active execution, blocked closure, and stale controller intent are no longer conflated.
+- **Earlier hardening still included**: `state=complete` still normalizes to `met`, restart-safe validation still honors status-recoverable completed waves before stale promotion checks, and detached runners still derive per-agent broker sticky keys by default.
 
 There are no breaking changes. Existing repos can upgrade in place with `pnpm up @chllming/wave-orchestration` and `pnpm exec wave upgrade`.
 
-For the practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
+For the practical `0.9.15` operating stance after the upgrade, read [../guides/recommendations-0.9.15.md](../guides/recommendations-0.9.15.md).
+
+## What `0.9.14` Was
+
+`0.9.14` exists on npmjs and is the latest published registry version before this local `0.9.15` work, but the published tarball is effectively a carry-forward of the `0.9.13` runtime and docs surface.
+
+Practical meaning:
+
+- if your repo already upgraded to npmjs `0.9.14`, you did not miss a hidden runtime feature wave between `0.9.13` and this local `0.9.15` branch
+- treat `0.9.14` as the public registry bridge version
+- the real next operator-visible change after that bridge release is the `0.9.15` closure-hardening surface described above
+
+## Orchestrator Workflow Changes In `0.9.15`
+
+If you run Wave through a coding agent or resident orchestrator, these are the behavior changes that matter in day-to-day operation:
+
+- **Do not hand-type final markers when you can avoid it.**
+  Prefer `wave signal proof`, `wave signal doc-delta`, `wave signal component`, `wave signal integration`, and `wave signal doc-closure`. They emit canonical marker syntax, support `--append-file`, and keep wrappers aligned with the shipped parser.
+- **Read status as a triplet, not one coarse state.**
+  `executionState` answers whether anything is still live, `closureState` answers whether closure is pending/evaluating/awaiting-adjudication/blocked/passed/failed, and `controllerState` answers whether the controller is active, idle, stale, or only carrying a relaunch plan.
+- **Treat `awaiting-adjudication` as its own operational state.**
+  It means the slice may be closure-complete in substance, but the machine transport of one or more markers was insufficient. It is not the same thing as proof pass, and it is not automatic evidence that the slice needs a rerun.
+- **Inspect adjudication before triggering targeted recovery.**
+  Use `wave control adjudication get --lane <lane> --wave <n> [--agent <id>] --json` first. If the artifact shows a transport-only ambiguity with coherent evidence, prefer a narrow follow-up or marker repair over a broad rerun.
+- **Keep targeted recovery for real regressions.**
+  Semantic proof gaps, missing deliverables, missing proof artifacts, and runtime-state failures still belong in rerun or relaunch workflows. `0.9.15` narrows rerun intent; it does not weaken the proof contract.
+- **Update custom orchestrator prompts and wrappers.**
+  Any repo-owned orchestration prompt that tells agents to hand-compose `[wave-*]` markers should now prefer the `wave signal ...` helpers, and any wrapper that only reads `status` should be updated to consider the additive status triplet when it needs finer control decisions.
 
 ## What `0.9.4` Changes
 
-The current `0.9.13` surface keeps everything from `0.9.2` and adds the earlier gate-value and setup improvements with no breaking changes.
+The current `0.9.15` surface keeps everything from `0.9.2` and adds the earlier gate-value and setup improvements with no breaking changes.
 
 The practical changes are:
 
@@ -43,7 +73,7 @@ There are no breaking changes. Just upgrade with `pnpm up @chllming/wave-orchest
 
 If your repo uses wave-gate markers, you can now use `gap` for dimensions where the gap is documented and not an actionable blocker.
 
-For the practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
+For the practical `0.9.15` operating stance after the upgrade, read [../guides/recommendations-0.9.15.md](../guides/recommendations-0.9.15.md).
 
 ## What `0.9.2` Changes
 
@@ -62,7 +92,7 @@ The practical changes are:
 
 If your repo copied starter docs, shell automation, runbooks, or `wave.config.json` defaults, these are the areas most likely to need a sync before the current package cut.
 
-For a practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
+For a practical `0.9.15` operating stance after the upgrade, read [../guides/recommendations-0.9.15.md](../guides/recommendations-0.9.15.md).
 For the concrete operator setup in Nemoshell, Docker, and other sandboxed shells, also read [../guides/sandboxed-environments.md](../guides/sandboxed-environments.md).
 
 ## What `0.8.6` Changes
@@ -183,10 +213,12 @@ 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.9.13` Release Model
+## `0.9.15` Release Model
 
-The current `0.9.13` surface combines these strands:
+The current `0.9.15` surface combines these strands:
 
+- the closure adjudication, canonical signal-helper, and control-projection split introduced in `0.9.15`
+- the proof-alias, restart-safe completed-wave validation, and detached-runner sticky-key hardening from `0.9.13`
 - the gap-value wave-gate fix and first-time setup UX improvements released in `0.9.4`
 - the detached process-runner and sandbox supervisor hardening released in `0.9.2`
 - the shipped `0.9.0` monorepo project support and project-aware runtime isolation
@@ -197,6 +229,29 @@ The current `0.9.13` surface combines these strands:
 - the Corridor-backed security surface: direct or brokered provider fetches, normalized per-wave artifacts, and closure gating before integration
 - the packaged recommendations guide, sandbox setup guide, and release-surface alignment follow-up that make the current docs describe that combined surface consistently
 
+### Closure adjudication and orchestrator-visible status splitting
+
+This is the main new operational layer in `0.9.15`.
+
+The runtime now:
+
+- classifies implementation failures as transport, semantic, artifact, or state failures without breaking the legacy `statusCode` surface
+- holds eligible transport-only failures in deterministic adjudication instead of forcing a rerun immediately
+- persists adjudication artifacts that operators can inspect with `wave control adjudication get`
+- exposes `executionState`, `closureState`, and `controllerState` so live runtime work is no longer confused with blocked closure or stale control intent
+- gives orchestrators and wrappers a canonical `wave signal ...` helper path for emitting final markers
+
+If your repo copied orchestrator prompts, shell wrappers, or control-surface consumers, this is the main sync set to apply from `0.9.15`:
+
+- `README.md`
+- `docs/README.md`
+- `docs/plans/current-state.md`
+- `docs/plans/migration.md`
+- `docs/guides/recommendations-0.9.15.md`
+- `docs/guides/signal-wrappers.md`
+- `docs/reference/cli-reference.md`
+- `docs/reference/coordination-and-closure.md`
+
 ### Sandbox-safe execution and lower-overhead live runs
 
 This remains the main execution-model shift introduced in `0.9.2`.
@@ -295,7 +350,7 @@ The interactive `wave draft` flow supports `design` as a worker role and scaffol
 
 ## Version-Specific Upgrade Guidance
 
-## Upgrading From `0.8.5` To `0.9.13`
+## Upgrading From `0.8.5` To `0.9.15`
 
 This is the smallest upgrade, but it changes the live wait-loop contract for external automation and intentionally long-running agents.
 
@@ -332,7 +387,7 @@ If the repo copied starter surface, sync:
 - if the repo uses long-running watchers, confirm they can write the ack file where the prompt tells them to
 - reroute one targeted feedback or coordination request and confirm the resident signal version changes even when the signal kind stays the same
 
-## Upgrading From `0.8.4` To `0.9.13`
+## Upgrading From `0.8.4` To `0.9.15`
 
 ### What changed
 
@@ -370,7 +425,7 @@ If your repo copied starter config defaults, also sync the `designRolePromptPath
 - hybrid design stewards rejoin implementation when they explicitly own code
 - long-running prompts receive signal-state and ack paths when the repo uses the new waiting model
 
-## Upgrading From `0.9.9` To `0.9.13`
+## Upgrading From `0.9.9` To `0.9.15`
 
 Run-state history is now capped at 200 entries (20 per wave). Existing bloated run-state files will be automatically pruned on the next write. No config changes needed.
 
@@ -378,9 +433,9 @@ Run-state history is now capped at 200 entries (20 per wave). Existing bloated r
 
 Helper assignment barriers are now advisory in bootstrap gate mode. No config changes needed.
 
-## Upgrading From `0.8.3` To `0.9.13`
+## Upgrading From `0.8.3` To `0.9.15`
 
-Treat this as one move to the current `0.9.13` surface.
+Treat this as one move to the current `0.9.15` surface.
 
 ### What changed across that range
 
@@ -413,7 +468,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.9.13`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.9.15`
 
 This is the main migration path for older adopted repos.
 
@@ -454,7 +509,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.9.13`
+## Upgrading From `0.5.x` Or Earlier To `0.9.15`
 
 Do not treat this as a tiny patch bump.
 
@@ -564,4 +619,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.9.13` 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, adds the recent proof-alias, restart-safe validation, and credential-broker concurrency fixes, and still 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.
+The current `0.9.15` 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, adds the recent proof-alias, restart-safe validation, and credential-broker concurrency fixes, and still 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/reference/cli-reference.md

@@ -168,6 +168,8 @@ wave control status --project <id> --lane <lane> --wave <n> [--agent <id>] [--ru
 
 The JSON payload now includes:
 
+- `executionState`, `closureState`, `controllerState`
+  Additive top-level status triplet that separates live execution, closure health, and controller intent.
 - `signals.wave`
   Versioned wave-level signal state for wrappers and external operators.
 - `signals.agents`
@@ -177,6 +179,8 @@ The JSON payload now includes:
 - `forwardedClosureGaps`
   Earliest-first forwarded `wave-proof-gap` records from the relaunch plan, including the stage key, originating agent, attempt, detail, and downstream closure targets.
 
+Each entry in `logicalAgents[]` also carries additive `executionState` and `closureState` fields. The existing `state` field remains for compatibility.
+
 Starter repos also include `scripts/wave-status.sh` and `scripts/wave-watch.sh` as thin readers over this JSON payload. They use exit `0` for completed, `20` for input-required, `40` for failed, and `30` from `wave-watch.sh --until-change` when the signal changed but the wave stayed active. For the full wrapper contract, read [../guides/signal-wrappers.md](../guides/signal-wrappers.md).
 
 ### wave control telemetry
@@ -188,6 +192,16 @@ wave control telemetry status --project <id> --lane <lane> [--run <id>] [--json]
 wave control telemetry flush  --project <id> --lane <lane> [--run <id>] [--json]
 ```
 
+### wave control adjudication
+
+Read persisted closure adjudication artifacts for transport-only implementation failures that were held out of immediate relaunch.
+
+```
+wave control adjudication get --project <id> --lane <lane> --wave <n> [--agent <id>] [--json]
+```
+
+The JSON payload returns `adjudications[]`, including adjudication `status`, `failureClass`, `reason`, captured evidence, and any synthesized canonical signals.
+
 ### wave control task
 
 Operator task surface for coordination records.
@@ -327,6 +341,25 @@ wave control proof revoke \
   [--operator <name>] [--detail "<text>"] [--json]
 ```
 
+## wave signal
+
+Emit canonical machine-readable closure markers without hand-typing them.
+
+```
+wave signal proof --completion <level> --durability <level> --proof <level> --state <met|complete|gap> [--detail <text>] [--json] [--append-file <path>]
+wave signal doc-delta --state <none|owned|shared-plan> [--path <file> ...] [--detail <text>] [--json] [--append-file <path>]
+wave signal component --id <component> --level <level> --state <met|complete|gap> [--detail <text>] [--json] [--append-file <path>]
+wave signal integration --state <ready-for-doc-closure|needs-more-work> --claims <n> --conflicts <n> --blockers <n> [--detail <text>] [--json] [--append-file <path>]
+wave signal doc-closure --state <closed|no-change|delta> [--path <file> ...] [--detail <text>] [--json] [--append-file <path>]
+```
+
+Notes:
+
+- `complete` is accepted for proof and component state and is normalized to `met`.
+- the command rejects unsafe field content that would break `key=value` parsing and fails if the emitted marker would not round-trip through the shipped parser.
+- `--append-file` appends the canonical emitted marker line to an existing file, which is useful for wrappers and local agent logs.
+- `--json` returns the emitted line plus the append target for wrapper-friendly automation.
+
 ## wave coord
 
 Coordination log access. Legacy surface; prefer `wave control task` for new work.
@@ -629,7 +662,7 @@ Interactive draft currently offers worker role kinds:
 - `research`
 - `security`
 
-Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.9.13` 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.9.15` 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

@@ -66,6 +66,8 @@ The runtime writes several different artifacts, but they do different jobs:
   `.tmp/<lane>-wave-launcher/security/wave-<n>-corridor.json`
 - wave dashboard:
   `.tmp/<lane>-wave-launcher/dashboards/wave-<n>.json`
+- closure adjudication artifacts:
+  `.tmp/<lane>-wave-launcher/closure/wave-<n>/attempt-<a>/<agent>.json`
 - run-state:
   `.tmp/<lane>-wave-launcher/run-state.json`
 
@@ -75,6 +77,17 @@ That control-plane log also carries observed `wave_run`, `attempt`, and `agent_r
 
 Live waves now keep refreshing that derived state while agents are still running. Shared summaries, inboxes, dashboard coordination metrics, and clarification routing are not only recomputed at attempt boundaries; they are also refreshed during active wave execution so stale clarification and acknowledgement timing is machine-visible before the attempt ends.
 
+Wave projections also separate three different operator questions:
+
+- `executionState`
+  Is anything still actively running for this wave or agent?
+- `closureState`
+  Is closure still evaluating, blocked, awaiting adjudication, passed, or failed?
+- `controllerState`
+  Is the controller active, idle, stale, or only carrying a persisted relaunch plan?
+
+That triplet is additive. Legacy top-level `status`, `phase`, and per-agent `state` remain available for compatibility.
+
 ## What Agents Should Use
 
 Use the coordination log for conversational or workflow state:
@@ -142,7 +155,7 @@ Practical rule:
 
 That means a targeted helper request only blocks while it remains open *and* still has blocking severity in coordination state.
 
-For the practical `0.9.13` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
+For the practical `0.9.15` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.9.15.md](../guides/recommendations-0.9.15.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.
 
@@ -160,6 +173,8 @@ For implementation agents with an exit contract, closure validates:
 
 Deliverables and proof artifacts are local ownership proof. They do not replace cross-agent follow-up.
 
+When implementation closure fails only because a transport-level marker is malformed, Wave can now hold that failure in deterministic adjudication instead of immediately turning it into a relaunch. Fully missing required proof markers remain non-passing closure failures. Adjudication is only eligible for transport-only proof failures with exit `0`, landed deliverables, required proof artifacts, a valid result envelope, and no explicit negative semantic gap. The persisted adjudication artifact records the evidence used for that decision so operators can inspect it later through `wave control adjudication get`.
+
 That distinction matters:
 
 - if Agent A1 owns `src/foo.ts` and `docs/reviews/foo.md`, those should be modeled as A1 deliverables

package/docs/reference/npmjs-token-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.9.13` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.9.15` 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.9.13`.
+5. Push the release commit and release tag, for example `v0.9.15`.
 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 `0.9.13` source.
+7. Verify the npmjs publish completes successfully for the tagged `0.9.15` source.

package/docs/reference/package-publishing-flow.md

@@ -15,7 +15,7 @@ Release preparation happens in the repository itself:
 - update release-surface docs and fixtures
 - validate the repo
 - merge the release changes to `main`
-- push a version tag such as `v0.9.13`
+- push a version tag such as `v0.9.15`
 
 Registry publishing happens in GitHub Actions after the tag push:
 
@@ -88,6 +88,8 @@ node scripts/wave.mjs doctor --json
 node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
 ```
 
+`launch --dry-run --no-dashboard` works in a clean checkout even when no `.wave/project-profile.json` exists yet. Live launches still run first-time project setup when a profile is missing.
+
 ### Registry verification commands
 
 After publish:
@@ -127,9 +129,9 @@ This repository normally protects `main`, so release changes should land through
 Typical git flow:
 
 ```bash
-git checkout -b release/0.9.13
-git push -u origin release/0.9.13
-gh pr create --base main --head release/0.9.13
+git checkout -b release/0.9.15
+git push -u origin release/0.9.15
+gh pr create --base main --head release/0.9.15
 gh pr merge <pr-number> --merge --delete-branch
 ```
 
@@ -138,13 +140,13 @@ gh pr merge <pr-number> --merge --delete-branch
 After the release commit is on `main`, push the version tag:
 
 ```bash
-git tag v0.9.13
-git push origin v0.9.13
+git tag v0.9.15
+git push origin v0.9.15
 ```
 
 That tag push is the event that starts both publishing workflows.
 
-The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.13`, the pushed tag must be `v0.9.13`.
+The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.15`, the pushed tag must be `v0.9.15`.
 
 ## GitHub Actions Workflows
 
@@ -212,9 +214,9 @@ Expected result after a successful publish:
 
 ```json
 {
-  "version": "0.9.13",
+  "version": "0.9.15",
   "dist-tags": {
-    "latest": "0.9.13"
+    "latest": "0.9.15"
   }
 }
 ```
@@ -231,8 +233,8 @@ If a tag-triggered publish fails before the package is actually published, the f
 Example:
 
 ```bash
-git tag -f v0.9.13 <fixed-commit>
-git push origin refs/tags/v0.9.13 --force
+git tag -f v0.9.15 <fixed-commit>
+git push origin refs/tags/v0.9.15 --force
 ```
 
 Use that only before the package is live on npmjs. Once npmjs has accepted a version, do not try to republish the same version; cut a new version instead.

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

@@ -191,7 +191,7 @@ 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.9.13.md](../../guides/recommendations-0.9.13.md) for the recommended `0.9.13` operating stance that combines advisory turn budgets with softer non-proof coordination states, targeted recovery, restart-safe validation, and optional TMUX operator surfaces
+- see [../../guides/recommendations-0.9.15.md](../../guides/recommendations-0.9.15.md) for the recommended `0.9.15` operating stance that combines advisory turn budgets with softer non-proof coordination states, targeted recovery, restart-safe validation, and optional TMUX operator surfaces
 
 ## Runtime Pages
 
@@ -203,7 +203,7 @@ Practical guidance:
 
 `wave.config.json` may also declare a `waveControl` block for local-first telemetry delivery.
 
-Packaged defaults in `@chllming/wave-orchestration@0.9.13`:
+Packaged defaults in `@chllming/wave-orchestration@0.9.15`:
 
 - `endpoint`: `https://wave-control.up.railway.app/api/v1`
 - `reportMode`: `metadata-only`

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.9.13 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.9.15 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.9.13` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.9.15` 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.
 
@@ -17,7 +17,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
   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.9.13` 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.9.15` 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.
@@ -46,7 +46,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened through `0.9.13`:
+Together these samples cover the main surfaces added or hardened through `0.9.15`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -184,7 +184,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.9.13` 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.9.15` 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.9.13` 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.9.15` 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

@@ -23,7 +23,7 @@ That packaged endpoint is for the default metadata-reporting surface. The owned-
 
 ### Packaged Default Endpoint
 
-This is the release default in `@chllming/wave-orchestration@0.9.13`.
+This is the release default in `@chllming/wave-orchestration@0.9.15`.
 
 - receives local-first telemetry uploads
 - supports normal run and benchmark query surfaces

package/docs/roadmap.md

@@ -2,9 +2,9 @@
 
 This roadmap is intentionally short and current. The older planner-foundation and ad-hoc-run phase list has been removed because that work no longer describes the actual shipping direction for this package.
 
-## Current Release: 0.9.13
+## Current Release: 0.9.15
 
-`0.9.13` is the current packaged surface.
+`0.9.15` is the current packaged surface.
 
 It includes:
 
@@ -13,6 +13,8 @@ It includes:
 - better behavior in constrained sandboxes such as LEAPclaw, OpenClaw, Nemoshell, and Docker-based operator environments
 - a safer `submit -> supervise -> status/wait -> attach` control path for long-running agentic orchestration
 - tighter supervisor recovery, progress journaling, and closure/retry correctness
+- deterministic adjudication for transport-only implementation closure failures
+- canonical `wave signal ...` helpers plus additive `executionState` / `closureState` / `controllerState` control projections
 - the current protected Wave Control model: Stack-authenticated browser access, Wave-managed approval states and provider grants, PATs, service tokens, encrypted per-user credentials, and runtime env leasing
 - owned Context7 and Corridor broker routes plus the Corridor-backed security context that can gate closure before integration
 
@@ -56,6 +58,6 @@ That line is expected to carry:
 
 For this repository, the practical sequence is:
 
-1. Ship `0.9.13` with the proof-alias, restart-safe validation, detached-runner credential-broker, and release-doc alignment fixes.
+1. Ship `0.9.15` with closure adjudication hardening, canonical signal helpers, richer control-state projections, and aligned release docs.
 2. Maintain this Node package for bug fixes, compatibility, operational hardening, and release-surface sync rather than a broad new feature wave.
 3. Move long-term execution investment to the LEAPclaw + Go + Temporal architecture and the Rust standalone runtime.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chllming/wave-orchestration",
-  "version": "0.9.13",
+  "version": "0.9.15",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {

package/releases/manifest.json

@@ -2,6 +2,41 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.9.15",
+      "date": "2026-04-10",
+      "summary": "Closure adjudication hardening, canonical signal helpers, and clearer execution-versus-closure control projections.",
+      "features": [
+        "Implementation closure now normalizes structured marker extraction behind one parser, preserving compatibility with wrapped, fenced, list-prefixed, and JSON-embedded marker output while surfacing richer diagnostics.",
+        "Transport-only implementation failures can now resolve through deterministic closure adjudication instead of always becoming generic rerun work, with persisted artifacts under `.tmp/<lane>-wave-launcher/closure/wave-<n>/attempt-<a>/<agent>.json`.",
+        "Operators can inspect those artifacts with `wave control adjudication get`, including adjudication `status`, `failureClass`, evidence, and synthesized canonical signals.",
+        "The new `wave signal` helper family emits canonical `proof`, `doc-delta`, `component`, `integration`, and `doc-closure` markers, supports `--append-file`, and keeps wrapper-driven marker output aligned with the shipped parser.",
+        "`wave control status` and dashboard payloads now expose additive `executionState`, `closureState`, and `controllerState` fields, plus per-agent `executionState` and `closureState`, so live runtime work is no longer conflated with blocked closure or stale controller intent.",
+        "The shipped versioned operating guide is now `docs/guides/recommendations-0.9.15.md`, and release docs, migration guidance, runtime-config docs, package-publishing docs, tracked install-state fixtures, and the release manifest now all point at the same `0.9.15` surface.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor --json` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.9.15` release surface.",
+        "If your repo copied starter docs or runbooks, sync `README.md`, `docs/README.md`, `docs/plans/current-state.md`, `docs/plans/migration.md`, `docs/reference/coordination-and-closure.md`, `docs/reference/runtime-config/README.md`, `docs/reference/wave-control.md`, `docs/reference/package-publishing-flow.md`, and `docs/guides/recommendations-0.9.15.md` so local guidance matches the packaged release.",
+        "Update any repo-owned orchestrator prompts, shell wrappers, or custom marker emitters to prefer `wave signal ...` and to treat `awaiting-adjudication` as distinct from both pass and rerun-needed.",
+        "Teach any external operator dashboards or automation that consume `wave control status --json` to read `executionState`, `closureState`, and `controllerState` instead of flattening everything into the legacy top-level `status` field."
+      ],
+      "breaking": false
+    },
+    {
+      "version": "0.9.14",
+      "date": "2026-04-09",
+      "summary": "Registry carry-forward release of the 0.9.13 surface.",
+      "features": [
+        "Published `0.9.14` to npmjs after `0.9.13`, advancing the public package version while keeping the effective runtime and docs surface aligned with the previously shipped `0.9.13` content.",
+        "No intentional runtime-behavior delta beyond the package-version publication itself.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target."
+      ],
+      "manualSteps": [
+        "If you upgraded to the published npmjs `0.9.14`, treat it operationally as the `0.9.13` surface and continue to validate with `pnpm exec wave doctor --json` plus `pnpm exec wave launch --lane main --dry-run --no-dashboard`."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.9.13",
       "date": "2026-04-09",