@chllming/wave-orchestration 0.5.4 → 0.6.0

package/docs/guides/author-and-run-waves.md

@@ -0,0 +1,135 @@
+# Authoring And Running Waves
+
+This is the shortest path from "I need a new wave" to "the launcher is ready to run it."
+
+Use this guide first. The narrower planner and terminal-surface pages remain useful when you need extra detail, but most operators should not need to assemble the workflow from multiple docs.
+
+## 1. Set Repo Defaults Once
+
+Start by teaching the planner how this repo usually works:
+
+```bash
+pnpm exec wave project setup
+pnpm exec wave project show --json
+```
+
+The saved project profile remembers:
+
+- default oversight mode
+- default terminal surface
+- default draft template
+- default lane
+- typed deploy environments
+
+That keeps later drafts consistent and removes repeated bootstrap questions.
+
+## 2. Draft The Wave
+
+Generate a structured draft:
+
+```bash
+pnpm exec wave draft --wave 1 --template implementation
+```
+
+The planner writes two artifacts:
+
+- `docs/plans/waves/specs/wave-<n>.json`
+- `docs/plans/waves/wave-<n>.md`
+
+The JSON spec is the planner-owned structured artifact. The markdown wave is still the launcher-owned execution surface.
+
+When you review the generated wave, tighten the parts the planner cannot fully infer:
+
+- file ownership
+- validation commands
+- proof artifacts
+- `cont-EVAL` targets when needed
+- security review expectations when needed
+- explicit `### Skills` only where defaults are not enough
+
+If you want examples of denser hand-authored waves, read [docs/reference/sample-waves.md](../reference/sample-waves.md).
+
+## 3. Choose The Execution Posture
+
+Every wave should be authored with an explicit operating posture in mind:
+
+- `oversight`
+  Best default. Use when a human may need to inspect progress, answer clarifications, or approve risky steps.
+- `dark-factory`
+  Use only when environments, validation, rollback, and closure evidence are already explicit enough for routine execution without human intervention.
+
+Human feedback is an escalation path, not the operating mode itself. The launcher still tries to resolve clarification inside the orchestration loop before creating a human ticket.
+
+## 4. Choose The Operator Surface
+
+Live runs always execute in `tmux`. The terminal surface only decides how you attach:
+
+- `vscode`
+  VS Code gets temporary attach entries for the live tmux sessions.
+- `tmux`
+  Terminal-native operation with no VS Code integration.
+- `none`
+  Dry-run only.
+
+Recommended defaults:
+
+- local interactive work: `vscode`
+- remote shell or devbox: `tmux`
+- CI or validation-only work: `none` with `--dry-run`
+
+## 5. Dry-Run Before Live Execution
+
+Treat dry-run as the quality gate for the authored wave:
+
+```bash
+pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --dry-run --no-dashboard
+```
+
+Check that the dry-run artifacts reflect the wave you meant to author:
+
+- resolved executors and overlays look correct
+- ownership is narrow and explicit
+- skills and Context7 inputs are attached where expected
+- proof and closure requirements match the actual task
+- no ambiguous prompts or missing deliverables remain
+
+## 6. Launch Live
+
+When the dry-run artifacts look correct, launch the wave with the operator surface you actually want:
+
+```bash
+pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --terminal-surface vscode
+pnpm exec wave launch --lane main --start-wave 1 --end-wave 1 --terminal-surface tmux --keep-sessions
+```
+
+Useful flags:
+
+- `--no-dashboard`
+  Skip the dashboard session.
+- `--keep-sessions`
+  Preserve tmux sessions for inspection after the wave completes.
+- `--keep-terminals`
+  Preserve temporary VS Code terminal entries.
+
+## 7. Understand Closure
+
+A wave is not done when an implementation agent says it is done. Closure depends on the combined runtime surfaces:
+
+- implementation contracts pass
+- required deliverables exist
+- proof artifacts exist when the wave requires them
+- dependencies and helper assignments are resolved
+- `cont-EVAL` satisfies declared targets when present
+- security review publishes its report and final marker when present
+- integration, docs, and `cont-QA` all pass
+
+For the detailed execution model, read [docs/concepts/what-is-a-wave.md](../concepts/what-is-a-wave.md).
+
+## Supporting Detail
+
+Use these pages when you need deeper detail rather than the main workflow:
+
+- [docs/guides/planner.md](./planner.md)
+- [docs/guides/terminal-surfaces.md](./terminal-surfaces.md)
+- [docs/concepts/operating-modes.md](../concepts/operating-modes.md)
+- [docs/reference/runtime-config/README.md](../reference/runtime-config/README.md)

