@chllming/wave-orchestration 0.9.0 → 0.9.1

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

@@ -0,0 +1,272 @@
+# Package Publishing Flow
+
+This document describes how this repo publishes `@chllming/wave-orchestration` end to end, including the scripts, workflows, release artifacts, and verification steps involved.
+
+## Overview
+
+The package publish flow has two layers:
+
+1. repo-owned release preparation
+2. tag-triggered registry publishing
+
+Release preparation happens in the repository itself:
+
+- bump `package.json`
+- update release-surface docs and fixtures
+- validate the repo
+- merge the release changes to `main`
+- push a version tag such as `v0.9.1`
+
+Registry publishing happens in GitHub Actions after the tag push:
+
+- [publish-npm.yml](../../.github/workflows/publish-npm.yml) publishes to npmjs
+- [publish-package.yml](../../.github/workflows/publish-package.yml) publishes to GitHub Packages
+- [npmjs-token-publishing.md](./npmjs-token-publishing.md) documents the npm token setup used by `publish-npm.yml`
+
+Both workflows run on tag pushes matching `v*`, and each workflow now fails fast unless `github.ref_name` exactly matches `v${package.json.version}`.
+
+## Release Artifacts That Move Together
+
+These files are part of the release surface and should be updated in the same change when the package version changes:
+
+- `package.json`
+- `README.md`
+- `CHANGELOG.md`
+- `docs/README.md`
+- `docs/plans/current-state.md`
+- `docs/plans/migration.md`
+- `docs/guides/sandboxed-environments.md`
+- `docs/reference/coordination-and-closure.md`
+- `docs/reference/runtime-config/README.md`
+- `releases/manifest.json`
+- `.wave/install-state.json`
+- tracked `.wave/upgrade-history/*`
+- versioned docs such as `docs/guides/recommendations-<version>.md`
+- `AGENTS.md`
+
+This repo treats those files as part of the package-facing release contract, not just internal documentation.
+
+## Scripts And Commands Involved
+
+### Main CLI entrypoint
+
+- `scripts/wave.mjs`
+  Routes install and lifecycle commands into `scripts/wave-orchestrator/install.mjs`.
+
+The lifecycle commands relevant to publishing are:
+
+- `wave doctor`
+- `wave changelog`
+- `wave upgrade`
+- `wave self-update`
+
+### Install and release-state module
+
+- `scripts/wave-orchestrator/install.mjs`
+
+This module owns the local package-lifecycle surfaces:
+
+- `wave init`
+  Seeds or adopts starter workspace files.
+- `wave doctor`
+  Validates that the current workspace matches the installed package expectations.
+- `wave changelog`
+  Reads `releases/manifest.json` and prints release notes.
+- `wave upgrade`
+  Writes `.wave/install-state.json` and a markdown/json report into `.wave/upgrade-history/`.
+- `wave self-update`
+  Updates the dependency in the target workspace, prints changelog deltas, and then runs `wave upgrade`.
+
+### Release-validation commands
+
+These are the normal validation commands before tagging:
+
+```bash
+pnpm test
+pnpm test -- test/wave-orchestrator/release-surface.test.ts
+node scripts/wave.mjs doctor --json
+node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
+```
+
+### Registry verification commands
+
+After publish:
+
+```bash
+npm view @chllming/wave-orchestration version dist-tags --json
+gh run list --limit 10
+```
+
+## End-to-End Flow
+
+### 1. Prepare the release change
+
+Update the release artifacts together, then validate locally.
+
+Typical local flow:
+
+```bash
+pnpm test -- test/wave-orchestrator/release-surface.test.ts
+node scripts/wave.mjs doctor --json
+node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
+```
+
+If the version changed, also refresh the tracked workspace lifecycle state:
+
+```bash
+pnpm exec wave upgrade
+pnpm exec wave changelog --since-installed
+```
+
+In this source repo, `.wave/install-state.json` and tracked `.wave/upgrade-history/` records are intentionally part of the release surface.
+
+### 2. Merge the release change to `main`
+
+This repository protects `main`, so release changes must land through a pull request rather than a direct push.
+
+Typical git flow:
+
+```bash
+git checkout -b release/0.9.1
+git push -u origin release/0.9.1
+gh pr create --base main --head release/0.9.1
+gh pr merge <pr-number> --merge --delete-branch
+```
+
+### 3. Push the release tag
+
+After the release commit is on `main`, push the version tag:
+
+```bash
+git tag v0.9.1
+git push origin v0.9.1
+```
+
+That tag push is the event that starts both publishing workflows.
+
+The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.1`, the pushed tag must be `v0.9.1`.
+
+## GitHub Actions Workflows
+
+### npmjs publish
+
+- workflow: [publish-npm.yml](../../.github/workflows/publish-npm.yml)
+- trigger: push tags matching `v*`
+- runtime: Node 22
+- auth secret: `NPM_TOKEN`
+- publish command:
+
+```bash
+pnpm publish --access public --no-git-checks
+```
+
+The workflow does:
+
+1. `actions/checkout`
+2. `pnpm/action-setup`
+3. `actions/setup-node` with `registry-url: https://registry.npmjs.org`
+4. verify `github.ref_name === "v" + package.json.version`
+5. `pnpm install --frozen-lockfile`
+6. `pnpm test`
+7. `pnpm publish --access public --no-git-checks`
+
+### GitHub Packages publish
+
+- workflow: [publish-package.yml](../../.github/workflows/publish-package.yml)
+- trigger: push tags matching `v*`
+- runtime: Node 22
+- auth token: `GITHUB_TOKEN`
+- publish command:
+
+```bash
+pnpm publish --registry=https://npm.pkg.github.com --no-git-checks
+```
+
+The workflow does:
+
+1. `actions/checkout`
+2. `pnpm/action-setup`
+3. `actions/setup-node` with `registry-url: https://npm.pkg.github.com`
+4. verify `github.ref_name === "v" + package.json.version`
+5. `pnpm install --frozen-lockfile`
+6. `pnpm test`
+7. `pnpm publish --registry=https://npm.pkg.github.com --no-git-checks`
+
+## Verification After Tag Push
+
+Use GitHub Actions first:
+
+```bash
+gh run list --limit 10 --json workflowName,headBranch,headSha,status,conclusion,url
+gh run watch <run-id> --exit-status
+gh run view <run-id> --log-failed
+```
+
+Then verify the public registry:
+
+```bash
+npm view @chllming/wave-orchestration version dist-tags --json
+```
+
+Expected result after a successful publish:
+
+```json
+{
+  "version": "0.9.1",
+  "dist-tags": {
+    "latest": "0.9.1"
+  }
+}
+```
+
+## Repair Flow When Publish Fails
+
+If a tag-triggered publish fails before the package is actually published, the fastest repair path is:
+
+1. fix the repo issue in a new commit
+2. move the tag to the fixed commit
+3. force-push the tag
+4. watch the rerun
+
+Example:
+
+```bash
+git tag -f v0.9.1 <fixed-commit>
+git push origin refs/tags/v0.9.1 --force
+```
+
+Use that only before the package is live on npmjs. Once npmjs has accepted a version, do not try to republish the same version; cut a new version instead.
+
+Common failure classes:
+
+- release-surface drift
+  A versioned doc or fixture did not move with `package.json`.
+- workflow-environment drift
+  The CI runtime differs from the runtime that was locally validated.
+- missing secrets
+  `NPM_TOKEN` is missing or invalid for npmjs.
+- test assumptions on ignored files
+  CI cannot see local-only workstation files such as `.vscode/terminals.json`.
+
+## Security And Secrets
+
+For npmjs publishing:
+
+- keep `NPM_TOKEN` scoped as narrowly as possible
+- use `Read and write` only for the target package or scope
+- rotate the token periodically
+- revoke temporary or emergency tokens after use
+
+GitHub Packages publishing uses the workflow `GITHUB_TOKEN`, so it does not require a separate package-publish secret.
+
+## What This Flow Does Not Do
+
+There is no dedicated local `release` shell script in this repo that bumps versions, tags commits, and publishes in one command.
+
+The flow today is intentionally split:
+
+- repo release preparation is explicit and reviewable
+- package lifecycle state is recorded by `wave upgrade`
+- actual registry publishing is delegated to tag-triggered GitHub Actions
+
+That split keeps release metadata, workspace upgrade history, and package publication visible and auditable.

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

