@chllming/wave-orchestration 0.8.1 → 0.8.2

package/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 ## Unreleased
 
+## 0.8.2 - 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.2` as the current release surface.
+
+### Fixed And Hardened
+
+- `wave control status` now stops surfacing stale blocking edges after a wave has already reached `phase=completed`.
+- Completed waves now suppress stale `nextTimer` deadlines and preserve successful logical-agent states instead of re-blocking agents from historical open request records.
+
+### Testing And Validation
+
+- Added regression coverage for completed-wave control-status projections so historical request records stay visible without reopening blocking state after closure.
+
 ## 0.8.1 - 2026-03-24
 
 ### Changed

package/README.md

@@ -79,18 +79,18 @@ Wave is built to mitigate those failures with a canonical authority set, generat
 
 Current release:
 
-- `@chllming/wave-orchestration@0.8.1`
-- Release tag: [`v0.8.1`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.1)
+- `@chllming/wave-orchestration@0.8.2`
+- Release tag: [`v0.8.2`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.2)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.8.1`:
+Highlights in `0.8.2`:
 
-- `resolved-by-policy` helper follow-up now closes single-target helper assignments authoritatively instead of leaving stale helper-assignment barriers open.
-- Manual `wave coord post --kind resolved-by-policy` now defaults to `status=resolved`, which matches the intended policy-closure semantics.
-- Multi-target helper requests no longer over-close sibling assignments from a request-level policy note; assignment-specific evidence is required.
-- The architecture-hardening migration plan, reducer or envelope wiring, and aligned docs or skills from the prior release remain intact.
-- Upgrade and operator docs now cover the full `0.8.1` package surface end to end.
+- `wave control status` now clears stale blocking edges once a wave is already completed instead of replaying historical open request records as live blockers.
+- Completed waves now suppress stale `nextTimer` deadlines and preserve successful logical-agent states in the control-status projection.
+- The helper-assignment policy-closure fixes from `0.8.1` remain intact.
+- The architecture-hardening migration plan, reducer or envelope wiring, and aligned docs or skills from the prior releases remain intact.
+- Upgrade and operator docs now cover the full `0.8.2` package surface end to end.
 
 Requirements:
 

package/docs/plans/current-state.md

@@ -1,6 +1,6 @@
 # Current State
 
-- The starter workspace in this source repo reflects the `0.8.1` package release surface.
+- The starter workspace in this source repo reflects the `0.8.2` 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/`.

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.8.1` Wave surface.
+Use it as the single reference example for the current `0.8.2` Wave surface.
 
 It intentionally combines more sections than a normal production wave so one file can demonstrate:
 

package/docs/plans/migration.md

@@ -24,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.8.1
+## Upgrading From 0.6.x To 0.8.2
 
 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.8.1` carries forward the `0.8.0` architecture-hardening release surface and tightens helper-assignment closure handling: `resolved-by-policy` records now default to `resolved`, single-target helper requests can close from policy follow-up without mutating the original request, and multi-target helper requests only close from assignment-specific policy evidence so sibling assignments stay honest.
+`0.8.2` carries forward the `0.8.1` helper-assignment fixes and hardens the control-status projection layer: completed waves no longer replay stale blocking edges or overdue timers from historical coordination records, and successful logical-agent state stays preserved once the wave is terminal.
 
 ### Required Repo Changes
 
@@ -42,7 +42,7 @@ 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.1` authority-model language, also sync:
+If the repo copied the shipped starter architecture docs or skills and wants the `0.8.2` authority-model language, also sync:
 
 - `docs/agents/wave-launcher-role.md`
 - `docs/agents/wave-orchestrator-role.md`

package/docs/reference/npmjs-trusted-publishing.md

@@ -2,7 +2,7 @@
 
 This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
 
-The current `0.8.1` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.8.2` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
 
 ## What This Repo Already Does
 
@@ -47,6 +47,6 @@ If this repo later needs private npm dependencies during CI, consider a separate
 1. Confirm [publish-npm.yml](../../.github/workflows/publish-npm.yml) is on the default branch.
 2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
 3. Confirm the package version has been bumped and committed.
-4. Push the release commit and release tag, for example `v0.8.1`.
+4. Push the release commit and release tag, for example `v0.8.2`.
 5. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
 6. Verify the npmjs publish completes successfully for the tagged source.

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the current 0.8.1 Wave surface."
+summary: "Showcase-first sample waves that demonstrate the current 0.8.2 Wave surface."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the current `0.8.1` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the current `0.8.2` authored Wave surface.
 
 The examples are intentionally denser than typical production waves. Their job is to teach the current authoring and runtime surface quickly, not to be the smallest possible launch-ready files.
 