package/docs/guides/planner.md

@@ -2,6 +2,8 @@
 
 The planner foundation is the first structured authoring layer on top of the existing wave runtime.
 
+If you want the full author-to-launch workflow, start with [author-and-run-waves.md](./author-and-run-waves.md). This page stays focused on planner-specific behavior.
+
 It reduces repeated setup questions, stores project defaults, and generates wave specs plus markdown that already fit the launcher.
 
 ## What Ships Today
@@ -103,6 +105,8 @@ So planner structure and skill resolution already reinforce each other.
 5. Run `pnpm exec wave launch --lane <lane> --start-wave <n> --end-wave <n> --dry-run --no-dashboard`.
 6. Only launch live once the dry-run artifacts look correct.
 
+If you want concrete authored examples after the planner baseline, see [docs/reference/sample-waves.md](../reference/sample-waves.md).
+
 ## Best Practices
 
 - Treat the generated draft as a strong starting point, not untouchable output.
@@ -111,3 +115,4 @@ So planner structure and skill resolution already reinforce each other.
 - Add explicit `### Skills` only when the lane, role, runtime, and deploy-kind defaults are not enough.
 - Use the component matrix as a planning contract, not just a reporting surface.
 - Prefer updating the project profile when the same answers recur across waves.
+- Use [docs/reference/sample-waves.md](../reference/sample-waves.md) when you want examples of denser human-authored waves that combine multiple modern surfaces such as `cont-EVAL`, delegated benchmark families, or proof-first live validation.

package/docs/guides/terminal-surfaces.md

@@ -1,5 +1,7 @@
 # Terminal Surfaces And Dashboards
 
+If you want the end-to-end drafting and live-run workflow, start with [author-and-run-waves.md](./author-and-run-waves.md). This page stays focused on terminal-surface details.
+
 Wave has separate concepts for execution substrate and operator surface.
 
 The important detail is:

package/docs/plans/component-cutover-matrix.json

@@ -49,7 +49,7 @@
       "title": "Closure sweep and role gates",
       "canonicalDocs": [
         "docs/plans/wave-orchestrator.md",
-        "docs/agents/wave-evaluator-role.md",
+        "docs/agents/wave-cont-qa-role.md",
         "docs/agents/wave-documentation-role.md"
       ],
       "currentLevel": "repo-landed",

package/docs/plans/component-cutover-matrix.md

@@ -20,7 +20,7 @@ The starter entries reflect the snapshot shipped in this repository. Replace the
 
 - `wave-parser-and-launcher`: parser, manifest, launcher, and dry-run execution flow
 - `executor-abstraction-and-prompt-transport`: executor selection, prompt overlays, and transport into `codex`, `claude`, `opencode`, or `local`
-- `closure-sweep-and-role-gates`: documentation steward, evaluator, and post-implementation closure logic
+- `closure-sweep-and-role-gates`: documentation steward, cont-QA, and post-implementation closure logic
 - `context7-scope-and-prefetch`: Context7 bundle resolution, prefetch, cache, and prompt injection
 - `state-artifacts-and-feedback`: status summaries, dashboards, logs, message boards, and human feedback queue
 - `starter-docs-and-adoption-guidance`: starter README, shared-plan docs, and adoption instructions

package/docs/plans/current-state.md

@@ -1,5 +1,6 @@
 # Current State
 
+- The starter workspace in this source repo reflects the `0.6.0` package release surface.
 - The repository contains the published `@chllming/wave-orchestration` package plus the starter scaffold used by `wave init`.
 - The runtime is package-first and non-destructive for adopting repos: `wave init --adopt-existing` records existing repo-owned plans, waves, prompts, and config without overwriting them, and `wave upgrade` writes only `.wave/install-state.json` plus `.wave/upgrade-history/`.
 - This source repo is itself kept as an adopted Wave workspace, so `node scripts/wave.mjs doctor --json` should pass from the repo root.