@@ -190,7 +190,7 @@ Practical guidance:
 - prefer `budget.minutes` for normal synthesis, integration, and closure work
 - use generic `budget.turns` as a planning hint, not a hard failure trigger
 - only set `claude.maxTurns` or `opencode.steps` when you deliberately want a hard ceiling for that runtime
-- see [../../guides/recommendations-0.9.0.md](../../guides/recommendations-0.9.0.md) for the recommended `0.9.0` operating stance that combines advisory turn budgets with softer non-proof coordination states
+- see [../../guides/recommendations-0.9.1.md](../../guides/recommendations-0.9.1.md) for the recommended `0.9.1` operating stance that combines advisory turn budgets with softer non-proof coordination states
 
 ## Runtime Pages
 
@@ -202,7 +202,7 @@ Practical guidance:
 
 `wave.config.json` may also declare a `waveControl` block for local-first telemetry delivery.
 
-Packaged defaults in `@chllming/wave-orchestration@0.9.0`:
+Packaged defaults in `@chllming/wave-orchestration@0.9.1`:
 
 - `endpoint`: `https://wave-control.up.railway.app/api/v1`
 - `reportMode`: `metadata-only`

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.9.0 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.9.1 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.9.0` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.9.1` authored Wave surface.
 
 The examples are intentionally denser than typical production waves. Their job is to teach the current authoring and runtime surface quickly, not to be the smallest possible launch-ready files.
 
