@chllming/wave-orchestration 0.8.6 → 0.8.8

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.8.6 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.8.8 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.8.6` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.8.8` 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.6` 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.8` 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.
@@ -42,7 +42,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 through `0.8.6`:
+Together these samples cover the main surfaces added or hardened through `0.8.8`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -89,7 +89,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.8.6` 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.8.8` 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.8.6` 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.8.8` 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

@@ -42,6 +42,8 @@ This lets the control plane answer:
 - which proof and benchmark artifacts back a claim
 - whether a benchmark result is comparison-valid or only diagnostic
 - which coordination failures blocked closure
+- which blockers were hard, soft, stale, or advisory
+- whether a blocked wave is terminal or recoverable and which targeted rerun request was queued
 
 ## Run Identity
 
@@ -92,6 +94,20 @@ Signals to preserve:
 - benchmark trust:
   every benchmark item should distinguish capability from validity
 
+## Blocker And Recovery Metadata
+
+Wave Control should preserve the softer runtime policy, not flatten it away.
+
+In practice that means `coordination_record`, `task`, `gate`, `wave_run`, and `rerun_request` payloads should keep fields such as:
+
+- `blocking`
+- `blockerSeverity`
+- `recoverable`
+- `recoveryReason`
+- queued rerun request ids or resume targets
+
+That distinction matters because a wave that is `blocked` by a proof-critical gate is different from a wave that is `blocked` only long enough to surface a targeted recovery after timeout, max-turn, rate-limit, or missing-status failure. The control plane should let operators ask which barriers still stop closure outright and which ones were intentionally downgraded to advisory or stale context.
+
 ## Artifact Contract
 
 Selected artifacts are described with typed descriptors:

package/docs/reference/wave-planning-lessons.md

@@ -74,11 +74,15 @@ runtime setup, and the closure artifacts all describe the same truth.
 ## 7. Runtime setup matters as much as wave prose
 
 - Do not use small fixed turn caps for synthesis-heavy or closure-heavy agents.
-  Bound them with `budget.minutes`, not `budget.turns`.
+  Bound them with `budget.minutes`, not generic `budget.turns`.
+- Treat generic `budget.turns` as advisory unless you intentionally set a
+  runtime-specific hard stop such as `claude.max_turns` or `opencode.steps`.
 - Pin exact model and reasoning settings for each runtime. Ambiguous profiles
   create unclear failure modes.
 - Avoid cross-runtime fallback on live-proof or deploy-sensitive slices unless
   there is a very good reason.
+- For non-proof-centric owners, prefer targeted recovery and reuse over broad
+  relaunch when a timeout or max-turn event leaves partial artifacts behind.
 - Context7 should be explicit and real; unresolved bundles create noise instead
   of help.
 
@@ -121,6 +125,8 @@ runtime setup, and the closure artifacts all describe the same truth.
 - Are A8 and A0 told what would make the wave fail honestly?
 - Are runtime pins, Context7 bundles, and budgets specific enough to avoid
   preventable execution failures?
+- Can any non-proof coordination ask be authored as `soft`, `stale`, or
+  `advisory` instead of silently becoming a hard closure blocker?
 - Would a reviewer understand the difference between “code landed” and
   “component promoted” just by reading the wave file?
 

package/docs/research/coordination-failure-review.md

@@ -229,16 +229,16 @@ This is the central failure highlighted by `HiddenBench` and `Silo-Bench`, and t
 
 ### 3. Expertise routing is explicit, but shallow
 
-[scripts/wave-orchestrator/routing-state.mjs](../../scripts/wave-orchestrator/routing-state.mjs) is better than unconstrained self-organization, but it still routes mostly by:
+[scripts/wave-orchestrator/routing-state.mjs](../../scripts/wave-orchestrator/routing-state.mjs) is better than unconstrained self-organization, and it now has a light same-wave success preference, but it still routes mostly by:
 
 - explicit target
 - configured preferred agents
 - declared capability ownership