@@ -8,6 +9,14 @@
   - `.wave/project-profile.json` stores default oversight mode, terminal surface, draft template, lane, and deploy-environment memory
   - `wave project setup|show` manage that profile
   - `wave draft` writes planner JSON specs plus launcher-compatible markdown waves
+- Ad-hoc task runs are now first-class:
+  - `wave adhoc plan|run|list|show|promote` manage transient operator-driven work
+  - requests, generated specs, rendered markdown, and final results live under `.wave/adhoc/runs/<run-id>/`
+  - runtime state stays isolated under `.tmp/<lane>-wave-launcher/adhoc/<run-id>/`
+  - ad-hoc runs always keep integration, documentation, and cont-QA closure, while `cont-EVAL` and security review are synthesized only when the request needs them
+  - documentation closure still queues canonical shared-plan docs when a run reports a shared-plan delta, alongside the ad-hoc closure report
+  - `wave adhoc promote` copies the stored ad-hoc spec into numbered roadmap artifacts instead of re-deriving it from the current project profile
+  - repo-local path hints become owned paths; external references such as URLs are ignored
 - The harness supports `codex`, `claude`, `opencode`, and `local` executors.
 - Cross-runtime skills are now first-class:
   - canonical bundles live under `skills/`
@@ -21,13 +30,18 @@
   - a per-wave ledger
   - docs queues
   - explicit integration summaries with actionable claim, interface, proof, docs, and deploy-risk evidence
+  - versioned runtime artifact contracts for manifests, dashboards, relaunch plans, helper-assignment snapshots, dependency snapshots, and run-state
+  - append-only `run-state.json` history with per-wave current state, compatibility `completedWaves`, and causal completion or blocker evidence
   - 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
   - an internal, read-only replay validator for trace bundles, with legacy `traceVersion: 1` bundles kept in best-effort warning mode
   - orchestrator-first clarification triage plus human escalation artifacts
+  - persisted relaunch plans under `.tmp/<lane>-wave-launcher/status/` so targeted retry intent can survive a launcher restart
+  - a thinner launcher entrypoint that now delegates session launch or wait and closure-sweep orchestration to dedicated modules while preserving the existing CLI surface
 - Runtime executor support now includes:
   - Codex `exec` profile, inline config, search, image, add-dir, JSON, and ephemeral flags
   - Claude settings overlay merging for inline settings and hooks
   - OpenCode merged config overlays plus multi-file attachments
+  - per-agent 429/rate-limit retries for Codex, Claude Code, and OpenCode via `--agent-rate-limit-*`
   - dry-run prompt and executor-preview materialization under `.tmp/<lane>-wave-launcher/dry-run/`
   - operator-selectable terminal surfaces: `vscode`, `tmux`, or `none` for dry-run only
 - Full runtime configuration reference pages now ship under `docs/reference/runtime-config/`.
@@ -37,11 +51,15 @@
   - hard runtime mix targets
   - retry-time fallback order
   - generic runtime budgets
+  - sticky retry policy for proof-centric owners unless fallback is explicitly enabled
 - Capability routing is now first-class:
   - open capability-targeted requests become explicit helper assignments
   - helper assignments are written into coordination state, the ledger, summaries, and traces
   - helper assignments remain blocking until the linked follow-up resolves
-- Closure now runs in staged order: implementation and proof, then `A8` integration, then `A9` documentation, then `A0` evaluator.
+- Closure now runs in staged order: implementation and proof, then optional `E0` cont-EVAL, then optional security review, then `A8` integration, then `A9` documentation, then `A0` cont-QA.
+- `E0` is hybrid: planner-generated waves keep it report-only, while hand-authored waves may assign explicit tuning files and thereby make `E0` participate in implementation proof gating.
+- Live closure is strict: `cont-EVAL` must prove the declared eval contract with exact target and benchmark ids, and `cont-QA` must provide both final verdict and final gate artifacts. Legacy evaluator-era shapes remain replay-only compatibility inputs.
+- Proof-centric waves can now declare `### Proof artifacts`, and implementation proof validation can require those machine-visible local artifacts in addition to deliverables and structured proof markers.
 - Routed clarifications remain blocking until the linked follow-up request or escalation is fully resolved.
 - Required inbound cross-lane dependency tickets under `.tmp/wave-orchestrator/dependencies/` block both autonomous wave launch and lane finalization while they remain unresolved.
 - Cross-lane dependency workflows now include:

