@sjawhar/claude-envoy 1.13.0 → 1.14.1

package/.claude-plugin/plugin.json

@@ -2,5 +2,5 @@
   "name": "claude-envoy",
   "description": "Deliver Envoy events as Claude Code channel notifications and expose Envoy MCP tools.",
   "mcpServers": "./.mcp.json",
-  "version": "1.13.0"
+  "version": "1.14.1"
 }

package/.omp-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-envoy",
-  "version": "1.13.0",
+  "version": "1.14.1",
   "description": "Deliver Envoy events as Claude Code channel notifications and expose Envoy MCP tools.",
   "mcpServers": {}
 }

package/dist/dispatch.js

@@ -14662,7 +14662,8 @@ var IssueEventPayloadSchema = object({
   route: string2().nullish(),
   changed: array(string2()).optional(),
   ancestors: array(string2()).optional(),
-  thread_logins: array(string2()).optional()
+  thread_logins: array(string2()).optional(),
+  forced: object({ past: array(string2()) }).optional()
 });
 var ArtifactCreatedEventPayloadSchema = object({
   artifact: object({ id: string2().optional(), slug: string2().optional(), name: string2().optional() }).optional()
@@ -15615,12 +15616,12 @@ var dispatchToolSpecs = [
   {
     name: "dispatch_related",
     example: { project: "CORE", title: "Retry failed webhook deliveries" },
-    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issue leaves that issue's own items out, " + "as a check on that issue's own write does; keywords_only skips meaning search.",
+    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issues leaves each named issue's own " + "items out of the results, at most 50 of them, so a draft under a parent can leave out " + "that parent and its children without changing how rare the text's words are; " + "keywords_only skips meaning search.",
     arguments: (z) => ({
       project: z.string().describe("Project key to search within, such as CORE."),
       title: z.string({ max: ISSUE_TITLE_MAX }).describe("Optional title to check, as an issue title; at most 1,000 characters.").optional(),
       text: z.string().describe("Optional text to check, such as a draft spec or a question.").optional(),
-      exclude_issue: z.string().describe("Optional issue key in the project whose own items are left out.").optional(),
+      exclude_issues: z.array(z.string()).describe("Optional issue keys in the project whose own items are left out of the results; at most 50.").optional(),
       keywords_only: z.boolean().describe("Search by keywords only, skipping meaning search.").optional()
     }),
     validation: {
@@ -20543,11 +20544,19 @@ function relatedCheckLines(suggestions, context) {
       lines.push(`A past decision may already answer this: ${suggestionLabel(decision)}, answered by ${decision.answered_by}${when} \u2192 ${absoluteHref(decision.href, context.configUrl)}`);
       lines.push(...askLines(decision.ask));
     }
+    const likely = suggestions.likely_duplicate;
+    if (likely !== undefined && likely !== null) {
+      lines.push(`Likely duplicate: ${likely.key} [${likely.status}] ${likely.title} \u2192 ${absoluteHref(likely.href, context.configUrl)}`);
+      lines.push("Read it. If it is the same work, fold this issue into it by the duplicate rule of skill://dispatch-first.");
+    }
+    if (suggestions.near_copy_check !== undefined && suggestions.near_copy_check !== "") {
+      lines.push(`No near-copy check was made: ${suggestions.near_copy_check}.`);
+    }
     for (const match of suggestions.title_matches ?? []) {
-      lines.push(`Title overlaps you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
+      lines.push(`Near copy you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
     }
   } catch (error) {
-    lines.push(`The check's past decision or title overlaps could not be shown: ${messageFor(error)}`);
+    lines.push(`The check's past decision or near copies could not be shown: ${messageFor(error)}`);
   }
   return lines;
 }
@@ -22430,7 +22439,13 @@ function eventHead(event) {
       return textHead(`${event.payload.name} v${event.payload.version.number}${event.payload.version.summary ? `: ${event.payload.version.summary}` : ""}`);
     case "artifact.human_edited":
       return textHead(humanEditHead(event.payload));
-    case "issue.created":
+    case "issue.created": {
+      const forced = event.payload.forced;
+      const head = `status ${event.payload.status}`;
+      if (forced === undefined)
+        return head;
+      return forced.past.length === 0 ? `${head} \xB7 forced, the near-copy check did not answer` : `${head} \xB7 forced past ${forced.past.join(", ")}`;
+    }
     case "issue.updated":
     case "issue.closed":
       return `status ${event.payload.status}`;
@@ -22446,10 +22461,14 @@ function eventRef(event) {
   const kind = event.type.startsWith("message.") ? "message" : event.type.startsWith("comment.") || event.type.startsWith("suggestion.") ? "comment" : event.type.startsWith("ask.") ? "ask" : undefined;
   return kind === undefined ? undefined : `dispatch://${event.issue_key}/${kind}/${id}`;
 }
+function eventActorText(actor) {
+  const title = actor.kind === "session" ? actor.origin?.session_title : undefined;
+  return title === undefined || title === "" ? actorText(actor) : `${actorText(actor)} (${title})`;
+}
 function eventLine(event) {
   const head = eventHead(event);
   const ref = eventRef(event);
-  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${actorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
+  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${eventActorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
 }
 function childrenSummary(issue) {
   return [
@@ -23266,15 +23285,17 @@ async function executeDispatchTool(input) {
         const candidates = duplicateCandidates(error);
         return {
           text: [
-            `Not created: "${title}" looks like a duplicate.`,
+            `Not created: "${title}" is a near copy of an open issue.`,
             ...candidates.map((candidate) => {
               const href = new URL(candidate.href, linkBase).toString();
               return `${candidate.key} [${candidate.status}] ${candidate.title} \u2192 ${href}`;
             }),
-            "Reference the existing issue, or run dispatch issue again with --force after reading it."
+            "Read each issue above. If one is the same work, fold this into it by the duplicate rule of skill://dispatch-first.",
+            "If none is, run dispatch issue again with --force, and write in the new issue's spec why it is not each issue named here."
           ].join(`
 `),
-          details: { duplicates: candidates }
+          details: { duplicates: candidates },
+          refused: true
         };
       }
     }
@@ -23442,12 +23463,12 @@ async function executeDispatchTool(input) {
       const project = stringArg(args, "project");
       const title = optionalString(args, "title");
       const text = optionalString(args, "text");
-      const excludeIssue = optionalString(args, "exclude_issue");
+      const excludeIssues = optionalStringArray(args, "exclude_issues");
       const keywordsOnly = optionalBoolean(args, "keywords_only");
       const suggestions = await client.related(project, {
         ...title === undefined ? {} : { title },
         ...text === undefined ? {} : { text },
-        ...excludeIssue === undefined ? {} : { exclude_issue: excludeIssue },
+        ...excludeIssues === undefined ? {} : { exclude_issues: excludeIssues },
         ...keywordsOnly === undefined ? {} : { keywords_only: keywordsOnly }
       });
       return {
@@ -28293,7 +28314,7 @@ async function runDispatchCli(argv, rawEnv, io) {
   if (parsed.kind === "refused") {
     return parsed.tool === undefined ? refuse([`dispatch: ${parsed.problems.join(`
 `)}`, "Run dispatch --help."].join(`
-`), USAGE) : refuse(new ToolInputError(parsed.tool, parsed.problems).message, REFUSED, parsed.tool);
+`), USAGE) : refuse(new ToolInputError(parsed.tool, parsed.problems).message, USAGE, parsed.tool);
   }
   const hostName = env.DISPATCH_HOST ?? (env.CLAUDE_CODE_CHILD_SESSION === "1" ? "claude" : undefined);
   const host = HOSTS.find((name) => name === hostName);
@@ -28321,7 +28342,7 @@ async function runDispatchCli(argv, rawEnv, io) {
       serverUrls: settings?.enabled === true ? dispatchServerUrls(settings) : []
     });
     if (problems.length > 0) {
-      return refuse(new ToolInputError(parsed.tool, problems).message, REFUSED, parsed.tool);
+      return refuse(new ToolInputError(parsed.tool, problems).message, USAGE, parsed.tool);
     }
     print(JSON.stringify(parsed.args, null, 2));
     return OK;
@@ -28458,7 +28479,7 @@ async function runDispatchCli(argv, rawEnv, io) {
       notes.push(followNoticeText(followed, await subscriptions()));
     }
     entry = { tool, details: result.details };
-    code = OK;
+    code = result.refused === true ? REFUSED : OK;
   } catch (error) {
     text = messageFor(error);
     if (error instanceof DispatchWriteLandedError) {
@@ -28466,7 +28487,7 @@ async function runDispatchCli(argv, rawEnv, io) {
       code = OK;
     } else {
       entry = { tool, error: text };
-      code = REFUSED;
+      code = error instanceof ToolInputError ? USAGE : REFUSED;
     }
   }
   try {

package/dist/envoy-channel.js

@@ -36311,7 +36311,8 @@ var IssueEventPayloadSchema = object({
   route: string2().nullish(),
   changed: array(string2()).optional(),
   ancestors: array(string2()).optional(),
-  thread_logins: array(string2()).optional()
+  thread_logins: array(string2()).optional(),
+  forced: object({ past: array(string2()) }).optional()
 });
 var ArtifactCreatedEventPayloadSchema = object({
   artifact: object({ id: string2().optional(), slug: string2().optional(), name: string2().optional() }).optional()
@@ -37264,12 +37265,12 @@ var dispatchToolSpecs = [
   {
     name: "dispatch_related",
     example: { project: "CORE", title: "Retry failed webhook deliveries" },
-    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issue leaves that issue's own items out, " + "as a check on that issue's own write does; keywords_only skips meaning search.",
+    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issues leaves each named issue's own " + "items out of the results, at most 50 of them, so a draft under a parent can leave out " + "that parent and its children without changing how rare the text's words are; " + "keywords_only skips meaning search.",
     arguments: (z) => ({
       project: z.string().describe("Project key to search within, such as CORE."),
       title: z.string({ max: ISSUE_TITLE_MAX }).describe("Optional title to check, as an issue title; at most 1,000 characters.").optional(),
       text: z.string().describe("Optional text to check, such as a draft spec or a question.").optional(),
-      exclude_issue: z.string().describe("Optional issue key in the project whose own items are left out.").optional(),
+      exclude_issues: z.array(z.string()).describe("Optional issue keys in the project whose own items are left out of the results; at most 50.").optional(),
       keywords_only: z.boolean().describe("Search by keywords only, skipping meaning search.").optional()
     }),
     validation: {
@@ -47325,11 +47326,19 @@ function relatedCheckLines(suggestions, context) {
       lines.push(`A past decision may already answer this: ${suggestionLabel(decision)}, answered by ${decision.answered_by}${when} \u2192 ${absoluteHref(decision.href, context.configUrl)}`);
       lines.push(...askLines(decision.ask));
     }
+    const likely = suggestions.likely_duplicate;
+    if (likely !== undefined && likely !== null) {
+      lines.push(`Likely duplicate: ${likely.key} [${likely.status}] ${likely.title} \u2192 ${absoluteHref(likely.href, context.configUrl)}`);
+      lines.push("Read it. If it is the same work, fold this issue into it by the duplicate rule of skill://dispatch-first.");
+    }
+    if (suggestions.near_copy_check !== undefined && suggestions.near_copy_check !== "") {
+      lines.push(`No near-copy check was made: ${suggestions.near_copy_check}.`);
+    }
     for (const match of suggestions.title_matches ?? []) {
-      lines.push(`Title overlaps you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
+      lines.push(`Near copy you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
     }
   } catch (error) {
-    lines.push(`The check's past decision or title overlaps could not be shown: ${messageFor(error)}`);
+    lines.push(`The check's past decision or near copies could not be shown: ${messageFor(error)}`);
   }
   return lines;
 }
@@ -49180,7 +49189,13 @@ function eventHead(event) {
       return textHead(`${event.payload.name} v${event.payload.version.number}${event.payload.version.summary ? `: ${event.payload.version.summary}` : ""}`);
     case "artifact.human_edited":
       return textHead(humanEditHead(event.payload));
-    case "issue.created":
+    case "issue.created": {
+      const forced = event.payload.forced;
+      const head = `status ${event.payload.status}`;
+      if (forced === undefined)
+        return head;
+      return forced.past.length === 0 ? `${head} \xB7 forced, the near-copy check did not answer` : `${head} \xB7 forced past ${forced.past.join(", ")}`;
+    }
     case "issue.updated":
     case "issue.closed":
       return `status ${event.payload.status}`;
@@ -49196,10 +49211,14 @@ function eventRef(event) {
   const kind = event.type.startsWith("message.") ? "message" : event.type.startsWith("comment.") || event.type.startsWith("suggestion.") ? "comment" : event.type.startsWith("ask.") ? "ask" : undefined;
   return kind === undefined ? undefined : `dispatch://${event.issue_key}/${kind}/${id}`;
 }
+function eventActorText(actor) {
+  const title = actor.kind === "session" ? actor.origin?.session_title : undefined;
+  return title === undefined || title === "" ? actorText(actor) : `${actorText(actor)} (${title})`;
+}
 function eventLine(event) {
   const head = eventHead(event);
   const ref = eventRef(event);
-  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${actorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
+  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${eventActorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
 }
 function childrenSummary(issue) {
   return [
@@ -50016,15 +50035,17 @@ async function executeDispatchTool(input) {
         const candidates = duplicateCandidates(error);
         return {
           text: [
-            `Not created: "${title}" looks like a duplicate.`,
+            `Not created: "${title}" is a near copy of an open issue.`,
             ...candidates.map((candidate) => {
               const href = new URL(candidate.href, linkBase).toString();
               return `${candidate.key} [${candidate.status}] ${candidate.title} \u2192 ${href}`;
             }),
-            "Reference the existing issue, or run dispatch issue again with --force after reading it."
+            "Read each issue above. If one is the same work, fold this into it by the duplicate rule of skill://dispatch-first.",
+            "If none is, run dispatch issue again with --force, and write in the new issue's spec why it is not each issue named here."
           ].join(`
 `),
-          details: { duplicates: candidates }
+          details: { duplicates: candidates },
+          refused: true
         };
       }
     }
@@ -50192,12 +50213,12 @@ async function executeDispatchTool(input) {
       const project = stringArg(args, "project");
       const title = optionalString(args, "title");
       const text = optionalString(args, "text");
-      const excludeIssue = optionalString(args, "exclude_issue");
+      const excludeIssues = optionalStringArray(args, "exclude_issues");
       const keywordsOnly = optionalBoolean(args, "keywords_only");
       const suggestions = await client.related(project, {
         ...title === undefined ? {} : { title },
         ...text === undefined ? {} : { text },
-        ...excludeIssue === undefined ? {} : { exclude_issue: excludeIssue },
+        ...excludeIssues === undefined ? {} : { exclude_issues: excludeIssues },
         ...keywordsOnly === undefined ? {} : { keywords_only: keywordsOnly }
       });
       return {
@@ -52110,7 +52131,7 @@ var legionPendingStatusWrite = object({
 var legionStrandedClaim = object({
   issue: issueKey,
   role: _enum2(LEGION_ROLES),
-  state: _enum2(["suspended", "failed"])
+  state: _enum2(["suspended", "failed", "retired"])
 });
 var legionHeldOutboxRow = object({
   id: number2().int().positive(),
@@ -52344,7 +52365,10 @@ var legionDeliveryView = object({
   queuedAt: timestamp,
   deliveredAt: timestamp.optional(),
   confirmedAt: timestamp.optional(),
-  interrupted: literal(true).optional()
+  interrupted: literal(true).optional(),
+  sendFailures: number2().int().nonnegative().optional(),
+  lastSendFailureAt: timestamp.optional(),
+  lastSendError: nonEmptyString.optional()
 });
 var LegionOperatorClaimResponse = object({
   token: nonEmptyString,
@@ -55155,9 +55179,9 @@ var import_nats2 = __toESM(require_mod4(), 1);
 
 // package.json
 var name = "@sjawhar/claude-envoy";
-var version2 = "1.13.0";
+var version2 = "1.14.1";
 var legion = {
-  daemonApiVersion: 55
+  daemonApiVersion: 56
 };
 
 // src/channel-forwarder.ts

package/dist/session-hook.js

@@ -13661,7 +13661,8 @@ var IssueEventPayloadSchema = object({
   route: string2().nullish(),
   changed: array(string2()).optional(),
   ancestors: array(string2()).optional(),
-  thread_logins: array(string2()).optional()
+  thread_logins: array(string2()).optional(),
+  forced: object({ past: array(string2()) }).optional()
 });
 var ArtifactCreatedEventPayloadSchema = object({
   artifact: object({ id: string2().optional(), slug: string2().optional(), name: string2().optional() }).optional()
@@ -14614,12 +14615,12 @@ var dispatchToolSpecs = [
   {
     name: "dispatch_related",
     example: { project: "CORE", title: "Retry failed webhook deliveries" },
-    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issue leaves that issue's own items out, " + "as a check on that issue's own write does; keywords_only skips meaning search.",
+    description: "Run the related-item check that dispatch issue, dispatch ask and a new decision block in " + "dispatch doc-edit run on their own write, and write nothing: it lists the three items of " + "one project most like a title and a text (at most one per issue or document, open ones " + "first), each ask with whether it is answered, and a past decision that already answers " + "the same question. Use it to check a draft before filing it. It searches by meaning and by " + "the text's rarest words, and says how it searched; when meaning search cannot run it " + "searches by keywords only and says why. When it could not search at all it says why and " + "names the dispatch search to run instead. exclude_issues leaves each named issue's own " + "items out of the results, at most 50 of them, so a draft under a parent can leave out " + "that parent and its children without changing how rare the text's words are; " + "keywords_only skips meaning search.",
     arguments: (z) => ({
       project: z.string().describe("Project key to search within, such as CORE."),
       title: z.string({ max: ISSUE_TITLE_MAX }).describe("Optional title to check, as an issue title; at most 1,000 characters.").optional(),
       text: z.string().describe("Optional text to check, such as a draft spec or a question.").optional(),
-      exclude_issue: z.string().describe("Optional issue key in the project whose own items are left out.").optional(),
+      exclude_issues: z.array(z.string()).describe("Optional issue keys in the project whose own items are left out of the results; at most 50.").optional(),
       keywords_only: z.boolean().describe("Search by keywords only, skipping meaning search.").optional()
     }),
     validation: {
@@ -19547,11 +19548,19 @@ function relatedCheckLines(suggestions, context) {
       lines.push(`A past decision may already answer this: ${suggestionLabel(decision)}, answered by ${decision.answered_by}${when} \u2192 ${absoluteHref(decision.href, context.configUrl)}`);
       lines.push(...askLines(decision.ask));
     }
+    const likely = suggestions.likely_duplicate;
+    if (likely !== undefined && likely !== null) {
+      lines.push(`Likely duplicate: ${likely.key} [${likely.status}] ${likely.title} \u2192 ${absoluteHref(likely.href, context.configUrl)}`);
+      lines.push("Read it. If it is the same work, fold this issue into it by the duplicate rule of skill://dispatch-first.");
+    }
+    if (suggestions.near_copy_check !== undefined && suggestions.near_copy_check !== "") {
+      lines.push(`No near-copy check was made: ${suggestions.near_copy_check}.`);
+    }
     for (const match of suggestions.title_matches ?? []) {
-      lines.push(`Title overlaps you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
+      lines.push(`Near copy you forced past: ${match.key} [${match.status}] ${match.title} \u2192 ${absoluteHref(match.href, context.configUrl)}`);
     }
   } catch (error) {
-    lines.push(`The check's past decision or title overlaps could not be shown: ${messageFor(error)}`);
+    lines.push(`The check's past decision or near copies could not be shown: ${messageFor(error)}`);
   }
   return lines;
 }
@@ -21434,7 +21443,13 @@ function eventHead(event) {
       return textHead(`${event.payload.name} v${event.payload.version.number}${event.payload.version.summary ? `: ${event.payload.version.summary}` : ""}`);
     case "artifact.human_edited":
       return textHead(humanEditHead(event.payload));
-    case "issue.created":
+    case "issue.created": {
+      const forced = event.payload.forced;
+      const head = `status ${event.payload.status}`;
+      if (forced === undefined)
+        return head;
+      return forced.past.length === 0 ? `${head} \xB7 forced, the near-copy check did not answer` : `${head} \xB7 forced past ${forced.past.join(", ")}`;
+    }
     case "issue.updated":
     case "issue.closed":
       return `status ${event.payload.status}`;
@@ -21450,10 +21465,14 @@ function eventRef(event) {
   const kind = event.type.startsWith("message.") ? "message" : event.type.startsWith("comment.") || event.type.startsWith("suggestion.") ? "comment" : event.type.startsWith("ask.") ? "ask" : undefined;
   return kind === undefined ? undefined : `dispatch://${event.issue_key}/${kind}/${id}`;
 }
+function eventActorText(actor) {
+  const title = actor.kind === "session" ? actor.origin?.session_title : undefined;
+  return title === undefined || title === "" ? actorText(actor) : `${actorText(actor)} (${title})`;
+}
 function eventLine(event) {
   const head = eventHead(event);
   const ref = eventRef(event);
-  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${actorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
+  return `- #${event.seq} ${event.type}${ref === undefined ? "" : ` ${ref}`} \xB7 ${eventActorText(event.actor)} \xB7 ${event.created_at}${head === undefined || head === "" ? "" : ` \xB7 ${head}`}`;
 }
 function childrenSummary(issue) {
   return [
@@ -22270,15 +22289,17 @@ async function executeDispatchTool(input) {
         const candidates = duplicateCandidates(error);
         return {
           text: [
-            `Not created: "${title}" looks like a duplicate.`,
+            `Not created: "${title}" is a near copy of an open issue.`,
             ...candidates.map((candidate) => {
               const href = new URL(candidate.href, linkBase).toString();
               return `${candidate.key} [${candidate.status}] ${candidate.title} \u2192 ${href}`;
             }),
-            "Reference the existing issue, or run dispatch issue again with --force after reading it."
+            "Read each issue above. If one is the same work, fold this into it by the duplicate rule of skill://dispatch-first.",
+            "If none is, run dispatch issue again with --force, and write in the new issue's spec why it is not each issue named here."
           ].join(`
 `),
-          details: { duplicates: candidates }
+          details: { duplicates: candidates },
+          refused: true
         };
       }
     }
@@ -22446,12 +22467,12 @@ async function executeDispatchTool(input) {
       const project = stringArg(args, "project");
       const title = optionalString(args, "title");
       const text = optionalString(args, "text");
-      const excludeIssue = optionalString(args, "exclude_issue");
+      const excludeIssues = optionalStringArray(args, "exclude_issues");
       const keywordsOnly = optionalBoolean(args, "keywords_only");
       const suggestions = await client.related(project, {
         ...title === undefined ? {} : { title },
         ...text === undefined ? {} : { text },
-        ...excludeIssue === undefined ? {} : { exclude_issue: excludeIssue },
+        ...excludeIssues === undefined ? {} : { exclude_issues: excludeIssues },
         ...keywordsOnly === undefined ? {} : { keywords_only: keywordsOnly }
       });
       return {

package/legion/skills/legion-architect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: legion-architect
-description: "Use when you are a Legion root or sub-architect: decomposing children, gating the root spec, releasing waves, accepting a reviewed head, or handling a delivered wake or a worker's escalation. Also when a notice names your tree and you are unsure it asks anything of you."
+description: "Use when you are a Legion root or sub-architect: decomposing children, gating the root spec, releasing children, accepting a reviewed head, or handling a delivered wake or a worker's escalation. Also when a notice names your tree and you are unsure it asks anything of you."
 ---
 
 # Legion architect
@@ -24,26 +24,28 @@ You own one issue tree from its first decision to the merge that closes it. The
 ## 1. Decompose or adopt
 
 - Read a child's handoff, create children, split across repositories or attach architecture components as `skill://legion-architect/references/decomposition.md` says.
-- Adopt children a human created and release them in the first wave. Never replace or re-decompose them.
+- Adopt children a human created and release them at once. Never replace or re-decompose them.
 - Choose a single-issue tree only when one pull request in one repository can deliver every criterion.
-- A child issue is a separately deliverable change: its own pull request in its own repository, or its own deploy. Never use a child to track a to-do, a fix found in review, a proof of the root's acceptance, or a part of your own work: do it in this tree. Each child costs a workspace, an admission wait and a review loop. Before any `dispatch issue` that creates a child, and before `release_children`, run the red-team check in `skill://legion-architect/references/decomposition.md`.
+- A child issue needs a repository or a deploy order of its own: its code is in a repository no open pull request of this tree is in, or it must be applied on its own before other work of the tree can build on it. A repeated change — the same edit per program, directory or instance — is one child, never one per instance. Never use a child to track a to-do, a fix found in review, a proof of the root's acceptance, or a part of your own work: do it in this tree. Each child costs a workspace, an admission wait and a review loop. Before any `dispatch issue` that creates a child, and before `release_children`, run the red-team check in `skill://legion-architect/references/decomposition.md`.
+- Work in a repository this tree already has a pull request in, which waits on a sibling's merge, is no child and is not parked in `backlog`: write it into the spec of the issue whose pull request carries it — the parent's, or the sibling's when the parent's pull request is in another repository — so one pull request lands it in order.
+- A child that duplicates another issue and is not yet released is never released: fold it by the duplicate rule of `skill://dispatch-first`. The daemon records a child at its release and re-asserts a status only on an issue it has recorded, so that close stands. A released duplicate goes out with `park_child` instead.
 - Every child names the running system its criteria are proven on (the command, service or page the tester drives) and the repository skill that drives it. If the repository cannot exercise a criterion end to end, building that path is work of this tree.
-- The issue's primary document is the root spec: extend it in place, because a second "spec" artifact replaces the human's document. Mark each requirement of it as a `requirement` block, and write the issue's Verification document (`verification.md`) beside it: one `check` block per thing that must be proved, each with `serves` naming the requirements it serves, its `surface` (`browser`, `cli` or `api`), its `run`, its `when` (`before_merge`, `after_merge` or `default_branch`) and its `negative_control`. The checks are the gate every later role reads: the implementer and the tester record a result against each, and the reviewer approves only once every `before_merge` check of the issue has a passing result current at the head. The waves and the plan's tasks go in the children and the planner's `plan` handoff, not the root spec.
+- The issue's primary document is the root spec: extend it in place, because a second "spec" artifact replaces the human's document. Mark each requirement of it as a `requirement` block, and write the issue's Verification document (`verification.md`) beside it: one `check` block per thing that must be proved, each with `serves` naming the requirements it serves, its `surface` (`browser`, `cli` or `api`), its `run`, its `when` (`before_merge`, `after_merge` or `default_branch`) and its `negative_control`. The checks are the gate every later role reads: the implementer and the tester record a result against each, and the reviewer approves only once every `before_merge` check of the issue has a passing result current at the head. The decomposition's order and the plan's tasks go in the children and the planner's `plan` handoff, not the root spec.
 - Read `skill://legion-architect/references/design-gate.md` before you write the root spec and before any edit to it after approval, because any new version closes the gate. It also names the design gate steps your `Legion addressing` line declares, the document each step records, and says that a sub-architect runs none.
 - File every child of your decomposition before `dispatch request-approval`, and before `register_gate` where your line gates no step: the gate's opening starts your root's own first phase unless Dispatch shows an open child under it, so a child filed after it opens leaves the root working beside its children.
-- A root architect then ends its turn and releases no wave until every gated step is open: a delivered wake shows `design-approved` on the root, and under more than one step `gatedSteps` in your record (the `legion` tool's `read_record`) shows each step `approved`. The daemon starts no phase in the tree before that. A root that waited on a person's answer gets no `design-approved` notice: a resume task saying "this resume is your design-approved wake" is that wake. A sub-architect waits for none and releases its children with `release_children`.
+- A root architect then ends its turn and releases no child until every gated step is open: a delivered wake shows `design-approved` on the root, and under more than one step `gatedSteps` in your record (the `legion` tool's `read_record`) shows each step `approved`. The daemon starts no phase in the tree before that. A root that waited on a person's answer gets no `design-approved` notice: a resume task saying "this resume is your design-approved wake" is that wake. A sub-architect waits for none and releases its children with `release_children`.
 
 ## 2. Children in flight
 
-- Set a child's dependencies in one call naming every issue it waits on: `dispatch issue-update --issue <child> --blocked-by <a> --blocked-by <b>`, or `--blocked-by` on `dispatch issue` at creation. The call replaces the child's whole list, so read its existing links first (`dispatch read`). Release it with the rest: `legion({ op: "release_children", issues: ["LEGION-41", "LEGION-42"] })`. Legion holds a released child that waits on an issue not `done` and starts it itself at its last blocker's close. A child that builds on another repository's merged change is not held this way: release it as `skill://legion-architect/references/decomposition.md` "Across repositories" says.
-- Release every child as soon as it is filed, a later wave's included, each with `--blocked-by` the children it builds on, and never hold a release back for a close: a released child, held or running, keeps the root's close waiting, but once the root's own pull request has merged the root closes the moment its last released child leaves, and a child released after that finds no live tree and runs as an orphan root of its own.
+- Set a child's dependencies in one call naming every issue it waits on: `dispatch issue-update --issue <child> --blocked-by <a> --blocked-by <b>`, or `--blocked-by` on `dispatch issue` at creation. The call replaces the child's whole list, so read its existing links first (`dispatch read`). Release it with the rest: `legion({ op: "release_children", issues: ["LEGION-41", "LEGION-42"] })`. Legion holds a released child that waits on an issue not `done` and starts it itself at its last blocker's close. A child that builds on another repository's merged change is not held this way: release it as `skill://legion-architect/references/decomposition.md` "Across repositories" says. No child of this tree waits on a sibling's merge in a repository this tree already has a pull request in: that work rides in the pull request that carries it (section 1).
+- Release every child as soon as it is filed, each with `--blocked-by` the issues it waits on, and never hold a release back for a close: a released child, held or running, keeps the root's close waiting, but once the root's own pull request has merged the root closes the moment its last released child leaves, and a child released after that finds no live tree and runs as an orphan root of its own.
 - On each `child-closed`, read the child's handoff. Edit the spec of each open child the result changes, and take out each child it makes unneeded with `park_child` and say why with `dispatch comment`.
 - Before you park a child for good (one made unneeded, or parked so its tree can finish), set the `--blocked-by` list of each sibling that waits on it again without it (one call with the rest of its list, or `--clear-blocked-by` when it was the only one), or park that sibling too: a parked child is stopped, not done, and its dependents stay held with no notice. A park followed by `rerun_child` keeps its dependents' links: they wait through the rerun and start when the rerun's merge closes the child.
 - A released child holds an admission slot of its own while a worker of it has work, and waits in the admission line for one, so a tree of four working issues holds four of the cap's issues. It never becomes a root while your tree is live.
 
 ## 3. Children complete
 
-Your issue's own first phase does not start while Dispatch shows an open child under it, one you filed and have not released included: the daemon tells you once per issue and run of its tree with a `children-first` notice naming each open child and the Dispatch status that holds it, and starts the parent at its next admission slot once the last of them has left the workflow, closed, gone to `icebox`, or been moved out from under it, to another parent or to none. So file and release the whole wave at once, and park what should not run. No notice marks the last child's close. A child filed after your issue started runs beside it, and the daemon refuses the parent's `sign_off` while that child is in the workflow: run the parent's last round (section 4) so its head carries the child's merge.
+Your issue's own first phase does not start while Dispatch shows an open child under it, one you filed and have not released included: the daemon tells you once per issue and run of its tree with a `children-first` notice naming each open child and the Dispatch status that holds it, and starts the parent at its next admission slot once the last of them has left the workflow, closed, gone to `icebox`, or been moved out from under it, to another parent or to none. So file and release every child at once, and park what should not run. No notice marks the last child's close. A child filed after your issue started runs beside it, and the daemon refuses the parent's `sign_off` while that child is in the workflow: run the parent's last round (section 4) so its head carries the child's merge.
 
 ## 4. Integration verification
 

package/legion/skills/legion-architect/references/acceptance.md

@@ -64,7 +64,7 @@ parent's check: a child's pull request never makes a parent check's result curre
 that carries part of a parent's requirement proves it with a check on the child's own
 Verification document whose `serves` names that requirement. Nothing in the tree builds on the parent's own merge, because that
 merge comes last: a child that waits for it waits forever, so work another child builds on is a
-first-wave child of its own. While the approved head does not carry those merges, or the result of
+child of its own, in a repository of its own or with a deploy of its own. While the approved head does not carry those merges, or the result of
 a check in another repository is older than the close of a child it needs, leave
 the issue in `accepting` until each of those children has closed (`child-closed`) or been parked
 for good (`child-status`). Move a parked child's criterion to other work first; never downgrade
@@ -204,7 +204,10 @@ child that never started is handed over too, carrying no run, whatever held it a
 waits in the line for a slot and for any unfinished blocker, and its architect starts as a fresh
 root and registers its own spec. Only a child that finished, was parked or was never released
 stays. The child stays its own tree; reopening the old root does not take it back. Park a child
-with `park_child` before then when its work should stop with the root.
+with `park_child` before then when its work should stop with the root. A root that is parked
+rather than closed hands over only a child at `awaiting_merge` whose pull request is still open,
+since the daemon re-admits no parked root and only that child's own new READY arms the merge the
+park disarmed; park that child too when its merge should wait with the root.
 
 If you are that child's architect:
 

package/legion/skills/legion-architect/references/decomposition.md

@@ -13,7 +13,7 @@ and an earlier one with `--version <n>`. The child's Conversation lists every ve
 
 ## Adopting children
 
-Put every adopted child into the first wave and release it with
+Release every adopted child at once with
 `legion({ op: "release_children", issues: ["LEGION-41", "LEGION-42"] })`. The daemon runs nothing on
 a child until it is released. Once it is released, the daemon moves it to `todo` and, while the
 root's design gate is open, starts its first phase itself at the child's own admission slot, and
@@ -44,18 +44,25 @@ EOF
   that each child should not exist. Name every child that is a to-do, a fix found in review, a
   proof of the root's acceptance, or a part of the architect's own work, and say where it folds:
   the root's pull request or an open child's."* `wait` for its verdict, since it runs as a job of
-  its own. A child survives only when it cannot ride in the
-  root's pull request or an open child's: its code is in a repository no open pull request of this
-  tree is in, or it is its own deploy: it must be applied on its own before other work of the tree
-  can build on it.
-  A repeated change — the same edit per program, directory or wave of this tree's own work —
-  survives as one child, never one per instance, and a deletion of what this tree replaced rides
-  in the pull request of the last change it waits on, never a child of its own: a wave is an order
-  of merges, not a deliverable.
-  Post the verdict, with the folds you made, as one `dispatch comment` on your own issue (the root,
-  in a root session): the architect
-  who wrote the list reads every child on it as needed, and the comment stops a later session
-  filing the same children again.
+  its own. A child survives it only when it needs a repository or a deploy order of its own: its
+  code is in a repository no open pull request of this tree is in, or it must be applied on its
+  own before other work of the tree can build on it. A repeated change — the same edit per
+  program, directory or instance of this tree's own work — is one child, never one per instance.
+  Work in a repository this tree already has a pull request in, which waits on a sibling's merge,
+  is no child and is not parked in `backlog`: write it into the spec of the issue whose pull
+  request carries it — the parent's, or the sibling's when the parent's pull request is in another
+  repository — so one pull request lands it in order, and a deletion of what this tree replaced
+  rides in the pull request of the last change it waits on the same way.
+  Post the verdict, with the folds you made, as one `dispatch comment` on your own issue (the
+  root, in a root session). Its first line is exactly `Red-team verdict for <root key>:`, with
+  the root's own key in place of the placeholder, so a reader can find it among the issue's
+  comments; the controller's weekly audit matches that line, and counts no child filed before
+  the release that first asked for it. The architect who wrote the list reads every child on it
+  as needed, and the comment stops a later session filing the same children again.
+- A child that duplicates another issue and is not yet released is never released: fold it by the
+  duplicate rule of `skill://dispatch-first`. The daemon records a child at its release and
+  re-asserts a status only on an issue it has recorded, so that close stands. A released duplicate
+  goes out with `park_child` instead.
 - Then paste each survivor's whole spec into a fresh `task(agent="plan-gap-analyst")` to check it
   against `skill://dispatch-writing-specs`, `wait` for its result, and fix what it flags: your own
   reread misses the terms
@@ -70,11 +77,13 @@ EOF
 - File every child before you request the root spec's approval, and before `register_gate` under
   `gates.design: off`: the gate's opening starts the root's own first phase unless Dispatch shows
   an open child under it, so a child filed after that leaves the root working beside its children.
-- Order the returned keys into waves with `--blocked-by` links (a later wave's child blocked by the
-  children it builds on), then release every child at once with `release_children`: Legion holds a
-  released child until its last blocker closes, and a child is inert only until it is released.
-  Each issue of the tree whose worker has work holds an admission slot of its own, so a wave of
-  four working children takes four of the deployment's cap.
+- Give a child `--blocked-by` only for an issue outside this tree's own repositories, or one whose
+  deploy another child builds on, then release every child at once with `release_children`:
+  Legion holds a released child until its last blocker closes, and a child is inert only until it
+  is released. No child waits on a sibling's merge in a repository this tree already has a pull
+  request in; that work is written into the spec of the issue whose pull request carries it.
+  Each issue of the tree whose worker has work holds an admission slot of its own, so four
+  working children take four of the deployment's cap.
 - Never release a child `--blocked-by` its own parent: the parent now merges last, so that child
   would wait forever.
 - Do not pass `--assignee`, because the default keeps the tree's questions in one Inbox: under the

package/legion/skills/legion-architect/references/design-gate.md

@@ -174,7 +174,7 @@ tree is at work, the root returns its admission slot and waits on its design gat
 approval or changes request delivers your next task, and so does a newer spec version once
 Dispatch shows the request back on your turn. While the root waits on a question instead, the
 human's approval or changes request of the spec answers that wait too, and the task says how the
-spec stands. Release no wave until every gated step is open: a delivered wake shows
+spec stands. Release no child until every gated step is open: a delivered wake shows
 `design-approved` on the root, or a task says its design gate is open, and under more than one
 step `gatedSteps` in your record shows each one `approved`. The daemon sends a root waiting on a
 person no `design-approved` notice, and "this resume is your design-approved wake" is that wake.
@@ -211,13 +211,13 @@ to the version it writes. Once they have answered:
 
 - When the answer is the whole change, request nothing: the document's chip reads Approved at the
   new version, its reviews dialog shows the review in their name, and the `design-approved` the
-  daemon sent opens nothing new. Carry on, and release no wave because of it.
+  daemon sent opens nothing new. Carry on, and release no child because of it.
 - When the answer changes the Summary, a requirement, a check or the tree's scope, rewrite that text and
   repeat steps 3 to 5 on the new version, with a one-sentence `--summary` naming what changed since
   the earlier approval, then the reviews' sentence (the card shows that approval, `Approved at
   version N on <date> by <who>.`, and its `Show diff` control carries the detail). The rewrite
   closes the gate until they approve;
-  work the daemon started at the answer keeps running. Release no new wave until the `design-approved`
+  work the daemon started at the answer keeps running. Release no further child until the `design-approved`
   after the rewrite; work already in flight continues. Every merger's `READY` in the tree is
   refused until a human approves the latest version.
 
@@ -238,7 +238,7 @@ are unchanged,
 the plan is the record and the tree carries on; otherwise change the root spec and request
 approval again.
 
-Later waves and re-scoping open children toward the same requirements need no spec edit and no new
+Later children and re-scoping open children toward the same requirements need no spec edit and no new
 approval. A child issue's spec is never gated, and the child's own Verification document is
 written by its architect.
 

package/legion/skills/legion-architect/references/wake-routing.md

@@ -18,16 +18,16 @@ and 7 (a conflict, the hand-over, the close) is in
 
 | Wake | Procedure |
 | --- | --- |
-| `carried-gate-opened` | Only a root whose catch-up said `carried` gets it. Its `version` and `reason`: a human approved the old root's spec document at `version`, which opened the gate this root carried; the daemon has released any READY it refused and started any child waiting on it. It names no step: the carry brings the old root's gate records, and the catch-up reports every gated step the carry did not bring as unregistered, so register each of those on this issue's own document for that step (`skill://legion-architect/references/design-gate.md`). It is not `design-approved`: do not proceed to section 2 or release a wave because of it, and start nothing. |
+| `carried-gate-opened` | Only a root whose catch-up said `carried` gets it. Its `version` and `reason`: a human approved the old root's spec document at `version`, which opened the gate this root carried; the daemon has released any READY it refused and started any child waiting on it. It names no step: the carry brings the old root's gate records, and the catch-up reports every gated step the carry did not bring as unregistered, so register each of those on this issue's own document for that step (`skill://legion-architect/references/design-gate.md`). It is not `design-approved`: do not proceed to section 2 or release a child because of it, and start nothing. |
 | `child-status` | A child of your tree left the workflow or re-entered it, or joined your tree from the admission queue; the reason names the child and its new status, or reads `<KEY> joined the tree of <ROOT> from the admission queue`. `todo` (a human's move, your `release_children`, or your `rerun_child`) means it runs again under your tree from planning, and the daemon starts it; you start nothing. A child held for a blocker starts the same way once nothing holds it, and the reason, naming it and its root, says what cleared the hold: its last blocker's close, naming the issues it waited on, now done, or a person or you taking its blocked-by links off; you start nothing for it either. `backlog`, `icebox` or `triage` (a human's move, or your `park_child`) means the daemon has suspended its workers, and it advances no further until it is set back to `todo`. Joined from the admission queue means a root that waited for a slot and never ran, which a person made a child of your tree or your `release_children` adopted, now runs in your tree with no architect of its own and takes an admission slot of its own when its work starts, from planning when it is `todo` and parked otherwise; one that waits on an unfinished blocked-by issue is held for that blocker like any other child, and starts when nothing holds it; you start nothing. A reason saying an issue is beneath an ancestor whose reviewed head the daemon has already accepted is a person's `todo` the daemon recorded and holds at `admitted`: nothing starts it until that ancestor closes, and a `request_backward_move` of the ancestor is what runs it under the ancestor now. What the rest of the tree does is your decision. When a park leaves no child that an issue in `accepting` waits on, run that issue's last round (`skill://legion-architect/references/acceptance.md`). |
 | `child-closed` | Read the child completion and remaining open children. Re-scope open work, park obsolete work for good with `park_child` (first take its link off each sibling that waits on it, or park that sibling too, as section 2 says), and file any new child the result calls for, after the red-team check in `skill://legion-architect/references/decomposition.md`, and release it at once with `release_children`, blocked by what it builds on (section 2). When a worker waits on this child for a missing surface (see `phase-finished`), tell it to continue with `envoy_publish` to its role topic. The last child's close is not the end-game (section 3). When it was the last child an issue in `accepting` waits on, run that issue's last round (`skill://legion-architect/references/acceptance.md`). |
-| `child-release-stalled` | Its `reason` names a child your `release_children` released that your tree has not recorded, its parent, and why, one of three: the parent's release has not reached the daemon after three tries; or GitHub did not answer the App installation read of a repository on the child's parent chain, and the wave left the child unrecorded because a parent on that chain is not `todo`, or did not write the child `todo` because its parent is not recorded; or the daemon's recovery of such a repository, once GitHub answered, still left children unrecorded (one notice per tree lists them all, each with its parent). Read the parent's record with the `legion` tool's `read_record` (`issue` the parent); release the parent first when the `reason` says to, then run `release_children` for the child again once the parent is recorded in your tree, and tell the controller if it never is. |
+| `child-release-stalled` | Its `reason` names a child your `release_children` released that your tree has not recorded, its parent, and why, one of three: the parent's release has not reached the daemon after three tries; or GitHub did not answer the App installation read of a repository on the child's parent chain, and the release left the child unrecorded because a parent on that chain is not `todo`, or did not write the child `todo` because its parent is not recorded; or the daemon's recovery of such a repository, once GitHub answered, still left children unrecorded (one notice per tree lists them all, each with its parent). Read the parent's record with the `legion` tool's `read_record` (`issue` the parent); release the parent first when the `reason` says to, then run `release_children` for the child again once the parent is recorded in your tree, and tell the controller if it never is. |
 | `child-not-recorded` | Its `reason` names a child your tree did not record and why: its repository resolves to none (neither it nor an ancestor names one, and the project has no default), or to one not mapped to the project, or to one the daemon leaves out for a missing GitHub App. The daemon said why on the child too. Set the child's repository to one of the project's (`dispatch issue-update --repo owner/name`), then release it again with `release_children`; tell the controller when the repository it needs is not served. |
 | `children-first` | An issue of your tree starts no phase of its own while Dispatch shows an open child under it, a child you filed and have not released included. The reason names the parent and each open child with the Dispatch status that holds it, and each cycle it found (a child `blocked_by` an issue above it on its own parent chain, which only a person taking that link off ends: open a `dispatch ask`). It comes once per issue and run of its tree. Release every child that should run, and close, `park_child` or re-parent the rest; the daemon starts the parent's first phase at its next admission slot once the last open child has left the workflow. You start nothing. |
-| `design-approved` | Its `version` is the approved one, and it names no step: under more than one gated step, read `gatedSteps` in your own record (the `legion` tool's `read_record`) to see which step that version opened and whether another still holds the tree. A human approved the document of one gated step at its current version; that step is open. Proceed to section 2 once every gated step is `approved` — except on a root whose catch-up said `handed_over`: its workers already run their phases, so start nothing; the approval releases any READY the gate refused. One whose `version` is the version a human's own answer to a decision block wrote, after an earlier approval (Dispatch carried that approval to it, "After approval" in `skill://legion-architect/references/design-gate.md`), opens nothing new: carry on, and release no wave because of it. A root that was waiting on a question in `awaiting_person` gets no such notice: the task that resumes it says "Your spec is approved at version N and the design gate is open: this resume is your design-approved wake", and that resume is this wake — proceed to section 2 on it. |
+| `design-approved` | Its `version` is the approved one, and it names no step: under more than one gated step, read `gatedSteps` in your own record (the `legion` tool's `read_record`) to see which step that version opened and whether another still holds the tree. A human approved the document of one gated step at its current version; that step is open. Proceed to section 2 once every gated step is `approved` — except on a root whose catch-up said `handed_over`: its workers already run their phases, so start nothing; the approval releases any READY the gate refused. One whose `version` is the version a human's own answer to a decision block wrote, after an earlier approval (Dispatch carried that approval to it, "After approval" in `skill://legion-architect/references/design-gate.md`), opens nothing new: carry on, and release no child because of it. A root that was waiting on a question in `awaiting_person` gets no such notice: the task that resumes it says "Your spec is approved at version N and the design gate is open: this resume is your design-approved wake", and that resume is this wake — proceed to section 2 on it. |
 | `design-changes-requested` | Its `version` and `reason`, and no step: under more than one gated step, read `gatedSteps` in your own record (the `legion` tool's `read_record`) and take the step whose `status` is `changes_requested`. A human asked for changes to that step's document at `version`, for `reason`. Revise that document as the reason asks and request approval again as "The armed gate" in `skill://legion-architect/references/design-gate.md` says; end your turn; that step is closed. On a root that was waiting on a question in `awaiting_person`, a review the human gave after the wait began comes in the resume task, not in this notice, whether it answered the wait or came after something else did: the task names the review with its version and reason, unless a later approval superseded it. A `version` below the latest, or a second request for one version, is a request that reached the daemon late: read it as the same section's last paragraph says. Each request arrives once. |
 | `phase-finished` | The daemon has already moved the issue to its next phase by its fixed table and started that phase's role; you start nothing. Read the finishing phase's handoff on the Dispatch issue (`dispatch handoff-read --issue <issue> --phase <word>`); if it shows unresolved gaps, tell the role now working the issue (`envoy_publish` to its role topic). A `planner` notice that names a departure from the spec's design defers to the full condition in "After approval" of `skill://legion-architect/references/design-gate.md`: when the approved Summary, the requirements, the checks, the scope and the settled decisions still hold, the plan is the record; otherwise change the root spec and request approval again as that section says. A `reviewer` notice whose GitHub review is `CHANGES_REQUESTED` needs nothing from you: the daemon has returned the issue to `implementing` (Dispatch `in_progress`) and started the **implementer**, whose correction goes through the tester and the reviewer again, never straight to retro. A `reviewer` notice with an `APPROVED` review means the issue is in `accepting` and the acceptance is yours (section 6): read the evidence, then `sign_off` (a parent only after its last round, "The last round" in `skill://legion-architect/references/acceptance.md`) or send it back with `request_backward_move`. A `tester` notice with `verdict: "fail"` — its handoff carries `implementerProof.verdict: "rejected"`, or a failure naming a check with no current passing result — has gone back to the **implementer** by the daemon's table; never record that check's result from another role. A worker that reports no surface reaches the changed path sends that report instead of completing its phase, so the daemon starts nothing more on that issue and the worker stays idle in its session, not suspended: build the surface in this tree: a child issue (infrastructure, tooling, or a skill) after the red-team check in `skill://legion-architect/references/decomposition.md`, or, when the red team folds it, tell the waiting worker to move the issue back to `implementing` with `request_backward_move`, naming the surface. When it is a child, tell the waiting worker to continue with `envoy_publish` to its role topic once that child's `child-closed` arrives. That report is never a reason to advance the phase. |
-| `pr-blocked` | Its `reason` names the pull request and the `max_fix_attempts` it reached, or reads `Issue reached review_round_cap=<N>.` (the end of this row). The count is of heads pushed onto a red verdict: no handoff is a commit, so every such push counts except a push by the review App (a planner's, tester's, reviewer's or architect's), and the head pushed onto a red the tester's red tests earned (a planned red) does not count either. Published once per exhausted count, not on every later red verdict for that count. Read the failed CI evidence and recovery attempts. The notice moves nothing, and no later CI red within the attempt that ran the count out (the counted head, and every head pushed on top of it until a push lands on a head CI judged green or on a settled head whose base branch requires no check and no workflow, the tester's red tests onto the held red included) sends the work back from `testing`, `reviewing`, `accepting`, `retro` or `merging` either: the issue stays in its phase until you move it, or a worker's own decision does (a tester's `fail`, a reviewer's request for changes). A head pushed onto green CI, or onto a settled head whose base branch requires no check and no workflow, leaves that attempt, so its red still comes as a `checks-red`. In `implementing`, give the implementer the failing checks (`envoy_publish` to its role topic). In any later phase a worker holds, tell that worker (`envoy_publish` to its role topic) to move the issue back to `implementing` with `request_backward_move`, naming the failing checks, and the daemon starts the implementer. In `accepting`, where no worker holds a phase, the move is yours: `request_backward_move` with `issue`, naming the failing checks. In `awaiting_merge`, where no worker holds a phase and a backward move is refused, open a `dispatch ask` naming the failing checks for the human who merges. Do not treat the blocked PR as final. A `review_round_cap` reason is the implementer's round count instead: every move back to an earlier phase counts one, and the notice comes again with each round past the cap. It moves nothing either, since the round that reached the cap has already started its worker. Tell the rounds apart by what announced each: a tester's fail by its `phase-finished` with `verdict: "fail"`; a request for changes by the reviewer's `phase-finished` over a `CHANGES_REQUESTED` review; the daemon's own move by a `checks-red` notice, whose reason names a conflict (`the head conflicts with <base>`), the required checks that failed (`CI is red at <head>`), or the merge queue's failed merge and its failing run (`the merge queue took pull request #<n> out at READY's head …`); a worker's `request_backward_move` by a `phase-finished` from the role that asked, whose reason reaches only the task of the worker the move started, so ask that worker; your own send-back from `accepting` by the reason you gave. Judge the cap by the rounds that are not conflicts. Conflict returns need nothing from you beyond the next round. Tester fails, requests for changes and CI-red returns (a `checks-red` notice is raised for CI only when a required check fails on code the branch pushed, or when the merge queue fails the merge) are the rounds the cap is for. Each `review_round_cap` notice is a decision you make in the turn it wakes, never one left for the next round to make: read what every counted round found, choose one of the three below, act on it in the same turn, and post it as a `dispatch comment` on the issue naming the rounds you read and the choice. **Narrow**: the change itself is sound but each round finds more around it; tell the implementer and the reviewer (`envoy_publish` to each one's role topic) which checks of the issue the next round answers; a correctness finding is still fixed in this pull request, and so is a wording nit or any clear fix in a file it touches, so the `Fast-follow:` line carries only cleanup in files this pull request does not touch. **Split**: part of the work cannot settle in this pull request and is a separately deliverable change (`skill://legion-architect`, section 1). On a child, run the red-team check in `skill://legion-architect/references/decomposition.md`, then file that part as a child of this issue's parent, never of this one (this issue closes at its own merge, and the split part usually builds on this pull request's unmerged code): `dispatch issue --project <project> --parent <parent> --title '<outcome>' --blocked-by <this issue> --spec-file -`. Release it now with `release_children`: Legion holds it on that `--blocked-by` link until this issue closes, and starts it then. On the root, narrow it to what settles here and open a `dispatch ask` for the rest (`skill://legion-worker/references/findings.md`): a person decides whether that becomes an issue. Tell the implementer and the reviewer that this pull request no longer carries it. **Accept the rounds**: each round found less than the one before it, and the last found no defect in the change itself (a stale line, a comment that states an old default); let the loop run and say why in the comment. A later notice is a new decision: accept again only when its round found less than the round you last accepted, and otherwise narrow or split. A finding that changes what the spec requires or what a check proves is a decision block in the root spec ("After approval" in `skill://legion-architect/references/design-gate.md`), and `dispatch ask` is only for a decision that needs a human's authority; neither replaces the choice. Judge a worker's backward move by the reason that worker gives. A move you ordered for a conflict found before `awaiting_merge` ("A conflicting head" in `skill://legion-architect/references/acceptance.md`) is a conflict return. The merger's move back to `reviewing` for a READY refusal (`READY_UNREVIEWED_CHANGE`, or `READY_NOT_APPROVED` when its task names no approved head), and the reviewer's no-fix request for changes that follows it so the tester runs the head, are not the work going in circles either. A move that sends back code found wrong counts with the tester fails. |
+| `pr-blocked` | Its `reason` names the pull request and the `max_fix_attempts` it reached, or reads `Issue reached review_round_cap=<N>.` (the end of this row). The count is of heads pushed onto a red verdict: no handoff is a commit, so every such push counts except a push by the review App (a planner's, tester's, reviewer's or architect's), and the head pushed onto a red the tester's red tests earned (a planned red) does not count either. Published once per exhausted count, not on every later red verdict for that count. Read the failed CI evidence and recovery attempts. The notice moves nothing, and no later CI red within the attempt that ran the count out (the counted head, and every head pushed on top of it until a push lands on a head CI judged green or on a settled head whose base branch requires no check and no workflow, the tester's red tests onto the held red included) sends the work back from `testing`, `reviewing`, `accepting`, `retro` or `merging` either: the issue stays in its phase until you move it, or a worker's own decision does (a tester's `fail`, a reviewer's request for changes). A head pushed onto green CI, or onto a settled head whose base branch requires no check and no workflow, leaves that attempt, so its red still comes as a `checks-red`. In `implementing`, give the implementer the failing checks (`envoy_publish` to its role topic). In any later phase a worker holds, tell that worker (`envoy_publish` to its role topic) to move the issue back to `implementing` with `request_backward_move`, naming the failing checks, and the daemon starts the implementer. In `accepting`, where no worker holds a phase, the move is yours: `request_backward_move` with `issue`, naming the failing checks. In `awaiting_merge`, where no worker holds a phase and a backward move is refused, open a `dispatch ask` naming the failing checks for the human who merges. Do not treat the blocked PR as final. A `review_round_cap` reason is the implementer's round count instead: every move back to an earlier phase counts one, and the notice comes again with each round past the cap. It moves nothing either, since the round that reached the cap has already started its worker. Tell the rounds apart by what announced each: a tester's fail by its `phase-finished` with `verdict: "fail"`; a request for changes by the reviewer's `phase-finished` over a `CHANGES_REQUESTED` review; the daemon's own move by a `checks-red` notice, whose reason names a conflict (`the head conflicts with <base>`), the required checks that failed (`CI is red at <head>`), or the merge queue's failed merge and its failing run (`the merge queue took pull request #<n> out at READY's head …`); a worker's `request_backward_move` by a `phase-finished` from the role that asked, whose reason reaches only the task of the worker the move started, so ask that worker; your own send-back from `accepting` by the reason you gave. Judge the cap by the rounds that are not conflicts. Conflict returns need nothing from you beyond the next round. Tester fails, requests for changes and CI-red returns (a `checks-red` notice is raised for CI only when a required check fails on code the branch pushed, or when the merge queue fails the merge) are the rounds the cap is for. Each `review_round_cap` notice is a decision you make in the turn it wakes, never one left for the next round to make: read what every counted round found, choose one of the three below, act on it in the same turn, and post it as a `dispatch comment` on the issue naming the rounds you read and the choice. **Narrow**: the change itself is sound but each round finds more around it; tell the implementer and the reviewer (`envoy_publish` to each one's role topic) which checks of the issue the next round answers; a correctness finding is still fixed in this pull request, and so is a wording nit or any clear fix in a file it touches, so the `Fast-follow:` line carries only cleanup in files this pull request does not touch. **Split**: part of the work cannot settle in this pull request. It is a child only when it needs a repository or a deploy order of its own (`skill://legion-architect`, section 1), and then it goes through the red-team check in `skill://legion-architect/references/decomposition.md` and is filed as a child of this issue's parent, never of this one, since this issue closes at its own merge. Work in a repository this tree already has a pull request in is no child and is not parked in `backlog`: write it into the spec of the issue whose pull request carries it, the parent's, or a sibling's when the parent's pull request is in another repository. On the root, narrow it to what settles here and open a `dispatch ask` for the rest (`skill://legion-worker/references/findings.md`): a person decides whether that becomes an issue. Tell the implementer and the reviewer that this pull request no longer carries it. **Accept the rounds**: each round found less than the one before it, and the last found no defect in the change itself (a stale line, a comment that states an old default); let the loop run and say why in the comment. A later notice is a new decision: accept again only when its round found less than the round you last accepted, and otherwise narrow or split. A finding that changes what the spec requires or what a check proves is a decision block in the root spec ("After approval" in `skill://legion-architect/references/design-gate.md`), and `dispatch ask` is only for a decision that needs a human's authority; neither replaces the choice. Judge a worker's backward move by the reason that worker gives. A move you ordered for a conflict found before `awaiting_merge` ("A conflicting head" in `skill://legion-architect/references/acceptance.md`) is a conflict return. The merger's move back to `reviewing` for a READY refusal (`READY_UNREVIEWED_CHANGE`, or `READY_NOT_APPROVED` when its task names no approved head), and the reviewer's no-fix request for changes that follows it so the tester runs the head, are not the work going in circles either. A move that sends back code found wrong counts with the tester fails. |
 | `pr-merged` | The pull request merged and the issue did not close; its `reason` says why. Merged before the issue reached `awaiting_merge`: the workflow runs on, and the merge closes the issue the moment it gets there, your acceptance and retro first. Merged while the rest of the tree still runs: the reason names the pull request and every issue the close waits for, and the root waits in `awaiting_merge`, its workers kept and live and no admission slot held, until the last of them is done or parked ("The close" in `skill://legion-architect/references/acceptance.md`). Either way you start nothing and no further notice follows. |
 | `pr-closed-unmerged` | Decide from current scope whether the work is reopened, started over (`park_child` then `rerun_child`, for a child), or ended with a reason. Delegate the repository action to the responsible phase worker and keep ownership. |
 | `pull-request-missing` | Its `reason` names the issue, the repository, the branch and the handoff commit: the issue's implementer completed at that commit and GitHub lists no open pull request on the branch, so the issue stays in `implementing`. Tell the implementer (`envoy_publish` to its role topic) to open the pull request from that branch; the daemon records it and moves the issue to `testing` once it is open. When the work should not go on, decide as the `pr-closed-unmerged` row says. It comes once per handoff commit. |
@@ -44,4 +44,4 @@ and 7 (a conflict, the hand-over, the close) is in
 ## A root that joins your tree, and a refused release
 
 - A root that waited in the admission queue, never ran and never left another tree joins your tree once a person makes it your child, if it is `todo`, and otherwise at your release of it (the `child-status` row of [wake routing](skill://legion-architect/references/wake-routing.md)); once in, it is held for its blockers like any child you release. A root that left another tree, handed over by its finished tree or admitted as an orphan, stays its own tree and never joins yours, even one that was your root's child before your root was admitted again. A labelled `todo` issue under a child you have not released, unless it ran as a tree of its own or left another tree, is held under that unreleased child (not a blocked-by hold): it waits for no slot until your release of it or of that child brings it in, with any `todo` child of its own.
-- A release that cannot take a child in is refused 409 and writes nothing, its message naming the child and why: release the rest of the wave again without it. `CHILD_NOT_ADOPTABLE` is an issue that runs or ran as a tree of its own, carries a run handed over to it, or was handed over (or admitted as an orphan) as a root of its own: leave it there, or ask the controller. `CHILD_IN_OTHER_TREE` is another tree's child. When the tree it names is a root held under an unreleased child of yours (a root that queued and never ran, so it has no architect of its own), release that root, or the unreleased child it sits under, instead: its children come with it. Otherwise re-parent the child back in Dispatch, or ask that tree's architect or the controller.
+- A release that cannot take a child in is refused 409 and writes nothing, its message naming the child and why: release the rest again without it. `CHILD_NOT_ADOPTABLE` is an issue that runs or ran as a tree of its own, carries a run handed over to it, or was handed over (or admitted as an orphan) as a root of its own: leave it there, or ask the controller. `CHILD_IN_OTHER_TREE` is another tree's child. When the tree it names is a root held under an unreleased child of yours (a root that queued and never ran, so it has no architect of its own), release that root, or the unreleased child it sits under, instead: its children come with it. Otherwise re-parent the child back in Dispatch, or ask that tree's architect or the controller.

package/legion/skills/legion-controller/SKILL.md

@@ -33,10 +33,13 @@ Launch, `gh`, pull requests, takeover: `skill://legion-controller/references/ses
 
 1. Recheck [trees waiting on a root claim](#trees-waiting-on-a-root-claim).
 2. Do the wake's work, or, on a start message, the start procedure below.
-3. On your first turn of each UTC day, whatever woke you: run the weekly-plan reconciliation
+3. On your first turn of each UTC week, whatever woke you: run the weekly audit
+   (`skill://legion-controller/references/weekly-audit.md`) before the day's report, so its
+   numbers and its nudges go in that report.
+4. On your first turn of each UTC day, whatever woke you: run the weekly-plan reconciliation
    (`skill://legion-controller/references/backlog-stewardship.md`), then post the
    [daily report](#daily-report).
-4. Name the [free slots](#free-slots) in your summary, so a person sees room to hand Legion work.
+5. Name the [free slots](#free-slots) in your summary, so a person sees room to hand Legion work.
 
 ## What happened before you started
 

package/legion/skills/legion-controller/references/daily-report.md

@@ -73,6 +73,13 @@ every issue by its `dispatch://` link and what it does for the reader, every pul
   name, its `detail`, and a deployment row's `configLine`. Say who acts on it, as
   `skill://legion-controller/references/wakes.md` says for `tick`. With none open, say nothing of
   them.
+- **The week** (on the report of your first turn of each UTC week only, from
+  `skill://legion-controller/references/weekly-audit.md`): the window's two times; the forced
+  creates by filer with the no-answer creates apart; the tree sizes in the five buckets with the
+  parked descendants; each nudge you sent, by its tree; and the duplicate audit's pairs, those
+  you folded and those you skipped with the event that settles each. Name beside each number the
+  command that recounts it. When you lead a stream that keeps a scoreboard, the same two measures
+  go on it under `forced_creates_by_filer` and `tree_sizes`.
 
 A day with nothing finished says so in one sentence. When the lists do not fit, give each list's
 count and name its issues of `--priority 0` and `--priority 1`, in board rank order.

package/legion/skills/legion-controller/references/weekly-audit.md

@@ -0,0 +1,146 @@
+# The weekly audit
+
+Read this on your first turn of each UTC week, whatever woke you, and run all four passes below
+before you post the day's report. They are the week's own numbers, beside the daily ones. The
+fourth pass, the duplicate audit, serves R8 of dispatch://INFRA-1160 and is not optional.
+
+## The week
+
+The week's boundary is your first turn on or after Monday 00:00 UTC. The window is the seven days
+before that boundary: `date -u +%Y-%m-%dT%H:%M:%SZ` prints the time now, and the window runs from
+seven days before it to it. Name the window's two times in the report, so a reader can recount.
+
+You already ran this week when the report issue carries a message of yours from on or after the
+boundary whose text names the window. Read the report issue before you start
+(`skill://legion-controller/references/daily-report.md`).
+
+## 1. The week's forced creates
+
+A create that went past Dispatch's near-copy refusal with `--force` carries `forced` on its
+`issue.created` event, with `past` naming the issues the refusal named. A forced create the
+refusal would not have stopped carries nothing, so this is a count of overrides, not of uses of
+`--force`. A `past` that is the empty list is a create whose check did not answer: report those
+apart, since nobody forced past anything there. Each form reads as itself on the `issue.created`
+line: an override ends `forced past <keys>`, and a create whose check did not answer ends
+`forced, the near-copy check did not answer`.
+
+```bash
+dispatch issues --project <PROJECT> --all
+dispatch read --issue <KEY> --all-events   # read the issue.created line
+```
+
+`--all-events` is not optional: a bare `dispatch read` prints the last ten events alone, and on
+any issue with more than ten the `issue.created` line is not printed at all.
+
+Keep the issues created inside the window, read each one's `issue.created` line, and count by
+filer. The line names its writer as `session <id> (<the session's title>)`, and the filer is that
+title cut at its last middle dot (`·`), so `Legion implementer · INFRA-1160` counts as
+`Legion implementer`, with every person counted together as one filer. A session that carries no
+title prints its id alone and is counted by that id. Report, per filer, how many creates forced
+past a refusal and which issues each named, then the no-answer creates as their own line.
+
+The recount is the same two commands: name them in the report beside the number.
+
+## 2. The week's tree sizes
+
+A Legion tree is an open issue with the `legion` label and no ancestor carrying it, with its
+descendants. A tree closed inside the window counts at its close.
+
+```bash
+dispatch issues --project <PROJECT> --label legion --all
+dispatch read --issue <KEY>                          # Referenced by: child_of names its children
+dispatch issues --project <PROJECT> --parent <KEY>   # the same children, one level at a time
+```
+
+`Links: child_of` on that read gives the issue's own parent, never its children, so walk down
+instead: read the root, take each `child_of` row under `Referenced by:` as a child, and read each
+child the same way until a read names none. `dispatch issues --parent` lists one level in one
+request and is the shorter walk on a wide tree.
+
+Count each tree's descendants at any depth, and report the trees in five buckets: 0, 1-2, 3-5,
+6-10, and 11 or more. Count the parked descendants of each bucket too: a descendant in `backlog`
+or `icebox`. Name the recount commands beside the numbers, since a reader checks them against
+Dispatch's own parent links.
+
+The report and, when you lead a stream that keeps a scoreboard, the stream's scoreboard artifact
+both carry the two measures, under the keys `forced_creates_by_filer` and `tree_sizes`.
+
+## 3. The nudges
+
+Ask the architect of each tree the counts name to fold what can ride in an open pull request.
+Both rules below count only a tree with at least one open descendant, a descendant whose status
+is not `done`. A tree whose descendants are all closed has nothing left to fold, and a nudge
+sent to one asks its architect to fold work that is already finished.
+
+- a tree with at least one open descendant, and more than 8 descendants in all or more than 2
+  levels below its root;
+- a tree with at least one open descendant that filed a child no red-team verdict names. The
+  verdict is a comment on the root whose first line reads `Red-team verdict for <root key>:`
+  (`skill://legion-architect/references/decomposition.md`). Read the root's comments with
+  `dispatch read --issue <ROOT> --all-events` and the replies under each verdict comment; a child
+  named in none of them was filed without the check.
+
+  Count no child created before that first line existed. The architects write it from the Legion
+  release that carries this file, so every child filed before then has no verdict comment to
+  find and is not evidence of a skipped check: read the release's own publication time from its
+  tag and leave out every child created at or before it. Without that, the first run of this
+  pass nudges nearly every tree that has children. Until a release carries this file, there is
+  no such tag to read: when `git tag --contains <the commit that added this file>` names no
+  release, the cutoff is the time of your run, so every child that exists counts as filed
+  before the rule and no tree is nudged for a missing verdict yet.
+
+Each nudge is one `dispatch comment` on the tree's root, naming what you counted and asking the
+architect to fold what can ride in an open pull request of the tree. End the comment with
+`descendants: <n>, levels: <m>`, the counts you sent it at. When the daemon's state names an
+architect for the tree (`read_state`'s `issues.<KEY>`), send the same text to that architect's
+role topic with `envoy_publish`.
+
+Send no new comment to a tree whose architect replied in the thread of your newest nudge comment
+there, until the tree's descendants pass the number that comment ends with. A tree whose children
+were all filed before the verdict's first line existed has no such comment and is nudged once;
+the architect's reply then settles it until the tree grows.
+
+List every nudge you sent in the day's report.
+
+## 4. The duplicate audit
+
+For each open issue of the project, read the related items of its title and spec through the
+no-write related route, leaving the issue, its ancestors and its descendants out, and judge
+whether each pair the two issues' own records do not already settle is the same work.
+
+The project holds hundreds of open issues and one related read takes about a second, so a serial
+pass is ten minutes of HTTP before any judging. Shard the open list and dispatch one
+`task(agent="scout")` per shard of at most 50 issues, then `wait` for them: each returns the pairs
+it found with its evidence, and you judge and fold them yourself.
+
+Give each scout the shard's keys and these commands:
+
+```bash
+dispatch read --issue <KEY>                    # title, spec artifact, Links:, Referenced by:
+dispatch doc-read --issue <KEY>                # the spec text the related read uses
+dispatch related --project <PROJECT> --title '<its title>' --text-file - \
+  --exclude-issue <KEY> --exclude-issue <each ancestor> --exclude-issue <each descendant>
+```
+
+`--exclude-issue` is repeatable and takes up to 50 issues; the issue itself, its ancestors and its
+descendants all go in one call. The read names both: a `child_of` row under `Links:` is the
+issue's own parent, read again on that parent for the next ancestor up, and each `child_of` row
+under `Referenced by:` is a child, read again on each child for the next level down. Ask each
+scout for, per issue, every related item that is an issue with the reason it looks like the same
+work, and nothing else: no comment, no close, no message.
+
+A pair is settled, and is skipped rather than proposed, when the two issues already say so: one
+was closed as a duplicate of the other, one was reopened after such a close, or one was made a
+child of the other. Read the first two from `dispatch read --issue <KEY> --all-events`'s
+`Events:`: the close's reason is the `message.created` line just before `issue.closed`, and a
+reopen is an `issue.updated` line that moves the status off `done`. No `Events:` line reports a
+parent change, so read the third from the same read's `Links:` and `Referenced by:`.
+
+Fold each pair you judge the same work by the duplicate rule of `skill://dispatch-first`: keep the
+issue with the spec, copy to it what only the other has, and close the other
+(`--status done --reason 'Duplicate of dispatch://KEY.'`). An issue carrying the `legion` label,
+or another holder's claim, is not yours to close: comment the kept issue's name on it instead. A
+pair inside a Legion tree goes to that tree's architect with `envoy_publish`, which decides it.
+
+The report lists every pair you judged the same work, with what you did about it, and every pair
+you skipped with what settles it: the event, or the parent link.

package/legion/skills/legion-worker/SKILL.md

@@ -19,7 +19,7 @@ You work one phase of one issue in a jj workspace every role of the issue shares
 
 ## Stop rules
 
-- **A refused completion is information, not a retry loop.** Quote the answer verbatim to the architect, so "my work is lost" and "my work belongs to an ended run" read differently. `HANDOFF_STALE_GENERATION` (the issue is on a newer run) or `HANDOFF_NO_RUN` (your claim holds no task): push nothing further, end the turn without completing, and tell the architect; if the task then arrives and its work and handoff are already done, call `handoff_complete` again in that task's turn, and never redo the work or write a second handoff. `HANDOFF_STALE_ASSIGNMENT` (the issue left your phase and came back while your turn ran, so your work belongs to the assignment before the one the phase hands you now): end the turn without completing and tell the architect, and report that work and that verdict no further. The phase was entered again, so the task it hands you now is work of its own — a testing assignment after a red is for the head the fix pushed, which your verdict on the head before it does not answer for: do that work at the head the task names, write a handoff of its own for it, and complete in its turn. `HANDOFF_NOT_CURRENT_PHASE`: the issue left your phase; report, never complete again. `HANDOFF_NO_PULL_REQUEST` (the implementer's completion found no open pull request on `legion/<KEY>`, and none recorded merged): open it and complete again at the same commit; when the answer names a closed pull request, the architect decides the phase: tell it, and open or reopen nothing until it answers. `HANDOFF_ALREADY_RECORDED`: the first answer stands; if you did not see it, tell the architect. `HANDOFF_SESSION_MISMATCH` names a record another session wrote: read it, record it again from your session with `dispatch handoff-write`, and complete. A reminder is not a task: after an accepted completion, a second call is refused.
+- **A refused completion is information, not a retry loop.** Quote the answer verbatim to the architect, so "my work is lost" and "my work belongs to an ended run" read differently. `HANDOFF_STALE_GENERATION` (the issue is on a newer run) or `HANDOFF_NO_RUN` (the daemon can attribute your completion to no run: your claim holds no task of this issue's current run and phase — no task at all, or one of another run, of another phase, or of no phase — and the answer says which of those it holds): push nothing further, end the turn without completing, and tell the architect; if the task then arrives and its work and handoff are already done, call `handoff_complete` again in that task's turn, and never redo the work or write a second handoff. `HANDOFF_STALE_ASSIGNMENT` (the issue left your phase and came back while your turn ran, so your work belongs to the assignment before the one the phase hands you now): end the turn without completing and tell the architect, and report that work and that verdict no further. The phase was entered again, so the task it hands you now is work of its own — a testing assignment after a red is for the head the fix pushed, which your verdict on the head before it does not answer for: do that work at the head the task names, write a handoff of its own for it, and complete in its turn. `HANDOFF_NOT_CURRENT_PHASE`: the issue left your phase; report, never complete again. `HANDOFF_NO_PULL_REQUEST` (the implementer's completion found no open pull request on `legion/<KEY>`, and none recorded merged): open it and complete again at the same commit; when the answer names a closed pull request, the architect decides the phase: tell it, and open or reopen nothing until it answers. `HANDOFF_ALREADY_RECORDED`: the first answer stands; if you did not see it, tell the architect. `HANDOFF_SESSION_MISMATCH` names a record another session wrote: read it, record it again from your session with `dispatch handoff-write`, and complete. A reminder is not a task: after an accepted completion, a second call is refused.
 - **A turn that ends with your phase open is reminded**, at the end of every turn for as long as the phase stays open. Answer by completing, or with a WAITING line naming what you wait on, which buys a quiet wait; a turn that ends while background work of your own is still running buys the same quiet with no line at all, since that work wakes you when it finishes. A run of reminders that change nothing tells your architect. Under `runtime: kubernetes` that quiet wait also lets the daemon release your issue's pod, while background work of yours keeps the pod, because your session reports that work to the daemon.
 - **A released pod is not a stop.** Under `runtime: kubernetes` the daemon releases your issue's pod once no role of it has a turn in progress or a turn due for ten minutes. Your session, your phase, your place in it and the task you hold are all kept, and your unpushed commits and working-copy change are restored into the next pod, so a release costs a pod start and nothing else. A wait that raises no event of its own wakes you at the backstop alone, 60 minutes after the release, so name the wait in your WAITING line and expect that hour. A release keeps nothing else of the disk — `$TMPDIR`, every ignored file, each role's home, a test database and the CodeGraph index all go with the pod — so put work you must keep on the branch, in a tracked file or in Dispatch. The backstop runs only while your phase is open.
 - **The workspace is read-only for you from the moment your phase ends**, whether you ended it by completing or a CI red took it back while your turn ran: no commit, no `jj new`, no edit to a tracked file, in the turn still running when the message reaches you and in every turn after it, until a new task names your phase. Nothing stops that turn for you, so stopping is yours to do: drop the work in hand and leave whatever you have uncommitted. The active phase owns the workspace, and your session is kept, until your issue leaves the workflow, to answer questions and to take your next assignment.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/claude-envoy",
-  "version": "1.13.0",
+  "version": "1.14.1",
   "license": "Apache-2.0",
   "description": "Claude Code channel plugin for Legion's Envoy bus",
   "type": "module",
@@ -19,7 +19,7 @@
     "AGENTS.md"
   ],
   "legion": {
-    "daemonApiVersion": 55
+    "daemonApiVersion": 56
   },
   "repository": {
     "type": "git",

package/skills/dispatch/SKILL.md

@@ -9,7 +9,7 @@ Dispatch is a record for the people who decide, never a log of your work.
 
 - Use the `dispatch` command; the HTTP API only for what no command does. `dispatch <command> --help` gives its rules and an example.
 - Put long text on stdin: `--<field>-file -` with a quoted here-document (`<<'EOF'`); give object and list fields as JSON.
-- Exit 1 is a refusal, 2 a usage error. A refusal lists each problem: fix them all, then call once.
+- Exit 1 is a refusal, 2 a usage error. A refusal lists every problem: fix all, call once.
 - A Dispatch command hard to use, or storing or losing something wrongly, is a defect to report, not work around: open an issue in the owning project's code and tell that project's controller; a Legion role tells its architect (`skill://legion-worker/references/findings.md`).
 
 ## Asks and ask blocks
@@ -35,7 +35,7 @@ The question and the recommendation, as `skill://dispatch-writing-specs` writes
 
 ## Choosing what to work on
 
-- When you finish an issue, take the top ready one: `todo`, by priority then board rank, per project.
+- Finishing an issue, take the top `todo` one by priority then board rank, per project.
 - `todo` means specced and waiting on nothing; one that waits goes in `backlog`, saying on what.
 - Hold at most three issues in flight; move the rest to `backlog`, saying where each is.
 - Never reorder the board: one agent keeps each project's order (`issue-update --before`/`--after`). If the top looks wrong, tell `notifications.role.legion-<project>-controller`.

package/skills/dispatch-first/SKILL.md

@@ -5,19 +5,17 @@ description: "Use when a session has the dispatch command, before you plan, file
 
 # Dispatch first
 
-Dispatch holds the open issues, their specs and people's answers.
-
 ## Search before you act
 
 - Before you plan, file an issue, ask, post a finding or start work, run `dispatch search`.
-- Each query word must match. Use two or three words: the thing and what is wrong with it. Never paste a draft.
+- Each query word must match. Use two or three: the thing and what is wrong. Never paste a draft.
 
 ```bash
 dispatch search --query 'broadcast send order'
 dispatch search --query 'reviewer threads OR review comments'
 ```
 
-- No hits: remove a word before you add one. Try two or three wordings before you decide nothing exists.
+- No hits: remove a word before adding one. Try two or three wordings before deciding nothing exists.
 - Open each hit that can be yours with `dispatch read --issue KEY`, then its parent (`child_of` under `Links:`, or a document's `Issue:`), with its status and recent events.
 
 ## What to do with what you find
@@ -26,7 +24,7 @@ dispatch search --query 'reviewer threads OR review comments'
 
 - **Work already tracked:** put the finding on that issue. File a new issue only when no hit covers the work, and cite the nearest one you ruled out (`dispatch://KEY`).
 - **Question already decided:** the answered ask is the record. Cite it (`dispatch://KEY/ask/<id>`). Do not ask again.
-- **Duplicate found:** keep the issue with the spec, copy to it what only the duplicate has, and close the duplicate (`--status done --reason 'Duplicate of dispatch://KEY.'`). When it has the `legion` label or another holder's claim, comment the kept issue's name on it instead.
+- **Duplicate found, or a likely duplicate a create names:** read it; fold only when it is the same work. Keep the issue with the spec, copy to it what only the duplicate has, and close the duplicate (`--status done --reason 'Duplicate of dispatch://KEY.'`). When it has the `legion` label or another holder's claim, comment the kept issue's name on it instead.
 
 ## Research before you ask
 
@@ -36,8 +34,6 @@ dispatch search --query 'reviewer threads OR review comments'
 
 ## Reach a person only through Dispatch
 
-Reach a person through an ask, an ask block or an approval request.
-
 - The moment a person blocks your work, open an ask: an ask block for a design question its document records, else `dispatch ask`. A blocker that is not an open ask does not exist for them. A Legion phase worker sends decisions to its architect instead. Before you say you wait on a person, run `dispatch open-asks`.
 - A result a person asked for is the same: a document or artifact notifies nobody. End that document with an ask block asking their next step, else `dispatch ask`.
 - Record every request you accept in Dispatch before you start it: an issue, or a line in your issue's `open-items.md` artifact. Before you end a turn, read that record. Each item is done, in progress, or an open ask. Never drop one.

package/skills/dispatch-writing-specs/SKILL.md

@@ -28,7 +28,7 @@ Part | Content
 `Design` | How it meets them; a value and its reason for each limit, size and time
 `Decisions` | One line: `The decisions are in dispatch://KEY/artifact/decisions-md.`
 
-`serves` and `needs` name a block of this issue or an ancestor. Another agent can build and check the work from these alone. A small change gets a few sentences per part, no matrix; split a large design into child issues.
+`serves` and `needs` name a block of this issue or an ancestor. Another agent can build and check the work from these alone. A small change gets a few sentences per part, no matrix; split a large design into children.
 
 ## Rules for the text