@chllming/wave-orchestration 0.9.1 → 0.9.3

package/CHANGELOG.md

@@ -2,18 +2,69 @@
 
 ## Unreleased
 
+## 0.9.3 - 2026-03-30
+
+### Fixed And Hardened
+
+- WAVE_GATE_REGEX now accepts gap alongside pass|concerns|blocked for all five gate dimensions (architecture, integration, durability, live, docs). Previously, agents that reported a documented gap (e.g. live=gap for an infrastructure topology constraint) had their marker rejected entirely, causing missing-wave-gate failures that prevented wave closure.
+- validateContQaSummary now treats gap dimension values as a conditional pass (ok: true, statusCode: conditional-pass) instead of a hard blocker, with detail text listing which dimensions have documented gaps.
+- The cont-QA coordination prompt now documents gap as a valid dimension value alongside pass|concerns|blocked.
+
+### Added
+
+- First-time wave launch now auto-triggers wave project setup when no project profile exists, matching existing wave draft behavior. (Contributed by @justanothernate in #54)
+- wave project setup now shows descriptive help text before each prompt, explains all template and posture options inline, and adds whitespace between question groups for readability. (Contributed by @justanothernate in #54)
+- PromptSession gains a describe(text) method for writing contextual help to stderr during interactive setup flows.
+- parseArgs now passes the loaded config object through to runLauncherCli, avoiding a redundant loadWaveConfig() call.
+
+### Testing And Validation
+
+- `pnpm exec vitest run --config vitest.config.ts`
+- `node scripts/wave.mjs doctor --json`
+- `node scripts/wave.mjs launch --lane main --dry-run --no-dashboard`
+- `pnpm test -- test/wave-orchestrator/release-surface.test.ts`
+
+## 0.9.2 - 2026-03-29
+
+### Added
+
+- A dedicated Corridor reference at `docs/reference/corridor.md` covering `direct`, `broker`, and `hybrid` provider modes, implementation-owned path matching, generated `wave-<n>-corridor.json` artifacts, and the way Corridor can fail closure before integration.
+- Full shipped-surface documentation for owned `wave-control` deployments, including Stack-backed browser access, Wave-managed approval states and provider grants, PATs, service tokens, encrypted per-user credential storage, runtime credential leasing, and the separate `services/wave-control-web` frontend.
+- Starter-surface coverage for the renamed operating guide `docs/guides/recommendations-0.9.2.md`, including install seeding and regression coverage so fresh adopted workspaces receive the current recommendations guide path.
+
+### Changed
+
+- Promoted the current packaged surface to `0.9.2` so the documented Corridor, Wave Control auth and security model, release manifest, tracked install-state fixtures, and package publishing docs can be tagged and published cleanly without reusing the existing `0.9.1` npm release and git tag.
+- README, migration guidance, current-state notes, runtime-config docs, coordination docs, roadmap notes, package publishing docs, Wave Control docs, the new Corridor reference, and the tracked install-state fixtures now all point at the `0.9.2` surface and describe the same shipped security and control-plane model consistently.
+- `services/wave-control/README.md` and `docs/reference/wave-control.md` now document the current control-plane contract and the updated `wave-control-web` frontend surface instead of the older narrower auth description.
+
+### Fixed And Hardened
+
+- `scripts/wave-orchestrator/install.mjs` now seeds the current linked reference set, including `docs/reference/corridor.md`, `docs/reference/wave-control.md`, and `docs/reference/coordination-and-closure.md`, so fresh `wave init` workspaces do not miss the new release docs.
+- Release-surface fixtures now advance together to `0.9.2`, including `releases/manifest.json`, `.wave/install-state.json`, and the tracked `.wave/upgrade-history/` report for `0.9.1 -> 0.9.2`, which keeps repo-owned validation aligned with the packaged version.
+- The versioned recommendations guide rename now propagates through install coverage, package publishing docs, and release regression checks so future package cuts do not drift from the shipped file name.
+
+### Testing And Validation
+
+- `pnpm exec vitest run --config vitest.config.ts test/wave-orchestrator/install.test.ts`
+- `pnpm exec vitest run --config vitest.config.ts test/wave-orchestrator/release-surface.test.ts`
+- `node scripts/wave.mjs doctor --json`
+- `node scripts/wave.mjs launch --lane main --dry-run --no-dashboard`
+- `pnpm test -- test/wave-orchestrator/release-surface.test.ts`
+
 ## 0.9.1 - 2026-03-29
 
 ### Added
 
 - A dedicated sandbox setup guide at `docs/guides/sandboxed-environments.md` covering LEAPclaw/OpenClaw-style short-lived exec sandboxes, Nemoshell, and Docker or containerized operator setups.
 - Starter-surface and install coverage for the renamed recommendations guide `docs/guides/recommendations-0.9.1.md`, plus seeded docs that now point fresh workspaces at the sandbox-safe submit or supervise path.
+- A dedicated Corridor reference at `docs/reference/corridor.md` covering direct, brokered, and hybrid provider modes, owned-path matching, generated security artifacts, and closure-stage blocking behavior.
 
 ### Changed
 
 - Live agent execution now defaults to detached process runners instead of per-agent tmux execution sessions. Tmux remains an optional dashboard and operator projection surface only, which reduces session churn and lowers memory pressure during wider fan-outs.
 - The sandbox-facing runtime path is now `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach`, with read-side reconciliation and log-follow attach behavior designed for short-lived clients and long-running daemon ownership.
-- README, migration guidance, current-state notes, coordination docs, runtime-config docs, package publishing docs, install fixtures, and the versioned recommendations guide now all point at the `0.9.1` surface.
+- README, migration guidance, current-state notes, runtime-config docs, coordination docs, Wave Control docs, the new Corridor reference, package publishing docs, roadmap notes, install fixtures, and the versioned recommendations guide now all point at the `0.9.1` surface and describe the current authenticated Wave Control plus security surface consistently.
 
 ### Fixed And Hardened
 

package/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 chllming
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -107,17 +107,18 @@ Wave is built to mitigate those failures with a canonical authority set, generat
 
 Current release:
 
-- `@chllming/wave-orchestration@0.9.1`
-- Release tag: [`v0.9.1`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.9.1)
+- `@chllming/wave-orchestration@0.9.3`
+- Release tag: [`v0.9.3`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.9.3)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.9.1`:
+Highlights in `0.9.3`:
 
-- Live agent execution now uses detached process runners by default, which reduces tmux churn and memory pressure during wider orchestration bursts. Tmux is now optional and dashboard-only.
-- The sandbox-safe runtime path is now `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach`, which behaves better under short-lived exec clients such as LEAPclaw, OpenClaw, and Nemoshell.
-- Supervisor recovery, launcher progress journaling, and exact-context reads are now hardier for multi-wave runs, reruns, and daemon/client loss in containerized or sandboxed environments.
-- Release docs, migration guidance, sandbox setup guides, the versioned recommendations guide, the manifest, and the tracked install-state fixtures now all point at the `0.9.1` surface.
+- Wave-gate markers now accept `gap` alongside `pass`, `concerns`, and `blocked` for all five gate dimensions. Agents that report a documented gap (e.g. `live=gap` for an infrastructure topology constraint) no longer have their marker rejected entirely, and `cont-QA` treats gap values as a conditional pass instead of a hard blocker.
+- First-time `wave launch` now auto-triggers `wave project setup` when no project profile exists, matching existing `wave draft` behavior. The interactive setup flow now shows descriptive help text, explains all template and posture options inline, and adds whitespace between question groups for readability.
+- `PromptSession` gains a `describe(text)` method for writing contextual help to stderr during interactive setup flows.
+- `parseArgs` now passes the loaded config object through to `runLauncherCli`, avoiding a redundant `loadWaveConfig()` call.
+- Release docs, migration guidance, runtime-config and closure references, the manifest, and the tracked install-state fixtures now all point at the `0.9.3` surface.
 
 Requirements:
 
@@ -126,7 +127,8 @@ Requirements:
 - optional: `tmux` on `PATH` for dashboarded runs
 - at least one executor on `PATH`: `codex`, `claude`, or `opencode`
 - optional: `CONTEXT7_API_KEY` for launcher-side prefetch
-- optional: `WAVE_CONTROL_AUTH_TOKEN` for remote Wave Control reporting
+- optional: `WAVE_API_TOKEN` for owned Wave Control reporting, brokered provider access, and runtime credential leasing
+- compatibility fallback: `WAVE_CONTROL_AUTH_TOKEN`
 
 Telemetry defaults:
 
@@ -135,6 +137,13 @@ Telemetry defaults:
 - default identity fields include `projectId`, `lane`, `wave`, `runKind`, and related benchmark ids
 - opt out explicitly with `waveControl.enabled: false`, `waveControl.reportMode: "disabled"`, or `wave launch --no-telemetry`
 
+Owned Wave Control and security features:
+
+- the packaged default endpoint is metadata-first and intentionally rejects provider-broker and credential-leasing routes
+- owned deployments can add the authenticated `wave-control` app surface: Stack-backed browser sign-in, Wave-managed approval states, provider grants, PATs, service tokens, and encrypted per-user credential leasing
+- `externalProviders.corridor` can run in `direct`, `broker`, or `hybrid` mode, writes `.tmp/<lane>-wave-launcher/security/wave-<n>-corridor.json`, and can fail closure on fetch errors or matched blocking findings when `requiredAtClosure` stays enabled
+- see [docs/reference/wave-control.md](./docs/reference/wave-control.md), [docs/reference/corridor.md](./docs/reference/corridor.md), and [docs/reference/coordination-and-closure.md](./docs/reference/coordination-and-closure.md)
+
 ## Recommended Setup
 
 The easiest way to set up Wave in any repo is:
@@ -202,6 +211,7 @@ Useful docs:
 - `docs/guides/monorepo-projects.md`
 - `docs/guides/planner.md`
 - `docs/reference/runtime-config/README.md`
+- `docs/reference/corridor.md`
 - `docs/reference/wave-control.md`
 ```
 
@@ -355,7 +365,8 @@ codex mcp list
 - [docs/plans/architecture-hardening-migration.md](./docs/plans/architecture-hardening-migration.md): historical record of the completed architecture hardening stages
 - [docs/plans/context7-wave-orchestrator.md](./docs/plans/context7-wave-orchestrator.md): Context7 setup and bundle authoring
 - [docs/reference/runtime-config/README.md](./docs/reference/runtime-config/README.md): executor, runtime, and skill-projection configuration
-- [docs/reference/wave-control.md](./docs/reference/wave-control.md): local-first telemetry contract and Railway control-plane model
+- [docs/reference/corridor.md](./docs/reference/corridor.md): direct, brokered, and hybrid Corridor security context plus closure semantics
+- [docs/reference/wave-control.md](./docs/reference/wave-control.md): local-first telemetry contract, owned deployment model, auth surfaces, and credential/broker routes
 - [docs/reference/package-publishing-flow.md](./docs/reference/package-publishing-flow.md): end-to-end package publishing flow, workflows, and lifecycle scripts
 - [docs/reference/proof-metrics.md](./docs/reference/proof-metrics.md): README failure cases mapped to concrete telemetry and benchmark evidence
 - [docs/reference/skills.md](./docs/reference/skills.md): skill bundle format, resolution order, and runtime projection

package/docs/README.md

@@ -38,19 +38,23 @@ The useful path is journey-first:
 - Setting up multiple projects in one monorepo:
   Read [guides/monorepo-projects.md](./guides/monorepo-projects.md) for `defaultProject`, `projects.<projectId>`, project-scoped state paths, and telemetry defaults.
 - 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.9.1` 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.9.3` 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.
 - Running in LEAPclaw, OpenClaw, Nemoshell, Docker, or another short-lived sandbox:
   Read [guides/sandboxed-environments.md](./guides/sandboxed-environments.md) first for the submit or supervise pattern, persistent-state expectations, and dashboard guidance, then use [plans/sandbox-end-state-architecture.md](./plans/sandbox-end-state-architecture.md) for the deeper runtime design.
 - 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).
+  Read [plans/wave-orchestrator.md](./plans/wave-orchestrator.md), the standing reviewer prompt in [agents/wave-security-role.md](./agents/wave-security-role.md), and [reference/corridor.md](./reference/corridor.md) if the lane also wants provider-backed security context.
+- Running or self-hosting the control plane:
+  Read [reference/wave-control.md](./reference/wave-control.md) for the local-first telemetry contract plus the owned-deployment auth, broker, PAT, service-token, and credential-leasing model.
+- Using Corridor-backed security context:
+  Read [reference/corridor.md](./reference/corridor.md) for the direct, broker, and hybrid modes, then [reference/coordination-and-closure.md](./reference/coordination-and-closure.md) for how Corridor interacts with human security review and closure ordering.
 - 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`.
 - Publishing the package:
   Read [reference/package-publishing-flow.md](./reference/package-publishing-flow.md) for the end-to-end release path, the GitHub publish workflows, the lifecycle scripts, and the verification or repair flow.
-- Want the practical `0.9.1` operating stance:
-  Read [guides/recommendations-0.9.1.md](./guides/recommendations-0.9.1.md) for the recommended default around relaxed blocker states, advisory turn budgets, and targeted recovery.
+- Want the practical `0.9.3` operating stance:
+  Read [guides/recommendations-0.9.3.md](./guides/recommendations-0.9.3.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/agents/wave-security-role.md

@@ -16,6 +16,7 @@ Your job is to review the landed change set before integration closure, identify
 
 Operating rules:
 - Re-read the compiled shared summary, your inbox, the generated wave board projection, and the owned reports before major decisions.
+- If a Corridor artifact path is present in your prompt, read it before final disposition and reconcile its matched findings with your report. Do not ignore a blocking Corridor result without explaining why it is not relevant to the implementation-owned paths for this wave.
 - Do a threat-model pass before finalizing conclusions. Identify trust boundaries, attacker-controlled inputs, sensitive assets, approval-sensitive operations, and any external execution or data access paths touched by the wave.
 - Prefer exact findings and exact requested fixes over vague warnings.
 - Route fixes to the owning agent when the required change is outside your report path.

package/docs/architecture/README.md

@@ -1357,7 +1357,7 @@ The `wave-control-schema.mjs` module normalizes these entity types:
     "enabled": true,
     "endpoint": "https://wave-control.up.railway.app/api/v1",
     "reportMode": "metadata-only",
-    "authTokenEnv": "WAVE_CONTROL_AUTH_TOKEN"
+    "authTokenEnvVar": "WAVE_API_TOKEN"
   }
 }
 ```

package/docs/concepts/operating-modes.md

@@ -88,4 +88,4 @@ The current roadmap is a release-direction document, not a backlog of planner ph
 - typed values in planner output
 - better environment modeling
 
-The stricter execution semantics are still future work, not a hidden already-finished feature in `0.9.1`.
+The stricter execution semantics are still future work, not a hidden already-finished feature in `0.9.2`.

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

@@ -74,7 +74,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.9.1` is:
+The starter contract in `0.9.2` 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.9.1` package already includes the optional `design` worker role for pre-implementation design packets. This guide calls out where that affects drafting.
+The published `0.9.2` package already includes the optional `design` worker role for pre-implementation design packets. This guide calls out where that affects drafting.
 
 ## What Ships Today
 
@@ -48,7 +48,7 @@ pnpm exec wave launch --lane main --dry-run --no-dashboard
 - forward replanning of later waves
 - separate runtime enforcement for oversight vs dark-factory
 
-Those remain future work outside the current `0.9.1` release line. The planner foundation is about better structured authoring, not a second execution engine.
+Those remain future work outside the current `0.9.2` release line. The planner foundation is about better structured authoring, not a second execution engine.
 
 ## Project Profile
 

package/docs/guides/{recommendations-0.9.1.md → recommendations-0.9.2.md}

@@ -1,15 +1,15 @@
 ---
-title: "0.9.1 Recommendations"
-summary: "How to use 0.9.1's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+title: "0.9.2 Recommendations"
+summary: "How to use 0.9.2's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
 ---
 
-# 0.9.1 Recommendations
+# 0.9.2 Recommendations
 
-Use this guide when you are adopting `0.9.1` 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.
+Use this guide when you are adopting `0.9.2` 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.9.1` default is:
+For most repos, the safest `0.9.2` default is:
 
 - bound work with `budget.minutes`
 - leave generic `budget.turns` as advisory metadata
@@ -76,7 +76,7 @@ Only set a hard runtime ceiling when you deliberately want the runtime itself to
 
 ## 2. Softer Coordination States
 
-`0.9.1` keeps “still visible” separate from “still blocking”.
+`0.9.2` keeps “still visible” separate from “still blocking”.
 
 Use these states intentionally:
 
@@ -112,7 +112,7 @@ If the current wave cannot truthfully close without the answer, keep it blocking
 
 ## 4. Recovery Recommendation
 
-My recommendation after reviewing the current `0.9.1` code path is:
+My recommendation after reviewing the current `0.9.2` 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

package/docs/guides/recommendations-0.9.3.md

@@ -0,0 +1,137 @@
+---
+title: "0.9.3 Recommendations"
+summary: "How to use 0.9.3's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+---
+
+# 0.9.3 Recommendations
+
+Use this guide when you are adopting `0.9.3` 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.9.3` 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
+- in short-lived sandboxes, prefer `wave submit`, `wave supervise`, `wave status`, and `wave wait` instead of binding the full run to one client shell
+- when a wave-gate dimension has a documented gap that is not an actionable blocker, use `gap` instead of `pass` or `blocked` — the runtime treats it as a conditional pass
+
+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.9.2` 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
+
+Use `gap` in wave-gate markers when a dimension has a documented gap that is not actionable in the current wave. For example, `live=gap` is appropriate when an infrastructure topology constraint prevents full live validation but the constraint is known, documented, and does not represent a regression. Do not use `gap` to hide actual failures or unreviewed work.
+
+If the current wave cannot truthfully close without the answer, keep it blocking.
+
+## 4. Recovery Recommendation
+
+My recommendation after reviewing the current `0.9.3` 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/sandboxed-environments.md

@@ -8,7 +8,7 @@ Typical examples:
 - Nemoshell or similar hosted terminal sandboxes
 - Docker or devcontainer setups where the client process is disposable but the workspace and state volume persist
 
-The core rule in `0.9.1` is simple:
+The core rule in `0.9.3` is simple:
 
 - clients should be short-lived
 - supervision should be long-lived
@@ -94,7 +94,7 @@ If the sandbox only gives you short exec windows, `wave autonomous` should not b
 
 ## Docker And Containerized Setups
 
-Docker works well with the `0.9.1` process-backed runner model, but only if the state directories survive container restarts.
+Docker works well with the `0.9.3` process-backed runner model, but only if the state directories survive container restarts.
 
 Recommended container posture:
 

package/docs/plans/current-state.md

@@ -1,12 +1,15 @@
 # Current State
 
-- The published package is `0.9.1`; that release keeps the shipped monorepo, design-role, and signal-hygiene surfaces, but now also moves live agent execution to detached process runners, reduces tmux and memory pressure during wide orchestration bursts, and hardens the sandbox-safe supervisor path for LEAPclaw, OpenClaw, Nemoshell, Docker, and similar short-lived exec environments.
+- The published package is `0.9.3`; that release keeps the shipped monorepo, design-role, signal-hygiene, detached process-runner, and sandbox supervisor surfaces, and now also accepts `gap` as a valid wave-gate dimension value (alongside `pass`, `concerns`, and `blocked`) so that agents reporting a documented gap no longer trigger missing-wave-gate failures. First-time `wave launch` now auto-triggers `wave project setup` when no project profile exists, and the interactive setup flow shows descriptive help text and inline option explanations. The current authenticated Wave Control plus Corridor-backed security surface continues to ship in this repo.
 - The canonical shipped runtime architecture is documented in `docs/plans/end-state-architecture.md`; the sandbox-runtime companion is `docs/plans/sandbox-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.9.1` operating stance is documented in `docs/guides/recommendations-0.9.1.md`: keep proof and closure strict, keep generic `budget.turns` advisory, and use softer coordination states only for non-proof follow-up.
+- The recommended `0.9.3` operating stance is documented in `docs/guides/recommendations-0.9.3.md`: keep proof and closure strict, keep generic `budget.turns` advisory, and use softer coordination states only for non-proof follow-up.
 - Sandbox-safe setup guidance now ships in `docs/guides/sandboxed-environments.md`: use `wave submit/supervise/status/wait/attach` for short-lived clients, keep `tmux` optional and dashboard-only, and preserve `.tmp/` plus `.wave/` when running inside Nemoshell or Docker.
 - 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.
+- The companion control plane now ships in two packages:
+  - `services/wave-control/` is the backend for typed telemetry, Stack-authenticated app users, Wave-managed approval states and provider grants, PATs, dedicated service tokens, encrypted per-user credential storage, runtime env leasing, and owned broker routes for Context7 or Corridor
+  - `services/wave-control-web/` is the Vite/Lit browser frontend that signs in through Stack, persists the browser session, exposes overview/runs/benchmarks/tokens, and adds superuser-only user, provider-grant, and write-only credential management
 - 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`.
 - Planner foundation is now shipped:
@@ -55,6 +58,9 @@
   - authoritative proof registries projected to `.tmp/<lane>-wave-launcher/proof/` for compatibility, while preserving proof bundle lifecycle state so revoked or superseded operator evidence cannot keep satisfying closure
   - optional Wave Control telemetry under `.tmp/<lane>-wave-launcher/control-plane/telemetry/` for the implicit default project, or `.tmp/projects/<projectId>/<lane>-wave-launcher/control-plane/telemetry/` for explicit projects
   - packaged telemetry defaults now point at `https://wave-control.up.railway.app/api/v1` with `reportMode: metadata-only`, and repos must opt out explicitly if they do not want default project/lane/wave metadata delivery
+  - an optional `externalProviders.corridor` surface with `direct`, `broker`, and `hybrid` modes that writes `.tmp/<lane>-wave-launcher/security/wave-<n>-corridor.json` for the implicit default project, or `.tmp/projects/<projectId>/<lane>-wave-launcher/security/wave-<n>-corridor.json` for explicit projects
+  - closure-stage Corridor gating that can fail as `corridor-fetch-failed` or `corridor-blocked` before integration when the provider fetch fails or matched implementation-owned findings meet the configured threshold
+  - security and integration summaries that keep matched Corridor findings visible alongside the human security review instead of replacing the reviewer with provider output
   - reducer-driven live state snapshots plus persisted machine-readable shadow diffs for helper-assignment, blocker, contradiction, closure, and retry slices
   - reducer-authoritative helper-assignment blocking, retry target selection, and resume planning, with live gate and closure reads now driven from validated result envelopes
   - optional design agents that publish validated design packets under `docs/plans/waves/design/wave-<n>-<agent>.md`, gate implementation through `designGate`, and run before code-owning implementation agents

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.9.1` 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.9.2` surface now follows.
 
 For the sandbox-specific execution model, including async supervisor ownership, daemon adoption goals, and forwarded closure-gap behavior, read [sandbox-end-state-architecture.md](./sandbox-end-state-architecture.md).
 

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.9.1`.
+This is a showcase-first sample wave for the shipped `design` worker role in `0.9.2`.
 
 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.9.1` Wave surface.
+Use it as the single reference example for the current `0.9.2` Wave surface.
 
 It intentionally combines more sections than a normal production wave so one file can demonstrate: