@chllming/wave-orchestration 0.9.0 → 0.9.1

package/docs/concepts/operating-modes.md

@@ -82,10 +82,10 @@ That usually means:
 
 ## Relationship To The Roadmap
 
-The roadmap still includes stronger explicit oversight vs dark-factory workflows. What is shipped today is the planning foundation:
+The current roadmap is a release-direction document, not a backlog of planner phases. What is shipped today is still the planning foundation:
 
 - stored project defaults
 - typed values in planner output
 - better environment modeling
 
-The stricter execution semantics are the next step, not a hidden already-finished feature.
+The stricter execution semantics are still future work, not a hidden already-finished feature in `0.9.1`.

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.0` is:
+The starter contract in `0.9.1` is:
 
 - import `docs/agents/wave-design-role.md`
 - own one packet such as `docs/plans/waves/design/wave-<n>-<agentId>.md`
@@ -101,12 +101,12 @@ Human feedback is an escalation path, not the operating mode itself. The orchest
 
 ## 4. Choose The Operator Surface
 
-Live runs always execute in `tmux`. The terminal surface only decides how you attach:
+Live agent runs now execute in detached process runners. The terminal surface only decides how you follow logs and attach to dashboard projections:
 
 - `vscode`
-  VS Code gets temporary attach entries for the live tmux sessions.
+  VS Code gets temporary attach entries for process-backed agent logs and dashboard projections.
 - `tmux`
-  Terminal-native operation with no VS Code integration.
+  Terminal-native dashboard and operator projection surface with no VS Code integration.
 - `none`
   Dry-run only.
 
@@ -116,6 +116,16 @@ Recommended defaults:
 - remote shell or devbox: `tmux`
 - CI or validation-only work: `none` with `--dry-run`
 
+If the surrounding environment is the unstable part, not the repo itself, prefer the sandbox-safe path:
+
+- `wave submit`
+- `wave supervise`
+- `wave status`
+- `wave wait`
+- `wave attach`
+
+That is the right fit for LEAPclaw, OpenClaw, Nemoshell, Docker, and similar short-lived exec shells. Use direct `wave launch` when the client shell itself can stay alive for the entire wave. For the concrete setup patterns, read [sandboxed-environments.md](./sandboxed-environments.md).
+
 ## 5. Dry-Run Before Live Execution
 
 Treat dry-run as the quality gate for the authored wave:

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.0` 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.1` 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 roadmap work. The planner foundation is about better structured authoring, not a second execution engine.
+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.
 
 ## Project Profile
 

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

@@ -1,21 +1,22 @@
 ---
-title: "0.9.0 Recommendations"
-summary: "How to use 0.9.0's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+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."
 ---
 
-# 0.9.0 Recommendations
+# 0.9.1 Recommendations
 
-Use this guide when you are adopting `0.9.0` 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.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.
 
 ## Recommended Default
 
-For most repos, the safest `0.9.0` default is:
+For most repos, the safest `0.9.1` 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
 
 That recommendation matches the runtime:
 
@@ -75,7 +76,7 @@ Only set a hard runtime ceiling when you deliberately want the runtime itself to
 
 ## 2. Softer Coordination States
 
-`0.9.0` keeps “still visible” separate from “still blocking”.
+`0.9.1` keeps “still visible” separate from “still blocking”.
 
 Use these states intentionally:
 
@@ -111,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.0` code path is:
+My recommendation after reviewing the current `0.9.1` 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

