@chllming/wave-orchestration 0.9.11 → 0.9.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +31 -0
- package/README.md +7 -8
- package/docs/README.md +4 -10
- package/docs/architecture/README.md +12 -4
- package/docs/concepts/operating-modes.md +1 -1
- package/docs/guides/author-and-run-waves.md +3 -2
- package/docs/guides/planner.md +3 -3
- package/docs/guides/recommendations-0.9.13.md +49 -0
- package/docs/guides/sandboxed-environments.md +2 -2
- package/docs/guides/terminal-surfaces.md +1 -1
- package/docs/plans/current-state.md +3 -3
- package/docs/plans/end-state-architecture.md +1 -1
- package/docs/plans/examples/wave-example-design-handoff.md +1 -1
- package/docs/plans/examples/wave-example-live-proof.md +1 -1
- package/docs/plans/migration.md +31 -28
- package/docs/plans/wave-orchestrator.md +1 -1
- package/docs/reference/cli-reference.md +2 -2
- package/docs/reference/coordination-and-closure.md +1 -1
- package/docs/reference/npmjs-token-publishing.md +3 -3
- package/docs/reference/package-publishing-flow.md +12 -12
- package/docs/reference/runtime-config/README.md +2 -2
- package/docs/reference/sample-waves.md +5 -5
- package/docs/reference/skills.md +1 -1
- package/docs/reference/wave-control.md +3 -1
- package/docs/roadmap.md +3 -3
- package/package.json +8 -9
- package/releases/manifest.json +50 -0
- package/scripts/context7-api-check.sh +0 -0
- package/scripts/context7-export-env.sh +0 -0
- package/scripts/wave-autonomous.mjs +0 -0
- package/scripts/wave-dashboard.mjs +0 -0
- package/scripts/wave-human-feedback.mjs +0 -0
- package/scripts/wave-launcher.mjs +0 -0
- package/scripts/wave-local-executor.mjs +0 -0
- package/scripts/wave-orchestrator/agent-process-runner.mjs +24 -0
- package/scripts/wave-orchestrator/agent-state.mjs +4 -4
- package/scripts/wave-orchestrator/autonomous.mjs +2 -2
- package/scripts/wave-orchestrator/closure-engine.mjs +103 -6
- package/scripts/wave-orchestrator/closure-policy.mjs +319 -0
- package/scripts/wave-orchestrator/config.mjs +15 -0
- package/scripts/wave-orchestrator/coordination.mjs +2 -2
- package/scripts/wave-orchestrator/derived-state-engine.mjs +45 -2
- package/scripts/wave-orchestrator/executors.mjs +2 -1
- package/scripts/wave-orchestrator/gate-engine.mjs +72 -4
- package/scripts/wave-orchestrator/install.mjs +1 -1
- package/scripts/wave-orchestrator/launcher.mjs +44 -7
- package/scripts/wave-orchestrator/planner.mjs +4 -3
- package/scripts/wave-orchestrator/shared.mjs +2 -3
- package/scripts/wave-orchestrator/swe-bench-pro-task.mjs +1 -1
- package/scripts/wave-orchestrator/traces.mjs +22 -1
- package/scripts/wave-orchestrator/wave-files.mjs +14 -3
- package/scripts/wave-status.sh +0 -0
- package/scripts/wave-watch.sh +0 -0
- package/scripts/wave.mjs +0 -0
- package/wave.config.json +13 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,36 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.9.13 - 2026-04-09
|
|
4
|
+
|
|
5
|
+
### Added
|
|
6
|
+
- Regression coverage for pre-validation completed-wave recovery and per-agent detached runner sticky-key environment handling.
|
|
7
|
+
- `docs/guides/recommendations-0.9.13.md` as the current packaged operating guide.
|
|
8
|
+
|
|
9
|
+
### Changed
|
|
10
|
+
- Release docs, migration guidance, runtime-config references, package-publishing docs, the release manifest, and tracked install-state fixtures now align on the `0.9.13` surface.
|
|
11
|
+
|
|
12
|
+
### Fixed
|
|
13
|
+
- Structured `[wave-proof]` and `[wave-component]` markers now accept `state=complete` and normalize it to the existing `met` semantics downstream.
|
|
14
|
+
- Launcher pre-validation now unions `run-state.json` with status-derived completed waves before stale promotion checks, which keeps restart and resumed launches from blocking on superseded historical promotions.
|
|
15
|
+
- Detached process runners now derive a per-agent `LPM_AUTH_STICKY_KEY` by default and preserve explicit overrides so concurrent broker-backed agents on one node stop colliding on credential exports.
|
|
16
|
+
|
|
17
|
+
## 0.9.12 - 2026-04-08
|
|
18
|
+
|
|
19
|
+
### Added
|
|
20
|
+
- `docs/guides/recommendations-0.9.12.md` with the current operating guidance for advisory turn budgets, targeted recovery, low-entropy closure, and optional TMUX operator surfaces.
|
|
21
|
+
|
|
22
|
+
### Changed
|
|
23
|
+
- TMUX is now described consistently as an optional dashboard/projection layer across setup, launcher help, autonomous help, runbooks, and examples. Live agents remain process-backed, and `tmux + --no-dashboard` now emits an explicit informational note instead of implying TMUX is part of the execution backend.
|
|
24
|
+
- Wave Control's browser surface now uses a dashboard-first information architecture with `Dashboard`, `Operations`, `Access`, and `Account` views, cleaner section navigation, and richer summaries for runs, benchmarks, and access review work.
|
|
25
|
+
- Release docs, migration guidance, runtime-config references, package-publishing docs, the release manifest, and tracked install-state fixtures now align on the `0.9.12` surface.
|
|
26
|
+
|
|
27
|
+
### Fixed
|
|
28
|
+
- Bootstrap closure no longer silently skips a missing `cont-QA` run after semantic closure stewards already ran. The low-entropy fast path now stays limited to genuinely lightweight closure attempts.
|
|
29
|
+
- `closureModeThresholds.bootstrap` now participates in runtime mode resolution instead of being normalized and then ignored.
|
|
30
|
+
- Derived `closureComplexity` now incorporates clarification, helper-assignment, dependency, and contradiction barriers so emitted closure metadata matches the real closure state machine.
|
|
31
|
+
- Wave Control benchmark and run projections now expose richer status, comparison-readiness, item, review, and verification rollups for both API consumers and the browser UI.
|
|
32
|
+
- `normalizeWaveVerdict()` now preserves `hold` as its own verdict instead of collapsing it into `concerns`, which brings the shared parser back in line with the shipped verdict grammar and tests.
|
|
33
|
+
|
|
3
34
|
## 0.9.11 - 2026-04-07
|
|
4
35
|
|
|
5
36
|
### Fixed
|
package/README.md
CHANGED
|
@@ -107,18 +107,17 @@ Wave is built to mitigate those failures with a canonical authority set, generat
|
|
|
107
107
|
|
|
108
108
|
Current release:
|
|
109
109
|
|
|
110
|
-
- `@chllming/wave-orchestration@0.9.
|
|
111
|
-
- Release tag: [`v0.9.
|
|
110
|
+
- `@chllming/wave-orchestration@0.9.13`
|
|
111
|
+
- Release tag: [`v0.9.13`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.9.13)
|
|
112
112
|
- Public install path: npmjs
|
|
113
113
|
- Authenticated fallback: GitHub Packages
|
|
114
114
|
|
|
115
|
-
Highlights in `0.9.
|
|
115
|
+
Highlights in `0.9.13`:
|
|
116
116
|
|
|
117
|
-
-
|
|
118
|
-
-
|
|
119
|
-
-
|
|
120
|
-
-
|
|
121
|
-
- Release docs, migration guidance, runtime-config and closure references, the manifest, and the tracked install-state fixtures now all point at the `0.9.4` surface.
|
|
117
|
+
- Structured proof and component markers now accept `state=complete` as a `met` alias, so agents that emit the more natural completion wording no longer fail proof parsing.
|
|
118
|
+
- Pre-launch wave validation now treats status-recoverable completed waves as already completed, which prevents stale component-matrix promotion checks from blocking restart or resumed launches.
|
|
119
|
+
- Detached process runners now derive a per-agent broker sticky key by default and preserve explicit overrides, so concurrent agents on the same node can lease provider credentials safely.
|
|
120
|
+
- Release docs, migration guidance, runtime-config and closure references, the manifest, and the tracked install-state fixtures now all point at the `0.9.13` surface.
|
|
122
121
|
|
|
123
122
|
Requirements:
|
|
124
123
|
|
package/docs/README.md
CHANGED
|
@@ -17,7 +17,7 @@ The useful path is journey-first:
|
|
|
17
17
|
- `docs/concepts/`
|
|
18
18
|
Mental models and architecture. Read these first if you want to understand what a wave is, how runtime-agnostic execution works, or how Context7 differs from skills.
|
|
19
19
|
- `docs/guides/`
|
|
20
|
-
Task-oriented workflows. Use these when you need to set up the planner, choose an operating mode, or
|
|
20
|
+
Task-oriented workflows. Use these when you need to set up the planner, choose an operating mode, or pick an operator terminal surface such as optional tmux-backed dashboards.
|
|
21
21
|
- `docs/reference/`
|
|
22
22
|
Exact command, config, and file-format details. Use this when you need precise key names, runtime options, or bundle structure.
|
|
23
23
|
- `docs/plans/`
|
|
@@ -38,7 +38,7 @@ The useful path is journey-first:
|
|
|
38
38
|
- Setting up multiple projects in one monorepo:
|
|
39
39
|
Read [guides/monorepo-projects.md](./guides/monorepo-projects.md) for `defaultProject`, `projects.<projectId>`, project-scoped state paths, and telemetry defaults.
|
|
40
40
|
- Adding an optional pre-implementation design steward:
|
|
41
|
-
Read [guides/author-and-run-waves.md](./guides/author-and-run-waves.md), then the standing prompt in [agents/wave-design-role.md](./agents/wave-design-role.md). The shipped `0.9.
|
|
41
|
+
Read [guides/author-and-run-waves.md](./guides/author-and-run-waves.md), then the standing prompt in [agents/wave-design-role.md](./agents/wave-design-role.md). The shipped `0.9.13` surface includes `role-design` plus `tui-design`, with docs-first design stewards by default and explicit hybrid design stewards when a wave also gives that same agent code ownership.
|
|
42
42
|
- Running in LEAPclaw, OpenClaw, Nemoshell, Docker, or another short-lived sandbox:
|
|
43
43
|
Read [guides/sandboxed-environments.md](./guides/sandboxed-environments.md) first for the submit or supervise pattern, persistent-state expectations, and dashboard guidance, then use [plans/sandbox-end-state-architecture.md](./plans/sandbox-end-state-architecture.md) for the deeper runtime design.
|
|
44
44
|
- Want signal-driven automation or long-running watcher loops:
|
|
@@ -53,14 +53,8 @@ The useful path is journey-first:
|
|
|
53
53
|
Read [plans/migration.md](./plans/migration.md), then review the release notes in [../CHANGELOG.md](../CHANGELOG.md) before running `pnpm exec wave upgrade`.
|
|
54
54
|
- Publishing the package:
|
|
55
55
|
Read [reference/package-publishing-flow.md](./reference/package-publishing-flow.md) for the end-to-end release path, the GitHub publish workflows, the lifecycle scripts, and the verification or repair flow.
|
|
56
|
-
- Want the practical `0.9.
|
|
57
|
-
Read [guides/recommendations-0.9.
|
|
58
|
-
- [0.9.8 Operating Recommendations](guides/recommendations-0.9.8.md
|
|
59
|
-
- [0.9.9 Recommendations](guides/recommendations-0.9.9.md
|
|
60
|
-
- [0.9.10 Recommendations](guides/recommendations-0.9.10.md))).md](./guides/recommendations-0.9.7
|
|
61
|
-
- [0.9.8 Operating Recommendations](guides/recommendations-0.9.8.md
|
|
62
|
-
- [0.9.9 Recommendations](guides/recommendations-0.9.9.md
|
|
63
|
-
- [0.9.10 Recommendations](guides/recommendations-0.9.10.md))).md) for the recommended default around relaxed blocker states, advisory turn budgets, and targeted recovery.
|
|
56
|
+
- Want the practical `0.9.13` operating stance:
|
|
57
|
+
Read [guides/recommendations-0.9.13.md](./guides/recommendations-0.9.13.md) for the recommended default around advisory turn budgets, targeted recovery, restart-safe validation, and optional TMUX operator surfaces.
|
|
64
58
|
- Want the concrete runtime module map:
|
|
65
59
|
Read [plans/end-state-architecture.md](./plans/end-state-architecture.md) for the engine-by-engine architecture and artifact ownership model.
|
|
66
60
|
- Want the CLI surface map:
|
|
@@ -137,7 +137,7 @@ Multi-agent coding systems fail in predictable ways documented in recent researc
|
|
|
137
137
|
- `wave-state-reducer.mjs`: Rebuilds full deterministic wave state from canonical sources
|
|
138
138
|
|
|
139
139
|
**Layer 3 -- Supervisor and Projection Writer** (side effects)
|
|
140
|
-
- `session-supervisor.mjs`: Launches
|
|
140
|
+
- `session-supervisor.mjs`: Launches process-backed runs, manages optional tmux dashboard/projection sessions, writes observed lifecycle events (`agent_run.started`, `agent_run.completed`)
|
|
141
141
|
- `projection-writer.mjs`: Persists all human-facing projections (dashboards, traces, boards, summaries, inboxes, ledgers)
|
|
142
142
|
- `signals.mjs`: Writes versioned signal-state projections for long-running agents
|
|
143
143
|
|
|
@@ -307,7 +307,7 @@ For each wave in the selected range:
|
|
|
307
307
|
then transition to implementation agents.
|
|
308
308
|
|
|
309
309
|
6. For each selected agent run:
|
|
310
|
-
a. launchAgentSession() -- build prompt, resolve skills,
|
|
310
|
+
a. launchAgentSession() -- build prompt, resolve skills, launch the process-backed agent run
|
|
311
311
|
b. recordAgentRunStarted() -- supervisor writes control-plane event
|
|
312
312
|
|
|
313
313
|
7. waitForWaveCompletion()
|
|
@@ -342,7 +342,7 @@ For each wave in the selected range:
|
|
|
342
342
|
### Phase 3: Cleanup
|
|
343
343
|
|
|
344
344
|
```
|
|
345
|
-
-> cleanupLaneTmuxSessions() --
|
|
345
|
+
-> cleanupLaneTmuxSessions() -- clean up tmux dashboard/projection sessions (unless --keep-sessions)
|
|
346
346
|
-> removeLaneTemporaryTerminalEntries() -- clean terminal registry
|
|
347
347
|
-> releaseLauncherLock() -- release lock for other launchers
|
|
348
348
|
```
|
|
@@ -521,7 +521,15 @@ This is enforced by the `closure-engine.mjs` module. The launcher cannot bypass
|
|
|
521
521
|
|
|
522
522
|
### How the Closure Sweep Executes
|
|
523
523
|
|
|
524
|
-
The sweep is sequential and staged. Each stage launches
|
|
524
|
+
The sweep is sequential and staged for semantic closure work. Each required closure stage launches its steward, waits for it to complete, evaluates the gate, and only proceeds to the next stage if the gate passes. This is implemented in `runClosureSweepPhase()`.
|
|
525
|
+
|
|
526
|
+
Low-entropy waves now use a closure fast-path before any steward is launched:
|
|
527
|
+
|
|
528
|
+
- `closure-policy.mjs` can auto-satisfy integration from derived state when no contradictions, helper assignments, dependency barriers, security blockers, interface drift, or deploy risks remain.
|
|
529
|
+
- Documentation closure can auto-satisfy as `no-change` when no shared-plan or component-matrix delta remains, and can auto-close mechanical component-matrix reconciliation when the canonical matrix is already current.
|
|
530
|
+
- cont-QA can be skipped only in bootstrap closure mode, and only when no semantic closure steward had to run.
|
|
531
|
+
|
|
532
|
+
If the fast-path does not prove closure, the runtime falls back to the normal staged steward sequence below.
|
|
525
533
|
|
|
526
534
|
```
|
|
527
535
|
┌─────────────────────────────────────────────────────────────────────┐
|
|
@@ -88,4 +88,4 @@ The current roadmap is a release-direction document, not a backlog of planner ph
|
|
|
88
88
|
- typed values in planner output
|
|
89
89
|
- better environment modeling
|
|
90
90
|
|
|
91
|
-
The stricter execution semantics are still future work, not a hidden already-finished feature in `0.9.
|
|
91
|
+
The stricter execution semantics are still future work, not a hidden already-finished feature in `0.9.13`.
|
|
@@ -74,7 +74,7 @@ Good fits:
|
|
|
74
74
|
- multi-owner waves where downstream implementers need the same decisions and assumptions
|
|
75
75
|
- ambiguous tasks where open questions should become explicit before code owners fan out
|
|
76
76
|
|
|
77
|
-
The starter contract in `0.9.
|
|
77
|
+
The starter contract in `0.9.13` is:
|
|
78
78
|
|
|
79
79
|
- import `docs/agents/wave-design-role.md`
|
|
80
80
|
- own one packet such as `docs/plans/waves/design/wave-<n>-<agentId>.md`
|
|
@@ -148,6 +148,7 @@ When the dry-run artifacts look correct, launch the wave with the operator surfa
|
|
|
148
148
|
|
|
149
149
|
```bash
|
|
150
150
|
pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --terminal-surface vscode
|
|
151
|
+
pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --no-dashboard
|
|
151
152
|
pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --terminal-surface tmux --keep-sessions
|
|
152
153
|
```
|
|
153
154
|
|
|
@@ -156,7 +157,7 @@ Useful flags:
|
|
|
156
157
|
- `--no-dashboard`
|
|
157
158
|
Skip the dashboard session.
|
|
158
159
|
- `--keep-sessions`
|
|
159
|
-
Preserve tmux sessions for inspection after the wave completes.
|
|
160
|
+
Preserve tmux dashboard and projection sessions for inspection after the wave completes.
|
|
160
161
|
- `--keep-terminals`
|
|
161
162
|
Preserve temporary VS Code terminal entries.
|
|
162
163
|
|
package/docs/guides/planner.md
CHANGED
|
@@ -6,7 +6,7 @@ If you want the full author-to-launch workflow, start with [author-and-run-waves
|
|
|
6
6
|
|
|
7
7
|
It reduces repeated setup questions, stores project defaults, and generates wave specs plus markdown that already fit the launcher.
|
|
8
8
|
|
|
9
|
-
The published `0.9.
|
|
9
|
+
The published `0.9.13` package already includes the optional `design` worker role for pre-implementation design packets. This guide calls out where that affects drafting.
|
|
10
10
|
|
|
11
11
|
## What Ships Today
|
|
12
12
|
|
|
@@ -48,7 +48,7 @@ pnpm exec wave launch --lane main --dry-run --no-dashboard
|
|
|
48
48
|
- forward replanning of later waves
|
|
49
49
|
- separate runtime enforcement for oversight vs dark-factory
|
|
50
50
|
|
|
51
|
-
Those remain future work outside the current `0.9.
|
|
51
|
+
Those remain future work outside the current `0.9.13` release line. The planner foundation is about better structured authoring, not a second execution engine.
|
|
52
52
|
|
|
53
53
|
## Project Profile
|
|
54
54
|
|
|
@@ -70,7 +70,7 @@ The saved profile remembers:
|
|
|
70
70
|
|
|
71
71
|
- whether the repo is a new project
|
|
72
72
|
- default oversight mode
|
|
73
|
-
- default terminal surface for live runs (`vscode` or `tmux`; `none` remains dry-run only)
|
|
73
|
+
- default terminal surface for live runs (`vscode` or `tmux`; `none` remains dry-run only). This is an operator viewing preference, not the agent execution backend.
|
|
74
74
|
- default draft template
|
|
75
75
|
- default lane
|
|
76
76
|
- typed deploy environments
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Recommendations for 0.9.13
|
|
2
|
+
|
|
3
|
+
## Upgrade
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
wave self-update
|
|
7
|
+
# or: npm install -g @chllming/wave-orchestration@0.9.13
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
## What changed
|
|
11
|
+
|
|
12
|
+
### Marker parsing is more forgiving, proof standards are not
|
|
13
|
+
|
|
14
|
+
Agents sometimes emit `state=complete` instead of `state=met` in `[wave-proof]` and `[wave-component]` markers. Wave now accepts that alias and normalizes it to the existing `met` semantics.
|
|
15
|
+
|
|
16
|
+
Practical effect:
|
|
17
|
+
|
|
18
|
+
- natural completion phrasing no longer breaks proof parsing
|
|
19
|
+
- proof standards stay the same because the normalized state still means `met`
|
|
20
|
+
- operators can keep asking for machine-visible final markers without retraining every agent prompt immediately
|
|
21
|
+
|
|
22
|
+
### Restart-safe validation matters more than stale matrices
|
|
23
|
+
|
|
24
|
+
Historical completed waves can promote a component to an older level than the matrix's current level after later waves advanced it further. On restart, the launcher now consults both `run-state.json` and status-recoverable completions before stale promotion checks.
|
|
25
|
+
|
|
26
|
+
Practical effect:
|
|
27
|
+
|
|
28
|
+
- resumed launches stop reopening already completed historical waves
|
|
29
|
+
- component-matrix validation stays strict for active or genuinely incomplete work
|
|
30
|
+
- targeted recovery remains the right tool when only one later slice actually needs attention
|
|
31
|
+
|
|
32
|
+
### Concurrent detached runners need unique broker identity
|
|
33
|
+
|
|
34
|
+
When detached runners broker provider credentials, each agent now gets a unique default `LPM_AUTH_STICKY_KEY`. Explicit overrides still win.
|
|
35
|
+
|
|
36
|
+
Practical effect:
|
|
37
|
+
|
|
38
|
+
- same-node agents can lease credentials concurrently without trampling one shared sticky key
|
|
39
|
+
- local policy can still provide an explicit sticky key when a deployment needs custom routing
|
|
40
|
+
- retry or resume flows stay deterministic because the default key now scopes down to one agent attempt
|
|
41
|
+
|
|
42
|
+
## Recommendations
|
|
43
|
+
|
|
44
|
+
- **Proof markers**: keep requiring explicit final markers, but accept `complete` as an operationally harmless alias while normalizing downstream state to `met`.
|
|
45
|
+
- **Restart recovery**: prefer status-backed restart and targeted recovery over reauthoring older completed waves just because the component matrix has since moved on.
|
|
46
|
+
- **Credential brokering**: let the detached runner use its per-agent sticky-key default unless you have a clear external reason to override it.
|
|
47
|
+
- **Budgets**: keep using `budget.minutes` as the main wall-clock budget. Keep generic `budget.turns` advisory unless you deliberately need a runtime-specific hard ceiling.
|
|
48
|
+
- **Coordination severity**: continue to use `mark-advisory`, `mark-stale`, and `resolve-policy` for follow-up that should stay visible without falsely reopening proof-critical closure.
|
|
49
|
+
- **Targeted recovery**: prefer targeted recovery when one slice regresses or a restart left run-state behind. The most useful recovery work is still narrow and machine-visible.
|
|
@@ -8,7 +8,7 @@ Typical examples:
|
|
|
8
8
|
- Nemoshell or similar hosted terminal sandboxes
|
|
9
9
|
- Docker or devcontainer setups where the client process is disposable but the workspace and state volume persist
|
|
10
10
|
|
|
11
|
-
The core rule in `0.9.
|
|
11
|
+
The core rule in `0.9.13` is simple:
|
|
12
12
|
|
|
13
13
|
- clients should be short-lived
|
|
14
14
|
- supervision should be long-lived
|
|
@@ -94,7 +94,7 @@ If the sandbox only gives you short exec windows, `wave autonomous` should not b
|
|
|
94
94
|
|
|
95
95
|
## Docker And Containerized Setups
|
|
96
96
|
|
|
97
|
-
Docker works well with the `0.9.
|
|
97
|
+
Docker works well with the `0.9.13` process-backed runner model, but only if the state directories survive container restarts.
|
|
98
98
|
|
|
99
99
|
Recommended container posture:
|
|
100
100
|
|
|
@@ -57,7 +57,7 @@ pnpm exec wave dashboard --lane main --attach current
|
|
|
57
57
|
pnpm exec wave dashboard --lane main --attach global
|
|
58
58
|
```
|
|
59
59
|
|
|
60
|
-
Those commands work for both `tmux` and `vscode` terminal surfaces because
|
|
60
|
+
Those commands work for both `tmux` and `vscode` terminal surfaces because live dashboard projection sessions currently use the lane tmux socket when dashboards are enabled. If no live dashboard session exists, the attach command falls back to the last written dashboard JSON instead of failing immediately.
|
|
61
61
|
|
|
62
62
|
When `--terminal-surface vscode` is active, Wave also maintains a stable current-wave dashboard terminal entry instead of creating a new wave-numbered dashboard attach target for every wave transition.
|
|
63
63
|
|
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
# Current State
|
|
2
2
|
|
|
3
|
-
- The published package is `0.9.
|
|
3
|
+
- The published package is `0.9.13`; that release keeps the shipped monorepo, design-role, signal-hygiene, detached process-runner, and sandbox supervisor surfaces, and adds three focused operational hardening fixes: `state=complete` now maps cleanly onto the existing proof semantics, restart-safe launcher validation now honors status-recoverable completed waves before stale promotion checks, and detached runners now derive per-agent broker sticky keys by default. The current authenticated Wave Control plus Corridor-backed security surface continues to ship in this repo, with the browser UI still organized around dashboard-first navigation and richer run or benchmark analytics summaries.
|
|
4
4
|
- 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`.
|
|
5
5
|
- The repository contains the published `@chllming/wave-orchestration` package plus the starter scaffold used by `wave init`.
|
|
6
6
|
- 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/`.
|
|
7
|
-
- The recommended `0.9.
|
|
7
|
+
- The recommended `0.9.13` operating stance is documented in `docs/guides/recommendations-0.9.13.md`: keep proof and closure strict, keep generic `budget.turns` advisory, use targeted recovery for narrow restart-safe recovery work, and treat TMUX as an optional operator surface rather than a runtime requirement.
|
|
8
8
|
- 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.
|
|
9
9
|
- 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.
|
|
10
10
|
- The companion control plane now ships in two packages:
|
|
11
11
|
- `services/wave-control/` is the backend for typed telemetry, Stack-authenticated app users, Wave-managed approval states and provider grants, PATs, dedicated service tokens, encrypted per-user credential storage, runtime env leasing, and owned broker routes for Context7 or Corridor
|
|
12
|
-
- `services/wave-control-web/` is the Vite/Lit browser frontend that signs in through Stack, persists the browser session, exposes
|
|
12
|
+
- `services/wave-control-web/` is the Vite/Lit browser frontend that signs in through Stack, persists the browser session, exposes dashboard-first navigation across runs, benchmarks, tokens, and access review, and adds superuser-only user, provider-grant, and write-only credential management
|
|
13
13
|
- This source repo is itself kept as an adopted Wave workspace, so `node scripts/wave.mjs doctor --json` should pass from the repo root.
|
|
14
14
|
- The default lane is `main`.
|
|
15
15
|
- Planner foundation is now shipped:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# End-State Architecture
|
|
2
2
|
|
|
3
|
-
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.
|
|
3
|
+
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.13` surface now follows.
|
|
4
4
|
|
|
5
5
|
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).
|
|
6
6
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Wave 12 - Optional Design Steward Handoff
|
|
2
2
|
|
|
3
|
-
This is a showcase-first sample wave for the shipped `design` worker role in `0.9.
|
|
3
|
+
This is a showcase-first sample wave for the shipped `design` worker role in `0.9.13`.
|
|
4
4
|
|
|
5
5
|
This example demonstrates the docs-first design-steward path where a design packet is published before code-owning implementation begins.
|
|
6
6
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
This is a showcase-first sample wave.
|
|
4
4
|
|
|
5
|
-
Use it as the single reference example for the current `0.9.
|
|
5
|
+
Use it as the single reference example for the current `0.9.13` Wave surface.
|
|
6
6
|
|
|
7
7
|
It intentionally combines more sections than a normal production wave so one file can demonstrate:
|
|
8
8
|
|
package/docs/plans/migration.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Migration
|
|
2
2
|
|
|
3
|
-
This page is the practical repo-upgrade guide for the current `0.9.
|
|
3
|
+
This page is the practical repo-upgrade guide for the current `0.9.13` surface.
|
|
4
4
|
|
|
5
5
|
Use it when you are:
|
|
6
6
|
|
|
@@ -13,18 +13,21 @@ For the completed internal architecture cutover record, see [architecture-harden
|
|
|
13
13
|
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).
|
|
14
14
|
|
|
15
15
|
|
|
16
|
-
## What `0.9.
|
|
16
|
+
## What `0.9.13` Changes
|
|
17
|
+
|
|
18
|
+
The `0.9.13` surface keeps the existing proof-first runtime and adds three focused operational hardening fixes with no breaking changes.
|
|
19
|
+
|
|
20
|
+
- **Proof marker aliasing**: implementation and closure markers now accept `state=complete` as a compatibility alias for `state=met`, which keeps naturally phrased agent output from being rejected by the proof parser.
|
|
21
|
+
- **Restart-safe validation**: launcher pre-validation now treats waves reconstructed as complete from status files the same way it treats run-state-complete waves, so resumed launches stop tripping stale component-promotion checks from older completed waves.
|
|
22
|
+
- **Concurrent credential brokering**: detached process runners now derive a per-agent `LPM_AUTH_STICKY_KEY` and preserve explicit overrides, which prevents same-node agents from contending on one broker export by default.
|
|
17
23
|
|
|
18
|
-
|
|
24
|
+
There are no breaking changes. Existing repos can upgrade in place with `pnpm up @chllming/wave-orchestration` and `pnpm exec wave upgrade`.
|
|
19
25
|
|
|
20
|
-
|
|
21
|
-
- **Steward threshold fix**: `requireDocumentationStewardFromWave` is now strictly respected. Previously it was OR'd with `componentPromotionRuleActive`.
|
|
22
|
-
- **New config fields**: `gateModeThresholds`, `bootstrapPassConditions`, `testCommand`, `testCommandTimeout`.
|
|
23
|
-
- **No breaking changes**: existing repos get bootstrap mode for waves 0-3 by default.
|
|
26
|
+
For the practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
|
|
24
27
|
|
|
25
28
|
## What `0.9.4` Changes
|
|
26
29
|
|
|
27
|
-
The current `0.9.
|
|
30
|
+
The current `0.9.13` surface keeps everything from `0.9.2` and adds the earlier gate-value and setup improvements with no breaking changes.
|
|
28
31
|
|
|
29
32
|
The practical changes are:
|
|
30
33
|
|
|
@@ -40,11 +43,11 @@ There are no breaking changes. Just upgrade with `pnpm up @chllming/wave-orchest
|
|
|
40
43
|
|
|
41
44
|
If your repo uses wave-gate markers, you can now use `gap` for dimensions where the gap is documented and not an actionable blocker.
|
|
42
45
|
|
|
43
|
-
For the practical `0.9.
|
|
46
|
+
For the practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
|
|
44
47
|
|
|
45
48
|
## What `0.9.2` Changes
|
|
46
49
|
|
|
47
|
-
The
|
|
50
|
+
The `0.9.2` release established the packaged operator-guidance alignment, monorepo project support, and project-aware default telemetry from `0.9.0`, then added a more sandbox-friendly execution model and lower-overhead live orchestration.
|
|
48
51
|
|
|
49
52
|
The practical changes are:
|
|
50
53
|
|
|
@@ -55,11 +58,11 @@ The practical changes are:
|
|
|
55
58
|
- Corridor is now documented as a first-class security input, including direct versus broker versus hybrid mode, implementation-owned path matching, generated artifact paths, and the closure-gate interaction with the human security reviewer
|
|
56
59
|
- a dedicated setup guide now ships for LEAPclaw, OpenClaw, Nemoshell, Docker, and similar constrained environments
|
|
57
60
|
- 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
|
|
58
|
-
- the current release surface and tracked install-state fixtures now
|
|
61
|
+
- the current release surface and tracked install-state fixtures now move together on the active package version
|
|
59
62
|
|
|
60
|
-
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
|
|
63
|
+
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 current package cut.
|
|
61
64
|
|
|
62
|
-
For a practical `0.9.
|
|
65
|
+
For a practical `0.9.13` operating stance after the upgrade, read [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
|
|
63
66
|
For the concrete operator setup in Nemoshell, Docker, and other sandboxed shells, also read [../guides/sandboxed-environments.md](../guides/sandboxed-environments.md).
|
|
64
67
|
|
|
65
68
|
## What `0.8.6` Changes
|
|
@@ -127,7 +130,7 @@ pnpm exec wave upgrade
|
|
|
127
130
|
|
|
128
131
|
### 3. Sync repo-owned starter surface only if you copied it
|
|
129
132
|
|
|
130
|
-
The most common sync set for
|
|
133
|
+
The most common sync set for the current release line is:
|
|
131
134
|
|
|
132
135
|
- `docs/agents/wave-launcher-role.md`
|
|
133
136
|
- `docs/agents/wave-orchestrator-role.md`
|
|
@@ -180,9 +183,9 @@ pnpm exec wave coord inbox --lane main --wave 0 --agent A1 --dry-run
|
|
|
180
183
|
|
|
181
184
|
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.
|
|
182
185
|
|
|
183
|
-
## `0.9.
|
|
186
|
+
## `0.9.13` Release Model
|
|
184
187
|
|
|
185
|
-
The current `0.9.
|
|
188
|
+
The current `0.9.13` surface combines these strands:
|
|
186
189
|
|
|
187
190
|
- the gap-value wave-gate fix and first-time setup UX improvements released in `0.9.4`
|
|
188
191
|
- the detached process-runner and sandbox supervisor hardening released in `0.9.2`
|
|
@@ -196,7 +199,7 @@ The current `0.9.10` surface combines these strands:
|
|
|
196
199
|
|
|
197
200
|
### Sandbox-safe execution and lower-overhead live runs
|
|
198
201
|
|
|
199
|
-
This
|
|
202
|
+
This remains the main execution-model shift introduced in `0.9.2`.
|
|
200
203
|
|
|
201
204
|
The runtime now:
|
|
202
205
|
|
|
@@ -205,7 +208,7 @@ The runtime now:
|
|
|
205
208
|
- keeps `wave attach --agent` usable through log-follow attach even when no live interactive terminal session exists
|
|
206
209
|
- uses `wave submit/supervise/status/wait/attach` as the preferred sandbox-safe surface for short-lived clients
|
|
207
210
|
|
|
208
|
-
If your repo copied sandbox, CI, or container runbooks, this is the main sync set to apply from `0.9.2
|
|
211
|
+
If your repo copied sandbox, CI, or container runbooks, this is the main sync set to apply from that `0.9.2` execution-model cut:
|
|
209
212
|
|
|
210
213
|
- `README.md`
|
|
211
214
|
- `docs/README.md`
|
|
@@ -216,14 +219,14 @@ If your repo copied sandbox, CI, or container runbooks, this is the main sync se
|
|
|
216
219
|
|
|
217
220
|
### Authenticated Wave Control and Corridor-backed security
|
|
218
221
|
|
|
219
|
-
|
|
222
|
+
That same `0.9.2` doc surface also describes the current control-plane and security model as shipped:
|
|
220
223
|
|
|
221
224
|
- owned Wave Control deployments use Stack for browser sign-in, then apply Wave-managed approval states and provider grants on top of that identity
|
|
222
225
|
- approved users and superusers can issue PATs for scoped repo-runtime access, while dedicated service tokens keep machine-admin workflows separate from user-owned runtime credentials
|
|
223
226
|
- arbitrary stored credentials are encrypted at rest and only returned through explicit runtime lease responses
|
|
224
227
|
- `externalProviders.corridor` can run direct, brokered through an owned Wave Control deployment, or hybrid; the result is persisted as a normalized security artifact and can block closure before integration
|
|
225
228
|
|
|
226
|
-
If your repo copied release docs, security runbooks, or Wave Control setup docs, this is the main sync set to apply from `0.9.2
|
|
229
|
+
If your repo copied release docs, security runbooks, or Wave Control setup docs, this is the main sync set to apply from that `0.9.2` security-surface cut:
|
|
227
230
|
|
|
228
231
|
- `README.md`
|
|
229
232
|
- `docs/README.md`
|
|
@@ -292,7 +295,7 @@ The interactive `wave draft` flow supports `design` as a worker role and scaffol
|
|
|
292
295
|
|
|
293
296
|
## Version-Specific Upgrade Guidance
|
|
294
297
|
|
|
295
|
-
## Upgrading From `0.8.5` To `0.9.
|
|
298
|
+
## Upgrading From `0.8.5` To `0.9.13`
|
|
296
299
|
|
|
297
300
|
This is the smallest upgrade, but it changes the live wait-loop contract for external automation and intentionally long-running agents.
|
|
298
301
|
|
|
@@ -329,7 +332,7 @@ If the repo copied starter surface, sync:
|
|
|
329
332
|
- if the repo uses long-running watchers, confirm they can write the ack file where the prompt tells them to
|
|
330
333
|
- reroute one targeted feedback or coordination request and confirm the resident signal version changes even when the signal kind stays the same
|
|
331
334
|
|
|
332
|
-
## Upgrading From `0.8.4` To `0.9.
|
|
335
|
+
## Upgrading From `0.8.4` To `0.9.13`
|
|
333
336
|
|
|
334
337
|
### What changed
|
|
335
338
|
|
|
@@ -367,7 +370,7 @@ If your repo copied starter config defaults, also sync the `designRolePromptPath
|
|
|
367
370
|
- hybrid design stewards rejoin implementation when they explicitly own code
|
|
368
371
|
- long-running prompts receive signal-state and ack paths when the repo uses the new waiting model
|
|
369
372
|
|
|
370
|
-
## Upgrading From `0.9.9` To `0.9.
|
|
373
|
+
## Upgrading From `0.9.9` To `0.9.13`
|
|
371
374
|
|
|
372
375
|
Run-state history is now capped at 200 entries (20 per wave). Existing bloated run-state files will be automatically pruned on the next write. No config changes needed.
|
|
373
376
|
|
|
@@ -375,9 +378,9 @@ Run-state history is now capped at 200 entries (20 per wave). Existing bloated r
|
|
|
375
378
|
|
|
376
379
|
Helper assignment barriers are now advisory in bootstrap gate mode. No config changes needed.
|
|
377
380
|
|
|
378
|
-
## Upgrading From `0.8.3` To `0.9.
|
|
381
|
+
## Upgrading From `0.8.3` To `0.9.13`
|
|
379
382
|
|
|
380
|
-
Treat this as one move to the current `0.9.
|
|
383
|
+
Treat this as one move to the current `0.9.13` surface.
|
|
381
384
|
|
|
382
385
|
### What changed across that range
|
|
383
386
|
|
|
@@ -410,7 +413,7 @@ If your repo copied starter docs or skills, sync:
|
|
|
410
413
|
- dry-run one design-steward wave if the repo wants the new authored surface
|
|
411
414
|
- 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
|
|
412
415
|
|
|
413
|
-
## Upgrading From `0.6.x` Or `0.7.x` To `0.9.
|
|
416
|
+
## Upgrading From `0.6.x` Or `0.7.x` To `0.9.13`
|
|
414
417
|
|
|
415
418
|
This is the main migration path for older adopted repos.
|
|
416
419
|
|
|
@@ -451,7 +454,7 @@ pnpm exec wave control proof get --lane main --wave 0 --json
|
|
|
451
454
|
|
|
452
455
|
If the repo carries proof-first waves, verify that required proof artifacts still exist locally and not only in historical summaries.
|
|
453
456
|
|
|
454
|
-
## Upgrading From `0.5.x` Or Earlier To `0.9.
|
|
457
|
+
## Upgrading From `0.5.x` Or Earlier To `0.9.13`
|
|
455
458
|
|
|
456
459
|
Do not treat this as a tiny patch bump.
|
|
457
460
|
|
|
@@ -561,4 +564,4 @@ For repos that depend on replay parity, replay at least:
|
|
|
561
564
|
|
|
562
565
|
## Summary
|
|
563
566
|
|
|
564
|
-
The current `0.9.
|
|
567
|
+
The current `0.9.13` 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, adds the recent proof-alias, restart-safe validation, and credential-broker concurrency fixes, and still 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.
|
|
@@ -126,7 +126,7 @@ The live runtime is organized around explicit modules:
|
|
|
126
126
|
## Setup
|
|
127
127
|
|
|
128
128
|
1. Install the package with `pnpm add -D @chllming/wave-orchestration`.
|
|
129
|
-
2. Confirm
|
|
129
|
+
2. Confirm at least one real executor (`codex`, `claude`, or `opencode`) is available if you want live wave execution. Install `tmux` only if you want terminal-native dashboard or projection attach.
|
|
130
130
|
3. Run `pnpm exec wave init` for a fresh repo, or `pnpm exec wave init --adopt-existing` for a repo with existing Wave files you want preserved.
|
|
131
131
|
4. Review [wave.config.json](../../wave.config.json).
|
|
132
132
|
5. Review the role prompts, starter `skills/` bundles, and docs you want the repo to own.
|
|
@@ -54,7 +54,7 @@ Closure-role bindings do not have a CLI override surface. When a wave file decla
|
|
|
54
54
|
| `--agent-launch-stagger-ms <n>` | `1200` | Delay between agent launches |
|
|
55
55
|
| `--terminal-surface <mode>` | `vscode` | `tmux`, `vscode`, or `none` |
|
|
56
56
|
| `--no-dashboard` | off | Disable the per-wave dashboard projection session |
|
|
57
|
-
| `--cleanup-sessions` | on |
|
|
57
|
+
| `--cleanup-sessions` | on | Clean up lane tmux dashboard and projection sessions after each wave |
|
|
58
58
|
| `--keep-sessions` | off | Keep lane tmux dashboard and projection sessions |
|
|
59
59
|
| `--keep-terminals` | off | Keep temporary terminal entries |
|
|
60
60
|
| `--orchestrator-id <id>` | generated | Stable orchestrator identity |
|
|
@@ -629,7 +629,7 @@ Interactive draft currently offers worker role kinds:
|
|
|
629
629
|
- `research`
|
|
630
630
|
- `security`
|
|
631
631
|
|
|
632
|
-
Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.9.
|
|
632
|
+
Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.9.13` surface uses `design-pass` as the default executor profile for that role and typically assigns a packet path like `docs/plans/waves/design/wave-<n>-<agentId>.md`. Interactive draft scaffolds the docs-first default; hybrid design stewards are authored by explicitly adding implementation-owned paths and the normal implementation contract sections.
|
|
633
633
|
|
|
634
634
|
## Ad-Hoc Task Commands
|
|
635
635
|
|
|
@@ -142,7 +142,7 @@ Practical rule:
|
|
|
142
142
|
|
|
143
143
|
That means a targeted helper request only blocks while it remains open *and* still has blocking severity in coordination state.
|
|
144
144
|
|
|
145
|
-
For the practical `0.9.
|
|
145
|
+
For the practical `0.9.13` recommendation on when to keep records blocking versus when to downgrade them to `soft`, `stale`, or `advisory`, see [../guides/recommendations-0.9.13.md](../guides/recommendations-0.9.13.md).
|
|
146
146
|
|
|
147
147
|
This page is documenting runtime semantics first. The important contract is that closure follows the durable coordination state, not that a particular human or agent used one exact command path to mutate it.
|
|
148
148
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
|
|
4
4
|
|
|
5
|
-
The current `0.9.
|
|
5
|
+
The current `0.9.13` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
|
|
6
6
|
|
|
7
7
|
## What This Repo Already Does
|
|
8
8
|
|
|
@@ -48,6 +48,6 @@ If this repo later needs private npm dependencies during CI, consider a separate
|
|
|
48
48
|
2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
|
|
49
49
|
3. Confirm the package version has been bumped and committed.
|
|
50
50
|
4. Confirm `README.md`, `CHANGELOG.md`, `releases/manifest.json`, and `docs/plans/migration.md` all describe the same release surface.
|
|
51
|
-
5. Push the release commit and release tag, for example `v0.9.
|
|
51
|
+
5. Push the release commit and release tag, for example `v0.9.13`.
|
|
52
52
|
6. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
|
|
53
|
-
7. Verify the npmjs publish completes successfully for the tagged source.
|
|
53
|
+
7. Verify the npmjs publish completes successfully for the tagged `0.9.13` source.
|