@chllming/wave-orchestration 0.8.9 → 0.9.1

package/docs/plans/current-state.md

@@ -1,21 +1,23 @@
 # Current State
 
-- The published package is `0.8.9`; that release keeps the shipped design-role and signal-hygiene starter surface, preserves design packet report paths during reducer and trace summary reconstruction, and reports blocked design passes as design-gate failures before implementation starts.
-- 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.8.9` operating stance is documented in `docs/guides/recommendations-0.8.9.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`.
 - Planner foundation is now shipped:
-  - `.wave/project-profile.json` stores default oversight mode, terminal surface, draft template, lane, and deploy-environment memory
+  - `.wave/project-profile.json` stores default oversight mode, terminal surface, draft template, lane, and deploy-environment memory for the implicit default project
+  - explicit monorepo projects store the same profile under `.wave/projects/<projectId>/project-profile.json`
   - `wave project setup|show` manage that profile
   - `wave draft` writes planner JSON specs plus launcher-compatible markdown waves
 - Ad-hoc task runs are now first-class:
   - `wave adhoc plan|run|list|show|promote` manage transient operator-driven work
-  - requests, generated specs, rendered markdown, and final results live under `.wave/adhoc/runs/<run-id>/`
-  - runtime state stays isolated under `.tmp/<lane>-wave-launcher/adhoc/<run-id>/`
+  - requests, generated specs, rendered markdown, and final results live under `.wave/adhoc/<projectId>/runs/<run-id>/` for explicit projects, while the implicit default project keeps the legacy layout
+  - runtime state stays isolated under `.tmp/<lane>-wave-launcher/adhoc/<run-id>/` for the implicit default project, or `.tmp/projects/<projectId>/<lane>-wave-launcher/adhoc/<run-id>/` for explicit projects
   - `wave feedback respond --run <run-id>` now reconciles answered human-input state inside that isolated ad-hoc state root and can queue a safe one-shot continuation request without touching roadmap state
   - ad-hoc runs always keep integration, documentation, and cont-QA closure, while `cont-EVAL` and security review are synthesized only when the request needs them
   - documentation closure still queues canonical shared-plan docs when a run reports a shared-plan delta, alongside the ad-hoc closure report
@@ -45,12 +47,14 @@
   - 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
   - operator-applied retry overrides projected to `.tmp/<lane>-wave-launcher/control/` for compatibility with selected reruns, explicit reuse selectors, reuse clearing or preservation, and explicit resume targets
   - 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 local-first, best-effort reporting to the Railway-hosted analysis plane
+  - 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
   - 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,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.8.9` 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.8.9`.
+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.
 
@@ -12,6 +12,8 @@ Use this shape when:
 
 If you want the hybrid design-steward variant instead, keep the same packet path but also assign that same design agent implementation-owned files plus the normal implementation contract sections. The runtime will then run the design pass first and include that same agent in the later implementation fan-out.
 
+All launcher-owned `.tmp/main-wave-launcher/...` paths in this example assume the implicit default project. For explicit monorepo projects, rewrite them to `.tmp/projects/<projectId>/main-wave-launcher/...` and launch the wave with `--project <projectId>`.
+
 **Commit message**: `Feat: add design packet before implementation fan-out`
 
 ## Component promotions

package/docs/plans/examples/wave-example-live-proof.md

@@ -2,11 +2,12 @@
 
 This is a showcase-first sample wave.
 
-Use it as the single reference example for the current `0.8.9` 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:
 
 - standard closure roles (`A0`, `E0`, `A8`, `A9`)
+- optional security review (`A7`) before integration closure
 - `## Eval targets` with delegated and pinned benchmark selection
 - richer `### Executor` blocks, budgets, and sticky retry
 - `### Skills`
@@ -19,6 +20,10 @@ It intentionally combines more sections than a normal production wave so one fil
 
 This example is intentionally denser than a launch-minimal wave. Its job is to teach the full authored surface in one place.
 
+It keeps the starter closure role ids (`A0`, `E0`, `A8`, `A9`, `A7`) so the example stays easy to scan. If your repo uses different ids, keep the same role prompts and closure intent but rename the agent ids at the wave level.
+
+All launcher-owned `.tmp/main-wave-launcher/...` paths in this example assume the implicit default project. For explicit monorepo projects, rewrite them to `.tmp/projects/<projectId>/main-wave-launcher/...` and launch the wave with `--project <projectId>`.
+
 **Commit message**: `Docs: add full modern sample wave`
 
 ## Component promotions

package/docs/plans/examples/wave-example-rollout-fidelity.md