@@ -17,7 +17,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
   Shows what a good `repo-landed` outcome looks like when one promoted component only closes honestly if desired-state records, reconcile-loop substrate, and cluster-view surfaces land together. It emphasizes maturity discipline, explicit deliverables, and shared-plan closure without drifting into `pilot-live` claims.
 
 - [Full modern sample wave](../plans/examples/wave-example-live-proof.md)
-  Shows the combined `0.9.0` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
+  Shows the combined `0.9.1` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
 
 - [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md)
   Shows the shipped design-role surface: one pre-implementation design steward publishes a design packet, downstream implementation owners read that packet before coding, and normal closure roles still decide final completion. For terminal or operator-surface work, pair that shape with explicit `tui-design` in the design steward's `### Skills`. For the hybrid variant, explicitly give that same design agent implementation-owned paths and the normal implementation contract sections.
@@ -46,7 +46,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened through `0.9.0`:
+Together these samples cover the main surfaces added or hardened through `0.9.1`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -184,7 +184,7 @@ Adapt more aggressively when:
 ## Suggested Reading Order
 
 1. Start with [High-fidelity repo-landed rollout wave](../plans/examples/wave-example-rollout-fidelity.md) if you want the clearest example of good closure-ready wave fidelity for a repo-only outcome.
-2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.0` surface.
+2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.1` surface.
 3. Read [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md) if the task needs a design packet before implementation fan-out.
 4. Read [docs/evals/README.md](../evals/README.md) if you want more background on benchmark target selection.
 5. Read [docs/reference/live-proof-waves.md](./live-proof-waves.md) if you want more detail on proof-first `pilot-live` authoring.

package/docs/reference/skills.md

@@ -124,7 +124,7 @@ Top-level and lane-local skill attachment use the same shape:
 
 Lane-local `lanes.<lane>.skills` extends the global config instead of replacing it.
 
-Optional design workers in the shipped `0.9.0` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
+Optional design workers in the shipped `0.9.1` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
 
 Long-running agents that should stay resident and react only to orchestrator signal changes can add `signal-hygiene` explicitly in `### Skills`. That bundle is not auto-attached and is not meant for normal one-shot implementation agents.
 

package/docs/roadmap.md

@@ -1,226 +1,68 @@
 # Wave Orchestrator Roadmap
 
-Wave Orchestrator should keep wave markdown as the authored plan surface, but it needs a higher planning-fidelity bar and a better authoring loop.
+This roadmap is intentionally short and current. The older planner-foundation and ad-hoc-run phase list has been removed because that work no longer describes the actual shipping direction for this package.
 
-The same planning and execution substrate should also support ad-hoc operator requests without forcing every one-off task into the long-lived numbered roadmap sequence.
+## Current Release: 0.9.1
 
-The target is the level of specificity shown in [Wave 7](/home/coder/slowfast.ai/docs/plans/waves/wave-7.md): explicit sequencing, hard requirements, exact validation commands, earlier-wave inputs, concrete ownership, and clear closure rules. This roadmap focuses on how to get this repo there without replacing the current architecture.
+`0.9.1` is the runtime-hardening release.
 
-## Current Position
+It focuses on:
 