@@ -0,0 +1,158 @@
+# Running Wave In Sandboxed Environments
+
+Use this guide when Wave is running under a short-lived shell or exec environment rather than a normal long-lived operator shell.
+
+Typical examples:
+
+- LEAPclaw or OpenClaw-style agent harnesses that give you short `exec` windows
+- 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:
+
+- clients should be short-lived
+- supervision should be long-lived
+- agent execution should be process-backed, not tmux-backed
+
+Wave now launches agents through detached process runners by default, which lowers tmux session churn and memory pressure compared with the old “every live agent owns a tmux session” shape. Tmux is now optional and dashboard-only.
+
+## Recommended Model
+
+For sandboxes, prefer the async supervisor surface:
+
+```bash
+pnpm exec wave submit ...
+pnpm exec wave supervise ...
+pnpm exec wave status ...
+pnpm exec wave wait ...
+pnpm exec wave attach ...
+```
+
+Use direct `wave launch` when:
+
+- you control a normal long-lived shell
+- the launcher process can stay alive for the whole run
+- you are doing local debugging or dry-run validation
+
+Do not bind a multi-hour wave to one short-lived sandbox client process.
+
+## Baseline Configuration
+
+Set the Codex sandbox default in `wave.config.json` for the lane or executor profile instead of retyping `--codex-sandbox` on every command.
+
+Typical sandbox-safe pattern:
+
+```json
+{
+  "executors": {
+    "codex": {
+      "sandbox": "workspace-write"
+    }
+  }
+}
+```
+
+Use a stricter mode such as `read-only` when the task truly should not write. Use `danger-full-access` only when the outer environment is already providing the isolation you want.
+
+Treat `tmux` as optional:
+
+- install it only if you want live dashboard attach
+- use `--no-dashboard` in constrained environments when you do not need the extra projection process
+
+## LEAPclaw / OpenClaw / Nemoshell Pattern
+
+In these environments, the common failure mode is a short-lived client exec timeout while the wave itself needs much longer.
+
+Preferred shape:
+
+1. A disposable client submits work.
+2. A durable daemon owns the run.
+3. Clients poll or wait observationally.
+
+Example:
+
+```bash
+runId=$(pnpm exec wave submit \
+  --project backend \
+  --lane main \
+  --start-wave 2 \
+  --end-wave 2 \
+  --no-dashboard \
+  --json | jq -r .runId)
+
+pnpm exec wave status --run-id "$runId" --project backend --lane main --json
+pnpm exec wave wait --run-id "$runId" --project backend --lane main --timeout-seconds 300 --json
+```
+
+Keep `wave supervise` alive outside the short-lived client call:
+
+- a long-lived host shell
+- a background service
+- a job runner that can outlive the client request
+
+If the sandbox only gives you short exec windows, `wave autonomous` should not be the thing owning the run. Use submit plus observe instead.
+
+## 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.
+
+Recommended container posture:
+
+- mount the repo root as a persistent volume
+- preserve `.tmp/` and `.wave/`
+- run `wave supervise` in a long-lived container or sidecar
+- use `wave submit/status/wait` from short-lived execs
+- disable dashboards unless the image actually includes `tmux` and you want the extra process
+
+Practical rules:
+
+- dashboard attach is optional; log-follow attach is enough for most sandbox automation
+- `wave attach --agent <id>` now follows the recorded log when no live interactive session exists
+- `wave attach --dashboard` falls back to the last written dashboard file when no live dashboard session exists
+
+## Terminal Surface Recommendations
+
+For constrained sandboxes:
+
+- `--terminal-surface vscode`
+  Good when the repo is local and the editor integration is useful.
+- `--terminal-surface tmux`
+  Good only when `tmux` is installed and you actually want live dashboard attach.
+- `--terminal-surface none`
+  Dry-run only.
+
+The important distinction is that terminal surface is now an operator preference, not the agent execution backend.
+
+## Validation Checklist
+
+Run these after setup changes:
+
+```bash
+pnpm exec wave doctor --json
+pnpm exec wave launch --lane main --dry-run --no-dashboard
+```
+
+For a sandboxed lane, also verify:
+
+- `wave submit --json` returns a `runId`
+- `wave status` and `wave wait` work with exact `--project` and `--lane`
+- the supervisor run tree exists under `.tmp/.../control/supervisor/runs/<runId>/`
+- dashboards are either intentionally disabled or intentionally backed by a real `tmux` install
+
+## When To Keep Using `wave launch`
+
+Use `wave launch` directly when:
+
+- you are on a normal workstation shell
+- the launcher can stay alive for the entire run
+- you want the fastest direct local workflow
+- you are debugging wave behavior and want the simplest path
+
+Use `wave submit` plus `wave supervise` when the surrounding environment, not the wave itself, is the unstable part.
+
+## Related Docs
+
+- [author-and-run-waves.md](./author-and-run-waves.md)
+- [terminal-surfaces.md](./terminal-surfaces.md)
+- [../reference/cli-reference.md](../reference/cli-reference.md)
+- [../plans/sandbox-end-state-architecture.md](../plans/sandbox-end-state-architecture.md)