+- demonstrated same-wave completions on the capability
 - least-busy fallback
 
-It does not yet weight:
+Beyond that light historical-success preference, it still does not weight:
 
-- historical success on a capability
 - evidence quality by agent
 - confidence calibration
 - expert-leverage metrics
@@ -247,14 +247,14 @@ So the repo partially addresses the concern from `Multi-Agent Teams Hold Experts
 
 ### 4. Clarification and contradiction handling are still somewhat heuristic
 
-Clarification triage and integration evidence aggregation are real safeguards, but they still lean heavily on:
+Clarification triage, blocker taxonomy, operator downgrade controls, and integration evidence aggregation are real safeguards, but they still lean heavily on:
 
 - ownership mappings
 - artifact references
 - structured markers
 - text-level summaries and conflict extraction
 
-That is enough to make the runtime operationally safer, but it is not yet a richer semantic evidence-integration layer. Subtle contradictions or latent information asymmetries may still be missed.
+That is enough to make the runtime operationally safer. The newer hard-vs-soft blocker split also removes some unnecessary terminal failures by letting stale or advisory coordination remain visible without owning closure. But it is not yet a richer semantic evidence-integration layer, and subtle contradictions or latent information asymmetries may still be missed.
 
 ### 5. DPBench-style simultaneous coordination is only indirectly addressed
 
@@ -283,7 +283,7 @@ So the design points in the right direction, but the claim is not yet validated.
 
 If the standard is "does this repo merely claim multi-agent coordination," the answer is no. It has real machinery for blackboard-like state sharing, evidence-based closure, clarification handling, and coordination diagnostics.
 
-If the standard is "has this repo already demonstrated that its design beats the core failure modes isolated by HiddenBench, Silo-Bench, DPBench, and related work," the answer is also no. The design is substantially more credible than most MAS stacks, but the empirical proof is still missing.
+If the standard is "has this repo already demonstrated that its design beats the core failure modes isolated by HiddenBench, Silo-Bench, DPBench, and related work," the answer is also no. The design is substantially more credible than most MAS stacks, and it now also reduces avoidable failure through targeted recovery, blocker severity, and policy-safe downgrade paths, but the empirical proof is still missing.
 
 The most accurate claim today is:
 

package/package.json

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

package/releases/manifest.json

@@ -2,6 +2,42 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.8.8",
+      "date": "2026-03-27",
+      "summary": "0.8.8 release-surface alignment, packaged operating recommendations, and install-state fixture refresh.",
+      "features": [
+        "The practical operating recommendations guide now ships as `docs/guides/recommendations-0.8.8.md`, and the README, migration, coordination, and runtime-config docs now point at the same current package surface.",
+        "The tracked `.wave/install-state.json` fixture and upgrade-history metadata now align with the `0.8.8` package version so `wave doctor --json` no longer reports stale install-state versioning after the follow-up docs release.",
+        "Release-surface regression coverage now derives the recommendations-guide path from `package.json` instead of a hard-coded `0.8.7` filename, which hardens future release cuts against the same doc-link drift.",
+        "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` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.8.8` release surface.",
+        "If your repo copied current-surface 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`, and `docs/guides/recommendations-0.8.8.md` so local guidance matches the packaged release.",
+        "If your repo tracks the install-state fixture in source control, refresh `.wave/install-state.json` and the matching upgrade-history report so repo-owned validation stays aligned with the installed package."
+      ],
+      "breaking": false
+    },
+    {
+      "version": "0.8.7",
+      "date": "2026-03-27",
+      "summary": "Policy-consistency hardening, capability-specific same-wave routing, stable per-wave tmux session reuse, and 0.8.7 release-surface alignment.",
+      "features": [
+        "Generic `budget.turns` is now documented and tested consistently as advisory metadata only; hard runtime turn ceilings come only from runtime-specific settings such as `claude.maxTurns` or `opencode.steps`.",
+        "Capability-targeted helper routing now prefers demonstrated same-wave success for the requested capability before falling back to the least-busy matching capability owner, and unrelated completed work no longer counts as routing evidence.",
+        "Advisory, stale, and other non-blocking clarification or human-input records stay visible in control and reducer projections without reopening hard blocked reducer state by themselves.",
+        "Wave-agent, resident-orchestrator, and per-wave dashboard tmux sessions now reuse stable per-wave session names, so stale launcher exits stop accumulating extra sessions for the same wave.",
+        "Structured signal extraction now also recognizes markers embedded inside JSON log lines, so wrapped executor transcripts still produce proof, doc-delta, and component evidence."
+      ],
+      "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.7` routing, blocker-severity, signal-wrapper, and stable-session behavior.",
+        "If your repo copied starter scripts or operator docs, sync `scripts/wave-status.sh`, `scripts/wave-watch.sh`, `docs/guides/signal-wrappers.md`, `docs/guides/terminal-surfaces.md`, `docs/reference/cli-reference.md`, and any local tmux/session runbooks that still assume run-tagged session names.",
+        "If your repo copied planner or routing guidance, sync `docs/guides/planner.md`, `docs/reference/wave-planning-lessons.md`, `docs/plans/wave-orchestrator.md`, the `planner-agentic` bundle entry in `docs/context7/bundles.json`, and any local helper-assignment policy docs so they describe capability-specific same-wave routing evidence instead of generic prior completion.",
+        "If your repo relies on advisory `budget.turns` as if it were a hard ceiling, move that limit to the runtime-specific executor config (`claude.maxTurns` or `opencode.steps`) before you depend on deterministic turn enforcement."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.8.6",
       "date": "2026-03-25",

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

@@ -160,6 +160,44 @@ function appendParsedStructuredSignalCandidates(lines, candidates, { requireAll
   candidates.push(...parsedCandidates);
 }
 
+function collectEmbeddedStructuredSignalTexts(value, texts) {
+  if (!value || typeof value !== "object") {
+    return;
+  }
+  if (Array.isArray(value)) {
+    for (const item of value) {
+      collectEmbeddedStructuredSignalTexts(item, texts);
+    }
+    return;
+  }
+  if (typeof value.text === "string") {
+    texts.push(value.text);
+  }
+  if (typeof value.aggregated_output === "string") {
+    texts.push(value.aggregated_output);
+  }
+  for (const nestedValue of Object.values(value)) {
+    if (nestedValue && typeof nestedValue === "object") {
+      collectEmbeddedStructuredSignalTexts(nestedValue, texts);
+    }
+  }
+}
+
+function extractEmbeddedStructuredSignalTextsFromJsonLine(line) {
+  const trimmed = String(line || "").trim();
+  if (!trimmed || !/^[{\[]/.test(trimmed)) {
+    return [];
+  }
+  try {
+    const payload = JSON.parse(trimmed);
+    const texts = [];
+    collectEmbeddedStructuredSignalTexts(payload, texts);
+    return texts.filter(Boolean);
+  } catch {
+    return [];
+  }
+}
+
 function collectStructuredSignalCandidates(text) {
   if (!text) {
     return [];
@@ -167,6 +205,10 @@ function collectStructuredSignalCandidates(text) {
   const candidates = [];
   let fenceLines = null;
   for (const rawLine of String(text || "").split(/\r?\n/)) {
+    const embeddedTexts = extractEmbeddedStructuredSignalTextsFromJsonLine(rawLine);
+    for (const embeddedText of embeddedTexts) {
+      candidates.push(...collectStructuredSignalCandidates(embeddedText));
+    }
     const trimmed = rawLine.trim();
     if (/^```/.test(trimmed)) {
       if (fenceLines === null) {

package/scripts/wave-orchestrator/autonomous.mjs

@@ -27,8 +27,13 @@ import {
   maybeAnnouncePackageUpdate,
   WAVE_SUPPRESS_UPDATE_NOTICE_ENV,
 } from "./package-update-notice.mjs";
+import { buildTaskSnapshots } from "./control-plane.mjs";
+import { readWaveHumanFeedbackRequests } from "./coordination.mjs";
 import { readRunState } from "./wave-files.mjs";
-import { readDependencyTickets } from "./coordination-store.mjs";
+import {
+  readDependencyTickets,
+  readMaterializedCoordinationState,
+} from "./coordination-store.mjs";
 import { readWaveLedger } from "./ledger.mjs";
 
 const AUTONOMOUS_EXECUTOR_MODES = SUPPORTED_EXECUTOR_MODES.filter((mode) => mode !== "local");
@@ -249,7 +254,38 @@ function requiredInboundDependenciesOpen(lanePaths, lane) {
   });
 }
 
-function pendingHumanItemsForWave(lanePaths, wave) {
+function liveBlockingHumanItemsForWave(lanePaths, lane, wave) {
+  if (!lanePaths?.coordinationDir || !lanePaths?.feedbackRequestsDir) {
+    return null;
+  }
+  const coordinationState = readMaterializedCoordinationState(
+    path.join(lanePaths.coordinationDir, `wave-${wave}.jsonl`),
+  );
+  const feedbackRequests = readWaveHumanFeedbackRequests({
+    feedbackRequestsDir: lanePaths.feedbackRequestsDir,
+    lane,
+    waveNumber: wave,
+    agentIds: [],
+    orchestratorId: "",
+  });
+  return buildTaskSnapshots({
+    coordinationState,
+    feedbackRequests,
+  })
+    .filter(
+      (task) =>
+        ["human-input", "escalation"].includes(task.taskType) &&
+        task.blocking !== false &&
+        ["open", "working", "input-required"].includes(task.state),
+    )
+    .map((task) => task.taskId);
+}
+
+function pendingHumanItemsForWave(lanePaths, lane, wave) {
+  const liveItems = liveBlockingHumanItemsForWave(lanePaths, lane, wave);
+  if (Array.isArray(liveItems)) {
+    return liveItems;
+  }
   const existingLedger = readWaveLedger(path.join(lanePaths.ledgerDir, `wave-${wave}.json`));
   return [
     ...(existingLedger?.humanFeedback || []),
@@ -257,7 +293,7 @@ function pendingHumanItemsForWave(lanePaths, wave) {
   ];
 }
 
-function pendingHumanItemsForLane(lanePaths) {
+function pendingHumanItemsForLane(lanePaths, lane) {
   if (!fs.existsSync(lanePaths.ledgerDir)) {
     return [];
   }
@@ -271,7 +307,7 @@ function pendingHumanItemsForLane(lanePaths) {
     .filter((item) => Number.isFinite(item.wave))
     .sort((left, right) => left.wave - right.wave)
     .flatMap((item) =>
-      pendingHumanItemsForWave(lanePaths, item.wave).map((id) => ({
+      pendingHumanItemsForWave(lanePaths, lane, item.wave).map((id) => ({
         wave: item.wave,
         id,
       })),
@@ -292,7 +328,7 @@ export function readAutonomousBarrier(lanePaths, lane, wave = null) {
     };
   }
   if (wave === null) {
-    const pendingHumanEntries = pendingHumanItemsForLane(lanePaths);
+    const pendingHumanEntries = pendingHumanItemsForLane(lanePaths, lane);
     if (pendingHumanEntries.length > 0) {
       return {
         kind: "human-input",
@@ -303,7 +339,7 @@ export function readAutonomousBarrier(lanePaths, lane, wave = null) {
     }
     return null;
   }
-  const pendingHumanItems = pendingHumanItemsForWave(lanePaths, wave);
+  const pendingHumanItems = pendingHumanItemsForWave(lanePaths, lane, wave);
   if (pendingHumanItems.length > 0) {
     return {
       kind: "human-input",

package/scripts/wave-orchestrator/clarification-triage.mjs

@@ -4,6 +4,7 @@ import {
   appendCoordinationRecord,
   clarificationClosureCondition,
   clarificationLinkedRequests,
+  coordinationRecordBlocksWave,
   isOpenCoordinationStatus,
   readMaterializedCoordinationState,
 } from "./coordination-store.mjs";
@@ -467,14 +468,14 @@ export function triageClarificationRequests({
   ensureDirectory(lanePaths.feedbackTriageDir);
   const triagePath = triageLogPath(lanePaths, wave.wave);
   const openClarifications = (coordinationState?.clarifications || []).filter((record) =>
-    isOpenCoordinationStatus(record.status),
+    coordinationRecordBlocksWave(record),
   );
   let changed = false;
 
   for (const record of openClarifications) {
     const linkedRequests = clarificationLinkedRequests(coordinationState, record.id);
     const openLinkedRequests = linkedRequests.filter((entry) =>
-      isOpenCoordinationStatus(entry.status),
+      coordinationRecordBlocksWave(entry),
     );
     const openAckPendingLinkedRequests = openLinkedRequests.filter(
       (entry) => entry.status === "open",
@@ -487,7 +488,7 @@ export function triageClarificationRequests({
     const openEscalations = (coordinationState?.humanEscalations || []).filter(
       (entry) =>
         entry.closureCondition === clarificationClosureCondition(record.id) &&
-        isOpenCoordinationStatus(entry.status),
+        coordinationRecordBlocksWave(entry),
     );
     if (resolvedLinkedRequest || resolvedEscalation) {
       if (openEscalations.length > 0) {

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

@@ -1,6 +1,13 @@
 import fs from "node:fs";
 import path from "node:path";
-import { appendCoordinationRecord, clarificationClosureCondition, clarificationLinkedRequests, isOpenCoordinationStatus, readMaterializedCoordinationState, updateSeedRecords } from "./coordination-store.mjs";
+import {
+  appendCoordinationRecord,
+  clarificationClosureCondition,
+  clarificationLinkedRequests,
+  isOpenCoordinationStatus,
+  readMaterializedCoordinationState,
+  updateSeedRecords,
+} from "./coordination-store.mjs";
 import { answerFeedbackRequest, createFeedbackRequest } from "./feedback.mjs";
 import { readWaveHumanFeedbackRequests } from "./coordination.mjs";
 import { readWaveLedger } from "./ledger.mjs";
@@ -18,6 +25,7 @@ import {
   REPO_ROOT,
   sanitizeAdhocRunId,
   sanitizeLaneName,
+  toIsoTimestamp,
 } from "./shared.mjs";
 import {
   appendWaveControlEvent,
@@ -50,7 +58,7 @@ function printUsage() {
   wave control task create --lane <lane> --wave <n> --agent <id> --kind <request|blocker|clarification|handoff|evidence|claim|decision|human-input> --summary <text> [options]
   wave control task list --lane <lane> --wave <n> [--agent <id>] [--json]
   wave control task get --lane <lane> --wave <n> --id <task-id> [--json]
-  wave control task act <start|resolve|dismiss|cancel|reassign|answer|escalate> --lane <lane> --wave <n> --id <task-id> [options]
+  wave control task act <start|resolve|dismiss|cancel|reassign|answer|escalate|defer|mark-advisory|mark-stale|resolve-policy> --lane <lane> --wave <n> --id <task-id> [options]
 
   wave control rerun request --lane <lane> --wave <n> [--agent <id> ...] [--resume-cursor <cursor>] [--reuse-attempt <id> ...] [--reuse-proof <id> ...] [--reuse-derived-summaries <true|false>] [--invalidate-component <id> ...] [--clear-reuse <id> ...] [--preserve-reuse <id> ...] [--requested-by <name>] [--reason <text>] [--json]
   wave control rerun get --lane <lane> --wave <n> [--json]
@@ -94,6 +102,8 @@ function parseArgs(argv) {
     detail: "",
     targets: [],
     priority: "normal",
+    blocking: null,
+    blockerSeverity: "",
     dependsOn: [],
     artifactRefs: [],
     status: "open",
@@ -155,6 +165,10 @@ function parseArgs(argv) {
       options.targets.push(String(args[++i] || "").trim());
     } else if (arg === "--priority") {
       options.priority = String(args[++i] || "").trim();
+    } else if (arg === "--blocking") {
+      options.blocking = normalizeBooleanish(args[++i], true);
+    } else if (arg === "--severity") {
+      options.blockerSeverity = String(args[++i] || "").trim();
     } else if (arg === "--depends-on") {
       options.dependsOn.push(String(args[++i] || "").trim());
     } else if (arg === "--artifact") {
@@ -264,7 +278,10 @@ const BLOCKING_TASK_TYPES = new Set([
 ]);
 
 function taskBlocksAgent(task) {
-  return BLOCKING_TASK_TYPES.has(String(task?.taskType || "").trim().toLowerCase());
+  return (
+    BLOCKING_TASK_TYPES.has(String(task?.taskType || "").trim().toLowerCase()) &&
+    task?.blocking !== false
+  );
 }
 
 function assignmentRelevantToAgent(assignment, agentId = "") {
@@ -462,7 +479,9 @@ function buildBlockingEdge({
       selectionTargetsAgent(task.assigneeAgentId, attemptSelection)
     );
   });
-  const pendingHuman = scopedTasks.find((task) => task.state === "input-required");
+  const pendingHuman = scopedTasks.find(
+    (task) => task.state === "input-required" && task.blocking !== false,
+  );
   if (pendingHuman) {
     return {
       kind: "human-input",
@@ -472,7 +491,10 @@ function buildBlockingEdge({
     };
   }
   const escalation = scopedTasks.find(
-    (task) => task.taskType === "escalation" && ["open", "working"].includes(task.state),
+    (task) =>
+      task.taskType === "escalation" &&
+      task.blocking !== false &&
+      ["open", "working"].includes(task.state),
   );
   if (escalation) {
     return {
@@ -483,7 +505,10 @@ function buildBlockingEdge({
     };
   }
   const clarification = scopedTasks.find(
-    (task) => task.taskType === "clarification" && ["open", "working"].includes(task.state),
+    (task) =>
+      task.taskType === "clarification" &&
+      task.blocking !== false &&
+      ["open", "working"].includes(task.state),
   );
   if (clarification) {
     return {
@@ -564,7 +589,10 @@ function buildBlockingEdge({
     };
   }
   const blocker = scopedTasks.find(
-    (task) => task.taskType === "blocker" && ["open", "working"].includes(task.state),
+    (task) =>
+      task.taskType === "blocker" &&
+      task.blocking !== false &&
+      ["open", "working"].includes(task.state),
   );
   if (blocker) {
     return {
@@ -575,7 +603,10 @@ function buildBlockingEdge({
     };
   }
   const request = scopedTasks.find(
-    (task) => task.taskType === "request" && ["open", "working"].includes(task.state),
+    (task) =>
+      task.taskType === "request" &&
+      task.blocking !== false &&
+      ["open", "working"].includes(task.state),
   );
   if (request) {
     return {
@@ -738,7 +769,9 @@ function printStatus(payload) {
 function appendCoordinationStatusUpdate(logPath, record, status, options = {}) {
   return appendCoordinationRecord(logPath, {
     ...record,
+    ...(options.patch || {}),
     status,
+    updatedAt: options.updatedAt || toIsoTimestamp(),
     summary: options.summary || record.summary,
     detail: options.detail || record.detail,
     source: options.source || "operator",
@@ -823,6 +856,73 @@ function appendTaskCoordinationEvent(logPath, lanePaths, wave, record, action, o
       source: "operator",
     });
   }
+  if (action === "defer") {
+    return appendCoordinationStatusUpdate(logPath, record, record.status, {
+      detail:
+        options.detail ||
+        `${record.summary || record.id} deferred by operator; keep visible but do not block wave progression.`,
+      patch: {
+        blocking: false,
+        blockerSeverity: "soft",
+      },
+    });
+  }
+  if (action === "mark-advisory") {
+    return appendCoordinationStatusUpdate(logPath, record, record.status, {
+      detail:
+        options.detail ||
+        `${record.summary || record.id} marked advisory by operator; keep visible without blocking closure.`,
+      patch: {
+        blocking: false,
+        blockerSeverity: "advisory",
+      },
+    });
+  }
+  if (action === "mark-stale") {
+    return appendCoordinationStatusUpdate(logPath, record, record.status, {
+      detail:
+        options.detail ||
+        `${record.summary || record.id} marked stale by operator; historical context preserved without blocking.`,
+      patch: {
+        blocking: false,
+        blockerSeverity: "stale",
+      },
+    });
+  }
+  if (action === "resolve-policy") {
+    const resolvedRecord = appendCoordinationStatusUpdate(logPath, record, "resolved", {
+      detail: options.detail || `Resolved by operator policy: ${record.summary || record.id}.`,
+      patch: {
+        blocking: false,
+        blockerSeverity: "advisory",
+      },
+    });
+    const policyRecord = appendCoordinationRecord(logPath, {
+      id: `policy-${record.id}`,
+      lane: lanePaths.lane,
+      wave: wave.wave,
+      agentId: options.agent || "operator",
+      kind: "resolved-by-policy",
+      targets: record.targets,
+      priority: record.priority,
+      artifactRefs: record.artifactRefs,
+      dependsOn: Array.from(new Set([record.id, ...(record.dependsOn || [])])),
+      closureCondition:
+        record.kind === "clarification-request"
+          ? clarificationClosureCondition(record.id)
+          : record.closureCondition || "",
+      summary: record.summary,
+      detail: options.detail || `Operator resolved ${record.id} by policy.`,
+      status: "resolved",
+      source: "operator",
+      blocking: false,
+      blockerSeverity: "advisory",
+    });
+    return {
+      resolvedRecord,
+      policyRecord,
+    };
+  }
   throw new Error(`Unsupported task action: ${action}`);
 }
 
@@ -975,6 +1075,8 @@ export async function runControlCli(argv) {
         artifactRefs: options.artifactRefs,
         status: options.status,
         source: "operator",
+        ...(options.blocking !== null ? { blocking: options.blocking } : {}),
+        ...(options.blockerSeverity ? { blockerSeverity: options.blockerSeverity } : {}),
       });
       console.log(JSON.stringify(record, null, 2));
       return;
@@ -1067,14 +1169,27 @@ export async function runControlCli(argv) {
         throw new Error(`Task not found: ${options.id}`);
       }
       const updated = appendTaskCoordinationEvent(logPath, lanePaths, wave, record, action, options);
-      if (record.kind === "clarification-request" && ["resolve", "dismiss"].includes(action)) {
+      if (record.kind === "clarification-request" && ["resolve", "dismiss", "resolve-policy"].includes(action)) {
         const nextStatus = action === "resolve" ? "resolved" : "cancelled";
+        const linkedStatus = action === "resolve-policy" ? "resolved" : nextStatus;
         for (const linked of clarificationLinkedRequests(coordinationState, record.id).filter((entry) =>
           isOpenCoordinationStatus(entry.status),
         )) {
-          appendCoordinationStatusUpdate(logPath, linked, nextStatus, {
-            detail: `${action === "resolve" ? "Resolved" : "Cancelled"} via clarification ${record.id}.`,
+          appendCoordinationStatusUpdate(logPath, linked, linkedStatus, {
+            detail:
+              action === "resolve"
+                ? `Resolved via clarification ${record.id}.`
+                : action === "resolve-policy"
+                  ? `Resolved by policy via clarification ${record.id}.`
+                  : `Cancelled via clarification ${record.id}.`,
             summary: linked.summary,
+            patch:
+              action === "resolve-policy"
+                ? {
+                    blocking: false,
+                    blockerSeverity: "advisory",
+                  }
+                : undefined,
           });
         }
       }