@chllming/wave-orchestration 0.7.3 → 0.8.0

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 ## Unreleased
 
+## 0.8.0 - 2026-03-24
+
+### Changed
+
+- Updated the shipped package metadata, release manifest, README, migration guide, sample-wave docs, and npm publishing runbook to advertise `0.8.0` as the current release surface.
+- Added the architecture hardening migration plan and aligned the active README, guides, runbooks, role prompts, and starter skills to the canonical authority-set and thin-launcher architecture model.
+
+### Fixed And Hardened
+
+- Hardened reducer and task replay determinism so coordination-derived work uses stable semantic task identity and reducer output is fit for authoritative replay.
+- Hardened helper-assignment, contradiction or fact wiring, resume planning, and gate evaluation so the reducer, control-plane schema, and result-envelope path agree on the same live closure and retry state.
+- Hardened live launcher evaluation by computing reducer snapshots during real runs instead of keeping that path effectively test-only.
+
+### Testing And Validation
+
+- Added regression coverage that guards the active docs and starter skills against stale launcher-truth wording and asserts the migration surface is anchored on the canonical authority-set architecture.
+- Re-ran the full Vitest suite, `wave doctor --json`, and `wave launch --lane main --dry-run --no-dashboard`, while preserving shared `0.7.3` parity behavior where the release-era suites overlap.
+
 ## 0.7.3 - 2026-03-23
 
 ### Changed

package/README.md

@@ -13,7 +13,7 @@ The framework does three things:
 - `One orchestrator, many runtimes.`
   Planning, skills, evals, proof, and traces stay constant while the executor adapter changes.
 - `A blackboard-style multi-agent system.`
-  The coordination log is canonical shared state; the rolling board, shared summary, inboxes, ledger, and integration views are generated projections over that state.
+  Wave definitions, the coordination log, the control-plane log, and immutable result envelopes form the machine-trustable authority set; the rolling board, shared summary, inboxes, ledger, and integration views are generated projections over that state.
 - `Completion is goal-driven and proof-bounded.`
   Waves close only when deliverables, proof artifacts, eval targets, dependencies, and closure stewards agree.
 - `Context is compiled, not hand-maintained.`
@@ -28,7 +28,7 @@ The framework does three things:
 1. Define shared docs plus `docs/plans/waves/wave-<n>.md` files, or generate them with `wave draft`.
 2. Run `wave launch --dry-run` to validate the wave and materialize prompts, shared summaries, inboxes, dashboards, and executor previews before any live execution.
 3. During live execution, implementation agents write claims, evidence, requests, and decisions into the canonical coordination log instead of relying on ad hoc terminal narration.
-4. The launcher compiles blackboard projections from that state: rolling board, shared summary, per-agent inboxes, ledger, docs queue, dependency views, and integration summaries.
+4. The reducer and derived-state engines materialize blackboard projections from the canonical authority set: rolling board, shared summary, per-agent inboxes, ledger, docs queue, dependency views, and integration summaries.
 5. Closure runs only when the integrated state is ready: optional `cont-EVAL` (`E0`), optional security review, integration (`A8`), documentation (`A9`), and `cont-QA` (`A0`).
 
 ## Architecture Surfaces
@@ -36,7 +36,7 @@ The framework does three things:
 - `Wave contract`
   Shared plan docs, wave markdown, deliverables, proof artifacts, and eval targets define the goal.
 - `Shared state`
-  The coordination log is the source of truth; the board is for humans, not the scheduler.
+  Decisions come from the canonical authority set; boards, inboxes, dashboards, and other summaries are human-facing or operator-facing projections.
 - `Runtime abstraction`
   Executor adapters preserve Codex, Claude, and OpenCode-specific launch features without changing the higher-level wave contract.
 - `Compiled context`
@@ -59,7 +59,7 @@ Representative rolling message board output from a real wave run:
 Recent multi-agent research keeps returning to the same failure modes:
 
 - `Cosmetic board, no canonical state`
-  Agents appear coordinated, but there is no machine-trustable source of truth underneath the conversation.
+  Agents appear coordinated, but there is no machine-trustable authority set underneath the conversation.
 - `Hidden evidence never gets pooled`
   One agent has the critical fact, but it never reaches shared state before closure.
 - `Communication without global-state reconstruction`
