@chllming/wave-orchestration 0.9.1 → 0.9.2

package/CHANGELOG.md

@@ -2,18 +2,47 @@
 
 ## Unreleased
 
+## 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,19 @@ 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.2`
+- Release tag: [`v0.9.2`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.9.2)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.9.1`:
+Highlights in `0.9.2`:
 
 - 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.
+- Owned Wave Control deployments now support Stack-authenticated browser access, Wave-managed approval states and provider grants, personal access tokens, dedicated service tokens, encrypted per-user credential leasing, and the separate `services/wave-control-web` operator frontend.
+- Corridor is now documented as a first-class security input: it can run direct or through an owned Wave Control broker, materialize per-wave security context on implementation-owned paths, and block closure before integration when fetches fail or matched findings cross the configured threshold.
+- Release docs, migration guidance, runtime-config and closure references, Wave Control docs, the new Corridor reference, the manifest, and the tracked install-state fixtures now all point at the `0.9.2` surface.
 
 Requirements:
 
@@ -126,7 +128,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 +138,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 +212,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 +366,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.2` 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.2` operating stance:
+  Read [guides/recommendations-0.9.2.md](./guides/recommendations-0.9.2.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/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.2` 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.2` 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.2`; 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, hardens the sandbox-safe supervisor path for LEAPclaw, OpenClaw, Nemoshell, Docker, and similar short-lived exec environments, and documents the current authenticated Wave Control plus Corridor-backed security surface that already ships 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.2` operating stance is documented in `docs/guides/recommendations-0.9.2.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:
 

package/docs/plans/migration.md

@@ -1,6 +1,6 @@
 # Migration
 
-This page is the practical repo-upgrade guide for the current `0.9.1` surface.
+This page is the practical repo-upgrade guide for the current `0.9.2` surface.
 
 Use it when you are:
 
@@ -12,22 +12,24 @@ 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.1` Changes
+## What `0.9.2` Changes
 
-The current `0.9.1` surface keeps the packaged operator-guidance alignment, monorepo project support, and project-aware default telemetry from `0.9.0`, but adds a more sandbox-friendly execution model and lower-overhead live orchestration.
+The current `0.9.2` surface keeps the packaged operator-guidance alignment, monorepo project support, and project-aware default telemetry from `0.9.0`, but adds a more sandbox-friendly execution model and lower-overhead live orchestration.
 
 The practical changes are:
 
 - live agent execution now uses detached process runners instead of per-agent tmux execution sessions, which reduces tmux churn and lowers memory pressure during broader fan-out
 - `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach` are now the preferred path for short-lived clients and sandbox automation
 - supervisor recovery now reconciles launcher status and progress more conservatively, preserves the correct remaining wave range during multi-wave reruns, and keeps read-side status/wait calls aligned even after daemon loss
+- the packaged docs now cover the actual shipped owned-deployment Wave Control surface: Stack-authenticated browser access, Wave-managed approval states and provider grants, PATs, service tokens, encrypted per-user credentials, runtime env leasing, and the separate `services/wave-control-web` frontend
+- Corridor is now documented as a first-class security input, including direct versus broker versus hybrid mode, implementation-owned path matching, generated artifact paths, and the closure-gate interaction with the human security reviewer
 - a dedicated setup guide now ships for LEAPclaw, OpenClaw, Nemoshell, Docker, and similar constrained environments
 - the `0.9.0` monorepo and project-aware state layout remains part of the release surface, including `defaultProject`, `projects.<projectId>`, project-scoped state roots, and project-aware CLI routing
-- the current release surface and tracked install-state fixtures now all move together on `0.9.1`
+- the current release surface and tracked install-state fixtures now all move together on `0.9.2`
 
-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 `0.9.1` package cut.
+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 `0.9.2` package cut.
 
-For a practical `0.9.1` operating stance after the upgrade, read [../guides/recommendations-0.9.1.md](../guides/recommendations-0.9.1.md).
+For a practical `0.9.2` operating stance after the upgrade, read [../guides/recommendations-0.9.2.md](../guides/recommendations-0.9.2.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
@@ -95,7 +97,7 @@ pnpm exec wave upgrade
 
 ### 3. Sync repo-owned starter surface only if you copied it
 
-The most common sync set for `0.9.1` is:
+The most common sync set for `0.9.2` is:
 
 - `docs/agents/wave-launcher-role.md`
 - `docs/agents/wave-orchestrator-role.md`
@@ -116,8 +118,10 @@ The most common sync set for `0.9.1` is:
 - `docs/context7/planner-agent/`
 - `docs/reference/wave-planning-lessons.md`
 - `docs/reference/cli-reference.md`
+- `docs/reference/corridor.md`
 - `docs/reference/skills.md`
 - `docs/reference/sample-waves.md`
+- `docs/reference/wave-control.md`
 - `docs/plans/current-state.md`
 - `docs/plans/end-state-architecture.md`
 - `docs/plans/wave-orchestrator.md`
@@ -146,20 +150,22 @@ 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.1` Release Model
+## `0.9.2` Release Model
 
-The current `0.9.1` surface is five changes together:
+The current `0.9.2` surface combines these strands:
 
-- the detached process-runner and sandbox supervisor hardening released in `0.9.1`
+- 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
 - 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, sandbox setup guide, and install-state alignment follow-up released in `0.9.1`
+- the current owned-deployment Wave Control surface: Stack-authenticated app access, provider grants, PATs, service tokens, encrypted per-user credentials, and runtime credential leasing
+- 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
 
 ### Sandbox-safe execution and lower-overhead live runs
 