-The repository already has the right runtime substrate:
+- detached process-backed agent execution instead of tmux-heavy live execution
+- lower steady-state memory pressure and less terminal churn during long runs
+- better behavior in constrained sandboxes such as LEAPclaw, OpenClaw, Nemoshell, and Docker-based operator environments
+- a safer `submit -> supervise -> status/wait -> attach` control path for long-running agentic orchestration
+- tighter supervisor recovery, progress journaling, and closure/retry correctness
 
-- lane-scoped state under `.tmp/`
-- wave parsing and validation
-- role-based execution with cont-qa, integration, and documentation stewards
-- executor profiles and lane runtime policy
-- compiled inboxes, ledgers, docs queues, dependency snapshots, and trace bundles
-- orchestrator-first clarification handling and human feedback workflows
+## Next Release: Final Planned Feature Release On This Line
 
-The biggest remaining gap is not runtime execution. It is authored planning quality, the tooling around planning, and a lower-friction entry point for ad-hoc work that still preserves the same coordination and trace surfaces.
+The next planned release after `0.9.1`, aside from bug fixes and release-surface maintenance, is the final feature release for this standalone Node-based line.
 
-## Planning Fidelity Target
+That release is focused on Wave Control authentication:
 
-Every serious wave should be able to answer these questions before launch:
+- token-based auth for `wave-control`
+- web auth for the Wave Control operator surface
+- a cleaner control-plane boundary between the local orchestrator runtime and authenticated operator access
+- documentation and setup guidance for protected control surfaces in local, containerized, and hosted environments
 
-- What earlier waves or artifacts are prerequisites?
-- What exact components are being promoted and why now?
-- What is the required runtime mix and fallback policy?
-- Which deploy environment or infra substrate is in scope?
-- Is the run `oversight` or `dark-factory`?
-- What exact validation commands must pass?
-- What exact artifact closes the role?
+After that release, this package should move into maintenance mode:
 
-Generated waves and transient ad-hoc runs should default to these sections when relevant:
+- bug fixes
+- compatibility updates
+- documentation updates
+- release-surface alignment work
 
-- sequencing note
-- reference rule or source-of-truth note
-- project bootstrap context
-- deploy environments
-- component promotions
-- Context7 defaults
-- per-agent required context
-- earlier-wave outputs to read
-- requirements
-- validation
-- output or closure contract
+## Strategic Direction: LEAPclaw Execution Model
 
-## Phase 1: Planner Foundation
+After the Wave Control auth release, the main execution roadmap moves away from expanding this Node runtime and toward the LEAPclaw execution model.
 
-Status: shipped in `0.5.4`.
+The target shape is:
 
-- Add saved project bootstrap memory in `.wave/project-profile.json` for the implicit default project, with project-scoped profiles under `.wave/projects/<projectId>/project-profile.json` for explicit monorepo projects.
-- Ask once whether the repo is a new project and keep that answer for future drafts.
-- Add `wave project setup` and `wave project show`.
-- Add interactive `wave draft` that writes:
-  - `docs/plans/waves/specs/wave-<n>.json`
-  - `docs/plans/waves/wave-<n>.md`
-- Treat the JSON draft spec as the canonical authoring artifact and render markdown from it.
-- Keep generated waves fully compatible with the current parser and launcher.
-- Add `wave launch --terminal-surface vscode|tmux|none`.
-- Support a tmux-only operator mode that never touches `.vscode/terminals.json`.
+- LEAPclaw-native execution semantics for agent orchestration and management
+- Go-based runtime ownership for the long-running execution layer
+- Temporal-backed workflow and recovery coordination
+- LEAPclaw nodes as the durable execution substrate for orchestrated agent work
+- Wave Control acting as an authenticated control and observability surface rather than the long-term primary execution engine
 
-Why first:
+This direction matches the broader local platform work in the sibling `slowfast.ai` repository, where the support-service and runtime direction already points toward LEAPclaw support services, Go runtime ownership, and Temporal-backed orchestration.
 
-- Better planning is the highest-leverage missing piece.
-- The repo already has strong runtime and closure machinery.
-- Project memory removes repeated setup questions and gives future planner steps a durable baseline.
+## Future Standalone Runtime Direction
 
-## Phase 2: Ad-Hoc Task Runs
+For future standalone Wave Orchestrator versions, the preferred implementation direction is the Rust runtime at:
 
-The orchestrator should support operator-driven one-off requests without requiring the user to author or commit a numbered roadmap wave first.
+- `https://github.com/chllming/agent-wave-orchestrator`
 
-CLI target:
+That line is expected to carry:
 
