@chllming/wave-orchestration 0.8.2 → 0.8.3

package/CHANGELOG.md

@@ -2,6 +2,23 @@
 
 ## Unreleased
 
+## 0.8.3 - 2026-03-24
+
+### Changed
+
+- Updated the shipped package metadata, release manifest, README, migration guide, sample-wave docs, current-state notes, and npm publishing runbook to advertise `0.8.3` as the current release surface.
+- Documented that `wave feedback respond` is a canonical-state repair path, not a feedback-JSON-only update, and that ad-hoc reconciliation must keep the `--run <id>` context.
+
+### Fixed And Hardened
+
+- Answered human-feedback requests now reconcile linked clarification, escalation, and helper-assignment state back into the canonical coordination log so reducer state, control surfaces, and launcher gates stop reading the wave as still `clarifying`.
+- `wave feedback respond --run <id>` now carries the ad-hoc run id through the reconciliation helper, so answered human input repairs the isolated ad-hoc lane state instead of the roadmap state root.
+- When a wave is stranded after a human answer arrives and no active attempt is still running, the human-input reconciliation path now writes a safe one-shot continuation request instead of leaving the wave waiting for manual relaunch bookkeeping.
+
+### Testing And Validation
+
+- Added regression coverage for direct `wave feedback respond` reconciliation and for the ad-hoc `--run <id>` answer path.
+
 ## 0.8.2 - 2026-03-24
 
 ### Changed
@@ -10,12 +27,14 @@
 
 ### 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.
+- `wave control status` now treats `phase=completed` as terminal in the control-status projection layer instead of replaying stale blocking edges from historical open coordination records.
+- Completed waves now return `blockingEdge: null` and `nextTimer: null`, so stale overdue timers or request blockers stop leaking into an already-closed wave view.
+- Successful logical-agent state is now preserved for completed waves, so agents that already finished cleanly stay `closed` or `satisfied` even when old request records remain visible in coordination history.
 
 ### Testing And Validation
 
 - Added regression coverage for completed-wave control-status projections so historical request records stay visible without reopening blocking state after closure.
+- Revalidated the shipped release surface with the full Vitest suite, `wave doctor --json`, and `wave launch --lane main --dry-run --no-dashboard`.
 
 ## 0.8.1 - 2026-03-24
 

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.2`
-- Release tag: [`v0.8.2`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.2)
+- `@chllming/wave-orchestration@0.8.3`
+- Release tag: [`v0.8.3`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.8.3)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.8.2`:
+Highlights in `0.8.3`:
 
-- `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.
+- Answering a human-feedback request now reconciles linked clarification, escalation, and helper-assignment state back into the canonical coordination log instead of only updating the feedback JSON.
+- `wave feedback respond --run <id>` now applies that same reconciliation and safe continuation flow to ad-hoc runs instead of writing into the roadmap lane state root.
+- When a stranded wave can safely continue after the answer arrives and no attempt is still running, Wave writes a one-shot continuation request automatically.
+- The completed-wave control-status hardening from `0.8.2` remains intact.
+- Upgrade and operator docs now cover the full `0.8.3` 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.2` package release surface.
+- The starter workspace in this source repo reflects the `0.8.3` 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/`.
@@ -15,6 +15,7 @@
   - `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>/`
+  - `wave feedback respond --run <run-id>` now reconciles answered human-input state inside that isolated ad-hoc state root and can queue a safe one-shot continuation request without touching roadmap state
   - 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
@@ -39,6 +40,7 @@
   - 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
+  - answered human-feedback responses that reconcile canonical coordination state, helper assignments, and safe continuation intent even when the launcher is no longer active
   - optional `--resident-orchestrator` support for a long-running, non-owning orchestrator session during live waves
   - persisted relaunch plans under `.tmp/<lane>-wave-launcher/status/` so targeted retry intent can survive a launcher restart
   - a canonical control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/` that records operator tasks, rerun requests, proof bundles, attempt lifecycle, and human-input events as append-only JSONL; `wave control` materializes state from this log

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.2` Wave surface.
+Use it as the single reference example for the current `0.8.3` 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.2
+## Upgrading From 0.6.x To 0.8.3
 
 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.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.
+`0.8.3` carries forward the `0.8.2` completed-wave control-status hardening and fixes the human-answer reconciliation path: answered feedback now closes the linked clarification or escalation chain in canonical coordination, re-syncs helper-assignment projections, and preserves ad-hoc `--run <id>` context when writing safe continuation intent.
 
 ### 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.2` authority-model language, also sync:
+If the repo copied the shipped starter architecture docs or skills and wants the `0.8.3` authority-model language, also sync:
 
 - `docs/agents/wave-launcher-role.md`
 - `docs/agents/wave-orchestrator-role.md`
@@ -57,6 +57,7 @@ After syncing those repo-owned files:
 1. Run `pnpm exec wave doctor`.
 2. Run `pnpm exec wave launch --lane main --dry-run --no-dashboard`.
 3. Use `pnpm exec wave dashboard --lane <lane> --attach current` or `--attach global` when you need to reattach to a live tmux-backed dashboard without reverse-engineering the socket or session name.
+4. If your operators answer human-input tickets through `wave feedback respond`, update any repo-local runbooks so ad-hoc runs always pass `--run <id>` when responding outside the main roadmap lane.
 
 ## Upgrading From 0.5.4 To 0.6.1
 

package/docs/reference/cli-reference.md

@@ -297,12 +297,14 @@ wave feedback ask \
 
 ```
 wave feedback respond \
-  --id <request-id> --response "<text>" \
+  [--run <id>] --id <request-id> --response "<text>" \
   [--operator <name>] [--force]
 ```
 
 `--force` overrides a previously answered request.
 
+When the answered request belongs to a live wave or ad-hoc run, `wave feedback respond` also reconciles the linked clarification, escalation, and helper-assignment state in canonical coordination. If no attempt is still running and the reducer can safely continue, it writes a one-shot continuation request instead of relaunching directly. Use `--run <id>` when answering an ad-hoc request so reconciliation targets the isolated ad-hoc state root.
+
 **List feedback requests:**
 
 ```
@@ -321,6 +323,8 @@ wave feedback watch [--lane <lane>] [--wave <n>] [--agent <id>] [--pending] [--r
 wave feedback show --id <request-id>
 ```
 
+All `wave feedback` subcommands accept `--run <id>` for ad-hoc runs.
+
 ## wave dep
 
 Cross-lane dependency management.

package/docs/reference/coordination-and-closure.md

@@ -250,6 +250,17 @@ pnpm exec wave control task act resolve --lane main --wave 10 --id escalation-cl
 
 That keeps clarification routing, dismissal, escalation, and human-answer handling inside the canonical coordination state instead of forcing ad hoc file edits.
 
+When the operator answers through the feedback queue directly, the answer path now repairs the same canonical state:
+
+```bash
+pnpm exec wave feedback respond \
+  --id 202603240000-main-w6-A3-abc123 \
+  --response "Use the 90-day compatibility window documented in docs/plans/migration.md." \
+  --operator ops-lead
+```
+
+For ad-hoc runs, include `--run <id>` on that command. The response path will reconcile the linked clarification or escalation chain, re-sync helper-assignment projections, and write a safe one-shot continuation request when the reducer can resume but no active attempt is still running.
+
 ## End-To-End Example: Required Dependency
 
 Assume the wave needs another lane to land a required API first.

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.2` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.8.3` 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.2`.
+4. Push the release commit and release tag, for example `v0.8.3`.
 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.2 Wave surface."
+summary: "Showcase-first sample waves that demonstrate the current 0.8.3 Wave surface."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the current `0.8.2` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the current `0.8.3` 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.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.8.3` 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.2`:
+Together these samples cover the main surfaces added or hardened for `0.8.3`:
 
 - 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.2",
+  "version": "0.8.3",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {

package/releases/manifest.json

@@ -2,6 +2,25 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.8.3",
+      "date": "2026-03-24",
+      "summary": "Human-input reconciliation repair, ad-hoc feedback-run context hardening, and 0.8.3 release-surface alignment.",
+      "features": [
+        "Answered human-feedback requests now reconcile linked clarification, escalation, and helper-assignment state back into the canonical coordination log instead of only updating the feedback request JSON.",
+        "`wave feedback respond --run <id>` now preserves ad-hoc run context while writing reconciliation and safe continuation state, so ad-hoc answers stop mutating the roadmap lane state root.",
+        "When no attempt is still running and the reducer can safely continue, human-input reconciliation writes a one-shot continuation request instead of leaving the wave stranded after the operator answer arrives.",
+        "Regression coverage now exercises both direct feedback-response reconciliation and the ad-hoc `--run <id>` path.",
+        "Shipped package metadata, README, migration guidance, current-state notes, sample-wave docs, and npm publishing instructions now point at the `0.8.3` release surface."
+      ],
+      "manualSteps": [
+        "If your operators answer tickets through `wave feedback respond`, update any repo-local runbooks so ad-hoc runs always pass `--run <id>` when answering outside the main roadmap lane.",
+        "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.3` runtime and human-input reconciliation 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 copied the shipped starter architecture docs or skills and wants the `0.8.3` operator guidance, sync the updated launcher and orchestrator role prompts plus the relevant runtime and closure-role skill bundles."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.8.2",
       "date": "2026-03-24",

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