@@ -15,7 +15,7 @@ The examples are intentionally denser than typical production waves. Their job i
   Shows what a good `repo-landed` outcome looks like when one promoted component only closes honestly if desired-state records, reconcile-loop substrate, and cluster-view surfaces land together. It emphasizes maturity discipline, explicit deliverables, and shared-plan closure without drifting into `pilot-live` claims.
 
 - [Full modern sample wave](../plans/examples/wave-example-live-proof.md)
-  Shows the combined `0.8.1` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
+  Shows the combined `0.8.2` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
 
 ## What These Examples Teach
 
@@ -38,7 +38,7 @@ The examples are intentionally denser than typical production waves. Their job i
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened for `0.8.1`:
+Together these samples cover the main surfaces added or hardened for `0.8.2`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chllming/wave-orchestration",
-  "version": "0.8.1",
+  "version": "0.8.2",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {

package/releases/manifest.json

@@ -2,6 +2,26 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.8.2",
+      "date": "2026-03-24",
+      "summary": "Completed-wave control-status projection hardening and 0.8.2 release-surface alignment.",
+      "features": [
+        "`wave control status` now clears stale blocking edges after a wave has already reached `phase=completed`, instead of replaying historical open request records as live blockers.",
+        "Completed waves now suppress stale `nextTimer` deadlines in the control-status projection.",
+        "Successful logical-agent states are preserved for completed waves instead of being re-blocked by stale coordination history in the control-status surface.",
+        "Regression coverage now exercises the completed-wave stale-blocking projection path directly.",
+        "Shipped package metadata, README, migration guidance, sample-wave docs, and npm publishing instructions now point at the `0.8.2` release surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.8.2` runtime and completed-wave control-status contract.",
+        "If an adopted repo fails `wave doctor` after the upgrade, sync the repo-owned planner starter surface (`docs/agents/wave-planner-role.md`, `skills/role-planner/`, `docs/context7/planner-agent/`, `docs/reference/wave-planning-lessons.md`, and the `planner-agentic` bundle entry) before relying on planner-aware validation.",
+        "If a repo carries custom operator docs for `wave control status`, update that guidance so completed waves are described as terminal projections where historical coordination records may remain visible without reopening blockers.",
+        "If an adopted repo copied the starter architecture docs or skill bundles, sync the updated role prompts, `skills/wave-core/`, runtime skills, and closure-role skills so local guidance matches the `0.8.2` authority model and completed-wave control behavior.",
+        "Review `docs/plans/architecture-hardening-migration.md` before continuing reducer-authoritative cutover work in repos that extend the shipped starter surface."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.8.1",
       "date": "2026-03-24",

package/scripts/wave-orchestrator/control-cli.mjs

@@ -270,6 +270,10 @@ function assignmentRelevantToAgent(assignment, agentId = "") {
   );
 }
 
+function isCompletedPhase(phase) {
+  return String(phase || "").trim().toLowerCase() === "completed";
+}
+
 function buildEffectiveSelection(lanePaths, wave, { activeAttempt = null, rerunRequest = null, relaunchPlan = null } = {}) {
   const activeAttemptSelected = Array.isArray(activeAttempt?.selectedAgentIds)
     ? Array.from(new Set(activeAttempt.selectedAgentIds.filter(Boolean)))
@@ -308,10 +312,20 @@ function buildEffectiveSelection(lanePaths, wave, { activeAttempt = null, rerunR
   };
 }
 
-function buildLogicalAgents({ lanePaths, wave, tasks, dependencySnapshot, capabilityAssignments, selection, proofRegistry }) {
+function buildLogicalAgents({
+  lanePaths,
+  wave,
+  tasks,
+  dependencySnapshot,
+  capabilityAssignments,
+  selection,
+  proofRegistry,
+  phase,
+}) {
   const selectedAgentIds = new Set(selection?.selectedAgentIds || []);
   const helperAssignments = Array.isArray(capabilityAssignments) ? capabilityAssignments : [];
   const openInbound = dependencySnapshot?.openInbound || [];
+  const completedPhase = isCompletedPhase(phase);
   return wave.agents.map((agent) => {
     const statusPath = statusPathForAgent(lanePaths, wave, agent);
     const statusRecord = readStatusRecordIfPresent(statusPath);
@@ -343,6 +357,11 @@ function buildLogicalAgents({ lanePaths, wave, tasks, dependencySnapshot, capabi
       (assignment) => assignment.blocking && assignment.assignedAgentId === agent.agentId,
     );
     const dependency = openInbound.find((record) => record.assignedAgentId === agent.agentId);
+    const satisfiedByStatus =
+      statusRecord?.code === 0 &&
+      (proofValidation.ok ||
+        isSecurityReviewAgent(agent) ||
+        isContEvalReportOnlyAgent(agent, { contEvalAgentId: lanePaths.contEvalAgentId }));
     let state = "planned";
     let reason = "";
     if (selection?.source === "active-attempt" && selectedAgentIds.has(agent.agentId)) {
@@ -354,6 +373,16 @@ function buildLogicalAgents({ lanePaths, wave, tasks, dependencySnapshot, capabi
         selection?.source === "relaunch-plan"
           ? "Selected by the persisted relaunch plan."
           : "Selected by active rerun request.";
+    } else if (completedPhase && satisfiedByStatus) {
+      state = [
+        lanePaths.contEvalAgentId || "E0",
+        lanePaths.integrationAgentId || "A8",
+        lanePaths.documentationAgentId || "A9",
+        lanePaths.contQaAgentId || "A0",
+      ].includes(agent.agentId) || isSecurityReviewAgent(agent)
+        ? "closed"
+        : "satisfied";
+      reason = "Completed wave preserves the latest satisfied agent state.";
     } else if (targetedBlockingTasks.some((task) => task.state === "working")) {
       state = "working";
       reason = targetedBlockingTasks.find((task) => task.state === "working")?.title || "";
@@ -365,7 +394,7 @@ function buildLogicalAgents({ lanePaths, wave, tasks, dependencySnapshot, capabi
         helperAssignment?.summary ||
         dependency?.summary ||
         "";
-    } else if (statusRecord?.code === 0 && (proofValidation.ok || isSecurityReviewAgent(agent) || isContEvalReportOnlyAgent(agent, { contEvalAgentId: lanePaths.contEvalAgentId }))) {
+    } else if (satisfiedByStatus) {
       state = [
         lanePaths.contEvalAgentId || "E0",
         lanePaths.integrationAgentId || "A8",
@@ -401,7 +430,19 @@ function selectionTargetsAgent(agentId, selectionSet) {
   return Boolean(agentId) && selectionSet.has(agentId);
 }
 
-function buildBlockingEdge({ tasks, capabilityAssignments, dependencySnapshot, activeAttempt, rerunRequest, relaunchPlan, agentId = "" }) {
+function buildBlockingEdge({
+  tasks,
+  capabilityAssignments,
+  dependencySnapshot,
+  activeAttempt,
+  rerunRequest,
+  relaunchPlan,
+  agentId = "",
+  phase,
+}) {
+  if (isCompletedPhase(phase)) {
+    return null;
+  }
   const attemptSelection = new Set(activeAttempt?.selectedAgentIds || []);
   const scopeToActiveAttempt = !agentId && attemptSelection.size > 0;
   const scopedTasks = (agentId
@@ -546,6 +587,7 @@ export function buildControlStatusPayload({ lanePaths, wave, agentId = "" }) {
   const logPath = coordinationLogPath(lanePaths, wave.wave);
   const coordinationState = readMaterializedCoordinationState(logPath);
   const ledger = readWaveLedger(ledgerPath(lanePaths, wave.wave)) || { phase: "planned" };
+  const phase = ledger.phase || "unknown";
   const capabilityAssignments = buildRequestAssignments({
     coordinationState,
     agents: wave.agents,
@@ -596,7 +638,7 @@ export function buildControlStatusPayload({ lanePaths, wave, agentId = "" }) {
   return {
     lane: lanePaths.lane,
     wave: wave.wave,
-    phase: ledger.phase || "unknown",
+    phase,
     agentId: agentId || null,
     blockingEdge: buildBlockingEdge({
       tasks,
@@ -606,6 +648,7 @@ export function buildControlStatusPayload({ lanePaths, wave, agentId = "" }) {
       rerunRequest,
       relaunchPlan,
       agentId,
+      phase,
     }),
     logicalAgents: buildLogicalAgents({
       lanePaths,
@@ -615,6 +658,7 @@ export function buildControlStatusPayload({ lanePaths, wave, agentId = "" }) {
       capabilityAssignments,
       selection,
       proofRegistry,
+      phase,
     }).filter((agent) => !agentId || agent.agentId === agentId),
     tasks,
     helperAssignments: (capabilityAssignments || []).filter(
@@ -634,7 +678,7 @@ export function buildControlStatusPayload({ lanePaths, wave, agentId = "" }) {
     selectionSource: selection.source,
     rerunRequest,
     relaunchPlan,
-    nextTimer: nextTaskDeadline(tasks),
+    nextTimer: isCompletedPhase(phase) ? null : nextTaskDeadline(tasks),
     activeAttempt: controlState.activeAttempt,
   };
 }