package/docs/plans/examples/wave-example-live-proof.md

@@ -0,0 +1,435 @@
+# Wave 14 - Example Full Modern Release Surface
+
+This is a showcase-first sample wave.
+
+Use it as the single reference example for the current `0.6.0` Wave surface.
+
+It intentionally combines more sections than a normal production wave so one file can demonstrate:
+
+- standard closure roles (`A0`, `E0`, `A8`, `A9`)
+- `## Eval targets` with delegated and pinned benchmark selection
+- richer `### Executor` blocks, budgets, and sticky retry
+- `### Skills`
+- `### Capabilities`
+- `### Deliverables`
+- `### Exit contract`
+- proof-first live validation with `### Proof artifacts`
+- `## Deploy environments`
+- infra and deploy-verifier specialists
+
+This example is intentionally denser than a launch-minimal wave. Its job is to teach the full authored surface in one place.
+
+**Commit message**: `Docs: add full modern sample wave`
+
+## Component promotions
+
+- learning-memory-action-plane: pilot-live
+- executor-abstraction-and-prompt-transport: baseline-proved
+
+## Deploy environments
+
+- prod: kubernetes default (primary production cluster)
+- staging: custom-deploy (manual preflight and recovery flow)
+
+## Eval targets
+
+- id: live-proof-fidelity | selection: delegated | benchmark-family: blackboard-fidelity | objective: Preserve machine-visible live proof through summaries, inboxes, and integration closure | threshold: Critical live-proof facts remain visible through final closure
+- id: contradiction-recovery | selection: pinned | benchmarks: claim-conflict-detection,evidence-based-repair | objective: Surface and repair conflicting live claims before PASS | threshold: Material contradictions become explicit repair work before final closure
+- id: silo-escape | selection: delegated | benchmark-family: silo-escape | objective: Reconstruct the correct global state from distributed live and repo evidence | threshold: Integration closure reflects the full cross-agent state instead of partial local views
+
+## Context7 defaults
+
+- bundle: node-typescript
+- query: "Orchestration state machines, retry policy, summary fidelity, and durable validation for coding agents"
+
+## Agent A0: cont-QA
+
+### Role prompts
+
+- docs/agents/wave-cont-qa-role.md
+
+### Executor
+
+- id: claude
+- model: claude-sonnet-4-6
+- claude.allowed_tools: Read,Glob
+
+### Context7
+
+- bundle: none
+
+### Prompt
+
+```text
+Primary goal:
+- Treat live proof as a real closure input, not as a narrative claim.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/master-plan.md, docs/plans/current-state.md, and docs/plans/migration.md.
+
+Specific expectations:
+- do not PASS unless the declared proof artifacts exist locally
+- do not infer host truth from stale repo-local snapshots
+- rely on the declared proof bundle, integration summary, and doc closure state
+
+File ownership (only touch these paths):
+- docs/plans/waves/reviews/wave-14-cont-qa.md
+```
+
+## Agent E0: cont-EVAL
+
+### Role prompts
+
+- docs/agents/wave-cont-eval-role.md
+
+### Executor
+
+- id: claude
+- model: claude-sonnet-4-6
+- claude.allowed_tools: Read,Glob
+- claude.output_format: json
+
+### Context7
+
+- bundle: none
+
+### Skills
+
+- role-cont-eval
+
+### Prompt
+
+```text
+Primary goal:
+- Evaluate whether the wave actually preserves, integrates, and repairs distributed live-proof evidence before closure.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/evals/README.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/master-plan.md, docs/plans/current-state.md, and docs/plans/migration.md.
+
+Specific expectations:
+- for delegated targets, choose the smallest benchmark set that genuinely exercises the failure mode
+- for pinned targets, run the exact benchmark ids named in the wave contract
+- record the exact selected target ids and benchmark ids in the append-only report
+
+File ownership (only touch these paths):
+- docs/plans/waves/reviews/wave-14-cont-eval.md
+```
+
+## Agent A8: Integration Steward
+
+### Role prompts
+
+- docs/agents/wave-integration-role.md
+
+### Executor
+
+- id: claude
+- model: claude-sonnet-4-6
+
+### Context7
+
+- bundle: none
+
+### Capabilities
+
+- integration
+- live-proof-reconciliation
+- contradiction-recovery
+- blackboard-fidelity
+
+### Prompt
+
+```text
+Primary goal:
+- Reconcile repo changes, proof artifacts, infra state, and deploy-verifier evidence into one closure-ready decision.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/master-plan.md and docs/plans/current-state.md.
+
+Specific expectations:
+- treat missing proof artifacts as blocking
+- prefer explicit follow-up requests over vague warnings
+- call out stale or contradictory live-proof claims
+- use the `cont-EVAL` report and exact benchmark ids as evidence, not as a suggestion
+
+File ownership (only touch these paths):
+- .tmp/main-wave-launcher/integration/wave-14.md
+- .tmp/main-wave-launcher/integration/wave-14.json
+```
+
+## Agent A9: Documentation Steward
+
+### Role prompts
+
+- docs/agents/wave-documentation-role.md
+
+### Executor
+
+- profile: docs-pass
+
+### Context7
+
+- bundle: none
+
+### Prompt
+
+```text
+Primary goal:
+- Keep shared-plan docs and release-facing notes aligned with the proof-first live workflow.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/master-plan.md, docs/plans/current-state.md, and docs/plans/migration.md.
+
+File ownership (only touch these paths):
+- docs/plans/current-state.md
+- docs/plans/master-plan.md
+- docs/plans/migration.md
+- docs/evals/README.md
+```
+
+## Agent A1: Runtime And Summary Hardening
+
+### Executor
+
+- profile: implement-fast
+- model: gpt-5-codex
+- codex.config: model_reasoning_effort=high
+- codex.search: true
+- codex.json: true
+- codex.add_dirs: docs,scripts,test
+- fallbacks: claude, opencode
+- budget.minutes: 45
+
+### Context7
+
+- bundle: node-typescript
+- query: "Retry orchestration, summary integrity, validation rules, and Vitest coverage for agent systems"
+
+### Skills
+
+- role-implementation
+- runtime-codex
+- repo-coding-rules
+
+### Components
+
+- executor-abstraction-and-prompt-transport
+
+### Capabilities
+
+- status-reconciliation
+- benchmark-integration
+- summary-fidelity
+
+### Exit contract
+
+- completion: integrated
+- durability: durable
+- proof: integration
+- doc-impact: owned
+
+### Deliverables
+
+- scripts/wave-orchestrator/launcher.mjs
+- scripts/wave-orchestrator/coordination-store.mjs
+- test/wave-orchestrator/launcher.test.ts
+- test/wave-orchestrator/coordination-store.test.ts
+
+### Prompt
+
+```text
+Primary goal:
+- Tighten the runtime's handling of retries, summaries, and benchmark-facing evidence so proof-centric closure stays machine-visible.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/evals/README.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/current-state.md and docs/plans/wave-orchestrator.md.
+
+Specific expectations:
+- preserve prompt-hash-based reuse safety
+- keep distributed evidence visible through the shared summary and inbox layers
+- add or update regression coverage for any retry or summary behavior you change
+
+File ownership (only touch these paths):
+- scripts/wave-orchestrator/launcher.mjs
+- scripts/wave-orchestrator/coordination-store.mjs
+- test/wave-orchestrator/launcher.test.ts
+- test/wave-orchestrator/coordination-store.test.ts
+```
+
+## Agent A6: Learning Plane Live Validation
+
+### Executor
+
+- id: codex
+- retry-policy: sticky
+- budget.minutes: 30
+- codex.search: true
+- codex.json: true
+
+### Context7
+
+- bundle: none
+
+### Skills
+
+- role-infra
+- provider-kubernetes
+- provider-custom-deploy
+
+### Components
+
+- learning-memory-action-plane
+
+### Capabilities
+
+- live-proof
+- restart-safety
+- deploy-validation
+
+### Exit contract
+
+- completion: live
+- durability: durable
+- proof: live
+- doc-impact: owned
+
+### Deliverables
+
+- docs/plans/waves/reviews/wave-14-live-proof.md
+
+### Proof artifacts
+
+- path: .tmp/wave-14-learning-proof/learning-dry-run-status.json | kind: live-status | required-for: pilot-live
+- path: .tmp/wave-14-learning-proof/learning-plane-before-restart.json | kind: live-status | required-for: pilot-live
+- path: .tmp/wave-14-learning-proof/learning-plane-after-restart.json | kind: restart-check | required-for: pilot-live
+- path: .tmp/wave-14-learning-proof/learning-vector-manifest.json | kind: manifest | required-for: pilot-live
+
+### Prompt
+
+```text
+Primary goal:
+- Capture restart-safe learning-plane proof as a local machine-visible bundle and write the review note that closure roles will trust.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+- Read docs/plans/current-state.md and docs/plans/wave-orchestrator.md.
+
+Operator command sequence:
+- leapctl learning status --json > .tmp/wave-14-learning-proof/learning-plane-before-restart.json
+- leapctl learning dry-run --json > .tmp/wave-14-learning-proof/learning-dry-run-status.json
+- leapctl learning restart --env prod
+- leapctl learning status --json > .tmp/wave-14-learning-proof/learning-plane-after-restart.json
+- leapctl learning manifest --json > .tmp/wave-14-learning-proof/learning-vector-manifest.json
+
+Specific expectations:
+- closure only counts when the declared proof artifacts exist locally
+- if live host state and cached state disagree, prefer current control-plane truth and log the discrepancy explicitly
+- if proof arrives after a failed attempt, expect a targeted rerun on the same executor instead of generic fallback
+- post exact artifact paths and machine-visible evidence through coordination instead of assuming closure agents will rediscover host state
+
+File ownership (only touch these paths):
+- .tmp/wave-14-learning-proof/
+- docs/plans/waves/reviews/wave-14-live-proof.md
+```
+
+## Agent A7: Infra Proof Steward
+
+### Role prompts
+
+- docs/agents/wave-infra-role.md
+
+### Executor
+
+- id: opencode
+- opencode.format: json
+- opencode.steps: 12
+
+### Context7
+
+- bundle: none
+
+### Skills
+
+- role-infra
+- provider-kubernetes
+
+### Prompt
+
+```text
+Primary goal:
+- Verify infra and workload identity assumptions around the live proof owner's commands.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+
+Specific expectations:
+- emit infra markers instead of vague prose
+- call out drift or setup-required states explicitly
+- open targeted follow-up work if the live proof owner depends on unresolved infra setup
+
+File ownership (only touch these paths):
+- .tmp/main-wave-launcher/logs/wave-14-a7.log
+```
+
+## Agent D1: Deploy Verifier
+
+### Role prompts
+
+- docs/agents/wave-deploy-verifier-role.md
+
+### Executor
+
+- id: opencode
+- opencode.format: json
+- opencode.steps: 10
+
+### Context7
+
+- bundle: none
+
+### Skills
+
+- role-deploy
+- provider-kubernetes
+- provider-custom-deploy
+
+### Prompt
+
+```text
+Primary goal:
+- Verify that the rollout associated with the live proof owner is healthy enough to preserve the `pilot-live` claim.
+
+Required context before coding:
+- Read docs/reference/repository-guidance.md.
+- Read docs/research/agent-context-sources.md.
+- Read docs/reference/live-proof-waves.md.
+
+Specific expectations:
+- use explicit deploy status markers for healthy, failed, or rolled-over states
+- do not sign off on implied host health
+- if rollout evidence is incomplete, leave an explicit deploy-risk trail for integration and cont-QA
+
+File ownership (only touch these paths):
+- .tmp/main-wave-launcher/logs/wave-14-d1.log
+```