@chllming/wave-orchestration 0.9.10 → 0.9.12

package/docs/reference/npmjs-token-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.9.2` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.9.12` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
 
 ## What This Repo Already Does
 
@@ -48,6 +48,6 @@ If this repo later needs private npm dependencies during CI, consider a separate
 2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
 3. Confirm the package version has been bumped and committed.
 4. Confirm `README.md`, `CHANGELOG.md`, `releases/manifest.json`, and `docs/plans/migration.md` all describe the same release surface.
-5. Push the release commit and release tag, for example `v0.9.2`.
+5. Push the release commit and release tag, for example `v0.9.12`.
 6. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
 7. Verify the npmjs publish completes successfully for the tagged source.

package/docs/reference/package-publishing-flow.md

@@ -15,7 +15,7 @@ Release preparation happens in the repository itself:
 - update release-surface docs and fixtures
 - validate the repo
 - merge the release changes to `main`
-- push a version tag such as `v0.9.2`
+- push a version tag such as `v0.9.12`
 
 Registry publishing happens in GitHub Actions after the tag push:
 
@@ -122,14 +122,14 @@ In this source repo, `.wave/install-state.json` and tracked `.wave/upgrade-histo
 
 ### 2. Merge the release change to `main`
 
-This repository protects `main`, so release changes must land through a pull request rather than a direct push.
+This repository normally protects `main`, so release changes should land through a pull request unless the repo policy has been intentionally relaxed for a one-off release cut.
 
 Typical git flow:
 
 ```bash
-git checkout -b release/0.9.2
-git push -u origin release/0.9.2
-gh pr create --base main --head release/0.9.2
+git checkout -b release/0.9.12
+git push -u origin release/0.9.12
+gh pr create --base main --head release/0.9.12
 gh pr merge <pr-number> --merge --delete-branch
 ```
 
@@ -138,13 +138,13 @@ gh pr merge <pr-number> --merge --delete-branch
 After the release commit is on `main`, push the version tag:
 
 ```bash
-git tag v0.9.2
-git push origin v0.9.2
+git tag v0.9.12
+git push origin v0.9.12
 ```
 
 That tag push is the event that starts both publishing workflows.
 
-The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.2`, the pushed tag must be `v0.9.2`.
+The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.12`, the pushed tag must be `v0.9.12`.
 
 ## GitHub Actions Workflows
 
@@ -212,9 +212,9 @@ Expected result after a successful publish:
 
 ```json
 {
-  "version": "0.9.2",
+  "version": "0.9.12",
   "dist-tags": {
-    "latest": "0.9.2"
+    "latest": "0.9.12"
   }
 }
 ```
@@ -231,8 +231,8 @@ If a tag-triggered publish fails before the package is actually published, the f
 Example:
 
 ```bash
-git tag -f v0.9.2 <fixed-commit>
-git push origin refs/tags/v0.9.2 --force
+git tag -f v0.9.12 <fixed-commit>
+git push origin refs/tags/v0.9.12 --force
 ```
 
 Use that only before the package is live on npmjs. Once npmjs has accepted a version, do not try to republish the same version; cut a new version instead.

package/docs/reference/runtime-config/README.md

@@ -191,7 +191,7 @@ Practical guidance:
 - prefer `budget.minutes` for normal synthesis, integration, and closure work
 - use generic `budget.turns` as a planning hint, not a hard failure trigger
 - only set `claude.maxTurns` or `opencode.steps` when you deliberately want a hard ceiling for that runtime
-- see [../../guides/recommendations-0.9.3.md](../../guides/recommendations-0.9.3.md) for the recommended `0.9.3` operating stance that combines advisory turn budgets with softer non-proof coordination states
+- see [../../guides/recommendations-0.9.12.md](../../guides/recommendations-0.9.12.md) for the recommended `0.9.12` operating stance that combines advisory turn budgets with softer non-proof coordination states, targeted recovery, and optional TMUX operator surfaces
 
 ## Runtime Pages
 
@@ -203,7 +203,7 @@ Practical guidance:
 
 `wave.config.json` may also declare a `waveControl` block for local-first telemetry delivery.
 
-Packaged defaults in `@chllming/wave-orchestration@0.9.3`:
+Packaged defaults in `@chllming/wave-orchestration@0.9.12`:
 
 - `endpoint`: `https://wave-control.up.railway.app/api/v1`
 - `reportMode`: `metadata-only`

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.9.2 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.9.12 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.9.2` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.9.12` 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.
 
@@ -17,7 +17,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
   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.9.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.
+  Shows the combined `0.9.12` 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.
 
 - [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md)
   Shows the shipped design-role surface: one pre-implementation design steward publishes a design packet, downstream implementation owners read that packet before coding, and normal closure roles still decide final completion. For terminal or operator-surface work, pair that shape with explicit `tui-design` in the design steward's `### Skills`. For the hybrid variant, explicitly give that same design agent implementation-owned paths and the normal implementation contract sections.