@@ -73,24 +73,24 @@ Recent multi-agent research keeps returning to the same failure modes:
 - `Premature closure`
   Agents say they are done before proof, evals, or integrated state actually support PASS.
 
-Wave is built to mitigate those failures with canonical shared state, generated blackboard projections, explicit ownership, goal-driven, proof-bounded closure, replayable traces, and local-first telemetry. For the research framing and the current gaps, see [docs/research/coordination-failure-review.md](./docs/research/coordination-failure-review.md). For the concrete signal map, see [docs/reference/proof-metrics.md](./docs/reference/proof-metrics.md).
+Wave is built to mitigate those failures with a canonical authority set, generated blackboard projections, explicit ownership, goal-driven, proof-bounded closure, replayable traces, and local-first telemetry. For the research framing and the current gaps, see [docs/research/coordination-failure-review.md](./docs/research/coordination-failure-review.md). For the concrete signal map, see [docs/reference/proof-metrics.md](./docs/reference/proof-metrics.md).
 
 ## Quick Start
 
 Current release:
 
-- `@chllming/wave-orchestration@0.7.3`
-- Release tag: [`v0.7.3`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.7.3)
+- `@chllming/wave-orchestration@0.8.0`
+- Release tag: [`v0.8.0`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.0)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.7.3`:
+Highlights in `0.8.0`:
 
-- Malformed end-of-tail fenced blocks no longer hide later final `[wave-proof]`, `[wave-doc-delta]`, and `[wave-component]` markers from the structured-signal collector.
-- Legacy proof-centric summaries now rebuild from source logs when required proof/doc/component fields are missing, even if a stale `structuredSignalDiagnostics` object already exists.
-- Final implementation marker diagnostics still distinguish truly missing markers from malformed marker syntax, so proof-centric failures stay actionable instead of collapsing into generic missing-marker noise.
-- Implementation prompts now keep incomplete work inside the required final markers with `state=gap` and route unresolved issues through `wave coord post`.
-- Upgrade and operator docs now cover the full `0.7.3` package surface end to end.
+- Reducer and task replay hardening now keeps coordination-derived task identity deterministic and strengthens authoritative replay of live wave state.
+- Gate evaluation, contradiction or fact schema wiring, and resume planning are aligned around control-plane state plus typed result-envelope reads.
+- Live launcher evaluation now computes reducer snapshots during real runs instead of leaving that path effectively test-only.
+- The package now ships a dedicated architecture hardening migration plan and aligns the active README, guides, role prompts, and starter skills to the canonical authority-set and thin-launcher model.
+- Upgrade and operator docs now cover the full `0.8.0` package surface end to end.
 
 Requirements:
 
@@ -183,6 +183,7 @@ codex mcp list
 - [docs/plans/examples/wave-example-rollout-fidelity.md](./docs/plans/examples/wave-example-rollout-fidelity.md): concrete example of what good wave fidelity looks like for a narrow, closure-ready outcome
 - [docs/reference/cli-reference.md](./docs/reference/cli-reference.md): complete CLI syntax for all commands and flags
 - [docs/plans/wave-orchestrator.md](./docs/plans/wave-orchestrator.md): operator runbook
+- [docs/plans/architecture-hardening-migration.md](./docs/plans/architecture-hardening-migration.md): staged cutover from the transitional launcher-centric runtime to the authority-set / reducer / phase-engine architecture
 - [docs/plans/context7-wave-orchestrator.md](./docs/plans/context7-wave-orchestrator.md): Context7 setup and bundle authoring
 - [docs/reference/runtime-config/README.md](./docs/reference/runtime-config/README.md): executor, runtime, and skill-projection configuration
 - [docs/reference/wave-control.md](./docs/reference/wave-control.md): local-first telemetry contract and Railway control-plane model

package/docs/README.md

@@ -3,7 +3,7 @@
 These docs are organized around three core ideas:
 
 - one orchestrator, many runtimes across Claude, Codex, OpenCode, and local execution
-- a blackboard-style multi-agent system with goal-driven, proof-bounded closure
+- a blackboard-style multi-agent system with a canonical authority set, generated projections, and proof-bounded closure
 - compiled context from shared state, skills, runtime files, and Context7 instead of hand-maintained per-runtime context files
 
 The useful path is journey-first:
@@ -39,6 +39,8 @@ The useful path is journey-first:
   Read [plans/wave-orchestrator.md](./plans/wave-orchestrator.md) and the standing reviewer prompt in [agents/wave-security-role.md](./agents/wave-security-role.md).
 - Upgrading an existing repo:
   Read [plans/migration.md](./plans/migration.md), then review the release notes in [../CHANGELOG.md](../CHANGELOG.md) before running `pnpm exec wave upgrade`.
+- Tracking the architecture hardening cutover:
+  Read [plans/architecture-hardening-migration.md](./plans/architecture-hardening-migration.md) for the staged migration from launcher-centric decisions to reducer and phase-engine ownership.
 - Looking for concrete example waves:
   Read [reference/sample-waves.md](./reference/sample-waves.md) for showcase-first examples that demonstrate the current authored wave surface.
 - Release notes and shipped deltas:

package/docs/agents/wave-cont-qa-role.md

@@ -18,6 +18,7 @@ Operating rules:
 - Review changed files against the relevant repository docs and plan docs.
 - Read docs/reference/repository-guidance.md and docs/research/agent-context-sources.md before making final judgments.
 - Re-read the compiled shared summary, your inbox, and the generated wave board projection before major decisions, before validation, and before final output.
+- Treat the shared summary, inbox, and board as generated views. When they conflict with landed code, control-plane state, or typed result artifacts, trust the canonical state.
 - Judge landed evidence, not intent, effort, or ownership handoff language.
 - Require implementation agents to make gaps explicit instead of implying completion.
 - Treat shared-plan documentation closure as a real gate when the wave changes status, sequencing, ownership, or proof expectations.

package/docs/agents/wave-integration-role.md

@@ -16,6 +16,7 @@ Your job is to synthesize cross-agent state after any `cont-EVAL` tuning pass an
 
 Operating rules:
 - Re-read the generated wave inboxes and coordination board projection before major decisions.
+- Treat summaries and board projections as generated views over canonical state, not as the only source of closure truth.
 - Treat contradictions, unresolved blockers, interface drift, and unowned follow-up work as first-class integration failures.
 - Prefer explicit follow-up requests over vague warnings.
 - Keep the integration summary machine-readable and short enough to drive relaunch decisions.

package/docs/agents/wave-launcher-role.md

@@ -12,7 +12,7 @@ Use this prompt when an agent or human operator should launch waves through the
 ```text
 You are the wave launcher operator.
 
