@chllming/wave-orchestration 0.6.3 → 0.7.0

package/skills/runtime-codex/SKILL.md

@@ -44,6 +44,7 @@ All context is in the prompt and added directories. There is no system prompt la
 - **No persistent state** -- each session starts clean. Do not rely on artifacts from previous sessions unless they are committed to the repo.
 - **Filesystem scope** -- write only to paths within the workspace. The sandbox may reject writes outside the project root.
 - **External APIs** -- avoid calling external APIs unless the task explicitly requires live verification. If network is unavailable, record the gap as a proof limitation.
+- **Runtime state** -- do not edit files under `.tmp/` (coordination logs, control-plane events, proof registries, dashboards, traces). These are managed by the launcher and operator tooling. You may read them when they appear in `--add-dir` bundles.
 
 <!-- CUSTOMIZE: List allowed network targets or external API endpoints for your project here. -->
 

package/skills/runtime-local/SKILL.md

@@ -31,6 +31,8 @@ When running a local smoke validation, verify each of the following:
 5. **Skill resolution** -- all skills referenced in the wave definition resolve to existing skill directories with valid `skill.json` and `SKILL.md` files.
 6. **Context bundle integrity** -- if overlays or context bundles are generated, they exist at the declared paths and are non-empty.
 7. **Role assignment consistency** -- each agent has exactly one role, and the role matches a known role skill.
+8. **Proof artifact declarations** -- if the wave declares `### Proof artifacts`, verify the paths are concrete and plausible. Local smoke cannot verify artifact content but can validate declaration structure.
+9. **Control-plane readiness** -- verify the control-plane directory structure exists. Local smoke validates directory layout, not event content.
 
 Report each check as pass, fail, or skip with a one-line reason.
 

package/skills/runtime-opencode/SKILL.md

@@ -46,6 +46,7 @@ Both the agent prompt and injected instructions are authoritative. When they con
 - When an edit depends on understanding adjacent code, read the relevant context first.
 - If a needed change falls outside your ownership, record it as a follow-up request naming the owning agent, the file, and the change.
 - Generated overlays (context bundles, summaries) are read-only reference. Do not edit overlay files.
+- Do not edit files under `.tmp/` (coordination logs, control-plane events, proof registries, dashboards, traces). These are managed by the launcher and operator tooling.
 
 ## Customization
 

package/skills/wave-core/SKILL.md

@@ -14,7 +14,7 @@
 
 ## Coordination Protocol
 
-1. Read the shared summary and your inbox at the start of every major step.
+1. Read the shared summary and your inbox at the start of every major step. Summaries and inboxes may refresh during execution, so re-read before major decisions.
 2. Post a coordination record when any of these occur:
    - meaningful progress on an exit contract deliverable
    - a blocker is discovered or resolved
@@ -26,7 +26,21 @@
 4. Do not batch coordination. Post records as events occur so downstream agents see them promptly.
 5. When a record references another agent, name that agent explicitly.
 6. Coordination records are append-only. Do not edit or delete previous records; post corrections as new records.
-7. When you receive an inbox message that requires action, acknowledge it with a coordination record before proceeding.
+7. When you receive an inbox message that requires action, acknowledge it with a coordination record before proceeding. Unacknowledged requests become overdue and may be rerouted.
+
+## Coordination State
+
+The canonical coordination state is the JSONL log under `.tmp/<lane>-wave-launcher/coordination/`. The markdown board is a generated projection for human reading, not the scheduler truth.
+
+Operator tasks, rerun requests, proof bundles, and attempt lifecycle are tracked in a separate control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/`. Proof registries and retry overrides under `proof/` and `control/` are projections from this log.
+
+Operators interact through `wave control`:
+- `wave control status` — why the wave is blocked or retrying.
+- `wave control task` — create, list, and act on coordination tasks.
+- `wave control rerun` — targeted retry intent.
+- `wave control proof` — authoritative proof bundle lifecycle.
+
+Legacy `wave coord`, `wave retry`, and `wave proof` remain available as compatibility surfaces.
 
 ## Ownership & Boundaries
 
@@ -46,6 +60,8 @@
 - Runtime-facing proof must be real evidence (logs, health checks, build output), not future-work notes.
 - Proof must be durable. Transient output (terminal scrollback, ephemeral logs) is not proof unless captured into a file.
 - When proof cannot be produced within the wave, record the gap explicitly with the reason and the follow-up owner.
+- When the wave declares `### Proof artifacts`, those machine-visible local artifacts are required for closure in addition to deliverables and structured markers.
+- Operators may register authoritative proof bundles via `wave control proof register`. Registered proof has lifecycle state: `active`, `superseded`, or `revoked`. Only active bundles satisfy closure. Do not rely on proof that has been revoked or superseded.
 
 ## Closure Checklist
 
@@ -65,13 +81,16 @@ If any condition is not met, the wave remains open. Do not approximate closure.
 
 Closure runs in staged order:
 1. Implementation and proof (all implementation agents).
-2. cont-EVAL (if present) -- must report `satisfied` before integration runs.
-3. Integration -- must report `ready-for-doc-closure` before documentation and cont-QA run.
-4. Documentation -- must report `closed` or `no-change`.
-5. cont-QA -- final verdict. Only PASS allows the wave to close.
+2. Optional security review -- must report `clear` or `concerns` before integration.
+3. cont-EVAL (if present) -- must report `satisfied` before integration runs.
+4. Integration -- must report `ready-for-doc-closure` before documentation and cont-QA run.
+5. Documentation -- must report `closed` or `no-change`.
+6. cont-QA -- final verdict. Only PASS allows the wave to close.
 
 Do not skip stages. Each stage depends on the prior stage completing.
 
