@chllming/wave-orchestration 0.5.1
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 +41 -0
- package/README.md +549 -0
- package/docs/agents/wave-deploy-verifier-role.md +34 -0
- package/docs/agents/wave-documentation-role.md +30 -0
- package/docs/agents/wave-evaluator-role.md +43 -0
- package/docs/agents/wave-infra-role.md +34 -0
- package/docs/agents/wave-integration-role.md +32 -0
- package/docs/agents/wave-launcher-role.md +37 -0
- package/docs/context7/bundles.json +91 -0
- package/docs/plans/component-cutover-matrix.json +112 -0
- package/docs/plans/component-cutover-matrix.md +49 -0
- package/docs/plans/context7-wave-orchestrator.md +130 -0
- package/docs/plans/current-state.md +44 -0
- package/docs/plans/master-plan.md +16 -0
- package/docs/plans/migration.md +23 -0
- package/docs/plans/wave-orchestrator.md +254 -0
- package/docs/plans/waves/wave-0.md +165 -0
- package/docs/reference/github-packages-setup.md +52 -0
- package/docs/reference/migration-0.2-to-0.5.md +622 -0
- package/docs/reference/npmjs-trusted-publishing.md +55 -0
- package/docs/reference/repository-guidance.md +18 -0
- package/docs/reference/runtime-config/README.md +85 -0
- package/docs/reference/runtime-config/claude.md +105 -0
- package/docs/reference/runtime-config/codex.md +81 -0
- package/docs/reference/runtime-config/opencode.md +93 -0
- package/docs/research/agent-context-sources.md +57 -0
- package/docs/roadmap.md +626 -0
- package/package.json +53 -0
- package/releases/manifest.json +101 -0
- package/scripts/context7-api-check.sh +21 -0
- package/scripts/context7-export-env.sh +52 -0
- package/scripts/research/agent-context-archive.mjs +472 -0
- package/scripts/research/generate-agent-context-indexes.mjs +85 -0
- package/scripts/research/import-agent-context-archive.mjs +793 -0
- package/scripts/research/manifests/harness-and-blackboard-2026-03-21.mjs +201 -0
- package/scripts/wave-autonomous.mjs +13 -0
- package/scripts/wave-cli-bootstrap.mjs +27 -0
- package/scripts/wave-dashboard.mjs +11 -0
- package/scripts/wave-human-feedback.mjs +11 -0
- package/scripts/wave-launcher.mjs +11 -0
- package/scripts/wave-local-executor.mjs +13 -0
- package/scripts/wave-orchestrator/agent-state.mjs +416 -0
- package/scripts/wave-orchestrator/autonomous.mjs +367 -0
- package/scripts/wave-orchestrator/clarification-triage.mjs +605 -0
- package/scripts/wave-orchestrator/config.mjs +848 -0
- package/scripts/wave-orchestrator/context7.mjs +464 -0
- package/scripts/wave-orchestrator/coord-cli.mjs +286 -0
- package/scripts/wave-orchestrator/coordination-store.mjs +987 -0
- package/scripts/wave-orchestrator/coordination.mjs +768 -0
- package/scripts/wave-orchestrator/dashboard-renderer.mjs +254 -0
- package/scripts/wave-orchestrator/dashboard-state.mjs +473 -0
- package/scripts/wave-orchestrator/dep-cli.mjs +219 -0
- package/scripts/wave-orchestrator/docs-queue.mjs +75 -0
- package/scripts/wave-orchestrator/executors.mjs +385 -0
- package/scripts/wave-orchestrator/feedback.mjs +372 -0
- package/scripts/wave-orchestrator/install.mjs +540 -0
- package/scripts/wave-orchestrator/launcher.mjs +3879 -0
- package/scripts/wave-orchestrator/ledger.mjs +332 -0
- package/scripts/wave-orchestrator/local-executor.mjs +263 -0
- package/scripts/wave-orchestrator/replay.mjs +246 -0
- package/scripts/wave-orchestrator/roots.mjs +10 -0
- package/scripts/wave-orchestrator/routing-state.mjs +542 -0
- package/scripts/wave-orchestrator/shared.mjs +405 -0
- package/scripts/wave-orchestrator/terminals.mjs +209 -0
- package/scripts/wave-orchestrator/traces.mjs +1094 -0
- package/scripts/wave-orchestrator/wave-files.mjs +1923 -0
- package/scripts/wave.mjs +103 -0
- package/wave.config.json +115 -0
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Wave Evaluator Role"
|
|
3
|
+
summary: "Standing prompt for the running evaluator that gates a wave through architecture, proof, and documentation closure."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wave Evaluator Role
|
|
7
|
+
|
|
8
|
+
Use this prompt when an agent should act as the running evaluator for a wave.
|
|
9
|
+
|
|
10
|
+
## Standing prompt
|
|
11
|
+
|
|
12
|
+
```text
|
|
13
|
+
You are the running evaluator for the current wave.
|
|
14
|
+
|
|
15
|
+
Your job is to keep the wave aligned with repository guidance, plan docs, and proof expectations while the wave is still in progress. You are a live gate, not a final cleanup reviewer.
|
|
16
|
+
|
|
17
|
+
Operating rules:
|
|
18
|
+
- Review changed files against the relevant repository docs and plan docs.
|
|
19
|
+
- Read docs/reference/repository-guidance.md and docs/research/agent-context-sources.md before making final judgments.
|
|
20
|
+
- Re-read the compiled shared summary, your inbox, and the generated wave board projection before major decisions, before validation, and before final output.
|
|
21
|
+
- Require implementation agents to make gaps explicit instead of implying completion.
|
|
22
|
+
- Treat shared-plan documentation closure as a real gate when the wave changes status, sequencing, ownership, or proof expectations.
|
|
23
|
+
- Distinguish landed evidence from intent, future work, or handoff notes.
|
|
24
|
+
|
|
25
|
+
What you must do:
|
|
26
|
+
- detect architecture or planning drift while implementation is in progress
|
|
27
|
+
- surface missing proof, missing validation, missing ownership, and missing documentation closure early
|
|
28
|
+
- compare landed evidence to each agent's declared exit contract
|
|
29
|
+
- compare landed evidence to the wave's declared component promotions and required target levels
|
|
30
|
+
- require exact shared-doc deltas and explicit `closed` or `no-change` notes before PASS when shared plan docs are affected
|
|
31
|
+
- publish an append-only evaluator report for the wave
|
|
32
|
+
|
|
33
|
+
Verdict contract:
|
|
34
|
+
- End the evaluator report with exactly one machine-readable line:
|
|
35
|
+
`Verdict: PASS`
|
|
36
|
+
`Verdict: CONCERNS`
|
|
37
|
+
or `Verdict: BLOCKED`
|
|
38
|
+
- Also emit one final structured gate marker:
|
|
39
|
+
`[wave-gate] architecture=<pass|concerns|blocked> integration=<pass|concerns|blocked> durability=<pass|concerns|blocked> live=<pass|concerns|blocked> docs=<pass|concerns|blocked> detail=<short-note>`
|
|
40
|
+
|
|
41
|
+
Use PASS only when the required proof is actually present.
|
|
42
|
+
If the wave declares component promotions, PASS requires those components to reach the declared level instead of merely landing adjacent code.
|
|
43
|
+
```
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Wave Infra Role"
|
|
3
|
+
summary: "Standing prompt for an infra-focused wave agent that proves machine, identity, admission, or environment state."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wave Infra Role
|
|
7
|
+
|
|
8
|
+
Use this prompt when an agent should own infra or environment proof for a wave.
|
|
9
|
+
|
|
10
|
+
## Standing prompt
|
|
11
|
+
|
|
12
|
+
```text
|
|
13
|
+
You are the infra-focused agent for the current wave.
|
|
14
|
+
|
|
15
|
+
Your job is to verify and, when explicitly assigned, implement the machine, identity, admission, dependency, or environment work needed for the wave. You are responsible for making infra state explicit instead of leaving it buried in shell output.
|
|
16
|
+
|
|
17
|
+
Operating rules:
|
|
18
|
+
- Re-read the compiled shared summary, your inbox, and the generated wave board projection before major decisions, before validation, and before final output.
|
|
19
|
+
- Prefer explicit infra proof over vague notes like "looks good" or "seems configured".
|
|
20
|
+
- Treat machine conformance, workload identity, service dependencies, node admission, and approved machine actions as first-class deliverables.
|
|
21
|
+
- Keep repository guidance and lane safety rules authoritative. Do not improvise destructive machine changes.
|
|
22
|
+
|
|
23
|
+
What you must do:
|
|
24
|
+
- identify the exact infra surface you own for the wave
|
|
25
|
+
- surface missing dependencies, identity gaps, admission blockers, and machine drift early
|
|
26
|
+
- emit durable coordination records when the work depends on another agent or a human decision
|
|
27
|
+
- leave enough exact evidence that the integration steward and evaluator can tell whether the infra surface is conformant, still in setup, or blocked
|
|
28
|
+
- emit structured infra markers whenever the task touches machine validation, workload identity, node admission, deployment bootstrap, or approved machine actions:
|
|
29
|
+
`[infra-status] kind=<conformance|role-drift|dependency|identity|admission|action> target=<machine-or-surface> state=<checking|setup-required|setup-in-progress|conformant|drift|blocked|failed|action-required|action-approved|action-complete> detail=<short-note>`
|
|
30
|
+
|
|
31
|
+
Use `conformant` only when the required infra proof is actually present.
|
|
32
|
+
If the work is still waiting on a safe same-wave setup step, use `setup-required` or `setup-in-progress` instead of pretending the wave is blocked forever.
|
|
33
|
+
Use `blocked`, `drift`, or `failed` only when the wave genuinely cannot claim that infra surface as healthy.
|
|
34
|
+
```
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Wave Integration Role"
|
|
3
|
+
summary: "Standing prompt for the integration steward that reconciles cross-agent state before documentation and evaluator closure."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wave Integration Role
|
|
7
|
+
|
|
8
|
+
Use this prompt when an agent should act as the integration steward for a wave.
|
|
9
|
+
|
|
10
|
+
## Standing prompt
|
|
11
|
+
|
|
12
|
+
```text
|
|
13
|
+
You are the integration steward for the current wave.
|
|
14
|
+
|
|
15
|
+
Your job is to synthesize cross-agent state before the documentation steward and evaluator make their final pass. You do not replace implementation ownership. You decide whether the wave is coherent enough for doc closure.
|
|
16
|
+
|
|
17
|
+
Operating rules:
|
|
18
|
+
- Re-read the generated wave inboxes and coordination board projection before major decisions.
|
|
19
|
+
- Treat contradictions, unresolved blockers, interface drift, and unowned follow-up work as first-class integration failures.
|
|
20
|
+
- Prefer explicit follow-up requests over vague warnings.
|
|
21
|
+
- Keep the integration summary machine-readable and short enough to drive relaunch decisions.
|
|
22
|
+
|
|
23
|
+
What you must do:
|
|
24
|
+
- identify open claims that are still unsupported
|
|
25
|
+
- identify conflicting claims or incompatible interface assumptions
|
|
26
|
+
- identify unresolved blockers and cross-component impacts
|
|
27
|
+
- identify proof gaps, doc gaps, and deploy or release risks that still block closure
|
|
28
|
+
- emit one final structured marker:
|
|
29
|
+
`[wave-integration] state=<ready-for-doc-closure|needs-more-work> claims=<n> conflicts=<n> blockers=<n> detail=<short-note>`
|
|
30
|
+
|
|
31
|
+
Use `ready-for-doc-closure` only when the remaining work is documentation and evaluator closure, not when material implementation or integration risk still exists.
|
|
32
|
+
```
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Wave Launcher Role"
|
|
3
|
+
summary: "Standing prompt for the operator that runs waves through the orchestrator."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Wave Launcher Role
|
|
7
|
+
|
|
8
|
+
Use this prompt when an agent or human operator should launch waves through the orchestrator.
|
|
9
|
+
|
|
10
|
+
## Standing prompt
|
|
11
|
+
|
|
12
|
+
```text
|
|
13
|
+
You are the wave launcher operator.
|
|
14
|
+
|
|
15
|
+
Your job is to run wave files safely, one wave at a time by default, while respecting launcher locks, runtime policy, clarification barriers, integration gates, documentation closure, and evaluator closure.
|
|
16
|
+
|
|
17
|
+
Before launching:
|
|
18
|
+
1. Run `pnpm exec wave doctor`.
|
|
19
|
+
2. Run `pnpm exec wave launch --lane main --dry-run --no-dashboard`.
|
|
20
|
+
3. Run `pnpm exec wave coord show --lane main --wave 0 --dry-run --json` and `pnpm exec wave coord inbox --lane main --wave 0 --agent A1 --dry-run` when you need to inspect seeded state.
|
|
21
|
+
4. Run `pnpm exec wave launch --lane main --reconcile-status`.
|
|
22
|
+
5. Run `pnpm exec wave feedback list --lane main --pending`.
|
|
23
|
+
6. Inspect `.tmp/main-wave-launcher/` state and dashboards when relevant.
|
|
24
|
+
|
|
25
|
+
Completion requires:
|
|
26
|
+
- all agents exit `0`
|
|
27
|
+
- integration must be `ready-for-doc-closure` before documentation and evaluator closure run
|
|
28
|
+
- evaluator verdict is `PASS`
|
|
29
|
+
- prompt hashes still match the current wave definitions
|
|
30
|
+
- shared-plan documentation closure is resolved when required
|
|
31
|
+
- no routed clarification chain or unresolved human escalation remains open
|
|
32
|
+
- runtime mix targets and retry fallbacks remain within lane policy
|
|
33
|
+
- live attempts write a hermetic `traceVersion: 2` trace bundle with `run-metadata.json`, `quality.json`, structured signals, copied launched-agent summaries, and recorded artifact hashes
|
|
34
|
+
|
|
35
|
+
Dry-run rule:
|
|
36
|
+
- `wave launch --dry-run` is pre-attempt only. It should seed derived state and leave `traces/` without `attempt-<k>` files.
|
|
37
|
+
```
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": 1,
|
|
3
|
+
"defaultBundle": "none",
|
|
4
|
+
"laneDefaults": {
|
|
5
|
+
"main": "none"
|
|
6
|
+
},
|
|
7
|
+
"bundles": {
|
|
8
|
+
"none": {
|
|
9
|
+
"description": "Disable Context7 prefetch for this run.",
|
|
10
|
+
"libraries": []
|
|
11
|
+
},
|
|
12
|
+
"node-typescript": {
|
|
13
|
+
"description": "Node.js and TypeScript runtime docs for JavaScript service and tooling work.",
|
|
14
|
+
"libraries": [
|
|
15
|
+
{
|
|
16
|
+
"libraryName": "nodejs",
|
|
17
|
+
"queryHint": "runtime APIs, child processes, streams, filesystem behavior, and process lifecycle"
|
|
18
|
+
},
|
|
19
|
+
{
|
|
20
|
+
"libraryName": "typescript",
|
|
21
|
+
"queryHint": "types, declarations, module resolution, tsconfig, and compiler behavior"
|
|
22
|
+
}
|
|
23
|
+
]
|
|
24
|
+
},
|
|
25
|
+
"react-web": {
|
|
26
|
+
"description": "React and Next.js docs for frontend work.",
|
|
27
|
+
"libraries": [
|
|
28
|
+
{
|
|
29
|
+
"libraryName": "react",
|
|
30
|
+
"queryHint": "components, hooks, rendering, forms, and data flow"
|
|
31
|
+
},
|
|
32
|
+
{
|
|
33
|
+
"libraryName": "nextjs",
|
|
34
|
+
"queryHint": "routing, server components, data fetching, and app router behavior"
|
|
35
|
+
}
|
|
36
|
+
]
|
|
37
|
+
},
|
|
38
|
+
"python-services": {
|
|
39
|
+
"description": "Python backend docs for API and worker services.",
|
|
40
|
+
"libraries": [
|
|
41
|
+
{
|
|
42
|
+
"libraryName": "python",
|
|
43
|
+
"queryHint": "language features, packaging, typing, and standard library behavior"
|
|
44
|
+
},
|
|
45
|
+
{
|
|
46
|
+
"libraryName": "fastapi",
|
|
47
|
+
"queryHint": "routing, request validation, dependency injection, and OpenAPI behavior"
|
|
48
|
+
}
|
|
49
|
+
]
|
|
50
|
+
},
|
|
51
|
+
"go-services": {
|
|
52
|
+
"description": "Go service and workflow docs for backend work.",
|
|
53
|
+
"libraries": [
|
|
54
|
+
{
|
|
55
|
+
"libraryName": "golang",
|
|
56
|
+
"queryHint": "packages, testing, concurrency, errors, and module layout"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"libraryName": "temporal",
|
|
60
|
+
"queryHint": "workflow setup, activities, schedules, retries, and worker bootstrap"
|
|
61
|
+
}
|
|
62
|
+
]
|
|
63
|
+
},
|
|
64
|
+
"persistence": {
|
|
65
|
+
"description": "Database and storage docs for persistence work.",
|
|
66
|
+
"libraries": [
|
|
67
|
+
{
|
|
68
|
+
"libraryName": "postgresql",
|
|
69
|
+
"queryHint": "schema changes, indexes, transactions, constraints, and query behavior"
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"libraryName": "sqlite",
|
|
73
|
+
"queryHint": "local persistence, fts, schema migration, and durability patterns"
|
|
74
|
+
}
|
|
75
|
+
]
|
|
76
|
+
},
|
|
77
|
+
"infra-ops": {
|
|
78
|
+
"description": "Infrastructure and service-manager docs for deployment and operations work.",
|
|
79
|
+
"libraries": [
|
|
80
|
+
{
|
|
81
|
+
"libraryName": "docker",
|
|
82
|
+
"queryHint": "images, builds, volumes, networking, and runtime configuration"
|
|
83
|
+
},
|
|
84
|
+
{
|
|
85
|
+
"libraryName": "systemd",
|
|
86
|
+
"queryHint": "units, dependencies, restart policies, readiness, and service management"
|
|
87
|
+
}
|
|
88
|
+
]
|
|
89
|
+
}
|
|
90
|
+
}
|
|
91
|
+
}
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
{
|
|
2
|
+
"version": 1,
|
|
3
|
+
"levels": [
|
|
4
|
+
"inventoried",
|
|
5
|
+
"contract-frozen",
|
|
6
|
+
"repo-landed",
|
|
7
|
+
"baseline-proved",
|
|
8
|
+
"pilot-live",
|
|
9
|
+
"qa-proved",
|
|
10
|
+
"fleet-ready",
|
|
11
|
+
"cutover-ready",
|
|
12
|
+
"deprecation-ready"
|
|
13
|
+
],
|
|
14
|
+
"components": {
|
|
15
|
+
"wave-parser-and-launcher": {
|
|
16
|
+
"title": "Wave parser and launcher",
|
|
17
|
+
"canonicalDocs": [
|
|
18
|
+
"README.md",
|
|
19
|
+
"docs/plans/wave-orchestrator.md"
|
|
20
|
+
],
|
|
21
|
+
"currentLevel": "repo-landed",
|
|
22
|
+
"promotions": [
|
|
23
|
+
{
|
|
24
|
+
"wave": 0,
|
|
25
|
+
"target": "repo-landed"
|
|
26
|
+
}
|
|
27
|
+
],
|
|
28
|
+
"proofSurfaces": [
|
|
29
|
+
"wave parsing",
|
|
30
|
+
"launcher dry-run",
|
|
31
|
+
"wave parser tests"
|
|
32
|
+
]
|
|
33
|
+
},
|
|
34
|
+
"executor-abstraction-and-prompt-transport": {
|
|
35
|
+
"title": "Executor abstraction and prompt transport",
|
|
36
|
+
"canonicalDocs": [
|
|
37
|
+
"README.md",
|
|
38
|
+
"docs/plans/context7-wave-orchestrator.md"
|
|
39
|
+
],
|
|
40
|
+
"currentLevel": "repo-landed",
|
|
41
|
+
"promotions": [],
|
|
42
|
+
"proofSurfaces": [
|
|
43
|
+
"executor launch specs",
|
|
44
|
+
"runtime overlays",
|
|
45
|
+
"executor tests"
|
|
46
|
+
]
|
|
47
|
+
},
|
|
48
|
+
"closure-sweep-and-role-gates": {
|
|
49
|
+
"title": "Closure sweep and role gates",
|
|
50
|
+
"canonicalDocs": [
|
|
51
|
+
"docs/plans/wave-orchestrator.md",
|
|
52
|
+
"docs/agents/wave-evaluator-role.md",
|
|
53
|
+
"docs/agents/wave-documentation-role.md"
|
|
54
|
+
],
|
|
55
|
+
"currentLevel": "repo-landed",
|
|
56
|
+
"promotions": [],
|
|
57
|
+
"proofSurfaces": [
|
|
58
|
+
"structured gate markers",
|
|
59
|
+
"closure sweep",
|
|
60
|
+
"launcher tests"
|
|
61
|
+
]
|
|
62
|
+
},
|
|
63
|
+
"context7-scope-and-prefetch": {
|
|
64
|
+
"title": "Context7 scope and prefetch",
|
|
65
|
+
"canonicalDocs": [
|
|
66
|
+
"docs/plans/context7-wave-orchestrator.md",
|
|
67
|
+
"docs/context7/bundles.json"
|
|
68
|
+
],
|
|
69
|
+
"currentLevel": "repo-landed",
|
|
70
|
+
"promotions": [],
|
|
71
|
+
"proofSurfaces": [
|
|
72
|
+
"bundle resolution",
|
|
73
|
+
"prefetch cache",
|
|
74
|
+
"prompt injection"
|
|
75
|
+
]
|
|
76
|
+
},
|
|
77
|
+
"state-artifacts-and-feedback": {
|
|
78
|
+
"title": "State artifacts and feedback",
|
|
79
|
+
"canonicalDocs": [
|
|
80
|
+
"docs/plans/wave-orchestrator.md",
|
|
81
|
+
"docs/plans/current-state.md"
|
|
82
|
+
],
|
|
83
|
+
"currentLevel": "repo-landed",
|
|
84
|
+
"promotions": [],
|
|
85
|
+
"proofSurfaces": [
|
|
86
|
+
"status summaries",
|
|
87
|
+
"dashboards",
|
|
88
|
+
"feedback queue"
|
|
89
|
+
]
|
|
90
|
+
},
|
|
91
|
+
"starter-docs-and-adoption-guidance": {
|
|
92
|
+
"title": "Starter docs and adoption guidance",
|
|
93
|
+
"canonicalDocs": [
|
|
94
|
+
"README.md",
|
|
95
|
+
"docs/plans/master-plan.md",
|
|
96
|
+
"docs/plans/migration.md"
|
|
97
|
+
],
|
|
98
|
+
"currentLevel": "repo-landed",
|
|
99
|
+
"promotions": [
|
|
100
|
+
{
|
|
101
|
+
"wave": 0,
|
|
102
|
+
"target": "repo-landed"
|
|
103
|
+
}
|
|
104
|
+
],
|
|
105
|
+
"proofSurfaces": [
|
|
106
|
+
"starter wave docs",
|
|
107
|
+
"adoption guidance",
|
|
108
|
+
"shared-plan closure"
|
|
109
|
+
]
|
|
110
|
+
}
|
|
111
|
+
}
|
|
112
|
+
}
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Component Cutover Matrix
|
|
2
|
+
|
|
3
|
+
This matrix is the canonical place to answer which harness components are expected to be working at which maturity level.
|
|
4
|
+
|
|
5
|
+
The starter entries reflect the snapshot shipped in this repository. Replace the component catalog and promotion map when you adapt the harness to a real product repo.
|
|
6
|
+
|
|
7
|
+
## Levels
|
|
8
|
+
|
|
9
|
+
- `inventoried`
|
|
10
|
+
- `contract-frozen`
|
|
11
|
+
- `repo-landed`
|
|
12
|
+
- `baseline-proved`
|
|
13
|
+
- `pilot-live`
|
|
14
|
+
- `qa-proved`
|
|
15
|
+
- `fleet-ready`
|
|
16
|
+
- `cutover-ready`
|
|
17
|
+
- `deprecation-ready`
|
|
18
|
+
|
|
19
|
+
## Components
|
|
20
|
+
|
|
21
|
+
- `wave-parser-and-launcher`: parser, manifest, launcher, and dry-run execution flow
|
|
22
|
+
- `executor-abstraction-and-prompt-transport`: executor selection, prompt overlays, and transport into `codex`, `claude`, `opencode`, or `local`
|
|
23
|
+
- `closure-sweep-and-role-gates`: documentation steward, evaluator, and post-implementation closure logic
|
|
24
|
+
- `context7-scope-and-prefetch`: Context7 bundle resolution, prefetch, cache, and prompt injection
|
|
25
|
+
- `state-artifacts-and-feedback`: status summaries, dashboards, logs, message boards, and human feedback queue
|
|
26
|
+
- `starter-docs-and-adoption-guidance`: starter README, shared-plan docs, and adoption instructions
|
|
27
|
+
|
|
28
|
+
## Current Starter Levels
|
|
29
|
+
|
|
30
|
+
| Component | Current level | Proof surfaces |
|
|
31
|
+
| --- | --- | --- |
|
|
32
|
+
| `wave-parser-and-launcher` | `repo-landed` | wave parsing, launcher dry-run, wave parser tests |
|
|
33
|
+
| `executor-abstraction-and-prompt-transport` | `repo-landed` | executor launch specs, runtime overlays, executor tests |
|
|
34
|
+
| `closure-sweep-and-role-gates` | `repo-landed` | structured gate markers, closure sweep, launcher tests |
|
|
35
|
+
| `context7-scope-and-prefetch` | `repo-landed` | bundle resolution, prefetch cache, prompt injection |
|
|
36
|
+
| `state-artifacts-and-feedback` | `repo-landed` | status summaries, dashboards, feedback queue |
|
|
37
|
+
| `starter-docs-and-adoption-guidance` | `repo-landed` | starter wave docs, adoption guidance, shared-plan closure |
|
|
38
|
+
|
|
39
|
+
## Starter Wave Promotions
|
|
40
|
+
|
|
41
|
+
- Wave 0 promotes `wave-parser-and-launcher` to `repo-landed`.
|
|
42
|
+
- Wave 0 promotes `starter-docs-and-adoption-guidance` to `repo-landed`.
|
|
43
|
+
|
|
44
|
+
## Usage
|
|
45
|
+
|
|
46
|
+
- Keep architecture and repository guidance docs descriptive.
|
|
47
|
+
- Keep wave-by-wave component maturity and promotion targets here.
|
|
48
|
+
- `currentLevel` is the canonical post-wave state of the repo, not a future plan. When a wave promotes a component, update `currentLevel` to the promoted target before closure.
|
|
49
|
+
- When component promotion gating is active, wave files must match this matrix exactly.
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
# Context7 and Wave Orchestrator
|
|
2
|
+
|
|
3
|
+
Context7 is for external library truth. Repository docs and source are for repository truth.
|
|
4
|
+
|
|
5
|
+
## Rules
|
|
6
|
+
|
|
7
|
+
- Prefer a narrow bundle per agent or wave.
|
|
8
|
+
- Keep bundle defaults and agent overrides aligned with the components the wave is promoting.
|
|
9
|
+
- Do not load broad external docs by default.
|
|
10
|
+
- Treat prefetched Context7 text as non-canonical prompt context.
|
|
11
|
+
- Keep Context7 bundle definitions in `docs/context7/bundles.json`.
|
|
12
|
+
- Launcher-side prefetch writes only to ignored cache paths under `.tmp/`.
|
|
13
|
+
|
|
14
|
+
## Setup
|
|
15
|
+
|
|
16
|
+
1. Add `CONTEXT7_API_KEY` to `.env.local` at repo root.
|
|
17
|
+
2. Export it before launching the wave runner or any executor directly:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
source scripts/context7-export-env.sh
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
3. Verify the key:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
pnpm context7:api-check
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
4. Review [docs/context7/bundles.json](../context7/bundles.json) and trim it to the external libraries your repository actually uses.
|
|
30
|
+
|
|
31
|
+
## Resolution Order
|
|
32
|
+
|
|
33
|
+
1. Agent `### Context7`
|
|
34
|
+
2. Wave `## Context7 defaults`
|
|
35
|
+
3. Lane default from `docs/context7/bundles.json`
|
|
36
|
+
4. `none`
|
|
37
|
+
|
|
38
|
+
## Bundle Authoring
|
|
39
|
+
|
|
40
|
+
Each bundle should be small and task-shaped. A bundle entry can name libraries by `libraryName` and optionally add a `queryHint` to keep fetched docs focused.
|
|
41
|
+
|
|
42
|
+
Example:
|
|
43
|
+
|
|
44
|
+
```json
|
|
45
|
+
{
|
|
46
|
+
"bundles": {
|
|
47
|
+
"node-typescript": {
|
|
48
|
+
"description": "Node.js and TypeScript runtime docs.",
|
|
49
|
+
"libraries": [
|
|
50
|
+
{
|
|
51
|
+
"libraryName": "nodejs",
|
|
52
|
+
"queryHint": "child processes, streams, filesystem, process lifecycle"
|
|
53
|
+
},
|
|
54
|
+
{
|
|
55
|
+
"libraryName": "typescript",
|
|
56
|
+
"queryHint": "module resolution, declarations, compiler behavior"
|
|
57
|
+
}
|
|
58
|
+
]
|
|
59
|
+
}
|
|
60
|
+
}
|
|
61
|
+
}
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Keep the `none` bundle defined so agents and waves can opt out explicitly.
|
|
65
|
+
|
|
66
|
+
## Wave Authoring
|
|
67
|
+
|
|
68
|
+
Wave-level default:
|
|
69
|
+
|
|
70
|
+
````md
|
|
71
|
+
## Context7 defaults
|
|
72
|
+
|
|
73
|
+
- bundle: node-typescript
|
|
74
|
+
- query: "Node process spawning and test execution"
|
|
75
|
+
````
|
|
76
|
+
|
|
77
|
+
Agent-level override:
|
|
78
|
+
|
|
79
|
+
````md
|
|
80
|
+
### Context7
|
|
81
|
+
|
|
82
|
+
- bundle: node-typescript
|
|
83
|
+
- query: "TypeScript declarations and module resolution"
|
|
84
|
+
````
|
|
85
|
+
|
|
86
|
+
## Injection
|
|
87
|
+
|
|
88
|
+
When a bundle is active, the launcher injects:
|
|
89
|
+
|
|
90
|
+
- the resolved bundle id
|
|
91
|
+
- the resolved query focus
|
|
92
|
+
- the allowed library list
|
|
93
|
+
- prefetched third-party snippets when available
|
|
94
|
+
|
|
95
|
+
The injected block appears before the assigned implementation prompt and is labeled non-canonical. This injection is executor-agnostic.
|
|
96
|
+
|
|
97
|
+
Wave coordination state is injected separately from Context7:
|
|
98
|
+
|
|
99
|
+
- a compiled shared summary from `.tmp/<lane>-wave-launcher/inboxes/wave-<n>/shared-summary.md`
|
|
100
|
+
- a compiled per-agent inbox from `.tmp/<lane>-wave-launcher/inboxes/wave-<n>/<agent-id>.md`
|
|
101
|
+
|
|
102
|
+
Those inbox artifacts are repository-state summaries. Context7 stays reserved for third-party library truth.
|
|
103
|
+
|
|
104
|
+
## Runtime Behavior
|
|
105
|
+
|
|
106
|
+
- Prefetch happens in the launcher before the agent session starts.
|
|
107
|
+
- Shared summary and per-agent inbox compilation also happen in the launcher before the executor is invoked.
|
|
108
|
+
- Cache files are written under `.tmp/<lane>-wave-launcher/context7-cache/`.
|
|
109
|
+
- Compiled inboxes are written under `.tmp/<lane>-wave-launcher/inboxes/`.
|
|
110
|
+
- Executor runtime overlays are written under `.tmp/<lane>-wave-launcher/executors/`.
|
|
111
|
+
- The resolved Context7 selection becomes part of the prompt fingerprint, so changing bundle or query invalidates prior success reuse.
|
|
112
|
+
- If `CONTEXT7_API_KEY` is missing, prefetch is disabled with a warning and the wave continues.
|
|
113
|
+
- If the Context7 API errors, the launcher fails open and starts the agent without the injected snippets.
|
|
114
|
+
- Use `--no-context7` when you want to force repository-only context for a run.
|
|
115
|
+
|
|
116
|
+
## Prompt Layering
|
|
117
|
+
|
|
118
|
+
- `codex`
|
|
119
|
+
The generated task prompt already contains the compiled shared summary, the compiled agent inbox, and the injected Context7 block. It is piped directly into `codex exec`.
|
|
120
|
+
- `claude`
|
|
121
|
+
The generated task prompt contains the compiled shared summary, the compiled agent inbox, and the injected Context7 block. The harness also writes a runtime system-prompt overlay and passes it with `--append-system-prompt-file` by default, or `--system-prompt-file` if `executors.claude.appendSystemPromptMode` is set to `replace`.
|
|
122
|
+
- `opencode`
|
|
123
|
+
The generated task prompt contains the compiled shared summary, the compiled agent inbox, and the injected Context7 block. The harness writes a temporary `opencode.json` plus an agent prompt file under `.tmp/.../executors/`, points `OPENCODE_CONFIG` at that overlay, and launches `opencode run`.
|
|
124
|
+
|
|
125
|
+
## Guidance
|
|
126
|
+
|
|
127
|
+
- Use Context7 for external library truth, setup syntax, SDK details, and version-specific API behavior.
|
|
128
|
+
- Do not use Context7 for repository architecture, plan decisions, ownership rules, or internal contracts.
|
|
129
|
+
- Prefer one active backend family in a bundle instead of mixing competing frameworks.
|
|
130
|
+
- Keep queries specific enough that the prefetched block stays small and useful.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Current State
|
|
2
|
+
|
|
3
|
+
- The repository contains the published `@chllming/wave-orchestration` package plus the starter scaffold used by `wave init`.
|
|
4
|
+
- 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/`.
|
|
5
|
+
- This source repo is itself kept as an adopted Wave workspace, so `node scripts/wave.mjs doctor --json` should pass from the repo root.
|
|
6
|
+
- The default lane is `main`.
|
|
7
|
+
- The harness supports `codex`, `claude`, `opencode`, and `local` executors.
|
|
8
|
+
- The runtime now includes:
|
|
9
|
+
- a canonical coordination JSONL log
|
|
10
|
+
- a generated markdown board projection
|
|
11
|
+
- compiled shared summaries and per-agent inboxes
|
|
12
|
+
- a per-wave ledger
|
|
13
|
+
- docs queues
|
|
14
|
+
- explicit integration summaries with actionable claim, interface, proof, docs, and deploy-risk evidence
|
|
15
|
+
- hermetic `traceVersion: 2` per-attempt trace bundles with copied launched-agent summaries, copied component matrices for promoted waves, a hashed `outcome.json` replay baseline, run metadata, and cumulative quality metrics
|
|
16
|
+
- an internal, read-only replay validator for trace bundles, with legacy `traceVersion: 1` bundles kept in best-effort warning mode
|
|
17
|
+
- orchestrator-first clarification triage plus human escalation artifacts
|
|
18
|
+
- Runtime executor support now includes:
|
|
19
|
+
- Codex `exec` profile, inline config, search, image, add-dir, JSON, and ephemeral flags
|
|
20
|
+
- Claude settings overlay merging for inline settings and hooks
|
|
21
|
+
- OpenCode merged config overlays plus multi-file attachments
|
|
22
|
+
- dry-run prompt and executor-preview materialization under `.tmp/<lane>-wave-launcher/dry-run/`
|
|
23
|
+
- Full runtime configuration reference pages now ship under `docs/reference/runtime-config/`.
|
|
24
|
+
- Lane runtime policy is active through `wave.config.json`:
|
|
25
|
+
- role-based default executors
|
|
26
|
+
- executor profiles
|
|
27
|
+
- hard runtime mix targets
|
|
28
|
+
- retry-time fallback order
|
|
29
|
+
- generic runtime budgets
|
|
30
|
+
- Capability routing is now first-class:
|
|
31
|
+
- open capability-targeted requests become explicit helper assignments
|
|
32
|
+
- helper assignments are written into coordination state, the ledger, summaries, and traces
|
|
33
|
+
- helper assignments remain blocking until the linked follow-up resolves
|
|
34
|
+
- Closure now runs in staged order: implementation and proof, then `A8` integration, then `A9` documentation, then `A0` evaluator.
|
|
35
|
+
- Routed clarifications remain blocking until the linked follow-up request or escalation is fully resolved.
|
|
36
|
+
- Required inbound cross-lane dependency tickets under `.tmp/wave-orchestrator/dependencies/` block both autonomous wave launch and lane finalization while they remain unresolved.
|
|
37
|
+
- Cross-lane dependency workflows now include:
|
|
38
|
+
- `wave dep post|show|resolve|render`
|
|
39
|
+
- per-wave inbound/outbound dependency snapshots under `.tmp/<lane>-wave-launcher/dependencies/`
|
|
40
|
+
- dependency-aware gating, inboxes, dashboards, and replay artifacts
|
|
41
|
+
- Dry-run remains pre-attempt only: it seeds derived state under `.tmp/<lane>-wave-launcher/dry-run/` and leaves `traces/` file-empty.
|
|
42
|
+
- Component maturity and starter wave promotions are tracked in `docs/plans/component-cutover-matrix.md` and `docs/plans/component-cutover-matrix.json`.
|
|
43
|
+
- Context7 bundle selection and launcher-side prompt injection are enabled through `docs/context7/bundles.json`.
|
|
44
|
+
- Research source links are committed in `docs/research/agent-context-sources.md`; hydrated caches stay local and ignored.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Master Plan
|
|
2
|
+
|
|
3
|
+
## Goals
|
|
4
|
+
|
|
5
|
+
- Keep the orchestrator generic enough to reuse across repositories.
|
|
6
|
+
- Preserve the working runtime features from the original implementation.
|
|
7
|
+
- Keep repo-specific policy in config and docs, not in engine code.
|
|
8
|
+
- Keep external-doc use narrow, explicit, and non-canonical.
|
|
9
|
+
|
|
10
|
+
## Near-Term Work
|
|
11
|
+
|
|
12
|
+
- Keep the starter wave, role prompts, and component cutover matrix aligned with the shipped launcher behavior.
|
|
13
|
+
- Expand `wave doctor` and migration guidance around cross-repo adoption, executor availability, and future breaking config changes.
|
|
14
|
+
- Add richer starter templates for additional repository shapes after the generic single-repo path is stable.
|
|
15
|
+
- Extend replay and trace tooling from internal helpers and file-backed artifacts into easier operator workflows, larger historical fixtures, and a public replay surface if it proves stable.
|
|
16
|
+
- Add the remaining roadmap items that are not yet shipped, especially richer capability routing and better operator workflows around cross-lane dependency tickets.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Migration
|
|
2
|
+
|
|
3
|
+
## Default Adoption Path
|
|
4
|
+
|
|
5
|
+
1. Install from the current GitHub Packages path as described in [github-packages-setup.md](../reference/github-packages-setup.md).
|
|
6
|
+
2. Install the package with `pnpm add -D @chllming/wave-orchestration`.
|
|
7
|
+
3. For a fresh repo, run `pnpm exec wave init`.
|
|
8
|
+
4. For a repo that already has Wave config, docs, or waves you want to preserve, run `pnpm exec wave init --adopt-existing`.
|
|
9
|
+
5. Edit `wave.config.json` for the repo's docs, roles, validation rules, executor defaults, and component-cutover matrix paths.
|
|
10
|
+
6. Replace the starter plan docs, sample waves, and component cutover matrix with repository-specific ones.
|
|
11
|
+
7. Configure Context7 bundles for the external libraries that repo actually uses.
|
|
12
|
+
8. Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` until validation passes.
|
|
13
|
+
9. Inspect seeded coordination and inbox artifacts with `pnpm exec wave coord show --lane main --wave 0 --dry-run --json` and `pnpm exec wave coord inbox --lane main --wave 0 --agent A1 --dry-run`.
|
|
14
|
+
10. Upgrade later with `pnpm up @chllming/wave-orchestration` and `pnpm exec wave upgrade`.
|
|
15
|
+
|
|
16
|
+
`wave-orchestration` also ships an npmjs trusted-publishing workflow for future zero-token installs, but that path is only active after the first npmjs release is published from this repo. Maintainer setup is documented in [npmjs-trusted-publishing.md](../reference/npmjs-trusted-publishing.md).
|
|
17
|
+
|
|
18
|
+
## Upgrade Contract
|
|
19
|
+
|
|
20
|
+
- Package upgrades change the runtime behavior in `node_modules`; they do not copy a new starter scaffold into the repo.
|
|
21
|
+
- `wave upgrade` writes `.wave/install-state.json` and `.wave/upgrade-history/*` only.
|
|
22
|
+
- Existing `wave.config.json`, role prompts, plan docs, Context7 bundles, and wave files are never overwritten by the upgrade flow.
|
|
23
|
+
- The current runtime expects the post-roadmap model: typed coordination, compiled inboxes, `A8` integration, staged closure, orchestrator-first clarification, and operational runtime policy.
|