-Your job is to run wave files safely, one wave at a time by default, while respecting launcher locks, runtime policy, clarification barriers, optional `cont-EVAL` gates, integration gates, documentation closure, and cont-QA closure.
+Your job is to run wave files safely, one wave at a time by default, while respecting launcher locks, runtime policy, reducer state, clarification barriers, optional `cont-EVAL` gates, integration gates, documentation closure, and cont-QA closure.
 
 Before launching:
 1. Run `pnpm exec wave doctor`.
@@ -24,6 +24,7 @@ Before launching:
 
 Completion requires:
 - all agents exit `0`
+- reducer and control-plane state show no unresolved helper-assignment, clarification, contradiction, or rerun blockers
 - if `cont-EVAL` is present, it must report satisfied targets before integration closure runs
 - integration must be `ready-for-doc-closure` before documentation and cont-QA closure run
 - cont-QA verdict is `PASS`
@@ -33,6 +34,8 @@ Completion requires:
 - runtime mix targets and retry fallbacks remain within lane policy
 - 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
 
+Generated boards, inboxes, and dashboards are operator surfaces. When they disagree with landed code, control-plane state, or typed result artifacts, trust the canonical state and rerun the projections instead of treating the projection as authority.
+
 Dry-run rule:
 - `wave launch --dry-run` is pre-attempt only. It should seed derived state and leave `traces/` without `attempt-<k>` files.
 ```

package/docs/agents/wave-orchestrator-role.md

@@ -15,10 +15,12 @@ You are the resident Wave orchestrator.
 Your job is to monitor the live wave for its full duration and intervene through the control plane instead of through product-code ownership.
 
 You do not own implementation files, proof markers, or closure verdicts.
-The launcher remains the scheduler truth and final authority for retries, barriers, and completion.
+You do not override reducer, gate, retry, or closure decisions with narrative claims.
 
 Operate through durable state:
 - coordination log
+- control-plane log
+- typed result artifacts when present
 - shared summary
 - per-wave dashboard
 - clarification triage artifacts
@@ -35,13 +37,13 @@ Hard limits:
 - do not edit product code, tests, or implementation-owned docs
 - do not satisfy another agent's deliverables or proof obligations
 - do not emit implementation, integration, documentation, or cont-QA closure markers
-- do not override launcher gate results with narrative claims
+- do not override reducer, gate, retry, or closure outputs with narrative claims
 
 Good interventions:
 - route or reroute a clarification to the current owner
 - resolve a clarification from existing repo policy or published artifacts
 - open or summarize a human escalation only after orchestrator-first routing is exhausted
-- post concise board or coordination notes when timing or routing policy changed
+- post concise projection or coordination notes when timing or routing policy changed
 
 Bad interventions:
 - taking over code ownership because an owner is slow

package/docs/concepts/operating-modes.md

@@ -38,7 +38,7 @@ Treat them as planning posture:
 
 Human feedback is a runtime escalation mechanism, not an operating mode.
 
-The launcher flow is:
+The runtime flow is:
 
 1. agent emits a clarification request or blocker
 2. the orchestrator tries to resolve it from repo state, policy, ownership, or targeted rerouting

package/docs/concepts/runtime-agnostic-orchestration.md

@@ -14,17 +14,18 @@ These layers are runtime-neutral:
 
 - wave parsing and validation
 - planner-produced wave specs and authored wave markdown
+- reducer state and phase-engine decisions
 - eval targets, deliverables, and proof artifacts
 - component and closure gates
 - skill resolution and attachment policy
 - compiled shared summaries and per-agent inboxes
-- coordination log and rendered message board
+- canonical authority-set state plus rendered projections
 - helper assignments and dependency handling
 - integration summaries, docs queues, and ledgers
 - dry-run previews
 - trace bundles and replay metadata
 
-The runtime only changes at the last step, when the launcher translates the resolved assignment into an executor-specific invocation.
+The runtime only changes at the last step, when the session supervisor and executor adapter translate the resolved assignment into an executor-specific invocation.
 
 ## Where Runtime-Specific Logic Lives
 
@@ -68,7 +69,7 @@ Executor choice resolves in a fixed order:
 4. CLI `--executor`
 5. global default
 
-After that choice is final, the launcher resolves runtime-specific overlays and any runtime-attached skill packs.
+After that choice is final, the orchestrator resolves runtime-specific overlays and any runtime-attached skill packs.
 
 ## Fallback And Mix Policy
 
@@ -86,7 +87,7 @@ The important part is that fallback does not change the higher-level wave contra
 The skill system follows the same pattern:
 
 - `skills/` is the canonical repo-owned source
-- the launcher resolves skill ids without caring which runtime will consume them
+- the orchestrator resolves skill ids without caring which runtime will consume them
 - the executor adapter projects those skills into the surface each runtime understands
 
 Examples:

package/docs/concepts/what-is-a-wave.md

@@ -38,17 +38,18 @@ Waves force a higher planning bar than ad hoc prompts. A good wave answers:
 
 ## Why This Is A Blackboard-Style Model
 
-Wave is blackboard-style because agents work against shared state instead of treating chat output as the system of record.
+Wave is blackboard-style because agents work against shared canonical state instead of treating chat output as the system of record.
 
-- the canonical coordination log is the machine-readable source of truth
-- the rolling board is a human projection over that state, not the scheduler's authority
-- shared summaries and per-agent inboxes are compiled views over the same state
+- wave definitions, the coordination log, and the control-plane log form the canonical authority set
+- attempt-scoped result envelopes are the immutable structured outcome surface for completed agent work
+- the rolling board is a human projection over that state, not a decision input
+- shared summaries and per-agent inboxes are compiled views over the same authority set
 - helper assignments, clarification flow, dependencies, and integration all operate on that shared state
 - closure depends on the integrated state, not on whether an agent says "done"
 
 ## Wave Anatomy
 
-Wave markdown is the authored execution surface today. A typical wave can include:
+Wave markdown is one authored declaration surface today. A typical wave can include:
 
 - title and commit message
 - project profile details such as oversight mode and lane
@@ -107,10 +108,10 @@ Implementation or specialist agents own the actual work slices. Closure roles do
 
 1. Author or draft the wave.
 2. Run `wave launch --dry-run --no-dashboard`.
-3. The launcher validates the wave, resolves executors and skills, builds prompts, and materializes operator surfaces.
+3. The launcher parses the wave, resolves executors and skills, rebuilds reducer state, and materializes operator surfaces.
 4. A live run launches implementation agents first when implementation work remains.
 5. Agents write structured coordination events instead of relying on ad hoc terminal output.
-6. The launcher checks implementation contracts, promoted-component proof, helper assignments, dependencies, and clarification state.
+6. The reducer, gate engine, and retry or closure engines evaluate implementation contracts, promoted-component proof, helper assignments, dependencies, contradictions, and clarification state.
 7. If implementation is ready, closure runs in order: optional `cont-EVAL`, optional security review, integration, documentation, then cont-QA.
 8. The attempt is captured in per-wave traces, ledgers, inboxes, summaries, and copied artifacts.
 
@@ -187,6 +188,7 @@ For proof-first live-wave examples, see [docs/reference/live-proof-waves.md](../
 The wave file is only part of the story. The runtime writes durable state under `.tmp/<lane>-wave-launcher/`, including:
 
 - prompts and logs
+- result envelopes
 - status summaries
 - coordination logs
 - rendered message boards
@@ -205,7 +207,7 @@ That is why a wave is better understood as a bounded execution record, not just
 The planner foundation adds a JSON draft spec at `docs/plans/waves/specs/wave-<n>.json`.
 
 - The JSON spec is the canonical planner artifact.
-- The rendered markdown stays compatible with the launcher and parser.
-- The launcher still executes the markdown wave file today.
+- The rendered markdown stays compatible with the current parser and operator workflow.
+- Live execution decisions come from parsed wave definitions plus canonical state, not from treating markdown as the only execution authority.
 
-This split keeps authoring structured while preserving the established execution surface.
+This split keeps authoring structured while preserving the established declaration surface.

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

@@ -36,7 +36,7 @@ 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.
+The JSON spec is the planner-owned structured artifact. The markdown wave remains a human-reviewable declaration surface, while live execution is driven from the parsed wave definition plus reducer and phase-engine state.
 
 When you review the generated wave, tighten the parts the planner cannot fully infer:
 
@@ -58,7 +58,7 @@ Every wave should be authored with an explicit operating posture in mind:
 - `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.
