@chllming/wave-orchestration 0.6.0 → 0.6.1

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 ## Unreleased
 
+## 0.6.1 - 2026-03-22
+
+- Published the post-merge `main` source as `0.6.1` so the default branch, tagged source, and package docs all agree on the current release.
+- Updated shipped package docs and release metadata to advertise `0.6.1` as the current release surface, including the runtime-config reference that still said `0.5.x` during the `0.6.0` cut.
+- No additional runtime behavior changes beyond the `0.6.0` workspace-scoped tmux isolation fix; this patch release aligns the published package with the merged source tree.
+
 ## 0.6.0 - 2026-03-22
 
 ### Breaking Changes

package/README.md

@@ -32,17 +32,17 @@ Representative rolling message board output from a real wave run:
 
 Current release:
 
-- `@chllming/wave-orchestration@0.6.0`
-- Release tag: [`v0.6.0`](https://github.com/chllming/wave-orchestration/releases/tag/v0.6.0)
+- `@chllming/wave-orchestration@0.6.1`
+- Release tag: [`v0.6.1`](https://github.com/chllming/wave-orchestration/releases/tag/v0.6.1)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.6.0`:
+Highlights in `0.6.1`:
 
 - `cont-EVAL` (`E0`) is now a first-class optional eval stage before integration, separate from final `cont-QA` closure.
 - Optional security review now has a dedicated role, report path, and `[wave-security]` closure marker.
 - `wave adhoc plan|run|show|promote` now supports transient operator requests on the same launcher substrate.
-- Starter docs and skills now cover the current `0.6.0` closure, benchmark, security, and provider surfaces.
+- Starter docs and skills now cover the current `0.6.1` closure, benchmark, security, and provider surfaces.
 
 Requirements:
 

package/docs/evals/README.md

@@ -18,14 +18,14 @@ For a full authored wave example that uses these patterns, see [docs/reference/s
 
 ## Migrating From Legacy Evaluator Waves
 
-If your `0.5.4`-era repo still talks about a single `evaluator` role, split that surface before adopting `0.6.0`:
+If your `0.5.4`-era repo still talks about a single `evaluator` role, split that surface before adopting `0.6.1`:
 
 - keep `A0` as `cont-QA` for the final closure verdict and `[wave-gate]`
 - add `E0` only when the wave needs benchmark-driven tuning or service-output evaluation
 - treat `cont-EVAL` as report-only unless the wave explicitly gives `E0` owned implementation files
 - keep `## Eval targets` at the wave level so `cont-EVAL` has an exact contract to satisfy
 
-`cont-EVAL` is not a rename of `cont-QA`. In `0.6.0`, `E0` proves the eval contract before integration, while `A0` still owns the final release verdict after documentation closure.
+`cont-EVAL` is not a rename of `cont-QA`. In `0.6.1`, `E0` proves the eval contract before integration, while `A0` still owns the final release verdict after documentation closure.
 
 ## When To Use Delegated Vs Pinned Targets
 

package/docs/plans/current-state.md

@@ -1,6 +1,6 @@
 # Current State
 
-- The starter workspace in this source repo reflects the `0.6.0` package release surface.
+- The starter workspace in this source repo reflects the `0.6.1` package release surface.
 - 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/`.
 - This source repo is itself kept as an adopted Wave workspace, so `node scripts/wave.mjs doctor --json` should pass from the repo root.

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.6.0` Wave surface.
+Use it as the single reference example for the current `0.6.1` Wave surface.
 
 It intentionally combines more sections than a normal production wave so one file can demonstrate:
 

package/docs/plans/migration.md

@@ -22,9 +22,9 @@ GitHub Packages remains available as an authenticated fallback path, and maintai
 - Fresh `wave init` seeds the starter `skills/` library. `wave init --adopt-existing` records existing repo-owned skill bundles when they are already present, but does not replace or rewrite them.
 - The current runtime expects the post-roadmap model: typed coordination, compiled inboxes, `A8` integration, staged closure, orchestrator-first clarification, and operational runtime policy.
 
-## Upgrading From 0.5.4 To 0.6.0
+## Upgrading From 0.5.4 To 0.6.1
 
-Read `CHANGELOG.md` first, then treat the rest of this page as the manual repo-owned migration checklist for the `0.6.0` release. `wave upgrade` will update package-owned runtime code only; it will not rewrite the docs, prompts, config, or wave files that your repo already owns.
+Read `CHANGELOG.md` first, then treat the rest of this page as the manual repo-owned migration checklist for the `0.6.1` release. `wave upgrade` will update package-owned runtime code only; it will not rewrite the docs, prompts, config, or wave files that your repo already owns.
 
 ### Required Repo Changes
 
@@ -32,7 +32,7 @@ Read `CHANGELOG.md` first, then treat the rest of this page as the manual repo-o
 2. Keep `A0` as the final closure owner that emits both the final verdict and `[wave-gate]`.
 3. Add `E0` only when the wave needs benchmark-driven tuning or service-output evaluation.
 4. Add wave-level `## Eval targets` whenever `cont-EVAL` is present.
-5. Update any starter docs or examples that still describe the pre-`0.6.0` evaluator model.
+5. Update any starter docs or examples that still describe the pre-`0.6.1` evaluator model.
 
 In practice that means checking:
 
@@ -47,7 +47,7 @@ In practice that means checking:
 
 ### Closure And Marker Changes
 
-Live `0.6.0` closure is stricter than `0.5.4`.
+Live `0.6.1` closure is stricter than `0.5.4`.
 
 - `cont-EVAL` must leave a report plus a final `[wave-eval]` marker whose `target_ids` exactly matches the wave contract and whose `benchmark_ids` stays within the benchmark catalog.
 - Security review, when present, must leave a report plus a final `[wave-security]` marker.

package/docs/reference/npmjs-trusted-publishing.md

@@ -2,7 +2,7 @@
 
 This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
 
-The current `0.6.0` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.6.1` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
 
 ## What This Repo Already Does
 
@@ -47,6 +47,6 @@ If this repo later needs private npm dependencies during CI, consider a separate
 1. Confirm [publish-npm.yml](../../.github/workflows/publish-npm.yml) is on the default branch.
 2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
 3. Confirm the package version has been bumped and committed.
-4. Push the release commit and release tag, for example `v0.6.0`.
+4. Push the release commit and release tag, for example `v0.6.1`.
 5. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
 6. Verify the npmjs publish completes successfully for the tagged source.

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

@@ -1,6 +1,6 @@
 # Runtime Configuration Reference
 
-This directory is the canonical reference for executor configuration in Wave `0.5.x`.
+This directory is the canonical reference for executor configuration in Wave `0.6.1`.
 
 Use it when you need the full supported surface for:
 

package/docs/reference/sample-waves.md

@@ -1,18 +1,18 @@
 ---
 title: "Sample Waves"
-summary: "A showcase-first sample wave that demonstrates the current 0.6.0 Wave surface."
+summary: "A showcase-first sample wave that demonstrates the current 0.6.1 Wave surface."
 ---
 
 # Sample Waves
 
-This guide points to one showcase-first sample wave that demonstrates the current `0.6.0` authored Wave surface.
+This guide points to one showcase-first sample wave that demonstrates the current `0.6.1` authored Wave surface.
 
 The example is intentionally denser than a typical production wave. Its job is to teach the current authoring and runtime surface quickly, not to be the smallest possible launch-ready file.
 
 ## Canonical Example
 
 - [Full modern sample wave](../plans/examples/wave-example-live-proof.md)
-  Shows the combined `0.6.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.6.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.
 
 ## What This Example Teaches
 
@@ -32,7 +32,7 @@ The example is intentionally denser than a typical production wave. Its job is t
 
 ## Feature Coverage Map
 
-This sample covers the main surfaces added or hardened for `0.6.0`:
+This sample covers the main surfaces added or hardened for `0.6.1`:
 
 - planner-era authored wave structure
 - cross-runtime `### Skills`

package/package.json

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

package/releases/manifest.json

@@ -2,6 +2,21 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.6.1",
+      "date": "2026-03-22",
+      "summary": "Patch release that aligns the published package with merged main and refreshed 0.6.1 release docs.",
+      "features": [
+        "The package version and release metadata now advertise `0.6.1` consistently across `package.json`, the shipped README, the changelog, and the release manifest.",
+        "Current-surface docs such as runtime configuration, sample waves, eval guidance, migration notes, and npm publishing instructions now point at the `0.6.1` release instead of the earlier `0.6.0` tag.",
+        "This patch release carries forward the `0.6.0` runtime behavior, including the workspace-scoped tmux resource isolation fix that unblocked publish-time CI."
+      ],
+      "manualSteps": [
+        "After upgrading, rerun `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` if you want to verify your repo against the same `0.6.1` package surface documented in this release.",
+        "If you pinned package docs or release references to `0.6.0`, update them to `0.6.1` so your operator guidance matches the published package tag."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.6.0",
       "date": "2026-03-22",