+An active rerun request blocks closure until consumed. If the operator has filed a rerun via `wave control rerun request`, the launcher applies it on the next retry and clears it afterward.
+
 ## Structured Markers Reference
 
 Emit markers exactly as shown. Parsers depend on the format.

package/skills/wave-core/references/marker-syntax.md

@@ -17,34 +17,42 @@ Example:
 ## wave-eval (cont-EVAL closure)
 Emitted by: cont-EVAL agent (E0)
 Format:
-`[wave-eval] state=<satisfied|needs-more-work|blocked> target_ids=<comma-separated-ids> benchmark_ids=<comma-separated-ids> detail=<short-note>`
+`[wave-eval] state=<satisfied|needs-more-work|blocked> targets=<n> benchmarks=<n> regressions=<n> target_ids=<comma-separated-ids> benchmark_ids=<comma-separated-ids> detail=<short-note>`
 
 Example:
-`[wave-eval] state=satisfied target_ids=prompt-quality,response-accuracy benchmark_ids=bench-01,bench-02 detail=all-targets-within-threshold`
+`[wave-eval] state=satisfied targets=2 benchmarks=2 regressions=0 target_ids=prompt-quality,response-accuracy benchmark_ids=bench-01,bench-02 detail=all-targets-within-threshold`
 
 ## wave-integration (integration closure)
 Emitted by: Integration steward (A8)
 Format:
-`[wave-integration] state=<ready-for-doc-closure|needs-more-work> blockers=<count> detail=<short-note>`
+`[wave-integration] state=<ready-for-doc-closure|needs-more-work> claims=<n> conflicts=<n> blockers=<n> detail=<short-note>`
 
 Example:
-`[wave-integration] state=ready-for-doc-closure blockers=0 detail=all-agents-coherent-no-contradictions`
+`[wave-integration] state=ready-for-doc-closure claims=0 conflicts=0 blockers=0 detail=all-agents-coherent-no-contradictions`
 
 ## wave-doc-closure (documentation closure)
 Emitted by: Documentation steward (A9)
 Format:
-`[wave-doc-closure] state=<closed|no-change|needs-work> affected=<comma-separated-file-list> detail=<short-note>`
+`[wave-doc-closure] state=<closed|no-change|delta> paths=<comma-separated-file-list> detail=<short-note>`
 
 Example:
-`[wave-doc-closure] state=closed affected=docs/plans/current-state.md,docs/plans/component-cutover-matrix.md detail=status-and-ownership-updated`
+`[wave-doc-closure] state=closed paths=docs/plans/current-state.md,docs/plans/component-cutover-matrix.md detail=status-and-ownership-updated`
+
+## wave-security (security review)
+Emitted by: Security reviewer
+Format:
+`[wave-security] state=<clear|concerns|blocked> findings=<n> approvals=<n> detail=<short-note>`
+
+Example:
+`[wave-security] state=clear findings=0 approvals=0 detail=no-blocking-security-findings`
 
 ## infra-status (infrastructure verification)
 Emitted by: Infra agent
 Format:
-`[infra-status] kind=<conformance|role-drift|dependency|identity|admission|action> surface=<name> state=<pass|warn|fail> detail=<short-note>`
+`[infra-status] kind=<conformance|role-drift|dependency|identity|admission|action> target=<surface> state=<checking|setup-required|setup-in-progress|conformant|drift|blocked|failed|action-required|action-approved|action-complete> detail=<short-note>`
 
 Example:
-`[infra-status] kind=dependency surface=node-22 state=pass detail=node-v22.15.0-confirmed`
+`[infra-status] kind=dependency target=node-22 state=conformant detail=node-v22.15.0-confirmed`
 
 ## deploy-status (deployment verification)
 Emitted by: Deploy agent

package/wave.config.json

@@ -60,6 +60,20 @@
           "minutes": 20
         }
       },
+      "planning-readonly": {
+        "id": "codex",
+        "model": "gpt-5-codex",
+        "tags": ["planning", "review"],
+        "budget": {
+          "minutes": 30
+        },
+        "codex": {
+          "search": true,
+          "json": true,
+          "sandbox": "read-only",
+          "config": ["model_reasoning_effort=high"]
+        }
+      },
       "security-review": {
         "id": "claude",
         "tags": ["security", "review"],
@@ -125,6 +139,37 @@
       "custom": ["provider-custom-deploy"]
     }
   },
+  "planner": {
+    "agentic": {
+      "executorProfile": "planning-readonly",
+      "defaultMaxWaves": 3,
+      "maxReplanIterations": 1,
+      "context7Bundle": "planner-agentic",
+      "context7Query": "Wave planning best practices, maturity alignment, closure gates, proof surfaces, rollout evidence, and coordination failure prevention",
+      "coreContextPaths": [
+        "AGENTS.md",
+        "wave.config.json",
+        "docs/roadmap.md",
+        "docs/plans/current-state.md",
+        "docs/plans/master-plan.md",
+        "docs/plans/wave-orchestrator.md",
+        "docs/reference/sample-waves.md",
+        "docs/plans/examples/wave-example-rollout-fidelity.md",
+        "docs/plans/examples/wave-example-live-proof.md",
+        "docs/reference/live-proof-waves.md",
+        "docs/plans/component-cutover-matrix.md",
+        "docs/plans/component-cutover-matrix.json",
+        "docs/reference/wave-planning-lessons.md",
+        "docs/research/coordination-failure-review.md"
+      ],
+      "lessonsPaths": [
+        "docs/reference/wave-planning-lessons.md"
+      ],
+      "researchTopicPaths": [
+        "docs/context7/planner-agent/topics/planning-and-orchestration.md"
+      ]
+    }
+  },
   "sharedPlanDocs": [
     "docs/plans/current-state.md",
     "docs/plans/master-plan.md",