package/docs/guides/terminal-surfaces.md

@@ -6,15 +6,16 @@ Wave has separate concepts for execution substrate and operator surface.
 
 The important detail is:
 
-- live runs use `tmux` sessions
-- terminal surfaces control how operators attach to those sessions
+- live agent runs use detached process runners
+- terminal surfaces control how operators follow logs and attach to dashboard projections
+- sandbox-safe submission and supervision are documented separately in [sandboxed-environments.md](./sandboxed-environments.md)
 
 ## The Three Terminal Surfaces
 
 - `vscode`
-  The launcher writes temporary entries to `.vscode/terminals.json` so VS Code can attach to the tmux sessions.
+  The launcher writes temporary entries to `.vscode/terminals.json` so VS Code can follow process-backed agent logs and attach to stable dashboard projections.
 - `tmux`
-  The launcher uses tmux only and never touches `.vscode/terminals.json`.
+  The launcher uses tmux only for dashboard and operator projection sessions and never touches `.vscode/terminals.json`.
 - `none`
   Dry-run only. No live terminal surface is allowed in this mode.
 
@@ -22,12 +23,12 @@ The important detail is:
 
 `vscode` is not a second process host. It is a convenience attachment surface.
 
-The actual live sessions still run in tmux. The VS Code terminal registry just exposes stable attach commands for those tmux sessions.
+The actual live agent work runs in detached processes. The VS Code terminal registry exposes stable log-follow commands for agents plus stable attach commands for dashboard projections.
 
 Use `vscode` when:
 
 - your main operator flow is inside VS Code
-- you want one-click attach behavior for agent sessions and dashboards
+- you want one-click attach behavior for agent logs and dashboards
 - touching `.vscode/terminals.json` is acceptable in the repo
 
 ## What `tmux` Really Means
@@ -47,7 +48,7 @@ By default the launcher can start per-wave dashboard sessions in tmux.
 
 Wave now maintains stable tmux attach targets for both the current-wave dashboard and the global dashboard on the lane socket.
 
-Wave-agent sessions and the resident orchestrator now also use stable per-wave tmux session names. A relaunch reuses the same session identity for that wave instead of creating a new run-tagged session name each time, which reduces stale session buildup after launcher crashes or interrupted retries.
+Wave agent execution no longer depends on tmux. `wave attach --agent` uses a live interactive session only when the runtime explicitly exposes one; otherwise it follows the recorded agent log or prints the terminal log tail.
 
 Use:
 