+Human feedback is an escalation path, not the operating mode itself. The orchestrator still tries to resolve clarification inside the control-plane and coordination workflow before creating a human ticket.
 
 ## 4. Choose The Operator Surface
 
@@ -113,7 +113,7 @@ Useful flags:
 
 ## 7. Understand Closure
 
-A wave is not done when an implementation agent says it is done. Closure depends on the combined runtime surfaces:
+A wave is not done when an implementation agent says it is done. Closure depends on the canonical authority set, typed result state, and the combined runtime projections:
 
 - implementation contracts pass
 - required deliverables exist

package/docs/plans/architecture-hardening-migration.md

@@ -0,0 +1,206 @@
+# Architecture Hardening Migration
+
+This document is the staged cutover plan from the legacy launcher-centric runtime to the end-state architecture described in [end-state-architecture.md](./end-state-architecture.md).
+
+The target model is fixed:
+
+- decisions come from the canonical authority set, not from projections
+- the reducer is deterministic and replayable
+- gate and closure reads are result-envelope-first
+- the launcher is a thin orchestrator over explicit phase engines plus the session supervisor
+
+## Invariants
+
+These rules stay true at every migration stage:
+
+- Canonical authority set:
+  wave definitions, the coordination log, and the control-plane event log are the authoritative decision inputs.
+- Immutable structured snapshots:
+  attempt-scoped result envelopes are the canonical structured output surface for completed agent work.
+- Projection-only rule:
+  dashboards, boards, summaries, inboxes, ledgers, proof registries, retry overrides, and status files are derived outputs only.
+- Deterministic replay:
+  the reducer must rebuild the same wave state from the same inputs with no random ids or launch-time side effects.
+- Thin-launcher direction:
+  the launcher may sequence engines and invoke the supervisor, but it must not remain the long-term decision brain.
+
+## Baseline And Parity Gate
+
+Every stage must preserve the shipped `0.7.3` behavior where the shared release-era suite overlaps.
+
+Required baseline checks:
+
+```bash
+pnpm test
+node scripts/wave.mjs doctor --json
+node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
+```
+
+Required parity checks:
+
+- keep the shared `v0.7.3` release-era suites green
+- preserve the CLI and runtime artifact contracts already shipped in `0.7.3`
+- require any new architecture-only tests to be additive, not replacements for release parity
+
+Rollback rule:
+
+- if a migration stage breaks the baseline or parity checks, revert that stage to shadow or compatibility mode before taking the next cutover step
+
+## Staged Cutover
+
+### Stage 0: Baseline Lock
+
+Objective:
+capture the current parity baseline and make the architecture vocabulary explicit in docs, prompts, skills, and tests.
+
+Work:
+
+- lock the `0.7.3` parity suite and validation commands
+- document the authority-set model and thin-launcher target everywhere operators and agents read first
+- add wording guardrails so the repo stops reintroducing launcher-as-brain language
+
+Exit criteria:
+
+- baseline and parity checks pass
+- active docs, prompts, and skills use the same authority-set vocabulary
+
+### Stage 1: Shadow Reducer With Diff Reporting
+
+Objective:
+run the reducer on live canonical inputs and compare its view against the compatibility decision path without making reducer output authoritative yet.
+
+Work:
+
+- compute reducer snapshots during live runs
+- persist machine-readable diffs for helper assignments, blockers, retry targets, contradiction state, and closure readiness
+- treat mismatches as regression signals, not silent telemetry
+
+Proof artifacts:
+
+- reducer shadow test coverage
+- replay fixtures that rebuild the same state from stored canonical inputs
+
+Exit criteria:
+
+- repeated live and replay runs show stable reducer output
+- high-value decision slices have zero unexplained shadow diffs
+
+Rollback trigger:
+
+- non-deterministic reducer output or persistent unexplained diffs in helper-assignment, retry, or closure slices
+
+### Stage 2: Reducer-Authoritative Helper Assignment And Retry
+
+Objective:
+promote the reducer to authority for a narrow but critical slice before broader cutover.
+
+Decision owner:
+
+- helper-assignment blocking state
+- retry target selection and resume-plan inputs
+
+Work:
+
+- drive helper-assignment barrier reads from reducer state
+- drive retry planning from reducer-produced blocker and retry-target state
+- keep compatibility projections, but stop letting them decide these slices independently
+
+Proof artifacts:
+
+- deterministic task-identity tests
+- retry-plan regressions from stored state
+- helper-assignment parity tests against `0.7.3` behavior
+
+Exit criteria:
+
+- live retry planning and helper blocking match replay
+- no launcher-only special cases remain in those decision paths
+
+Rollback trigger:
+
+- reducer-driven helper or retry behavior diverges from replay or loses blocking information
+
+### Stage 3: Envelope-Authoritative Gate Evaluation
+
+Objective:
+make typed result envelopes the primary closure read path.
+
+Work:
+
+- gate evaluation reads validated result envelopes first
+- summary, report, and marker parsing stays only as named compatibility adapters
+- contradictions, facts, proof bundles, and gate results use one schema vocabulary end to end
+
+Proof artifacts:
+
+- gate-engine regressions that prove envelopes dominate when present
+- compatibility tests that legacy marker/report inputs still replay correctly
+
+Exit criteria:
+
+- all live closure gates can succeed or block from envelope + canonical state input
+- marker parsing is clearly documented and tested as compatibility-only
+
+Rollback trigger:
+
+- missing envelope coverage for a live role or any gate that still depends on ad hoc log parsing for correctness
+
+### Stage 4: Phase-Engine Ownership Expansion
+
+Objective:
+move remaining decision logic out of the launcher loop and into explicit engines.
+
+Work:
+
+- keep derived-state, gate, retry, closure, and supervision boundaries explicit
+- have the launcher sequence engines instead of recomputing policy inline
+- keep human-input workflow semantics in control-plane events and reducer state, not supervisor-local rules
+
+Proof artifacts:
+
+- engine-level tests from stored state
+- replay tests that reconstruct closure sequencing without launching sessions
+
+Exit criteria:
+
+- decisions come from engine outputs, not launcher-local branches
+- the supervisor writes observed lifecycle facts only
+
+Rollback trigger:
+
+- any stage requires relanding launcher-only branches to preserve correctness
+
+### Stage 5: Compatibility Removal And Thin-Launcher Finish
+
+Objective:
+finish the migration by removing transitional authority seams.
+
+Work:
+
+- remove stale compatibility-only decision branches once replay and live coverage prove they are no longer needed
+- keep compatibility artifacts only where needed for operator ergonomics or historical replay
+- reduce launcher responsibilities to argument parsing, lock management, engine sequencing, supervisor invocation, and projection writes
+
+Exit criteria:
+
+- reducer-authoritative state drives live queries and replay
+- gate reads are envelope-first
+- compatibility parsing no longer decides live correctness
+- active docs no longer describe the launcher as the scheduler brain
+
+## Final Exit Criteria
+
+The architecture hardening migration is complete only when all of the following are true:
+
+- the canonical authority set is the only decision input model documented and enforced
+- reducer replay is deterministic and trusted for live state queries
+- retry and helper-assignment decisions are reducer-authoritative
+- gate and closure evaluation are result-envelope-first
+- projections remain operator aids only
+- the shared `0.7.3` parity suites still pass
+
+## Risks And Defaults
+
+- Structural debt may remain after behavioral cutover. A large `launcher.mjs` file is not by itself a migration failure if decisions already come from explicit engines, but finishing the thin-launcher cleanup is still required before calling the architecture complete.
+- Historical docs may still describe older behavior. Keep that wording explicitly historical instead of mixing it into active operator guidance.
+- When there is doubt between projection output and canonical state, trust canonical state and treat the projection as stale until rebuilt.