@@ -10,6 +10,8 @@ This example is intentionally generic. The component id, deliverable paths, and
 Go control-plane slices are illustrative, but the authored Wave structure,
 closure expectations, and maturity discipline match the current surface.
 
+All launcher-owned `.tmp/main-wave-launcher/...` paths in this example assume the implicit default project. For explicit monorepo projects, rewrite them to `.tmp/projects/<projectId>/main-wave-launcher/...` and launch the wave with `--project <projectId>`.
+
 **Commit message**: `Feat: land rollout substrate and desired-state records`
 
 ## Component promotions

package/docs/plans/migration.md

@@ -1,6 +1,6 @@
 # Migration
 
-This page is the practical repo-upgrade guide for the current `0.8.9` surface.
+This page is the practical repo-upgrade guide for the current `0.9.1` surface.
 
 Use it when you are:
 
@@ -10,20 +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.8.9` 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.8.9` surface keeps the `0.8.8` packaged operator-guidance alignment and adds a focused repair for design-pass replay and post-design transition handling.
+## 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:
 
-- reducer snapshots now preserve design packet report paths when they rebuild summaries from result envelopes
-- blocked design passes now stop at the design gate instead of being surfaced later as downstream implementation envelope failures
-- trace bundle summary reconstruction now also resolves design packet report paths, so copied design summaries stay aligned when they are rebuilt from logs
-- the current release surface and tracked install-state fixtures now all move together on `0.8.9`
+- 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, or operator runbooks, these are the areas most likely to need a sync before the `0.8.9` 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.8.9` operating stance after the upgrade, read [../guides/recommendations-0.8.9.md](../guides/recommendations-0.8.9.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
 
@@ -90,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.8.6` is:
+The most common sync set for `0.9.1` is:
 
 - `docs/agents/wave-launcher-role.md`
 - `docs/agents/wave-orchestrator-role.md`
@@ -104,6 +109,7 @@ The most common sync set for `0.8.6` 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`
@@ -119,6 +125,8 @@ The most common sync set for `0.8.6` is:
 
 If your repo copied starter `wave.config.json` defaults, also sync:
 
+- `defaultProject`
+- `projects.<projectId>`
 - `roles.designRolePromptPath`
 - `skills.byRole.design`
 - `executors.profiles.design-pass`
@@ -138,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.8.9` Release Model
+## `0.9.1` Release Model
 
-The current `0.8.9` 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.8.9`
+- 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
 
@@ -329,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.8.9`
+## Upgrading From `0.8.3` To `0.9.1`
 
-Treat this as one move to the current `0.8.9` surface.
+Treat this as one move to the current `0.9.1` surface.
 
 ### What changed across that range
 
@@ -364,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.8.9`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.9.1`
 
 This is the main migration path for older adopted repos.
 
@@ -405,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.8.9`
+## Upgrading From `0.5.x` Or Earlier To `0.9.1`
 
 Do not treat this as a tiny patch bump.
 
@@ -515,4 +545,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.8.9` 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.

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