@@ -56,18 +57,18 @@ pnpm exec wave dashboard --lane main --attach current
 pnpm exec wave dashboard --lane main --attach global
 ```
 
-Those commands work for both `tmux` and `vscode` terminal surfaces because the live sessions still run on the lane tmux socket.
+Those commands work for both `tmux` and `vscode` terminal surfaces because the live dashboard projections still run on the lane tmux socket. If no live dashboard session exists, the attach command falls back to the last written dashboard JSON instead of failing immediately.
 
 When `--terminal-surface vscode` is active, Wave also maintains a stable current-wave dashboard terminal entry instead of creating a new wave-numbered dashboard attach target for every wave transition.
 
 Important flags:
 
 - `--no-dashboard`
-  Disable the per-wave tmux dashboard session.
+  Disable the per-wave dashboard projection session.
 - `--cleanup-sessions`
-  Kill lane tmux sessions after each wave. This is the default.
+  Kill lane tmux dashboard and projection sessions after each wave. This is the default.
 - `--keep-sessions`
-  Preserve tmux sessions after the wave for inspection.
+  Preserve tmux dashboard and projection sessions after the wave for inspection.
 - `--keep-terminals`
   Keep temporary VS Code terminal entries instead of cleaning them up.
 
@@ -76,7 +77,8 @@ Important flags:
 - Use `vscode` for local interactive operator work when the temporary terminal registry is useful.
 - Use `tmux` for remote, CI-like, or editor-independent operation.
 - Use `none` only with `--dry-run`.
-- Prefer `wave dashboard --attach current|global` over manual `tmux -L <socket> attach ...` lookups.
+- In constrained sandboxes or containers, treat dashboards as optional and prefer `--no-dashboard` unless `tmux` is installed and you actually want the extra projection process.
+- Prefer `wave dashboard --attach current|global` over manual `tmux -L <socket> attach ...` lookups; it will fall back to the last written dashboard file when no live session exists.
 - Pair `--keep-sessions` with incident review or deep debugging, not as a default steady-state mode.
 - Pair `--no-dashboard` with scripted dry-runs or when the board and summaries are sufficient.
 

package/docs/plans/current-state.md

@@ -1,10 +1,11 @@
 # Current State
 
-- The published package is `0.9.0`; that release adds first-class monorepo project support, project-aware runtime isolation, and default metadata delivery to Wave Control while keeping the shipped design-role and signal-hygiene starter surface.
-- The canonical shipped runtime architecture is documented in `docs/plans/end-state-architecture.md`; historical cutover notes remain in `docs/plans/architecture-hardening-migration.md`.
+- The 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 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.0` operating stance is documented in `docs/guides/recommendations-0.9.0.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.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.
+- 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.
 - 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`.
@@ -46,6 +47,7 @@
   - orchestrator-first clarification triage plus human escalation artifacts
   - answered human-feedback responses that reconcile canonical coordination state, helper assignments, and safe continuation intent even when the launcher is no longer active
   - optional `--resident-orchestrator` support for a long-running, non-owning orchestrator session during live waves
+  - detached process-backed agent execution, per-agent runtime records, and log-follow attach behavior so normal agents no longer require tmux-backed execution sessions
   - seeded operator wrappers `scripts/wave-status.sh` and `scripts/wave-watch.sh` that expose machine-friendly wait, completion, failure, and input-required status by reading `wave control status --json`
   - persisted relaunch plans under `.tmp/<lane>-wave-launcher/status/` so targeted retry intent can survive a launcher restart
   - a canonical control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/` that records operator tasks, rerun requests, proof bundles, contradictions, facts, human-input workflow, observed `wave_run`, `attempt`, and `agent_run` lifecycle events, plus `wave_signal` and `agent_signal` update events as append-only JSONL; `wave control` materializes state from this log

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

@@ -1,6 +1,8 @@
 # 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.0` 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.1` 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).
 
 The thesis is unchanged: bounded waves, closure roles, proof artifacts, selective rerun, and delivery discipline. What changes is the internal authority model. The launcher stops being the decision engine and becomes a thin orchestrator that reads decisions from canonical state, sequences the engines, and delegates process work to the session supervisor.
 

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

@@ -1,6 +1,6 @@
 # Wave 12 - Optional Design Steward Handoff
 
-This is a showcase-first sample wave for the shipped `design` worker role in `0.9.0`.
+This is a showcase-first sample wave for the shipped `design` worker role in `0.9.1`.
 
 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.0` Wave surface.