package/docs/plans/current-state.md

@@ -1,6 +1,7 @@
 # Current State
 
-- The starter workspace in this source repo reflects the `0.7.3` package release surface.
+- The starter workspace in this source repo reflects the `0.8.0` package release surface.
+- The staged architecture cutover from launcher-centric decisions to reducer and phase-engine ownership is tracked in `docs/plans/architecture-hardening-migration.md`.
 - 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/`.
 - 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.
@@ -25,7 +26,8 @@
   - wave agents can add explicit `### Skills`
   - runtime projections are generated for Codex, Claude, OpenCode, and local execution
 - The runtime now includes:
-  - a canonical coordination JSONL log
+  - a canonical authority set built from wave definitions, coordination JSONL logs, and control-plane JSONL events
+  - immutable attempt-scoped result envelopes for structured role outcomes
   - a generated markdown board projection
   - compiled shared summaries and per-agent inboxes
   - active live-wave orchestration refresh that keeps summaries, inboxes, clarification triage, and dashboard coordination metrics current while agents are still running
@@ -43,7 +45,7 @@
   - operator-applied retry overrides projected to `.tmp/<lane>-wave-launcher/control/` for compatibility with selected reruns, explicit reuse selectors, reuse clearing or preservation, and explicit resume targets
   - authoritative proof registries projected to `.tmp/<lane>-wave-launcher/proof/` for compatibility, while preserving proof bundle lifecycle state so revoked or superseded operator evidence cannot keep satisfying closure
   - optional Wave Control telemetry under `.tmp/<lane>-wave-launcher/control-plane/telemetry/` for local-first, best-effort reporting to the Railway-hosted analysis plane