@@ -0,0 +1,153 @@
+# Sandbox End-State Architecture
+
+This document is the sandbox-runtime companion to [end-state-architecture.md](./end-state-architecture.md). The core architecture still applies: the canonical authority set remains wave definitions, the coordination log, and the control-plane event log. This page narrows that model to the execution environments that impose short-lived `exec` sessions, process ceilings, or terminal instability.
+
+The goal is straightforward: sandbox client commands must stay short and disposable, while long-running wave ownership moves to a durable supervisor that can survive launcher exit, sandbox timeout, and terminal churn.
+
+For the operator-facing setup flow in LEAPclaw, OpenClaw, Nemoshell, Docker, and similar environments, read [../guides/sandboxed-environments.md](../guides/sandboxed-environments.md). This page is the deeper design and authority-model reference.
+
+---
+
+## Problem Statement
+
+Sandboxed runtimes have failure modes that the generic architecture does not need to describe in detail:
+
+- the sandbox `exec` session may have a wall-clock timeout that is much shorter than a real wave
+- bursty `spawnSync` and `tmux` probes can hit `EAGAIN`, `EMFILE`, or related process pressure limits
+- the launcher process can die before child agents finish, leaving orphaned sessions and ambiguous status
+- a missing `tmux` session is not enough evidence that the actual agent process failed
+
+The shipped runtime now has an initial async supervisor wrapper plus forwarded closure-gap handling, but it does not yet satisfy the full sandbox ownership model described here.
+
+---
+
+## Target Command Model
+
+Sandbox-facing commands should follow an async submit/observe pattern:
+
+- `wave submit [launcher options]`
+  Validate the request, persist a run request, print a `runId`, and exit quickly.
+- `wave supervise`
+  Long-running daemon command that owns launch, monitoring, retry, adoption, and cleanup. This command is not intended to be bound to a short sandbox `exec` lifetime.
+- `wave status --run-id <id>`
+  Read canonical supervisor state for a run.
+- `wave wait --run-id <id> --timeout-seconds <n>`
+  Observe until a state change or timeout. Timing out never cancels the run.
+- `wave attach --run-id <id>`
+  Optional operator projection surface for `tmux` or another terminal UI. This is not a liveness authority.
+
+Compatibility rules:
+
+- `wave launch` remains the canonical full launcher surface for direct local execution and dry-run validation.
+- `wave autonomous` should submit and observe wave execution when it is used in sandbox-oriented flows.
+- `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach` are the preferred sandbox-facing surface, even while some internals remain partial.
+
+---
+
+## Canonical Authority In Sandboxed Runs
+
+The canonical authority set does not change, but sandbox supervision adds one more durable runtime layer:
+
+- wave definitions remain authoritative for declared work, closure roles, proof artifacts, and task contracts
+- coordination and control-plane logs remain authoritative for workflow, lifecycle, proof, and blocker state
+- supervisor run state becomes the canonical record of daemon-owned runtime observation for a submitted run
+
+The supervisor-owned state should converge on this per-run structure under `.tmp/<lane>-wave-launcher/supervisor/runs/<runId>/`:
+
+- `request.json`
+  Immutable submitted request.
+- `state.json`
+  Current daemon-owned run snapshot, including `runId`, `status`, `submittedAt`, `startedAt`, `completedAt`, `launcherPid`, `supervisorId`, `leaseExpiresAt`, `terminalDisposition`, and the latest observed launcher status.
+- `events.jsonl`
+  Supervisor-local observation history for adoption, retries, reconciliation, and cleanup decisions.
+- `launcher-status.json`
+  Canonical launcher completion status written atomically by the detached launcher wrapper.
+- `launcher.log`
+  Human-facing log stream only.
+- `agents/<agentId>.runtime.json`
+  Agent runtime observation record with fields such as `pid`, `pgid`, `attempt`, `startedAt`, `lastHeartbeatAt`, `exitCode`, `exitReason`, `statusPath`, and optional projection metadata like `tmuxSessionName`.
+
+Authority rules:
+
+- `tmux` is projection-only
+- dashboards, summaries, inboxes, and board markdown remain projections only
+- missing `tmux` state cannot by itself fail a run and is warning-only telemetry
+- pid checks, heartbeats, and atomic status files outrank terminal presence for liveness
+
+---
+
+## Daemon Ownership, Adoption, And Process Control
+
+The end state requires one daemon-owned control path for long-running work:
+
+1. `wave submit` writes the request and exits.
+2. `wave supervise` claims or renews a lease, launches work, and records observed runtime facts.
+3. `wave status` and `wave wait` read canonical state only.
+4. If the daemon dies, a later daemon instance can adopt active runs after lease expiry and continue observation without relaunching healthy agents.
+
+The daemon must own:
+
+- bounded process launch concurrency
+- async retry with jittered backoff for `EAGAIN`, `EMFILE`, and `ENFILE`
+- orphan adoption after stale lease detection
+- conservative orphan cleanup only after lease expiry, stale heartbeat, and failed pid confirmation
+- reconciliation between launcher status files, live pid state, and control-plane events
+
+The daemon must not depend on:
+
+- repeated `spawnSync("tmux", "list-sessions")` calls in the steady-state wait loop
+- one sandbox client process staying alive for the full wave duration
+- terminal presence as the source of truth for agent or wave health
+
+---
+
+## Closure Semantics For Forwarded Proof Gaps
+
+Closure staging still runs in the normal order:
+
+`implementation + proof -> cont-EVAL -> security/A7 -> integration/A8 -> docs/A9 -> cont-QA/A0`
+
+Sandbox stability does not change closure authority, but the daemon must preserve one special case:
+
+- `wave-proof-gap` from a closure-stage agent is a forwarded soft blocker, not an immediate full-wave stop
+
+Forwarding rules:
+
+- if A7 returns `wave-proof-gap`, the daemon still dispatches A8, A9, and A0 with the gap included as structured input
+- if A8 returns `wave-proof-gap`, the daemon still dispatches A9 and A0
+- if A9 returns `wave-proof-gap`, the daemon still dispatches A0
+- later closure agents must evaluate the currently available artifacts and report what is true; they must not refuse to run only because an earlier closure-stage agent reported `wave-proof-gap`
+- the final wave disposition remains blocked until the forwarded closure gaps are resolved
+
+Non-forwardable closure failures remain hard stops. Examples include malformed outputs, missing proof envelopes, explicit integration blockers, or invalid marker formats.
+
+---
+
+## Current Implementation Status
+
+Already landed:
+
+- `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach` exist as a file-backed async wrapper over the existing launcher
+- supervisor state now includes lease-backed daemon ownership, `events.jsonl`, exact lane-scoped lookup, and detached launcher-status reconciliation
+- agent runtime records now capture per-agent pid, heartbeat, runner metadata, terminal disposition, and attach or log-follow metadata for supervisor-owned runs
+- `wave autonomous` now submits and observes single-wave runs through the supervisor surface instead of binding them to one blocking launcher subprocess
+- closure-stage `wave-proof-gap` forwarding now continues later closure stages and records the blocker instead of failing the whole sweep immediately
+- retry planning now invalidates later closure reuse from the earliest forwarded closure-gap stage
+- agent execution now uses detached process runners by default, which lowers tmux session churn and memory pressure in wide fan-outs; tmux remains dashboard-only and `wave attach --agent` falls back to log following when no live session exists
+- launcher progress journaling now lets the supervisor recover finalized runs and safely resume the active wave without a repo-wide rescan
+
+Still missing for the true end state:
+
+- broader resume semantics beyond “restart the active wave with preserved control state”; recovery can now use finalized progress journals and canonical run-state completion, but multi-wave and auto-next recovery is still conservative
+- fully tmux-free live dashboard projection; dashboard attach now falls back to the last written dashboard file, but live dashboard sessions still use tmux today
+- full success inference from canonical runtime facts alone; the daemon still refuses to synthesize success from agent runtime files without either finalized progress or canonical run-state completion
+
+---
+
+## Remaining Gap Plan
+
+1. Implement supervisor lease, heartbeat, and stale-lock reclamation so a restarted daemon can adopt active runs without relaunching healthy work.
+2. Move liveness authority to pid, heartbeat, and atomic status files; keep `tmux` as projection-only and remove sync terminal probes from steady-state monitoring.
+3. Materialize supervisor events and per-agent runtime records as canonical daemon state, not only ad hoc wrapper files.
+4. Extend forwarded closure-gap handling into retry planning so the earliest forwarded gap invalidates later closure outputs for reuse while still preserving them for operator evidence.
+5. Converge sandbox-facing entrypoints so `submit/status/wait` become the default operator path and `autonomous` no longer owns a multi-hour blocking launcher process.