-- `wave adhoc plan --task "..."`
-- `wave adhoc run --task "..." [--task "..."]`
-- `wave adhoc list`
-- `wave adhoc show --run <id>`
-- `wave adhoc promote --run <id> --wave <n>`
+- its own runtime implementation
+- its own terminal-native/TUI operator surface
+- the longer-term standalone execution model once the Node package settles into maintenance mode
 
-Behavior:
+## Practical Guidance
 
-- accept one or more free-form task requests
-- normalize them into a single transient plan or spec
-- synthesize the worker roles needed for the request while still preserving cont-qa, integration, and documentation closure when relevant
-- run that transient plan through the existing launcher, coordination, inbox, ledger, docs queue, integration, and trace machinery
-- keep ad-hoc runs logged, inspectable, and replayable with the same basic operator surfaces as roadmap waves
-- route shared-plan documentation deltas into the canonical shared docs queue, plus an ad-hoc closure report for the run
-- treat only repo-local paths as ownership hints and ignore external references such as URLs
+For this repository, the practical sequence is:
 
-Storage model:
-
-- do not write ad-hoc runs into the canonical numbered wave sequence under `docs/plans/waves/`
-- store the original request, generated spec, rendered markdown, and final result under `.wave/adhoc/<projectId>/runs/<run-id>/` for explicit projects, while the implicit default project keeps the legacy layout
-- keep runtime state isolated under `.tmp/<lane>-wave-launcher/adhoc/<run-id>/`
-- extend trace metadata with `runKind: adhoc` and `runId`
-
-Design constraints:
-
-- reuse the planner and launcher instead of building a second runtime
-- treat ad-hoc as a transient single-run execution unit, not a fake roadmap wave
-- do not let ad-hoc completion mutate normal `completedWaves` lane state
-- give `wave coord`, `wave feedback`, and future replay or reporting flows a way to target `--run <id>`
-- promote numbered roadmap artifacts from the stored ad-hoc spec instead of recomputing them from the current project profile
-
-Why this matters:
-
-- many real operator requests are one-off bugfix, investigation, doc, infra, or release tasks
-- the framework's coordination, closure, and traceability should apply to ad-hoc work too
-- isolated ad-hoc runs preserve auditability without polluting the long-lived roadmap
-
-## Phase 3: Forward Replanning
-
-Add `wave update --from-wave <n>`.
-
-Rules:
-
-- closed waves are immutable
-- the current open wave and later waves may be regenerated
-- replanning must record what changed and why
-- new repo state, new user intent, and refreshed research may all trigger a replan
-
-Outputs:
-
-- updated draft JSON specs
-- regenerated markdown waves
-- a short replan summary for operator review
-
-Why this matters:
-
-- multi-wave plans drift as code lands
-- research and infra assumptions change
-- forward-only replanning preserves auditability without pretending older waves never existed
-
-## Phase 4: Infra and Deploy-Aware Planning
-
-Infra and deploy roles need typed environment context, not free-form prompt notes only.
-
-Project profile should support typed deploy providers with a `custom` escape hatch:
-
-- `railway-mcp`
-- `railway-cli`
-- `docker-compose`
-- `kubernetes`
-- `ssh-manual`
-- `custom`
-
-Planner-generated infra or deploy roles should know:
-
-- which environment they own
-- which substrate is authoritative
-- what credentials or executors are expected
-- what validation commands prove readiness
-- what rollback or recovery guidance applies
-
-This is especially important for `dark-factory` mode. Fully autonomous infra work should require stronger environment modeling than human-overseen work.
-
-## Phase 5: Oversight and Dark-Factory Modes
-
-Execution posture must be explicit plan data.
-
-Default:
-
-- `oversight`
-
-Opt-in:
-
-- `dark-factory`
-
-`oversight` means:
-
-- human checkpoints remain normal for live mutation, deploy, release, or risky infra work
-- the planner should generate explicit review gates
-
-`dark-factory` means:
-
-- the wave is intended to run end-to-end without routine human approvals
-- deploy environment, validation, rollback, and closure signals must be stricter
-- missing environment context is a planning error, not a runtime surprise
-
-## Phase 6: Coordination and Integration Upgrades
-
-The runtime already has strong coordination primitives, but the roadmap should still push these areas:
-
-- keep the canonical authority set explicit and the markdown board as a rendered view
-- keep compiled per-agent inboxes and shared summaries central to prompt construction
-- strengthen the integration steward output as the single closure-ready synthesis artifact
-- add `wave lint` for ownership, component promotion, runtime mix, deploy environment, and closure completeness
-- expand replay scenarios for replanning, autonomy modes, and infra-heavy waves
-
-## Additional Features Worth Scheduling
-
-- template packs for common wave shapes: implementation, QA, infra, release, migration
-- doc-delta extraction plus changelog or release-note queues when waves change public behavior
-- executor and credential preflight checks before launch
-- project-profile-aware defaults for lane, template, terminal surface, and oversight mode
-- richer branch and PR guidance in draft specs when the wave is release or deploy oriented
-- benchmark scenarios that compare oversight vs dark-factory outcomes
-
-## Research Notes
-
-The direction above is consistent with the local source set and the current external references:
-
-- OpenAI, “Harness engineering: leveraging Codex in an agent-first world”
-  - repository-local plans and environment design matter more than prompt-only control
-- Anthropic, “Effective harnesses for long-running agents”
-  - first-run initialization and durable progress artifacts are critical
-- DOVA
-  - deliberation-first orchestration and transparent intermediate state support better refinement loops
-- Silo-Bench
-  - communication alone is not enough; integration quality is the real bottleneck
-- Evaluating AGENTS.md
-  - repository-level context files help, but they should complement executable and versioned planning artifacts rather than replace them
-
-## Immediate Recommendation
-
-The next shipping sequence should be:
-
-1. planner foundation
-2. ad-hoc task runs on the same substrate
-3. forward replanning
-4. typed infra and deploy planning
-5. explicit oversight vs dark-factory workflows
-6. stronger linting, replay, and benchmark coverage
-
-That sequence keeps the current harness intact while making planning, execution posture, and infra ownership much more explicit and durable.
+1. Ship `0.9.1` with the sandbox/runtime hardening and aligned docs.
+2. Ship the Wave Control token/web auth release as the last planned feature release on this Node line.
+3. Keep this package maintained for bug fixes, compatibility, and release-surface sync.
+4. Move long-term execution investment to the LEAPclaw + Go + Temporal architecture and the Rust standalone runtime.