-  - a thinner launcher entrypoint that now delegates session launch or wait and closure-sweep orchestration to dedicated modules while preserving the existing CLI surface
+  - reducer-driven live state snapshots plus a launcher entrypoint that is being hardened toward thin orchestration 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

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

@@ -2,7 +2,7 @@
 
 This is a showcase-first sample wave.
 
-Use it as the single reference example for the current `0.7.3` Wave surface.
+Use it as the single reference example for the current `0.8.0` Wave surface.
 
 It intentionally combines more sections than a normal production wave so one file can demonstrate:
 

package/docs/plans/master-plan.md

@@ -9,8 +9,8 @@
 
 ## Near-Term Work
 
-- Keep the starter wave, role prompts, starter skills, and component cutover matrix aligned with the shipped launcher and planner behavior.
+- Keep the starter wave, migration docs, role prompts, starter skills, and component cutover matrix aligned with the authority-set architecture and the staged hardening plan.
 - Expand `wave doctor` and migration guidance around cross-repo adoption, executor availability, and future breaking config changes.
 - Build on the shipped planner foundation with richer starter templates and eventually ad-hoc or forward-replan flows.
 - 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.
-- Add the remaining roadmap items that are not yet shipped, especially stronger operating-mode enforcement and better operator workflows around cross-lane dependency tickets.
+- Add the remaining roadmap items that are not yet shipped, especially stronger operating-mode enforcement, thinner-launcher cleanup, and better operator workflows around cross-lane dependency tickets.