package/docs/plans/wave-orchestrator.md

@@ -38,7 +38,7 @@ The live runtime is organized around explicit modules:
 ## What It Does
 
 - parses wave plans from `docs/plans/waves/`
-- supports transient ad-hoc runs from `.wave/adhoc/runs/` on the same runtime substrate
+- supports transient ad-hoc runs from project-scoped `.wave/adhoc/<projectId>/runs/` storage on the same runtime substrate, with the implicit default project keeping the legacy layout
 - fans a wave out into one session per `## Agent ...` section
 - supports standing role imports from `docs/agents/*.md`
 - supports optional pre-implementation design stewards that publish design packets before code-owning implementation starts
@@ -103,9 +103,9 @@ The live runtime is organized around explicit modules:
 - `docs/reference/wave-control.md` documents the Wave Control telemetry and analysis plane, including entity types, artifact upload policies, and the local-first reporting contract.
 - `docs/plans/component-cutover-matrix.json` is the canonical machine-readable source for component maturity and per-wave promotion targets.
 - `.wave/install-state.json` records how the workspace was initialized and which package version is installed.
-- `.wave/project-profile.json` (created by `wave project setup`) records planner defaults such as oversight mode, terminal surface, and deploy-environment memory.
-- `.wave/adhoc/runs/<run-id>/` stores transient ad-hoc request, spec, rendered markdown, and result artifacts.
-- ad-hoc documentation closure always writes `.wave/adhoc/runs/<run-id>/reports/`, but shared-plan deltas still queue the canonical lane shared-plan docs.
+- `.wave/project-profile.json` (created by `wave project setup`) records planner defaults for the implicit default project; explicit projects use `.wave/projects/<projectId>/project-profile.json`.
+- `.wave/adhoc/<projectId>/runs/<run-id>/` stores transient ad-hoc request, spec, rendered markdown, and result artifacts for explicit projects, while the implicit default project keeps the legacy layout.
+- ad-hoc documentation closure writes project-scoped report paths under the run directory, but shared-plan deltas still queue the canonical lane shared-plan docs.
 - ad-hoc task ownership inference only accepts repo-local paths; URLs and other external references are ignored.
 - `wave adhoc promote` promotes the stored ad-hoc spec into `docs/plans/waves/` instead of re-reading the current project profile.