+Use it as the single reference example for the current `0.9.1` 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.0` surface.
+This page is the practical repo-upgrade guide for the current `0.9.1` surface.
 
 Use it when you are:
 
@@ -10,21 +10,25 @@ Use it when you are:
 
 For the completed internal architecture cutover record, see [architecture-hardening-migration.md](./architecture-hardening-migration.md). That document is historical. This one is the operator-facing upgrade checklist.
 
-## What `0.9.0` Changes
+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).
 
-The current `0.9.0` surface keeps the packaged operator-guidance alignment and adds first-class monorepo project support plus project-aware default telemetry.
+## What `0.9.1` 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 practical changes are:
 
-- `wave.config.json` can now declare `defaultProject` and `projects.<projectId>`, so one repo can host multiple Wave projects without lane-name collisions
-- planner defaults, docs roots, ad-hoc runs, dependency tickets, launcher state, and benchmark identity are now scoped by project when you use explicit monorepo projects
-- lane-scoped commands now accept `--project`, so the CLI can target the right project without relying on lane names alone
-- Wave Control defaults to `https://wave-control.up.railway.app/api/v1` with `reportMode: "metadata-only"` and sends project, lane, and wave metadata unless you explicitly opt out
-- the current release surface and tracked install-state fixtures now all move together on `0.9.0`
+- 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
+- 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`
 
-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.0` 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.1` package cut.
 
-For a practical `0.9.0` operating stance after the upgrade, read [../guides/recommendations-0.9.0.md](../guides/recommendations-0.9.0.md).
+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 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
 
@@ -91,7 +95,7 @@ pnpm exec wave upgrade
 
 ### 3. Sync repo-owned starter surface only if you copied it
 
-The most common sync set for `0.9.0` is:
+The most common sync set for `0.9.1` is:
 
 - `docs/agents/wave-launcher-role.md`
 - `docs/agents/wave-orchestrator-role.md`
@@ -105,6 +109,7 @@ The most common sync set for `0.9.0` is:
 - `scripts/wave-status.sh`
 - `scripts/wave-watch.sh`
 - `docs/guides/author-and-run-waves.md`
+- `docs/guides/sandboxed-environments.md`
 - `docs/guides/planner.md`
 - `docs/guides/terminal-surfaces.md`
 - `docs/guides/signal-wrappers.md`
@@ -141,14 +146,36 @@ 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.0` Release Model
+## `0.9.1` Release Model
 
-The current `0.9.0` surface is three changes together:
+The current `0.9.1` surface is five changes together:
 
+- the detached process-runner and sandbox supervisor hardening released in `0.9.1`
+- 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 and install-state alignment follow-up released in `0.9.0`
+- the packaged recommendations guide, sandbox setup guide, and install-state alignment follow-up released in `0.9.1`
+
+### Sandbox-safe execution and lower-overhead live runs
+
+This is the main new behavior in `0.9.1`.
+
+The runtime now:
+
+- launches live agents through detached process runners instead of per-agent tmux sessions
+- treats tmux as dashboard-only and optional
+- 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`:
+
+- `README.md`
+- `docs/README.md`
+- `docs/guides/sandboxed-environments.md`
+- `docs/guides/terminal-surfaces.md`
+- `docs/reference/cli-reference.md`
+- `docs/plans/sandbox-end-state-architecture.md`
 
 ### Signal-driven waiting and wrapper model
 
@@ -332,9 +359,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.0`
+## Upgrading From `0.8.3` To `0.9.1`
 
-Treat this as one move to the current `0.9.0` surface.
+Treat this as one move to the current `0.9.1` surface.
 
 ### What changed across that range
 
@@ -367,7 +394,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.0`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.9.1`
 
 This is the main migration path for older adopted repos.
 
@@ -408,7 +435,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.0`
+## Upgrading From `0.5.x` Or Earlier To `0.9.1`
 
 Do not treat this as a tiny patch bump.
 
@@ -518,4 +545,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.9.0` 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.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.