@@ -46,7 +46,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened through `0.9.2`:
+Together these samples cover the main surfaces added or hardened through `0.9.12`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -184,7 +184,7 @@ Adapt more aggressively when:
 ## Suggested Reading Order
 
 1. Start with [High-fidelity repo-landed rollout wave](../plans/examples/wave-example-rollout-fidelity.md) if you want the clearest example of good closure-ready wave fidelity for a repo-only outcome.
-2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.2` surface.
+2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.12` surface.
 3. Read [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md) if the task needs a design packet before implementation fan-out.
 4. Read [docs/evals/README.md](../evals/README.md) if you want more background on benchmark target selection.
 5. Read [docs/reference/live-proof-waves.md](./live-proof-waves.md) if you want more detail on proof-first `pilot-live` authoring.

package/docs/reference/skills.md

@@ -124,7 +124,7 @@ Top-level and lane-local skill attachment use the same shape:
 
 Lane-local `lanes.<lane>.skills` extends the global config instead of replacing it.
 
-Optional design workers in the shipped `0.9.2` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
+Optional design workers in the shipped `0.9.12` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
 
 Long-running agents that should stay resident and react only to orchestrator signal changes can add `signal-hygiene` explicitly in `### Skills`. That bundle is not auto-attached and is not meant for normal one-shot implementation agents.
 

package/docs/reference/wave-control.md

@@ -23,7 +23,7 @@ That packaged endpoint is for the default metadata-reporting surface. The owned-
 
 ### Packaged Default Endpoint
 
-This is the release default in `@chllming/wave-orchestration@0.9.2`.
+This is the release default in `@chllming/wave-orchestration@0.9.12`.
 
 - receives local-first telemetry uploads
 - supports normal run and benchmark query surfaces
@@ -44,6 +44,8 @@ An owned deployment can add:
 - broker routes for Context7 and Corridor
 - provider env leasing for deployment-owned OpenAI and Anthropic credentials
 
+The packaged browser UI now defaults to a dashboard-first information architecture with `Dashboard`, `Operations`, `Access`, and `Account` views. The goal is to put operator triage first, then let deeper run, benchmark, token, and access-management screens hang off that navigation instead of treating every surface as a flat peer tab.
+
 ## What Gets Reported
 
 Wave Control normalizes these entity types:

package/docs/roadmap.md

@@ -2,9 +2,9 @@
 
 This roadmap is intentionally short and current. The older planner-foundation and ad-hoc-run phase list has been removed because that work no longer describes the actual shipping direction for this package.
 
-## Current Release: 0.9.2
+## Current Release: 0.9.12
 
-`0.9.2` is the current packaged surface.
+`0.9.12` is the current packaged surface.
 
 It includes:
 
@@ -56,6 +56,6 @@ That line is expected to carry:
 
 For this repository, the practical sequence is:
 
-1. Ship `0.9.2` with the sandbox/runtime hardening and aligned docs.
+1. Ship `0.9.12` with the closure, operator-surface, and release-doc alignment fixes.
 2. Maintain this Node package for bug fixes, compatibility, operational hardening, and release-surface sync rather than a broad new feature wave.
 3. Move long-term execution investment to the LEAPclaw + Go + Temporal architecture and the Rust standalone runtime.

package/package.json

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

package/releases/manifest.json