@@ -6,6 +6,7 @@ import { readWaveHumanFeedbackRequests } from "./coordination.mjs";
 import { readWaveLedger } from "./ledger.mjs";
 import { buildDependencySnapshot, buildRequestAssignments } from "./routing-state.mjs";
 import { parseWaveFiles } from "./wave-files.mjs";
+import { answerHumanInputAndReconcile } from "./human-input-resolution.mjs";
 import {
   buildLanePaths,
   DEFAULT_COORDINATION_ACK_TIMEOUT_MS,
@@ -1017,6 +1018,13 @@ export async function runControlCli(argv) {
           operator: options.operator,
           force: true,
         });
+        answerHumanInputAndReconcile({
+          lanePaths,
+          wave,
+          requestId: options.id,
+          answeredPayload: answered,
+          operator: options.operator,
+        });
         appendWaveControlEvent(lanePaths, wave.wave, {
           entityType: "human_input",
           entityId: options.id,

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

@@ -23,6 +23,7 @@ import {
   writeJsonArtifact,
 } from "./coordination-store.mjs";
 import { answerFeedbackRequest } from "./feedback.mjs";
+import { answerHumanInputAndReconcile } from "./human-input-resolution.mjs";
 import { readWaveHumanFeedbackRequests } from "./coordination.mjs";
 import { readWaveProofRegistry } from "./proof-registry.mjs";
 import {
@@ -463,6 +464,13 @@ export async function runCoordinationCli(argv) {
         force: true,
         recordTelemetry: true,
       });
+      answerHumanInputAndReconcile({
+        lanePaths,
+        wave,
+        requestId: options.id,
+        answeredPayload: answered,
+        operator: options.operator,
+      });
       console.log(JSON.stringify(answered, null, 2));
       return;
     }

package/scripts/wave-orchestrator/feedback.mjs

@@ -21,6 +21,7 @@ import {
   truncate,
   writeJsonAtomic,
 } from "./shared.mjs";
+import { answerHumanInputByRequest } from "./human-input-resolution.mjs";
 import { safeQueueWaveControlEvent } from "./wave-control-client.mjs";
 
 function sanitizeToken(value) {
@@ -363,7 +364,7 @@ export async function runFeedbackCli(argv) {
     if (!options.id || !options.response) {
       throw new Error("respond requires --id and --response");
     }
-    answerFeedbackRequest({
+    const answered = answerFeedbackRequest({
       feedbackStateDir: stateDir,
       feedbackRequestsDir: requestsDir,
       requestId: options.id,
@@ -372,6 +373,15 @@ export async function runFeedbackCli(argv) {
       force: options.force,
       recordTelemetry: true,
     });
+    if (answered?.lane && Number.isFinite(Number(answered.wave))) {
+      answerHumanInputByRequest({
+        lane: answered.lane,
+        waveNumber: Number(answered.wave),
+        requestId: options.id,
+        operator: options.operator,
+        runId: options.runId || null,
+      });
+    }
     console.log(`[wave-human-feedback] answered ${options.id}`);
     return;
   }

package/scripts/wave-orchestrator/human-input-resolution.mjs

@@ -0,0 +1,344 @@
+import fs from "node:fs";
+import path from "node:path";
+import {
+  appendCoordinationRecord,
+  clarificationClosureCondition,
+  clarificationLinkedRequests,
+  isOpenCoordinationStatus,
+  readMaterializedCoordinationState,
+} from "./coordination-store.mjs";
+import { readWaveHumanFeedbackRequests } from "./coordination.mjs";
+import {
+  readControlPlaneEvents,
+  readWaveControlPlaneState,
+  syncWaveControlPlaneProjections,
+  waveControlPlaneLogPath,
+} from "./control-plane.mjs";
+import { readWaveLedger } from "./ledger.mjs";
+import { readRunExecutionSummary } from "./launcher-gates.mjs";
+import { buildResumePlan, clearWaveRelaunchPlan } from "./launcher-retry.mjs";
+import { readWaveProofRegistry } from "./proof-registry.mjs";
+import { buildDependencySnapshot, buildRequestAssignments, syncAssignmentRecords } from "./routing-state.mjs";
+import { buildLanePaths } from "./shared.mjs";
+import { reduceWaveState } from "./wave-state-reducer.mjs";
+import { parseWaveFiles } from "./wave-files.mjs";
+import { writeWaveRetryOverride } from "./retry-control.mjs";
+
+function coordinationLogPath(lanePaths, waveNumber) {
+  return path.join(lanePaths.coordinationDir, `wave-${waveNumber}.jsonl`);
+}
+
+function ledgerPath(lanePaths, waveNumber) {
+  return path.join(lanePaths.ledgerDir, `wave-${waveNumber}.json`);
+}
+
+function coordinationTriagePath(lanePaths, waveNumber) {
+  return path.join(lanePaths.feedbackTriageDir, `wave-${waveNumber}.jsonl`);
+}
+
+function appendCoordinationStatusUpdate(logPath, record, status, options = {}) {
+  return appendCoordinationRecord(logPath, {
+    ...record,
+    status,
+    summary: options.summary || record.summary,
+    detail: options.detail || record.detail,
+    source: options.source || "operator",
+  });
+}
+
+function appendTriageEscalationUpdateIfPresent(lanePaths, waveNumber, record) {
+  const triagePath = coordinationTriagePath(lanePaths, waveNumber);
+  if (!fs.existsSync(triagePath) || record?.kind !== "human-escalation") {
+    return;
+  }
+  appendCoordinationRecord(triagePath, record);
+}
+
+function loadWave(lanePaths, waveNumber) {
+  const waves = parseWaveFiles(lanePaths.wavesDir, { laneProfile: lanePaths.laneProfile });
+  const wave = waves.find((entry) => entry.wave === waveNumber);
+  if (!wave) {
+    throw new Error(`Wave ${waveNumber} not found in ${lanePaths.wavesDir}`);
+  }
+  return wave;
+}
+
+function taskRunInfoForAgent(lanePaths, wave, agent, proofRegistry) {
+  const safeName = `wave-${wave.wave}-${agent.slug}`;
+  return {
+    agent,
+    logPath: path.join(lanePaths.logsDir, `${safeName}.log`),
+    statusPath: path.join(lanePaths.statusDir, `${safeName}.status`),
+    proofRegistry,
+  };
+}
+
+function feedbackLinkMatchesRecord(record, requestId) {
+  const normalizedRequestId = String(requestId || "").trim();
+  if (!normalizedRequestId) {
+    return false;
+  }
+  if (String(record?.id || "").trim() === normalizedRequestId) {
+    return true;
+  }
+  if (
+    Array.isArray(record?.artifactRefs) &&
+    record.artifactRefs.some((ref) => String(ref || "").trim() === normalizedRequestId)
+  ) {
+    return true;
+  }
+  if (
+    Array.isArray(record?.dependsOn) &&
+    record.dependsOn.some((value) => String(value || "").trim() === normalizedRequestId)
+  ) {
+    return true;
+  }
+  return false;
+}
+
+function linkedClarificationIdsForRecords(records) {
+  const ids = new Set();
+  for (const record of records || []) {
+    if (record?.kind === "clarification-request" && record?.id) {
+      ids.add(record.id);
+      continue;
+    }
+    const closureCondition = String(record?.closureCondition || "").trim();
+    if (closureCondition.startsWith("clarification:")) {
+      ids.add(closureCondition.slice("clarification:".length));
+    }
+  }
+  return [...ids].filter(Boolean);
+}
+
+export function resolveFeedbackLinkedCoordination({
+  lanePaths,
+  wave,
+  requestId,
+  operator = "human-operator",
+  detail = "",
+}) {
+  const logPath = coordinationLogPath(lanePaths, wave.wave);
+  const state = readMaterializedCoordinationState(logPath);
+  const resolvedRecords = [];
+
+  const directlyLinked = state.latestRecords.filter((record) =>
+    isOpenCoordinationStatus(record.status) && feedbackLinkMatchesRecord(record, requestId),
+  );
+
+  for (const record of directlyLinked) {
+    const updated = appendCoordinationStatusUpdate(logPath, record, "resolved", {
+      detail: detail || `Resolved after answered human input ${requestId}.`,
+      summary: record.summary,
+      source: operator,
+    });
+    resolvedRecords.push(updated);
+    appendTriageEscalationUpdateIfPresent(lanePaths, wave.wave, updated);
+  }
+
+  const nextState = readMaterializedCoordinationState(logPath);
+  const clarificationIds = linkedClarificationIdsForRecords([
+    ...directlyLinked,
+    ...resolvedRecords,
+  ]);
+  for (const clarificationId of clarificationIds) {
+    const clarification = nextState.byId.get(clarificationId);
+    if (!clarification || !isOpenCoordinationStatus(clarification.status)) {
+      continue;
+    }
+    const updatedClarification = appendCoordinationStatusUpdate(logPath, clarification, "resolved", {
+      detail: detail || `Resolved after answered human input ${requestId}.`,
+      summary: clarification.summary,
+      source: operator,
+    });
+    resolvedRecords.push(updatedClarification);
+  }
+
+  const resolvedState = readMaterializedCoordinationState(logPath);
+  for (const clarificationId of clarificationIds) {
+    const linkedRequests = clarificationLinkedRequests(resolvedState, clarificationId).filter((entry) =>
+      isOpenCoordinationStatus(entry.status),
+    );
+    for (const linked of linkedRequests) {
+      const updatedLinked = appendCoordinationStatusUpdate(logPath, linked, "resolved", {
+        detail: `Resolved via clarification ${clarificationId}.`,
+        summary: linked.summary,
+        source: operator,
+      });
+      resolvedRecords.push(updatedLinked);
+    }
+    for (const escalation of (resolvedState.humanEscalations || []).filter(
+      (entry) =>
+        isOpenCoordinationStatus(entry.status) &&
+        entry.closureCondition === clarificationClosureCondition(clarificationId),
+    )) {
+      const updatedEscalation = appendCoordinationStatusUpdate(logPath, escalation, "resolved", {
+        detail: detail || `Resolved via clarification ${clarificationId}.`,
+        summary: escalation.summary,
+        source: operator,
+      });
+      resolvedRecords.push(updatedEscalation);
+      appendTriageEscalationUpdateIfPresent(lanePaths, wave.wave, updatedEscalation);
+    }
+  }
+
+  const assignmentState = readMaterializedCoordinationState(logPath);
+  const ledger = readWaveLedger(ledgerPath(lanePaths, wave.wave)) || { phase: "planned" };
+  const assignments = buildRequestAssignments({
+    coordinationState: assignmentState,
+    agents: wave.agents,
+    ledger,
+    capabilityRouting: lanePaths.capabilityRouting,
+  });
+  syncAssignmentRecords(logPath, {
+    lane: lanePaths.lane,
+    wave: wave.wave,
+    assignments,
+  });
+
+  return {
+    resolvedRecords,
+    clarificationIds,
+  };
+}
+
+export function buildResumePlanFromDisk({ lanePaths, wave }) {
+  const proofRegistry = readWaveProofRegistry(lanePaths, wave.wave);
+  const agentRuns = wave.agents.map((agent) =>
+    taskRunInfoForAgent(lanePaths, wave, agent, proofRegistry),
+  );
+  const agentResults = Object.fromEntries(
+    agentRuns
+      .map((runInfo) => [runInfo.agent.agentId, readRunExecutionSummary(runInfo, wave)])
+      .filter(([, summary]) => Boolean(summary)),
+  );
+  const coordinationState = readMaterializedCoordinationState(coordinationLogPath(lanePaths, wave.wave));
+  const feedbackRequests = readWaveHumanFeedbackRequests({
+    feedbackRequestsDir: lanePaths.feedbackRequestsDir,
+    lane: lanePaths.lane,
+    waveNumber: wave.wave,
+    agentIds: wave.agents.map((agent) => agent.agentId),
+    orchestratorId: "",
+  });
+  const ledger = readWaveLedger(ledgerPath(lanePaths, wave.wave)) || { phase: "planned" };
+  const dependencySnapshot = buildDependencySnapshot({
+    dirPath: lanePaths.crossLaneDependenciesDir,
+    lane: lanePaths.lane,
+    waveNumber: wave.wave,
+    agents: wave.agents,
+    ledger,
+    capabilityRouting: lanePaths.capabilityRouting,
+  });
+  const reducerState = reduceWaveState({
+    controlPlaneEvents: readControlPlaneEvents(waveControlPlaneLogPath(lanePaths, wave.wave)),
+    coordinationRecords: coordinationState.latestRecords || [],
+    agentResults,
+    waveDefinition: wave,
+    dependencyTickets: dependencySnapshot,
+    feedbackRequests,
+    laneConfig: {
+      lane: lanePaths.lane,
+      contQaAgentId: lanePaths.contQaAgentId || "A0",
+      contEvalAgentId: lanePaths.contEvalAgentId || "E0",
+      integrationAgentId: lanePaths.integrationAgentId || "A8",
+      documentationAgentId: lanePaths.documentationAgentId || "A9",
+      validationMode: "live",
+      evalTargets: wave.evalTargets,
+      benchmarkCatalogPath: lanePaths.laneProfile?.paths?.benchmarkCatalogPath,
+      laneProfile: lanePaths.laneProfile,
+      requireIntegrationStewardFromWave: lanePaths.requireIntegrationStewardFromWave,
+      capabilityRouting: lanePaths.capabilityRouting,
+    },
+  });
+  return buildResumePlan(reducerState, {
+    waveDefinition: wave,
+    lanePaths,
+  });
+}
+
+export function maybeWriteAutoResumeRequest({
+  lanePaths,
+  wave,
+  requestedBy = "human-operator",
+  reason = "",
+}) {
+  const controlState = readWaveControlPlaneState(lanePaths, wave.wave);
+  if (controlState.activeAttempt || controlState.activeRerunRequest) {
+    return null;
+  }
+  const resumePlan = buildResumePlanFromDisk({ lanePaths, wave });
+  if (!resumePlan.canResume || resumePlan.reason === "human-request") {
+    return { resumePlan, request: null };
+  }
+  if (resumePlan.resumeFromPhase === "completed") {
+    return { resumePlan, request: null };
+  }
+  clearWaveRelaunchPlan(lanePaths, wave.wave);
+  const payload = {
+    requestedBy,
+    reason:
+      reason ||
+      `Auto continuation after answered human input; resume from ${resumePlan.resumeFromPhase}.`,
+    preserveReusableAgentIds: resumePlan.reusableAgentIds,
+    reuseProofBundleIds: resumePlan.reusableProofBundleIds,
+    applyOnce: true,
+  };
+  if (resumePlan.resumeFromPhase === "implementation") {
+    payload.selectedAgentIds = resumePlan.invalidatedAgentIds;
+  } else {
+    payload.resumePhase = resumePlan.resumeFromPhase;
+  }
+  const request = writeWaveRetryOverride(lanePaths, wave.wave, payload);
+  return { resumePlan, request };
+}
+
+export function answerHumanInputAndReconcile({
+  lanePaths,
+  wave,
+  requestId,
+  answeredPayload,
+  operator = "human-operator",
+}) {
+  const detail =
+    `Resolved after human input ${requestId} was answered by ${operator}` +
+    (answeredPayload?.response?.text ? `: ${answeredPayload.response.text}` : ".");
+  const resolution = resolveFeedbackLinkedCoordination({
+    lanePaths,
+    wave,
+    requestId,
+    operator,
+    detail,
+  });
+  syncWaveControlPlaneProjections(
+    lanePaths,
+    wave.wave,
+    readWaveControlPlaneState(lanePaths, wave.wave),
+  );
+  const autoResume = maybeWriteAutoResumeRequest({
+    lanePaths,
+    wave,
+    requestedBy: operator,
+    reason: `Auto continuation after answered human input ${requestId}.`,
+  });
+  return {
+    resolution,
+    autoResume,
+  };
+}
+
+export function answerHumanInputByRequest({
+  lane,
+  waveNumber,
+  requestId,
+  operator = "human-operator",
+  runId = null,
+}) {
+  const lanePaths = buildLanePaths(lane, { adhocRunId: runId || null });
+  const wave = loadWave(lanePaths, waveNumber);
+  return answerHumanInputAndReconcile({
+    lanePaths,
+    wave,
+    requestId,
+    operator,
+  });
+}