@chllming/wave-orchestration 0.7.0 → 0.7.1

package/docs/reference/cli-reference.md

@@ -0,0 +1,547 @@
+---
+title: "CLI Reference"
+summary: "Complete syntax reference for all wave CLI commands, flags, and operator surfaces."
+---
+
+# CLI Reference
+
+Complete syntax for every `wave` command. All commands use `pnpm exec wave` as the entry point.
+
+## wave launch
+
+Launch waves for execution.
+
+```
+wave launch [options]
+```
+
+| Flag | Default | Description |
+|------|---------|-------------|
+| `--lane <name>` | `main` | Lane name |
+| `--start-wave <n>` | `0` | First wave to launch |
+| `--end-wave <n>` | last available | Last wave to launch |
+| `--auto-next` | off | Start from next unfinished wave and continue |
+| `--resume-control-state` | off | Preserve the prior auto-generated relaunch plan instead of treating the launch as a fresh wave start |
+| `--executor <id>` | lane config | Default executor: `codex`, `claude`, `opencode`, `local` |
+| `--codex-sandbox <mode>` | `danger-full-access` | Codex sandbox isolation level |
+| `--timeout-minutes <n>` | `60` | Max minutes to wait per wave |
+| `--max-retries-per-wave <n>` | `3` | Relaunch failed agents per wave |
+| `--agent-rate-limit-retries <n>` | `3` | Per-agent retries for 429 errors |
+| `--agent-rate-limit-base-delay-seconds <n>` | `1` | Base exponential backoff for 429 |
+| `--agent-rate-limit-max-delay-seconds <n>` | `60` | Max backoff delay for 429 |
+| `--agent-launch-stagger-ms <n>` | `250` | Delay between agent launches |
+| `--terminal-surface <mode>` | configured | `tmux`, `vscode`, or `none` |
+| `--no-dashboard` | off | Disable per-wave tmux dashboard |
+| `--cleanup-sessions` | on | Kill lane tmux sessions after each wave |
+| `--keep-sessions` | off | Keep lane tmux sessions |
+| `--keep-terminals` | off | Keep temporary terminal entries |
+| `--orchestrator-id <id>` | generated | Stable orchestrator identity |
+| `--resident-orchestrator` | off | Launch long-running non-owning orchestrator session |
+| `--no-telemetry` | off | Disable Wave Control event publication |
+| `--no-context7` | off | Disable Context7 prefetch |
+| `--dry-run` | off | Parse and validate only; do not execute |
+| `--reconcile-status` | off | Reconcile run-state from status files and exit |
+| `--state-file <path>` | default | Path to run-state JSON |
+| `--manifest-out <path>` | default | Write parsed manifest JSON |
+
+## wave autonomous
+
+Continuous wave execution without manual wave-by-wave invocation.
+
+```
+wave autonomous [options]
+```
+
+| Flag | Default | Description |
+|------|---------|-------------|
+| `--lane <name>` | `main` | Lane name |
+| `--executor <id>` | lane config | `codex`, `claude`, or `opencode` (not `local`) |
+| `--codex-sandbox <mode>` | `danger-full-access` | Codex sandbox mode |
+| `--timeout-minutes <n>` | `60` | Per-wave timeout passed to launcher |
+| `--max-retries-per-wave <n>` | `3` | Per-wave relaunches inside launcher |
+| `--max-attempts-per-wave <n>` | `1` | External attempts per wave |
+| `--agent-rate-limit-retries <n>` | `3` | Per-agent 429 retries |
+| `--agent-rate-limit-base-delay-seconds <n>` | `1` | Base 429 backoff |
+| `--agent-rate-limit-max-delay-seconds <n>` | `60` | Max 429 backoff |
+| `--agent-launch-stagger-ms <n>` | `250` | Delay between agent launches |
+| `--orchestrator-id <id>` | `<lane>-autonomous` | Orchestrator identity |
+| `--resident-orchestrator` | off | Launch resident orchestrator for each wave |
+| `--dashboard` | off | Enable dashboards |
+| `--keep-sessions` | off | Keep tmux sessions between waves |
+| `--keep-terminals` | off | Keep terminal entries between waves |
+
+## wave control
+
+Unified operator control surface. Preferred over legacy `wave coord`, `wave retry`, and `wave proof`.
+
+### wave control status
+
+Read-only view: blocking edges, logical agent state, tasks, dependencies, rerun intent, proof bundles, and next timers.
+
+When a launcher attempt is already running, `wave control status` treats that active attempt as the authoritative current fan-out. Older relaunch plans or unrelated closure blockers remain visible in the payload, but they do not override the live attempt view.
+
+```
+wave control status --lane <lane> --wave <n> [--agent <id>] [--run <id>] [--json]
+```
+
+### wave control telemetry
+
+Inspect and deliver the local Wave Control event queue.
+
+```
+wave control telemetry status --lane <lane> [--run <id>] [--json]
+wave control telemetry flush  --lane <lane> [--run <id>] [--json]
+```
+
+### wave control task
+
+Operator task surface for coordination records.
+
+**Create a task:**
+
+```
+wave control task create \
+  --lane <lane> --wave <n> --agent <id> \
+  --kind <kind> --summary "<text>" \
+  [--detail "<text>"] [--target <agent-or-capability>] \
+  [--priority normal|high] [--depends-on <id>] \
+  [--artifact <ref>] [--operator <name>] [--json]
+```
+
+Valid `--kind` values: `request`, `blocker`, `clarification`, `handoff`, `evidence`, `claim`, `decision`, `human-input`.
+
+Only `request`, `blocker`, `clarification`, `human-input`, and `escalation` are treated as blocking edges by `wave control status`. The rest (`handoff`, `evidence`, `claim`, `decision`) are informational.
+
+**List tasks:**
+
+```
+wave control task list --lane <lane> --wave <n> [--agent <id>] [--json]
+```
+
+**Get a single task:**
+
+```
+wave control task get --lane <lane> --wave <n> --id <task-id> [--json]
+```
+
+**Act on a task:**
+
+```
+wave control task act <action> \
+  --lane <lane> --wave <n> --id <task-id> \
+  [--detail "<text>"] [--operator <name>] [--json]
+```
+
+Actions:
+
+| Action | Extra flags | Effect |
+|--------|------------|--------|
+| `start` | — | Mark task in-progress |
+| `resolve` | `[--detail]` | Close the task as resolved |
+| `dismiss` | `[--detail]` | Close the task as not applicable |
+| `cancel` | `[--detail]` | Cancel the task |
+| `reassign` | `--to <agent>` | Supersede the original, reroute to a new agent |
+| `answer` | `--response "<text>"` | Answer a human-input or escalation task |
+| `escalate` | `[--detail]` | Escalate to human feedback queue |
+
+**Operator answer example** (responding to a human-input escalation):
+
+```bash
+pnpm exec wave control task act answer \
+  --lane main --wave 4 --id escalation-clarify-a7-rollout \
+  --response "The rollout strategy is canary-then-full. Use the Railway MCP health endpoint." \
+  --operator ops-lead
+```
+
+### wave control rerun
+
+Targeted rerun intent with agent selection, reuse control, and component invalidation.
+
+**Request a rerun:**
+
+```
+wave control rerun request \
+  --lane <lane> --wave <n> \
+  [--agent <id> ...] \
+  [--clear-reuse <id> ...] [--preserve-reuse <id> ...] \
+  [--invalidate-component <id> ...] \
+  [--resume-cursor <cursor>] \
+  [--reuse-attempt <id> ...] [--reuse-proof <id> ...] \
+  [--reuse-derived-summaries true|false] \
+  [--requested-by <name>] [--reason "<text>"] [--json]
+```
+
+`--agent` is repeatable or comma-separated. At least one of `--agent` or `--resume-cursor` is required.
+
+**Get active rerun request:**
+
+```
+wave control rerun get --lane <lane> --wave <n> [--json]
+```
+
+**Clear rerun request:**
+
+```
+wave control rerun clear --lane <lane> --wave <n>
+```
+
+### wave control proof
+
+Authoritative proof bundle lifecycle (active → superseded → revoked).
+
+**Register a proof bundle:**
+
+```
+wave control proof register \
+  --lane <lane> --wave <n> --agent <id> \
+  --artifact <path> [--artifact <path> ...] \
+  [--component <id[:level]> ...] \
+  [--authoritative] [--satisfy-owned-components] \
+  [--completion <level>] [--durability <level>] [--proof-level <level>] \
+  [--doc-delta <state>] [--operator <name>] [--detail "<text>"] [--json]
+```
+
+**Get proof bundles:**
+
+```
+wave control proof get --lane <lane> --wave <n> [--agent <id>] [--id <bundle-id>] [--json]
+```
+
+**Supersede a bundle** (register new evidence and mark the old bundle superseded):
+
+```
+wave control proof supersede \
+  --lane <lane> --wave <n> --id <old-bundle-id> \
+  --agent <id> --artifact <path> [--artifact <path> ...] \
+  [same options as register] [--json]
+```
+
+**Revoke a bundle:**
+
+```
+wave control proof revoke \
+  --lane <lane> --wave <n> --id <bundle-id> \
+  [--operator <name>] [--detail "<text>"] [--json]
+```
+
+## wave coord
+
+Coordination log access. Legacy surface; prefer `wave control task` for new work.
+
+**Post a coordination record:**
+
+```
+wave coord post \
+  --lane <lane> --wave <n> --agent <id> \
+  --kind <kind> --summary "<text>" \
+  [--detail "<text>"] [--target <agent>] \
+  [--priority normal|high] [--depends-on <id>] \
+  [--artifact <ref>] [--status <status>] [--dry-run]
+```
+
+**Show materialized coordination state:**
+
+```
+wave coord show --lane <lane> --wave <n> [--dry-run] [--json]
+```
+
+**Render markdown board from JSONL log:**
+
+```
+wave coord render --lane <lane> --wave <n> [--dry-run]
+```
+
+**Compile shared summary and agent inbox:**
+
+```
+wave coord inbox --lane <lane> --wave <n> --agent <id> [--dry-run]
+```
+
+**Explain why blocked or retrying:**
+
+```
+wave coord explain --lane <lane> --wave <n> [--agent <id>] [--json]
+```
+
+**Act on a coordination record:**
+
+```
+wave coord act <operation> --lane <lane> --wave <n> --id <id> [options]
+```
+
+| Operation | Extra flags | Effect |
+|-----------|------------|--------|
+| `resolve` | `[--detail]` | Resolve the record |
+| `dismiss` | `[--detail]` | Dismiss the record |
+| `reroute` | `--to <agent>` | Reroute to another agent |
+| `reassign` | `--to <agent>` | Reassign to another agent |
+| `escalate` | `[--detail]` | Escalate to human feedback |
+| `answer-human` | `--response "<text>"` | Answer a human feedback request |
+
+All `wave coord` subcommands accept `--run <id>` as a shorthand that sets the lane and wave to 0 for ad-hoc runs.
+
+## wave feedback
+
+Human feedback request queue. Final escalation layer after orchestrator-first triage.
+
+**Create a feedback request:**
+
+```
+wave feedback ask \
+  --lane <lane> --wave <n> --agent <id> \
+  --question "<text>" [--context "<text>"] \
+  [--orchestrator-id <id>] [--wait] [--timeout-seconds <n>]
+```
+
+**Respond to a feedback request:**
+
+```
+wave feedback respond \
+  --id <request-id> --response "<text>" \
+  [--operator <name>] [--force]
+```
+
+`--force` overrides a previously answered request.
+
+**List feedback requests:**
+
+```
+wave feedback list [--lane <lane>] [--wave <n>] [--agent <id>] [--pending] [--json]
+```
+
+**Watch for new requests:**
+
+```
+wave feedback watch [--lane <lane>] [--wave <n>] [--agent <id>] [--pending] [--refresh-ms <n>]
+```
+
+**Show a single request:**
+
+```
+wave feedback show --id <request-id>
+```
+
+## wave dep
+
+Cross-lane dependency management.
+
+**Post a dependency ticket:**
+
+```
+wave dep post \
+  --owner-lane <lane> --requester-lane <lane> \
+  --owner-wave <n> --requester-wave <n> \
+  --agent <id> --summary "<text>" \
+  [--detail "<text>"] [--target <agent>] \
+  [--artifact <ref>] [--priority normal|high] \
+  [--closure-condition "<text>"] [--required] [--json]
+```
+
+`--required` means the dependency blocks autonomous launch and lane finalization.
+
+**Show dependencies:**
+
+```
+wave dep show --lane <lane> [--wave <n>] [--json]
+```
+
+**Resolve a dependency:**
+
+```
+wave dep resolve --lane <lane> --id <id> --agent <id> [--detail "<text>"] [--status resolved|closed]
+```
+
+**Render dependency snapshot:**
+
+```
+wave dep render --lane <lane> [--wave <n>] [--json]
+```
+
+## wave benchmark
+
+Local and external benchmark execution.
+
+**List local cases:**
+
+```
+wave benchmark list [--json]
+```
+
+**Show a case definition:**
+
+```
+wave benchmark show --case <id> [--json]
+```
+
+**Run local benchmark cases:**
+
+```
+wave benchmark run [--case <id>] [--family <id>] [--benchmark <id>] [--arm <id>] [--output-dir <path>] [--json]
+```
+
+**List external adapters:**
+
+```
+wave benchmark adapters [--json]
+```
+
+**External benchmark commands:**
+
+```
+wave benchmark external-list [--adapter <id>] [--json]
+wave benchmark external-show --adapter <id> --manifest <path> [--json]
+wave benchmark external-run --adapter <id> --manifest <path> [--arm <id>] [--model <id>] [options]
+wave benchmark external-pilots --adapter <id> [--json]
+```
+
+## wave retry
+
+Legacy retry control. Prefer `wave control rerun`.
+
+**Show active retry override:**
+
+```
+wave retry show --lane <lane> --wave <n> [--json]
+```
+
+**Apply a retry override:**
+
+```
+wave retry apply --lane <lane> --wave <n> \
+  [--agent <id> ...] \
+  [--clear-reuse <id> ...] [--preserve-reuse <id> ...] \
+  [--resume-phase <phase>] \
+  [--requested-by <name>] [--reason "<text>"] [--json]
+```
+
+Requires either `--agent` or `--resume-phase`.
+
+**Clear retry override:**
+
+```
+wave retry clear --lane <lane> --wave <n>
+```
+
+## wave proof
+
+Legacy proof registration. Prefer `wave control proof`.
+
+**Show proof registry:**
+
+```
+wave proof show --lane <lane> --wave <n> [--agent <id>] [--json]
+```
+
+**Register proof:**
+
+```
+wave proof register --lane <lane> --wave <n> --agent <id> \
+  --artifact <path> [--artifact <path> ...] \
+  [--component <id[:level]> ...] \
+  [--authoritative] [--satisfy-owned-components] \
+  [--completion <level>] [--durability <level>] [--proof-level <level>] \
+  [--doc-delta <state>] [--operator <name>] [--detail "<text>"] [--json]
+```
+
+## wave local
+
+Smoke executor for testing prompt generation and closure signal extraction.
+
+```
+wave local --prompt <path> [--log <path>] [--status <path>]
+```
+
+## wave dashboard
+
+Live dashboard viewer.
+
+```
+wave dashboard --dashboard-file <path> [--lane <lane>] [--message-board <path>] [--watch] [--refresh-ms <n>]
+wave dashboard --lane <lane> --attach current|global
+```
+
+## Workspace Commands
+
+**Initialize workspace:**
+
+```
+wave init [--adopt-existing]
+```
+
+**Upgrade workspace after package update:**
+
+```
+wave upgrade
+```
+
+**One-command package update:**
+
+```
+wave self-update
+```
+
+**Show changelog since installed version:**
+
+```
+wave changelog [--since-installed]
+```
+
+**Health check:**
+
+```
+wave doctor [--json]
+```
+
+## Planner Commands
+
+**Setup project profile:**
+
+```
+wave project setup
+wave project show [--json]
+```
+
+**Draft waves:**
+
+```
+wave draft --wave <n> [--template implementation|qa|infra|release]
+wave draft --agentic --task "<description>" --from-wave <n>
+wave draft --show-run <run-id>
+wave draft --apply-run <run-id>
+```
+
+## Ad-Hoc Task Commands
+
+**Plan and run ad-hoc tasks:**
+
+```
+wave adhoc plan --task "<description>"
+wave adhoc run --task "<description>" [--yes] [--executor <id>]
+wave adhoc list [--json]
+wave adhoc show --run <id> [--json]
+wave adhoc promote --run <id> --wave <n>
+```
+
+## Common Patterns
+
+### Lane and wave targeting
+
+Most coordination commands accept `--lane` (default: `main`) and `--wave` (required). For ad-hoc runs, use `--run <id>` which sets the lane and defaults wave to 0.
+
+### JSON output
+
+Most commands accept `--json` for machine-readable output.
+
+### Operator attribution
+
+Commands that modify state accept `--operator <name>` (default: `human-operator`) for audit trails.
+
+### Repeatable flags
+
+Flags like `--agent`, `--artifact`, `--component`, `--target`, and `--depends-on` can be repeated or comma-separated:
+
+```bash
+# These are equivalent:
+wave control rerun request --lane main --wave 0 --agent A2 --agent A7
+wave control rerun request --lane main --wave 0 --agent A2,A7
+```