package/docs/plans/migration.md

@@ -1,5 +1,7 @@
 # Migration
 
+For the staged internal cutover from the legacy launcher-centric runtime to the authority-set / reducer / phase-engine architecture, see [architecture-hardening-migration.md](./architecture-hardening-migration.md). This page stays focused on package adoption and upgrade steps for repo operators.
+
 ## Default Adoption Path
 
 1. Install the package from npmjs with `pnpm add -D @chllming/wave-orchestration`.
@@ -22,13 +24,13 @@ GitHub Packages remains available as an authenticated fallback path, and maintai
 - Fresh `wave init` seeds the starter `skills/` library. `wave init --adopt-existing` records existing repo-owned skill bundles when they are already present, but does not replace or rewrite them.
 - The current runtime expects the post-roadmap model: typed coordination, compiled inboxes, `A8` integration, staged closure, orchestrator-first clarification, and operational runtime policy.
 
-## Upgrading From 0.6.x To 0.7.3
+## Upgrading From 0.6.x To 0.8.0
 
 Read `CHANGELOG.md` first, then treat this section as the repo-owned migration checklist for adopted `0.6.x` workspaces.
 
 `wave upgrade` updates the installed runtime only. It does not copy planner starter files into a repo that already owns its docs, skills, and Context7 bundles.
 