@@ -2,6 +2,38 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.9.12",
+      "date": "2026-04-08",
+      "summary": "Hybrid closure fast-path fixes, optional-TMUX release-surface cleanup, and a dashboard-first Wave Control UI refresh.",
+      "features": [
+        "Bootstrap closure now keeps the low-entropy fast path only for genuinely lightweight closure attempts; missing `cont-QA` runs are no longer silently skipped after semantic closure work already ran.",
+        "`closureModeThresholds.bootstrap` now participates in runtime mode resolution, and derived closure-complexity metadata now includes clarification, dependency, helper-assignment, and contradiction barriers.",
+        "Planner setup, launcher help, autonomous help, runbooks, and canned commands now describe TMUX consistently as an optional dashboard/projection layer instead of a required execution backend.",
+        "The `wave-control-web` browser surface now uses dashboard-first navigation with clearer `Dashboard`, `Operations`, `Access`, and `Account` views plus richer run and benchmark analytics summaries.",
+        "The shipped versioned operating guide is now `docs/guides/recommendations-0.9.12.md`, and release docs, migration guidance, runtime-config docs, package-publishing docs, tracked install-state fixtures, and the release manifest now all point at the same `0.9.12` surface.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor --json` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.9.12` release surface.",
+        "If your repo copied starter docs or runbooks, sync `README.md`, `docs/README.md`, `docs/plans/current-state.md`, `docs/plans/migration.md`, `docs/reference/coordination-and-closure.md`, `docs/reference/runtime-config/README.md`, `docs/reference/wave-control.md`, `docs/reference/package-publishing-flow.md`, and `docs/guides/recommendations-0.9.12.md` so local guidance matches the packaged release.",
+        "If your repo copied terminal-surface guidance or shell helpers, update any local wording that still treats TMUX as mandatory for live execution."
+      ],
+      "breaking": false
+    },
+    {
+      "version": "0.9.11",
+      "date": "2026-04-07",
+      "summary": "Cont-QA verdict parsing fix, log-first verdict authority, and sticky integration closure.",
+      "features": [
+        "`parseVerdictFromText()` now returns the first regex match instead of the last, fixing retry loops caused by stale `Verdict: BLOCKED` lines lingering in append-only cont-QA reports.",
+        "`buildAgentExecutionSummary()` now prefers the log-based `[wave-verdict]` marker over the report-file `Verdict:` line when both are present.",
+        "Integration closure now respects an explicit A8 `ready-for-doc-closure` sign-off with zero blockers instead of re-injecting synthesized proof/doc gaps on the next derived-state refresh.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target."
+      ],
+      "manualSteps": [],
+      "breaking": false
+    },
     {
       "version": "0.9.10",
       "date": "2026-04-07",

package/scripts/wave-orchestrator/agent-state.mjs

@@ -509,7 +509,9 @@ export function buildAgentExecutionSummary({ agent, statusRecord, logPath, repor
         : "";
   const reportVerdict = parseVerdictFromText(reportText, REPORT_VERDICT_REGEX);
   const logVerdict = parseVerdictFromText(signalText, WAVE_VERDICT_REGEX);
-  const verdict = reportVerdict.verdict ? reportVerdict : logVerdict;
+  // Prefer log verdict (authoritative for the current run) over report verdict
+  // (may accumulate stale entries across retries in append-only report files).
+  const verdict = logVerdict.verdict ? logVerdict : reportVerdict;
   const termination = detectTermination(agent, logText, statusRecord);
   return {
     agentId: agent?.agentId || null,

package/scripts/wave-orchestrator/autonomous.mjs

@@ -62,8 +62,8 @@ Options:
   --resident-orchestrator       Launch a resident orchestrator session for each live wave
   --executor <mode>             Default executor passed to launcher: ${AUTONOMOUS_EXECUTOR_MODES.join(" | ")} (default: lane config)
   --codex-sandbox <mode>        Codex sandbox mode override passed to launcher (default: lane config)
-  --dashboard                   Enable dashboards (default: disabled)
-  --keep-sessions               Keep tmux sessions between waves
+  --dashboard                   Enable dashboard projection sessions (default: disabled)
+  --keep-sessions               Keep tmux dashboard/projection sessions between waves
   --keep-terminals              Keep temporary terminal entries between waves
 `);
 }

package/scripts/wave-orchestrator/closure-engine.mjs

@@ -24,6 +24,10 @@ import {
   resolveWaveRoleBindings,
 } from "./role-helpers.mjs";
 import { summarizeResolvedSkills } from "./skills.mjs";
+import {
+  resolveClosureMode as resolveClosurePolicyMode,
+  resolveClosurePolicyConfig,
+} from "./closure-policy.mjs";
 
 function failureResultFromGate(gate, fallbackLogPath) {
   return {
@@ -134,6 +138,30 @@ function missingClosureRunGate(stage) {
   };
 }
 
+function shouldEvaluateStageBeforeLaunch(stage) {
+  return stage.key === "integration" || stage.key === "documentation";
+}
+
+function shouldSkipContQaStage({
+  stage,
+  wave,
+  lanePaths,
+  semanticClosureStagesRan,
+}) {
+  if (stage.key !== "cont-qa" || semanticClosureStagesRan) {
+    return false;
+  }
+  const closurePolicy = resolveClosurePolicyConfig(lanePaths);
+  if (!closurePolicy.autoClosure.allowSkipContQaInBootstrap) {
+    return false;
+  }
+  const closureMode = resolveClosurePolicyMode(
+    wave.wave,
+    closurePolicy.closureModeThresholds,
+  );
+  return closureMode === "bootstrap";
+}
+
 export async function runClosureSweepPhase({
   lanePaths,
   wave,
@@ -195,9 +223,58 @@ export async function runClosureSweepPhase({
     resolveWaveRoleBindings(wave, lanePaths);
   const _gateThresholds = lanePaths?.gateModeThresholds || lanePaths?.validation?.gateModeThresholds || options?.gateModeThresholds || null;
   const _resolvedGateMode = resolveGateMode(wave.wave, _gateThresholds);
+  let semanticClosureStagesRan = false;
   for (const [stageIndex, stage] of stagedRuns.entries()) {
+    const currentDerivedState = refreshDerivedState?.(dashboardState?.attempt || 0) || null;
+    if (shouldEvaluateStageBeforeLaunch(stage)) {
+      const preLaunchGate = evaluateClosureStage({
+        stage,
+        wave,
+        closureRuns,
+        lanePaths,
+        dashboardState,
+        derivedState: currentDerivedState,
+        refreshDerivedState,
+        readWaveContEvalGateFn: readContEvalGate,
+        readWaveSecurityGateFn: readSecurityGate,
+        readWaveIntegrationBarrierFn: readIntegrationBarrier,
+        readWaveDocumentationGateFn: readDocumentationGate,
+        readWaveComponentMatrixGateFn: readComponentMatrixGate,
+        readWaveContQaGateFn: readContQaGate,
+        contEvalAgentId,
+        integrationAgentId,
+        documentationAgentId,
+        contQaAgentId,
+      });
+      const autoSatisfiedStage =
+        preLaunchGate.ok &&
+        !preLaunchGate.agentId &&
+        (preLaunchGate.integrationState || preLaunchGate.docClosureState);
+      if (autoSatisfiedStage) {
+        recordCombinedEvent({
+          agentId: stage.agentId || null,
+          message: `${stage.label} already satisfied before launch: ${preLaunchGate.detail}`,
+        });
+        continue;
+      }
+    }
+    if (
+      shouldSkipContQaStage({
+        stage,
+        wave,
+        lanePaths,
+        semanticClosureStagesRan,
+      })
+    ) {
+      recordCombinedEvent({
+        agentId: stage.agentId || null,
+        message:
+          "cont-QA gate skipped in bootstrap because closure remained on the low-entropy fast path.",
+      });
+      continue;
+    }
     if (stage.runs.length === 0) {
-      if (_resolvedGateMode === "bootstrap") {
+      if (_resolvedGateMode === "bootstrap" && stage.key !== "cont-qa") {
         continue;
       }
       if (stageRequiresRun(stage, wave, lanePaths)) {
@@ -215,6 +292,9 @@ export async function runClosureSweepPhase({
       }
       continue;
     }
+    if (stage.key !== "cont-qa") {
+      semanticClosureStagesRan = true;
+    }
     for (const runInfo of stage.runs) {
       const existing = dashboardState.agents.find((entry) => entry.agentId === runInfo.agent.agentId);
       setWaveDashboardAgent(dashboardState, runInfo.agent.agentId, {
@@ -311,6 +391,7 @@ export async function runClosureSweepPhase({
       closureRuns,
       lanePaths,
       dashboardState,
+      derivedState: refreshDerivedState?.(dashboardState?.attempt || 0) || currentDerivedState,
       refreshDerivedState,
       readWaveContEvalGateFn: readContEvalGate,
       readWaveSecurityGateFn: readSecurityGate,
@@ -435,6 +516,7 @@ function evaluateClosureStage({
   closureRuns,
   lanePaths,
   dashboardState,
+  derivedState,
   refreshDerivedState,
   readWaveContEvalGateFn,
   readWaveSecurityGateFn,
@@ -464,24 +546,39 @@ function evaluateClosureStage({
       return readWaveIntegrationBarrierFn(
         wave,
         closureRuns,
-        refreshDerivedState?.(dashboardState?.attempt || 0),
+        derivedState || refreshDerivedState?.(dashboardState?.attempt || 0),
         {
           integrationAgentId,
           mode: "live",
           requireIntegrationStewardFromWave: lanePaths.requireIntegrationStewardFromWave,
+          laneProfile: lanePaths.laneProfile,
+          autoClosure: lanePaths.autoClosure,
         },
       );
     case "documentation": {
+      const componentMatrixGate = readWaveComponentMatrixGateFn(wave, closureRuns, {
+        laneProfile: lanePaths.laneProfile,
+        documentationAgentId,
+      });
       const documentationGate = readWaveDocumentationGateFn(wave, closureRuns, {
         mode: "live",
+        derivedState: derivedState || refreshDerivedState?.(dashboardState?.attempt || 0),
+        documentationAgentId,
+        laneProfile: lanePaths.laneProfile,
+        autoClosure: lanePaths.autoClosure,
+        componentMatrixGate,
       });
       if (!documentationGate.ok) {
         return documentationGate;
       }
-      return readWaveComponentMatrixGateFn(wave, closureRuns, {
-        laneProfile: lanePaths.laneProfile,
-        documentationAgentId,
-      });
+      return {
+        ...componentMatrixGate,
+        docClosureState: documentationGate.docClosureState || null,
+        detail:
+          documentationGate.docClosureState && componentMatrixGate.ok
+            ? documentationGate.detail
+            : componentMatrixGate.detail,
+      };
     }
     case "cont-qa":
       return readWaveContQaGateFn(wave, closureRuns, {