package/docs/reference/coordination-and-closure.md

@@ -164,7 +164,7 @@ What happens next:
 - that assignment is written into the assignment snapshot
 - the shared summary and A8 inbox now show the open helper work
 
-`wave control task list` and `wave control task get` surface both blocking and informative coordination kinds. `wave control status` only turns `request`, `blocker`, `clarification-request`, `human-feedback`, and `human-escalation` into blocking task edges; plain `handoff`, `evidence`, `claim`, and `decision` records stay visible without falsely blocking the owner.
+`wave control task list` and `wave control task get` surface both blocking and informative coordination kinds. `wave control status` only turns `request`, `blocker`, `clarification-request`, `human-feedback`, and `human-escalation` into blocking task edges; plain `handoff`, `evidence`, `claim`, and `decision` records stay visible without falsely blocking the owner. When a launcher attempt is already running, status scopes the top-level blocking edge to that active attempt instead of letting stale relaunch metadata or unrelated closure tasks dominate the wave-level view.
 
 ### Step 3: Why A1 Can Be Done But The Wave Is Still Blocked
 

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.7.0` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.7.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.7.0`.
+4. Push the release commit and release tag, for example `v0.7.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

@@ -141,7 +141,7 @@ Wave writes runtime artifacts here:
 
 Common files:
 
-- `launch-preview.json`: resolved invocation lines, env vars, retry mode, and structured attempt/turn-limit metadata
+- `launch-preview.json`: resolved invocation lines, env vars, retry mode, and structured attempt/turn-limit metadata for both dry-run and live launches
 - `skills.resolved.md`: compact metadata-first skill catalog for the selected agent and runtime
 - `skills.expanded.md`: full canonical/debug skill payload with `SKILL.md` bodies and adapters
 - `skills.metadata.json`: resolved skill ids, activation metadata, permissions, hashes, and generated artifact paths
@@ -161,7 +161,7 @@ Runtime-specific delivery:
 - OpenCode injects the compact catalog into `opencode.json` and attaches `skill.json`, `SKILL.md`, the selected adapter, and recursive `references/**` files through `--file`.
 - Local keeps skills prompt-only.
 
-`launch-preview.json` also records the resolved skill metadata plus a `limits` section. For Claude and OpenCode, that section reports the known turn ceiling and whether it came from the runtime-specific setting or generic `budget.turns`. For Codex, it explicitly records that Wave emitted no turn-limit flag and that any effective ceiling may come from the selected Codex profile or upstream runtime.
+`launch-preview.json` also records the resolved skill metadata plus a `limits` section. For Claude and OpenCode, that section reports the known turn ceiling and whether it came from the runtime-specific setting or generic `budget.turns`. For Codex, it explicitly records that Wave emitted no turn-limit flag and that any effective ceiling may come from the selected Codex profile or upstream runtime. If a live Codex run later terminates with a visible `Reached max turns (N)` log line, Wave appends that observed ceiling back into the live `launch-preview.json` as runtime evidence rather than pretending Wave set it.
 
 ## Recommended Validation Path
 

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

@@ -21,6 +21,7 @@ Wave launches Codex with `codex exec` and pipes the generated task prompt throug
 
 - There is no `executors.codex.model` key today. Use profile `model` or per-agent `model`.
 - Generic `budget.turns` does not set a Codex turn limit. If Codex stops on a turn ceiling, that limit came from the selected Codex profile or upstream Codex runtime, not from a Wave-emitted CLI flag.
+- Live runs still write `launch-preview.json`. If Codex later logs `Reached max turns (N)`, Wave records that observed ceiling under `limits.observedTurnLimit` with source `runtime-log`.
 - `codex.images`, `codex.add_dirs`, and `codex.config` accept either a string array in `wave.config.json` or a comma-separated list in a wave file.
 - Relative paths are passed to Codex relative to the repository root because Wave launches the executor from the repo workspace.
 
@@ -78,4 +79,4 @@ For a dry run, inspect:
 - `launch-preview.json` for the final `codex exec` command
 - any referenced prompt file under `.tmp/<lane>-wave-launcher/dry-run/prompts/`
 
-The preview records the exact `--profile`, repeated `-c`, `--image`, and `--add-dir` flags that Wave would use in a live launch. It also includes a `limits` block that makes Wave's Codex visibility explicit: `turnLimitSource: "not-set-by-wave"` means Wave emitted no Codex turn-limit flag, so any effective ceiling is external to the Wave CLI invocation.
+The preview records the exact `--profile`, repeated `-c`, `--image`, and `--add-dir` flags that Wave would use in a live launch. It also includes a `limits` block that makes Wave's Codex visibility explicit: `turnLimitSource: "not-set-by-wave"` means Wave emitted no Codex turn-limit flag, so any effective ceiling is external to the Wave CLI invocation. On a live run, that same preview file may later gain `observedTurnLimit` if the Codex runtime reports the ceiling in its log output.

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the current 0.7.0 Wave surface."
+summary: "Showcase-first sample waves that demonstrate the current 0.7.1 Wave surface."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the current `0.7.0` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the current `0.7.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.
 
@@ -15,7 +15,7 @@ The examples are intentionally denser than typical production waves. Their job i
   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.7.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.7.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 These Examples Teach
 
@@ -38,7 +38,7 @@ The examples are intentionally denser than typical production waves. Their job i
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened for `0.7.0`:
+Together these samples cover the main surfaces added or hardened for `0.7.1`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety

package/package.json

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