-`0.7.3` keeps the proof-centric closure hardening from `0.7.2` and closes the remaining parser hole: malformed unmatched end-of-tail fenced blocks no longer hide later final implementation markers, stale summaries rebuild when required proof/doc/component fields are still missing even if diagnostics already exist, malformed marker syntax still surfaces explicit parse errors, and incomplete implementation work should stay inside the required final markers with `state=gap` instead of trailing `[wave-gap]` lines.
+`0.8.0` carries forward the `0.7.3` proof-centric closure hardening and adds the first architecture-hardening release surface: reducer and retry parity fixes, result-envelope-first gate wiring, contradiction or fact schema alignment, a dedicated architecture migration plan, and starter docs or skills that now describe the canonical authority-set model instead of the old launcher-centric wording.
 
 ### Required Repo Changes
 
@@ -40,6 +42,14 @@ If the repo adopted Wave before the planner corpus became a tracked required sur
 - `docs/reference/wave-planning-lessons.md`
 - the `planner-agentic` bundle entry in `docs/context7/bundles.json`
 
+If the repo copied the shipped starter architecture docs or skills and wants the `0.8.0` authority-model language, also sync:
+
+- `docs/agents/wave-launcher-role.md`
+- `docs/agents/wave-orchestrator-role.md`
+- `skills/wave-core/`
+- the relevant runtime and closure-role starter skills under `skills/`
+- `docs/plans/architecture-hardening-migration.md`
+
 ### Recommended Upgrade Validation
 
 After syncing those repo-owned files: