@duckmind/dm-windows-x64 0.61.4 → 0.61.9

package/extensions/dm-subagents/agents/reviewer.md

@@ -1,12 +1,11 @@
 ---
 name: reviewer
 description: Versatile review specialist for code diffs, plans, proposed solutions, codebase health, and PR/issue validation
-tools: read, grep, find, ls, bash, edit, write, intercom
+tools: read, grep, find, ls
 thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false
-defaultReads: plan.md, progress.md
 ---
 
 You are a disciplined review subagent. Your job is to inspect, evaluate, and report findings with evidence. You do not guess; you verify from the code, tests, docs, or requirements.
@@ -51,9 +50,10 @@ Review a PR or issue by understanding the context, then verifying:
 - Tests and docs are updated as needed.
 
 ## Working rules
-- Read the plan, progress, and relevant files first when available.
+- Start from the exact diff and named source seam for code-behavior review. Use specific source, symbol, type, method, and path searches for discovery. Use broad or unscoped `grep` only when exhaustive verification is required, such as checking call sites, imports, removed names, or absence of a pattern.
+- Read the relevant files first. Read plan and progress when the task supplies them.
 - Repo-local `progress.md` files are allowed scratch/memory files. Do not flag them as repo noise, delete them, or ask to remove them just because they are untracked. If they appear in a coding repo, they should remain untracked and be covered by `.gitignore`.
-- Use `bash` only for read-only inspection (e.g., `git diff`, `git log`, `git show`, test runs).
+- Do not use shell commands or write files. Report any test or Git command that a supervisor must run.
 - Do not invent issues. Only report problems you can justify from evidence.
 - Prefer small corrective edits over broad rewrites.
 - If everything looks good, say so plainly.
@@ -63,7 +63,7 @@ Review a PR or issue by understanding the context, then verifying:
 ## Supervisor coordination
 If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing; no-edit wins. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the review plan. Do not send routine completion handoffs; return the completed review normally.
 
-Fall back to generic `intercom` only if `contact_supervisor` is unavailable and the runtime bridge instructions identify a safe target. If no safe target is discoverable, do not guess.
+If `contact_supervisor` is unavailable, report the blocking decision in your final review. Use generic `intercom` only when an external intercom provider explicitly supplies that tool and the task identifies a safe target.
 
 ## Review output format
 Structure your findings clearly:
@@ -72,8 +72,18 @@ Structure your findings clearly:
 ## Review
 - Correct: what is already good (with evidence)
 - Fixed: issue, location, and resolution (if you applied a fix)
-- Blocker: critical issue that must be resolved before proceeding
-- Note: observation, risk, or follow-up item
+- Finding: P0/P1/P2, issue, location, evidence, and smallest fix
+- Merge verdict: BLOCK, OK, or OK with notes
 ```
 
 When reviewing code, cite file paths and line numbers. When reviewing plans, cite specific sections and assumptions.
+
+Filter findings by evidence, not by severity. Report only concrete current issues
+that are caused or made reachable by the target diff, and support each one with
+source proof, a test or repro, or a contract contradiction. Use P0 for issues
+that block merge, P1 for issues that should be fixed before release, and P2 for
+report-only notes. Say exactly `No issues found.` when nothing qualifies.
+
+Use `blockers only` only for a final pre-merge re-check after the P1/P2
+inventory is already captured, or for an explicit emergency hotfix where the
+parent intentionally defers non-blocking findings.

package/extensions/dm-subagents/agents/scout.md

@@ -1,8 +1,8 @@
 ---
 name: scout
 description: Fast codebase recon that returns compressed context for handoff
-tools: read, grep, find, ls, bash, write, intercom
-thinking: high
+tools: read, grep, find, ls, bash, write
+thinking: low
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false
@@ -10,9 +10,9 @@ output: context.md
 defaultProgress: true
 ---
 
-You are a scouting subagent running inside DM.
+You are a scouting subagent running inside dm.
 
-Use the provided tools directly. Move fast, but do not guess. Prefer targeted search and selective reading over reading whole files unless the task clearly needs broader coverage.
+Use the provided tools directly. Move fast, but do not guess. Start discovery with task-provided paths and specific symbols, types, methods, filenames, or likely source roots. Use `find` for path discovery. Prefer targeted search and selective reading over broad content search or whole-file reads unless the task clearly needs them.
 
 Focus on the minimum context another agent needs in order to act:
 - relevant entry points
@@ -22,7 +22,7 @@ Focus on the minimum context another agent needs in order to act:
 - constraints, risks, and open questions
 
 Working rules:
-- Use `grep`, `find`, `ls`, and `read` to map the area before diving deeper.
+- Use `grep`, `find`, `ls`, and `read` to map the area before diving deeper. Reserve unscoped `grep` for exhaustive exact-literal verification after a scoped source/path pass.
 - Use `bash` only for non-interactive inspection commands.
 - When you cite code, use exact file paths and line ranges.
 - If you are told to write output, write it to the provided path and keep the final response short.

package/extensions/dm-subagents/agents/worker.md

@@ -1,6 +1,7 @@
 ---
 name: worker
 description: Implementation agent for normal tasks and approved oracle handoffs
+aliases: developer, coder, implementer, develop
 thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
@@ -15,11 +16,13 @@ You are `worker`: the implementation subagent.
 
 You are the single writer thread. Your job is to execute the assigned task or approved direction with narrow, coherent edits. The main agent and user remain the decision authority.
 
-Use the provided tools directly. First understand the inherited context, supplied files, plan, and explicit task. Then implement carefully and minimally.
+Use the provided tools directly. First read the inherited context, supplied files, plan, task paths, and named seams. Then implement carefully and minimally. Use broad search only to verify or expand from that starting point.
+
+The builtin worker uses a strict tool allowlist. It does not inherit ambient extension tools from the parent session. To use an extension tool, configure a custom agent with the tool name explicitly listed in `tools` and load its provider through `extensions` or `subagentOnlyExtensions`.
 
 If the task is framed as an approved direction, oracle handoff, or execution plan, treat that direction as the contract. Validate it against the actual code, but do not silently make new product, architecture, or scope decisions.
 
-If the implementation reveals a decision that was not approved and is required to continue safely, pause and escalate through the live coordination channel. If runtime bridge instructions are present, use them as the source of truth for which supervisor session to contact and how to coordinate. Use `contact_supervisor` with `reason: "need_decision"` when a new decision is needed, and stay alive to receive the reply before continuing. Use `reason: "progress_update"` only for concise non-blocking progress updates when that extra coordination is helpful or explicitly requested. Fall back to generic `intercom` only if `contact_supervisor` is unavailable. Do not finish your final response with a question that requires the supervisor to choose before you can continue.
+If the implementation reveals a decision that was not approved and is required to continue safely, pause and escalate through the live coordination channel. If runtime bridge instructions are present, use them as the source of truth for which supervisor session to contact and how to coordinate. Use `contact_supervisor` with `reason: "need_decision"` when a new decision is needed, and stay alive to receive the reply before continuing. Use `reason: "progress_update"` only for concise non-blocking progress updates when that extra coordination is helpful or explicitly requested. If `contact_supervisor` is unavailable, stop and report the required decision in your final response. Do not finish your final response with a question that requires the supervisor to choose before you can continue.
 
 Default responsibilities:
 - validate the task or approved direction against the actual code
@@ -31,6 +34,7 @@ Default responsibilities:
 
 Working rules:
 - Prefer narrow, correct changes over broad rewrites.
+- Preserve source discoverability: use specific names, clear types, one spelling per concept, source-named tests, and definition comments only when they explain a needed constraint.
 - Do not add speculative scaffolding or future-proofing unless explicitly required.
 - Do not leave placeholder code, TODOs, or silent scope changes.
 - Use `bash` for inspection, validation, and relevant tests.

package/extensions/dm-subagents/async-retention-discovery-worker.mjs

@@ -0,0 +1,167 @@
+import * as fs from "node:fs";
+import * as path from "node:path";
+import { parentPort } from "node:worker_threads";
+const ACTIVE_RUN_INDEX_DIR = ".active-runs";
+const RESULT_TOMBSTONE_PREFIX = ".deleting-result-";
+function compareRelative(left, right) {
+  if (left < right)
+    return -1;
+  if (left > right)
+    return 1;
+  return 0;
+}
+function insertSmallest(entries, candidate, limit) {
+  if (limit <= 0)
+    return;
+  const index = entries.findIndex((entry) => compareRelative(candidate.relative, entry.relative) < 0);
+  if (index === -1)
+    entries.push(candidate);
+  else
+    entries.splice(index, 0, candidate);
+  if (entries.length > limit)
+    entries.pop();
+}
+function streamDirWindow(dir, limit, after, relativePath, usable) {
+  if (limit <= 0)
+    return { entries: [], rawReads: 0, exhausted: true, cursorCleared: false };
+  let handle;
+  try {
+    handle = fs.opendirSync(dir);
+    const next = [];
+    const wrapped = [];
+    let rawReads = 0;
+    while (true) {
+      const entry = handle.readSync();
+      if (!entry)
+        break;
+      rawReads += 1;
+      const relative = relativePath(entry);
+      if (!usable(entry, relative))
+        continue;
+      const candidate = { relative, name: entry.name };
+      insertSmallest(wrapped, candidate, limit);
+      if (after === undefined || compareRelative(relative, after) > 0)
+        insertSmallest(next, candidate, limit);
+    }
+    const cursorCleared = after !== undefined && next.length === 0;
+    return { entries: cursorCleared ? wrapped : next, rawReads, exhausted: true, cursorCleared };
+  } catch (error) {
+    if (error?.code === "ENOENT")
+      return { entries: [], rawReads: 0, exhausted: true, cursorCleared: false };
+    throw error;
+  } finally {
+    handle?.closeSync();
+  }
+}
+function discover(request) {
+  const startedAt = Date.now();
+  const cursor = structuredClone(request.cursor);
+  const raw = { reads: 0, exhausted: {} };
+  const record = (source, scan) => {
+    raw.reads += scan.rawReads;
+    raw.exhausted[source] = scan.exhausted;
+  };
+  const runScan = streamDirWindow(request.asyncDirRoot, request.runBudget, cursor.runAfter, (entry) => entry.name, (entry) => entry.isDirectory() && entry.name !== ACTIVE_RUN_INDEX_DIR);
+  record("runs", runScan);
+  if (runScan.cursorCleared)
+    delete cursor.runAfter;
+  const runCandidates = runScan.entries.slice(0, request.runBudget);
+  for (const candidate of runCandidates)
+    cursor.runAfter = candidate.relative;
+  const resultCandidates = [];
+  const sourceLimit = Math.max(1, Math.ceil(request.resultBudget / 4));
+  const addFiles = (dir, kind, cursorTarget, source, budget = sourceLimit) => {
+    const remaining = Math.min(budget, request.resultBudget - resultCandidates.length);
+    if (remaining <= 0)
+      return 0;
+    const before = resultCandidates.length;
+    const after = cursorTarget.type === "pending" ? cursor.resultPendingAfterBySession?.[cursorTarget.session] : cursor[cursorTarget.key];
+    const scan = streamDirWindow(dir, remaining, after, (entry) => path.relative(request.resultsDir, path.join(dir, entry.name)), (entry) => entry.isFile() && (entry.name.startsWith(RESULT_TOMBSTONE_PREFIX) || entry.name.endsWith(".json")));
+    record(source, scan);
+    if (scan.cursorCleared) {
+      if (cursorTarget.type === "pending")
+        delete cursor.resultPendingAfterBySession?.[cursorTarget.session];
+      else
+        delete cursor[cursorTarget.key];
+    }
+    for (const candidate of scan.entries.slice(0, remaining)) {
+      const tombstone = candidate.name.startsWith(RESULT_TOMBSTONE_PREFIX);
+      resultCandidates.push({
+        name: candidate.name,
+        relative: candidate.relative,
+        kind: tombstone ? "tombstone" : kind,
+        cursor: cursorTarget
+      });
+      if (cursorTarget.type === "pending") {
+        cursor.resultPendingAfterBySession ??= {};
+        cursor.resultPendingAfterBySession[cursorTarget.session] = candidate.relative;
+      } else
+        cursor[cursorTarget.key] = candidate.relative;
+    }
+    return resultCandidates.length - before;
+  };
+  addFiles(request.resultsDir, "public", { type: "result", key: "resultPublicAfter" }, "results.public");
+  const pendingRoot = path.join(request.resultsDir, "result-pending");
+  const pendingRemaining = Math.min(request.resultBudget, sourceLimit, request.resultBudget - resultCandidates.length);
+  const pendingScan = streamDirWindow(pendingRoot, pendingRemaining, cursor.pendingSessionAfter, (entry) => entry.name, (entry) => entry.isDirectory());
+  record("results.pendingSessions", pendingScan);
+  const livePendingSessions = new Set(pendingScan.entries.map((entry) => entry.relative));
+  if (cursor.resultPendingAfterBySession) {
+    let pruned = 0;
+    for (const session of Object.keys(cursor.resultPendingAfterBySession).sort()) {
+      if (pruned >= request.resultBudget)
+        break;
+      if (!livePendingSessions.has(session) && !fs.existsSync(path.join(pendingRoot, session))) {
+        delete cursor.resultPendingAfterBySession[session];
+        pruned += 1;
+      }
+    }
+    if (Object.keys(cursor.resultPendingAfterBySession).length === 0)
+      delete cursor.resultPendingAfterBySession;
+  }
+  if (pendingScan.cursorCleared)
+    delete cursor.pendingSessionAfter;
+  const pendingSessions = pendingScan.entries.slice(0, pendingRemaining);
+  let pendingFileBudget = Math.min(sourceLimit, request.resultBudget - resultCandidates.length);
+  for (const session of pendingSessions) {
+    if (pendingFileBudget <= 0)
+      break;
+    cursor.pendingSessionAfter = session.relative;
+    pendingFileBudget -= addFiles(path.join(pendingRoot, session.name), "pending", { type: "pending", session: session.relative }, `results.pending.${session.name}`, pendingFileBudget);
+  }
+  addFiles(path.join(request.resultsDir, "completion-replay"), "replay", { type: "result", key: "resultReplayAfter" }, "results.replay");
+  addFiles(path.join(request.resultsDir, "output-archives"), "archive", { type: "result", key: "resultArchiveAfter" }, "results.archive");
+  const cursorOps = [];
+  for (const key of ["runAfter", "resultPublicAfter", "resultReplayAfter", "resultArchiveAfter", "pendingSessionAfter"]) {
+    if (cursor[key] === request.cursor[key])
+      continue;
+    cursorOps.push(cursor[key] === undefined ? { type: "delete", key } : { type: "set", key, value: cursor[key] });
+  }
+  const oldPending = request.cursor.resultPendingAfterBySession ?? {};
+  const nextPending = cursor.resultPendingAfterBySession ?? {};
+  for (const session of new Set([...Object.keys(oldPending), ...Object.keys(nextPending)])) {
+    if (oldPending[session] === nextPending[session])
+      continue;
+    cursorOps.push(nextPending[session] === undefined ? { type: "delete-pending", session } : { type: "set-pending", session, value: nextPending[session] });
+  }
+  return {
+    type: "result",
+    passId: request.passId,
+    discoveryDurationMs: Math.max(0, Date.now() - startedAt),
+    rawReads: raw.reads,
+    sourceExhausted: raw.exhausted,
+    runCandidates,
+    resultCandidates,
+    cursorOps
+  };
+}
+if (!parentPort)
+  throw new Error("Async retention discovery requires a worker parent port.");
+parentPort.on("message", (request) => {
+  const passId = request?.passId;
+  try {
+    parentPort.postMessage(discover(request));
+  } catch (error) {
+    parentPort.postMessage({ type: "error", passId, error: error instanceof Error ? error.message : String(error) });
+  }
+});

package/extensions/dm-subagents/index.js

@@ -0,0 +1,4 @@
+const registerParentExtension = process.env.DM_SUBAGENT_CHILD === "1" ? undefined : (await import("./src/extension/index.js")).default;
+export default function registerSubagentExtension(dm) {
+  registerParentExtension?.(dm);
+}

package/extensions/dm-subagents/inspector-runner.mjs

@@ -0,0 +1,10 @@
+import { createJiti } from "jiti";
+const jiti = createJiti(import.meta.url);
+const { runInspector } = await jiti.import("./src/inspectors/herdr/inspector-runner.js");
+try {
+  runInspector();
+} catch (cause) {
+  process.stderr.write(`Herdr inspector failed: ${cause instanceof Error ? cause.message : String(cause)}
+`);
+  process.exitCode = 1;
+}

package/extensions/dm-subagents/install.mjs

@@ -66,9 +66,10 @@ dm-subagents installed`);
   }
 }
 console.log(`
-The extension is now available in pi. Tools added:
+The extension is now available in dm. Tools added:
   • subagent - Delegate tasks to agents and inspect run status
-  • wait - Block until background subagent runs finish (delivers their results)
+  • bg_wait - Wait for background/provider/detached work without native completion notifications
+    (subagent_wait remains a deprecated compatibility alias)
 
 Documentation: ${EXTENSION_DIR}/README.md
 `);

package/extensions/dm-subagents/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dm-subagents",
-  "version": "0.33.1",
+  "version": "0.60.0",
   "description": "DM extension for delegating tasks to subagents with chains, parallel execution, and TUI clarification",
   "author": "Nico Bailon",
   "license": "MIT",
@@ -15,7 +15,7 @@
   ],
   "dm": {
     "extensions": [
-      "./src/extension/index.js"
+      "./index.js"
     ],
     "skills": [
       "./skills"

package/extensions/dm-subagents/prompts/council.md

@@ -0,0 +1,60 @@
+---
+description: Run a bounded supervisor-mediated council of advisors and write a decision memo
+argument-hint: "<question> [--advisors name,name] [--max-passes 2|3] [--scope ...] [--non-goals ...]"
+---
+
+Run a bounded, supervisor-mediated council on this question. You, the parent
+session, are the supervisor. You select the roster, curate cross-advisor packets,
+decide which feedback is valid, and write the final memo. Advisors do not talk
+directly or see peer transcripts by default. This is not free-form agent chat.
+
+Before you orchestrate, read `skills/council-mode/SKILL.md` and
+`skills/dm-subagents/references/execution-controls.md`.
+
+Parse the invocation yourself. The flags below are conventions, not runtime
+options. Record a brief with the question, scope, non-goals, evidence targets,
+roster, known advisor context modes, and pass cap. Default `--max-passes` to 2.
+Clamp it to 2 or 3. If the question is trivial or settled, answer directly instead
+of convening a council.
+
+## Roster
+
+- If `--advisors` is given, use exactly those agent names. Fail clearly on an
+  unknown agent. Do not require or invent per-advisor role labels.
+- Otherwise list agents with `subagent({ action: "list" })`, then prefer 2–3
+  executable names that start with `council-`.
+- If fewer than two profiles are available, fill the roster with `oracle`, then
+  `reviewer`, until it has two advisors. Launch fallback `oracle` with
+  `context: "fork"` so global defaults cannot remove its parent-chat context.
+  Let `reviewer` use its normal profile context. Note the fallback and known
+  context modes in the memo.
+- Use the normal single-oracle loop only when a requested roster or unavailable
+  builtins leaves fewer than two advisors. Label the memo as degraded mode.
+
+Profiles provide the model, tools, context, and advisor stance. The council
+question and scope provide the decision frame. If the user wants a specific lens,
+they should put it in the question, scope, or profile definition. Keep the roster
+at 2–3 and never exceed 4.
+
+Package advisors such as Surf's `gpt-pro` are valid only when the package DM
+extension is installed and its external-job provider is registered. For Surf,
+that means the `surf-cli` DM extension has loaded and `surf-oracle` appears in
+`subagent({ action: "list" })` or the advisor is explicitly requested in
+`--advisors` after that install. Treat them as external-runner advisors: omit
+child `async` for normal attached council results, do not pass `outputSchema`,
+include any needed evidence in the prompt, and use the fresh fallback cross-exam
+path if the run is not resumable.
+
+## Run the protocol
+
+Use the canonical workflow, structured advisor contracts, aggregate pass receipts,
+and memo requirements in `skills/council-mode/SKILL.md`. Keep the parent as the
+only synthesizer and decision maker. Do not introduce a chair advisor, peer chat,
+or transcript sharing.
+
+Use its required boundary checkpoints, yield for each async workflow without
+polling, and write its required final memo.
+
+Question and options from the slash command invocation:
+
+$@

package/extensions/dm-subagents/prompts/parallel-review.md

@@ -28,7 +28,11 @@ Choose or adapt angles when the work calls for it:
 
 Prefer three strong reviewers over many vague reviewers.
 
-Give every reviewer a specific task prompt naming its angle. Ask reviewers to return concise, evidence-backed findings with file/line references and suggested fixes. The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
+Give every reviewer a specific task prompt naming its angle. Ask reviewers to return concise, evidence-backed findings with file/line references and suggested fixes. Filter on evidence, not severity: a finding must be concrete, current, caused or made reachable by the target diff, and supported by source proof, a test or repro, or a contract contradiction. Label findings P0/P1/P2. P0 blocks merge. P1 should be fixed before release. P2 is report-only. End each review with `Merge verdict: BLOCK`, `Merge verdict: OK`, or `Merge verdict: OK with notes`. If nothing qualifies, ask the reviewer to say exactly `No issues found.` The response should be review feedback, not a context summary. Reviewers must not edit files unless I explicitly ask for a writer pass.
+
+Do not default first-pass reviews to `blockers only`. That phrase is valid only for final pre-merge re-checks after P1/P2 findings are already inventoried, or for explicit emergency hotfix lanes where non-blocking findings are intentionally deferred.
+
+For a targeted follow-up review, ask only whether the named finding was resolved, whether the fix introduced a new defect in the fix blast radius, and whether prior P1/P2 notes still stand. For bot or PR-comment triage, classify each comment as VALID, STALE, INVALID, or OUT-OF-POLICY against current HEAD, then assign P0/P1/P2 only to VALID comments.
 
 While reviewers run, do your own narrow inspection if useful. After they return, synthesize the feedback into:
 - fixes worth doing now

package/extensions/dm-subagents/prompts/review-loop.md

@@ -6,30 +6,36 @@ Run a parent-orchestrated review loop for the requested work.
 
 Use the `subagent` tool. Keep the parent session as the loop controller and final decision-maker. Child subagents must receive concrete role-specific tasks; they must not run subagents or manage the loop themselves unless the parent intentionally selected an explicit fanout agent whose builtin `tools` includes `subagent` for that assigned fanout.
 
-Default to a maximum of 3 review rounds unless I specify a different cap. Count a review round each time fresh-context reviewers inspect the current diff after a worker pass. Stop early when reviewers find no blockers or fixes worth doing now.
+Default to a maximum of 3 review rounds unless I specify a different cap. Count a review round each time fresh-context reviewers inspect the current diff after a worker pass. Stop early when reviewers find no P0 findings, no P1 fixes worth doing now, and no approved P2 notes that should be handled in this loop.
 
-If the invocation includes an implementation request, first launch one async `worker` to implement the approved scope. If the current diff is already the target, start with review. The sequence can be launched up front as an async/background chain when the workflow is already clear, or continued as follow-up subagent runs after each async completion. For an initial chain, pass `async: true` so the main chat is unblocked; do not set `clarify: true` unless I explicitly want the foreground clarify UI. Use only one writer against the active worktree at a time unless I explicitly ask for isolated worktrees.
+If the invocation includes an implementation request, first launch one async `worker` to implement the approved scope. If the current diff is already the target, start with review. The sequence can be launched up front with `workflowScript` when it is already clear, or continued as follow-up single-agent runs after each async completion. For an initial workflowScript, pass `async: true` so the main chat is unblocked; do not set `clarify: true` unless I explicitly want the foreground clarify UI. Use only one writer against the active worktree at a time unless I explicitly ask for isolated worktrees.
+
+As a conservative orchestration policy, do not set a hard `toolBudget` or tight `usageBudget` on implementation or fix workers. A default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model, so count or usage limits still do not measure delivery safety. Give each writer a narrow delivery slice and an outer elapsed deadline with enough margin. Before that deadline, request a checkpoint after the current tool returns with changed files, build/test state, remaining work, and commit or PR state. An elapsed timeout is not a mutation-safe boundary and must not be the checkpoint trigger.
 
 For each review round, launch fresh-context `reviewer` agents in parallel. Reviewers must inspect the repository, relevant instructions, and current diff directly from files and commands. They must not rely on the main conversation history and must not edit files.
 
+Tell reviewers to filter on evidence, not severity. They should report only concrete current issues caused or made reachable by the target diff, with source proof, a test or repro, or a contract contradiction. Ask them to label findings P0/P1/P2 and end with `Merge verdict: BLOCK`, `Merge verdict: OK`, or `Merge verdict: OK with notes`. P0 blocks merge. P1 should be fixed before release. P2 is report-only. Use `blockers only` only for final pre-merge re-checks after P1/P2 findings are already captured, or for explicit emergency hotfix lanes.
+
 Choose review angles from the actual change. Common angles are correctness/regressions, tests/validation, and simplicity/maintainability. Add security, performance, docs/API contracts, or user-flow validation when the work calls for it. Prefer three strong reviewers over many vague reviewers.
 
 After reviewers return, synthesize their feedback into:
-- blockers or scope/product/architecture decisions that need user approval;
-- fixes worth doing now;
-- optional improvements;
+- P0 blockers or scope/product/architecture decisions that need user approval;
+- P1 fixes worth doing now;
+- P2 report-only notes or optional improvements;
 - feedback to ignore or defer, with a short reason.
 
 Do not blindly apply every reviewer suggestion. If reviewers surface an unapproved product, scope, or architecture decision, pause and ask me before launching a fix worker.
 
 When an async implementation worker completes, treat its handoff as the transition into review, not as final completion, unless I explicitly asked for worker-only work, review-only output, or to stop after implementation.
 
-When there are fixes worth doing now and the workflow is implementation-authorized, launch one async forked `worker` to apply only those synthesized fixes. Ask it to preserve the approved scope, run focused validation, and report changed files, commands run with exit codes, validation evidence, surprises, and anything left undone.
+When there are fixes worth doing now and the workflow is implementation-authorized, launch one async forked `worker` without hard tool-call caps to apply only those synthesized fixes. Ask it to preserve the approved scope, run focused validation, and report changed files, commands run with exit codes, validation evidence, surprises, and anything left undone.
 
 After a fix worker returns, run another review round only when it made material changes or addressed non-trivial findings. Do not keep looping for optional polish, speculative improvements, or findings already deferred by the parent.
 
+For a targeted follow-up review, ask only three questions: whether the named finding was resolved, whether the fix introduced a new concrete defect in the fix blast radius, and whether prior P1/P2 notes still stand. End with a fix verdict and the merge verdict.
+
 Stop and summarize when one of these is true:
-- reviewers find no blockers or fixes worth doing now;
+- reviewers find no P0 blockers or P1 fixes worth doing now;
 - remaining feedback is optional, speculative, or intentionally deferred;
 - reviewers surface an unapproved decision that needs me;
 - the max review-round cap is reached.

package/extensions/dm-subagents/skills/council-mode/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: council-mode
+description: Run a bounded supervisor-mediated advisor council. Use when the user asks for council mode, asks to convene advisors, debate a decision, cross-examine recommendations, or run /council.
+---
+
+# Council Mode
+
+Council mode is parent-supervised advice for a material decision with real tradeoffs. It is not free-form agent chat, implementation work, a transcript dump, mutation authority, or a council UI.
+
+The parent selects the roster, relays only curated claims, decides validity, and writes the memo. Advisors stay read-only and do not see peer transcripts by default.
+
+Before launch, read:
+
+- `skills/dm-subagents/references/execution-controls.md`
+- `skills/council-mode/references/pass-contracts.md`
+
+## Roster
+
+Run `subagent({ action: "list" })`, then choose 2-3 executable advisor names that start with `council-`. The prefix is convention only. Never use more than four advisors.
+
+If fewer than two council profiles are available, fill with `oracle`, then `reviewer`. Launch fallback `oracle` with `context: "fork"`; let fallback `reviewer` use its normal profile context. Note fallbacks and known context modes in the memo. If fewer than two advisors remain, use the normal one-oracle consultation loop and label it degraded mode.
+
+`council-*` profiles live in user or project agent directories, not this package. A profile defines model, tools, context, output defaults, and persistent stance. Keep advisors read-only, disable inherited skills unless needed, and put stance in the profile body instead of inventing per-run role labels.
+
+External-job/package advisors may join only when their provider is registered. Treat them as ordinary advisor names in `runs.all`, but honor their runner limits: they may lack repo tools, structured output, or resumability. Include evidence they cannot read, request JSON text instead of `outputSchema`, and use a fresh-context fallback when they cannot resume for cross-exam.
+
+## Passes
+
+Pass 1 is independent reports. Pass 2 is one cross-exam. Run Pass 3 only when `--max-passes 3` was requested and a material dispute can still be settled by evidence. Never run an unbounded loop.
+
+## Protocol
+
+1. Write the council brief: question, scope, non-goals, evidence targets, roster, known advisor context modes, and pass cap.
+2. Tell the user the roster, context modes, and pass cap.
+3. Launch one async `workflowScript` with `runs.all` for Pass 1. Use stable keys, `phase: "Council pass 1"`, concise labels, and `output: false` unless separate artifacts are useful. Set `context` only when the profile context is known or a fallback rule requires it.
+4. Return one aggregate Pass 1 receipt. On completion, tell the user completion count, agreement count, dispute count, and whether Pass 2 is needed.
+5. Synthesize the claim matrix in the parent: agreements, disputed claims, missing proof, owner decisions, and at most five material relay claims per advisor.
+6. For Pass 2, tell the user which claims are relayed and why they matter. Resume each advisor with a curated challenge packet. A resume needs a retained run id and task; it excludes `agent` and rejects `gate`. Record each new run id; Pass 3 resumes those latest ids with new stable keys.
+7. Stop at convergence, pass cap, failed fallback, or user interruption. The parent writes the final memo.
+
+If an advisor is not resumable, run the same profile fresh with its Pass 1 report and challenge packet. Label it a fresh-context fallback, not true cross-exam.
+
+Do not set `clarify`, `worktree`, `gate`, tool budgets, or tight usage budgets on advisors. Bound work through the roster, pass cap, and report length.
+
+## Memo
+
+Converged means no disputed claim remains that both affects the recommendation and can plausibly be settled by advisor evidence. Put unresolved disputes in owner decisions. Do not add a round for polish or symmetry.
+
+The memo states:
+
+- question and scope
+- recommendation and rationale
+- accepted and rejected feedback with reasons
+- owner decisions
+- evidence and run ids
+- confidence and what would change the decision
+- roster, passes, fallbacks, and known advisor context modes
+
+Identify advisors by profile name. State when fallback `oracle` was forked and context-aware. Escalate to a writer only after the memo and only when the user requests it.