-This is the main new behavior in `0.9.1`.
+This is the main new behavior in `0.9.2`.
 
 The runtime now:
 
@@ -168,7 +174,7 @@ The runtime now:
 - keeps `wave attach --agent` usable through log-follow attach even when no live interactive terminal session exists
 - uses `wave submit/supervise/status/wait/attach` as the preferred sandbox-safe surface for short-lived clients
 
-If your repo copied sandbox, CI, or container runbooks, this is the main sync set to apply from `0.9.1`:
+If your repo copied sandbox, CI, or container runbooks, this is the main sync set to apply from `0.9.2`:
 
 - `README.md`
 - `docs/README.md`
@@ -177,6 +183,24 @@ If your repo copied sandbox, CI, or container runbooks, this is the main sync se
 - `docs/reference/cli-reference.md`
 - `docs/plans/sandbox-end-state-architecture.md`
 
+### Authenticated Wave Control and Corridor-backed security
+
+The same `0.9.2` doc surface also now describes the current control-plane and security model as shipped:
+
+- owned Wave Control deployments use Stack for browser sign-in, then apply Wave-managed approval states and provider grants on top of that identity
+- approved users and superusers can issue PATs for scoped repo-runtime access, while dedicated service tokens keep machine-admin workflows separate from user-owned runtime credentials
+- arbitrary stored credentials are encrypted at rest and only returned through explicit runtime lease responses
+- `externalProviders.corridor` can run direct, brokered through an owned Wave Control deployment, or hybrid; the result is persisted as a normalized security artifact and can block closure before integration
+
+If your repo copied release docs, security runbooks, or Wave Control setup docs, this is the main sync set to apply from `0.9.2`:
+
+- `README.md`
+- `docs/README.md`
+- `docs/reference/runtime-config/README.md`
+- `docs/reference/coordination-and-closure.md`
+- `docs/reference/corridor.md`
+- `docs/reference/wave-control.md`
+
 ### Signal-driven waiting and wrapper model
 
 This is the main new behavior in `0.8.6`.
@@ -359,9 +383,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.3` To `0.9.1`
+## Upgrading From `0.8.3` To `0.9.2`
 
-Treat this as one move to the current `0.9.1` surface.
+Treat this as one move to the current `0.9.2` surface.
 
 ### What changed across that range
 
@@ -394,7 +418,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.1`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.9.2`
 
 This is the main migration path for older adopted repos.
 
@@ -435,7 +459,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.1`
+## Upgrading From `0.5.x` Or Earlier To `0.9.2`
 
 Do not treat this as a tiny patch bump.
 
@@ -545,4 +569,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.9.1` 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.
+The current `0.9.2` 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/reference/cli-reference.md

@@ -629,7 +629,7 @@ Interactive draft currently offers worker role kinds:
 - `research`
 - `security`
 
-Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.9.1` 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.2` 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

@@ -36,6 +36,8 @@ At runtime, those distinctions map onto separate modules:
 
 Closure roles are resolved from the wave definition first, then from starter defaults. In other words, integration, documentation, `cont-QA`, `cont-EVAL`, and security review keep the same semantics even when a wave overrides the default role ids such as `A8`, `A9`, `A0`, `E0`, or `A7`.
 
+If `externalProviders.corridor.enabled` is on, Wave also materializes a normalized Corridor artifact before security and integration run. Security review still owns the human-readable report and `[wave-security]` marker, but the security gate can fail closed when the saved Corridor artifact reports a fetch failure or matched blocking findings on implementation-owned paths.
+
 ## Durable State Surfaces
 
 The runtime writes several different artifacts, but they do different jobs:
@@ -56,6 +58,12 @@ The runtime writes several different artifacts, but they do different jobs:
   `.tmp/<lane>-wave-launcher/inboxes/wave-<n>/<agent>.md`
 - integration summary:
   `.tmp/<lane>-wave-launcher/integration/wave-<n>.json`
+- security summary:
+  `.tmp/<lane>-wave-launcher/security/wave-<n>.json`
+- security markdown summary:
+  `.tmp/<lane>-wave-launcher/security/wave-<n>.md`
+- Corridor security context:
+  `.tmp/<lane>-wave-launcher/security/wave-<n>-corridor.json`
 - wave dashboard:
   `.tmp/<lane>-wave-launcher/dashboards/wave-<n>.json`
 - run-state:
@@ -134,7 +142,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.1` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.9.1.md](../guides/recommendations-0.9.1.md).
+For the practical `0.9.2` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.9.2.md](../guides/recommendations-0.9.2.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.
 
@@ -392,6 +400,15 @@ If present, security review must emit a final `[wave-security]` marker and publi
 - `concerns` remains visible in summaries and traces
 - `clear` is only valid when no unresolved findings or approvals remain
 
+Corridor does not replace that review. When `externalProviders.corridor.enabled` is on:
+
+- Wave first materializes the normalized Corridor artifact
+- `requiredAtClosure: true` turns provider fetch failures into `corridor-fetch-failed`
+- matched findings at or above the configured threshold turn the gate into `corridor-blocked`
+- matched findings still stay visible in security and integration summaries even when the human reviewer reports only advisory concerns
+
+Only implementation-owned non-doc, non-`.tmp/`, non-markdown paths are eligible for Corridor matching. See [corridor.md](./corridor.md) for the provider-specific rules.
+
 ### Integration
 
 Integration must reconcile cross-agent state and report `ready-for-doc-closure` only when there is no remaining meaningful contradiction, blocker, proof gap, or deploy risk.