package/package.json

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

package/releases/manifest.json

@@ -2,6 +2,25 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.9.1",
+      "date": "2026-03-29",
+      "summary": "Detached process-backed agent execution, sandbox-safe supervisor hardening, lower memory pressure, and 0.9.1 release-surface alignment.",
+      "features": [
+        "Live agent execution now uses detached process runners by default instead of per-agent tmux execution sessions, which reduces tmux churn and lowers memory use during wide orchestration bursts while keeping tmux as an optional dashboard projection layer.",
+        "The sandbox-facing path is now `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach`, with exact-context lookup, read-side launcher-status reconciliation, progress journaling, degraded-run handling, and log-follow attach behavior suited to LEAPclaw, OpenClaw, Nemoshell, and similar short-lived exec environments.",
+        "Supervisor recovery now relies on run-owned terminal artifacts and finalized progress instead of lane-global completion history, preserving the correct remaining wave range and final active wave during multi-wave reruns and launcher-loss recovery.",
+        "Ordinary runs, closure runs, and resident orchestrator runs now all preserve process-runtime metadata for timeout and cleanup, while process-backed resident orchestrators terminate cleanly and rate-limit retry detection stays scoped to the current attempt output.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target.",
+        "A dedicated setup guide now ships for sandboxed and containerized operation, including Nemoshell and Docker guidance, while README, migration docs, terminal-surface docs, runtime-config docs, coordination docs, and the renamed recommendations guide `docs/guides/recommendations-0.9.1.md` now describe the same sandbox-safe release surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.9.1` release surface.",
+        "If your repo runs Wave inside LEAPclaw, OpenClaw, Nemoshell, Docker, or another short-lived exec sandbox, move long-running orchestration to `wave supervise`, use `wave submit/status/wait/attach` from disposable clients, and set Codex sandbox defaults in `wave.config.json` instead of relying on per-command overrides.",
+        "If your repo copied starter docs or runbooks, sync `README.md`, `docs/README.md`, `docs/plans/current-state.md`, `docs/plans/migration.md`, `docs/reference/coordination-and-closure.md`, `docs/reference/runtime-config/README.md`, `docs/guides/sandboxed-environments.md`, `docs/guides/terminal-surfaces.md`, and `docs/guides/recommendations-0.9.1.md` so local guidance matches the packaged release."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.9.0",
       "date": "2026-03-28",