@coreplane/switchboard 1.245.0 → 1.246.0

package/dist/assets/deploy/cloudflare-resident/worker.ts

@@ -8906,19 +8906,18 @@ async function handleOp(env: Env, body: Record<string, unknown>, traceparent?: s
   return streamOp(stub.runOp(op as "test" | "build", ref, traceparent));
 }
 
-/** /op's payload mapping: results pass through; a named error sheds its
- *  transport-only `status` field (the body is the contract, never the code); a
- *  pending op that rejected is the typed 500 (`catchAllErr`, so `transient`
- *  rides beside the words), its status shed the same way. */
+/** /op's payload mapping: results pass through; a failure streams as the typed
+ *  document it is — the named error with its `status` IN the body, a pending
+ *  op that rejected as the typed 500 (`catchAllErr`, so `transient` rides
+ *  beside the words) — exactly as `/exec`, `/attach` and `/await-restore`
+ *  stream theirs, so the client reads the status off the document by the one
+ *  rule (`answeredStatus`) and judges `transient` by the one rule too
+ *  (`isTransientRefusal`: a 5xx carrying it), never by the field on a 200. */
 function streamOp(pending: Promise<Awaited<ReturnType<ResidentDO["runOp"]>>>): Response {
-  const shedStatus = (failure: ThreadErr): object => {
-    const { status: _status, ...rest } = failure;
-    return rest;
-  };
   return streamHeartbeatJson(
     pending,
-    (result) => ("error" in result ? shedStatus(result) : result),
-    (err) => shedStatus(catchAllErr(err, "op-failed")),
+    (result) => result,
+    (err) => catchAllErr(err, "op-failed"),
   );
 }
 

package/dist/assets/deploy/cloudflare-sandbox/worker.ts

@@ -111,6 +111,13 @@ const SDK_PIN: string = sandboxPkg.dependencies["@cloudflare/sandbox"];
 
 const WORKDIR = "/workspace";
 
+/** How long the SDK waits for the platform to grant a container instance
+ *  before its start fails (docs/reference/specs/execution.md item 23). The
+ *  SDK's default is 30 s and it retries, so a burst that the platform would
+ *  not admit took 63 s to say so; at 10 s (the SDK allows 5 s to 300 s) the
+ *  refusal reaches the start gate — and the executor's wait — in seconds. */
+const INSTANCE_GET_TIMEOUT_MS = 10_000;
+
 // Default per-command time limit, enforced by coreutils `timeout` inside the
 // sandbox. The tuned 280s applies when the body carries no timeoutMs (an older
 // bot); a caller-supplied timeoutMs is clamped server-side to the shared
@@ -806,7 +813,16 @@ export default {
     // One sandbox per thread; the DO name is the thread key. The stub's own
     // methods (`runCommand`, `readText`, …) are what the routes call — the
     // work happens in the Durable Object, the data comes back over RPC.
-    const sandbox = getSandbox(env.Sandbox, threadKey);
+    const sandbox = getSandbox(env.Sandbox, threadKey, {
+      containerTimeouts: {
+        // A refused instance grant is learned in seconds, not after the SDK's
+        // 30 s default and its retries (63 s to "no container instance" under
+        // a burst, docs/reference/specs/execution.md item 23): the gate turns
+        // it into the wait token and the executor re-sends. A grant that is
+        // merely slow is re-asked on the next send, which finds it made.
+        instanceGetTimeoutMS: INSTANCE_GET_TIMEOUT_MS,
+      },
+    });
 
     const url = new URL(request.url);
     const body = (await request.json().catch(() => ({}))) as Record<string, unknown>;

package/dist/assets/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "switchboard",
-  "version": "1.245.0",
+  "version": "1.246.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "switchboard",
-      "version": "1.245.0",
+      "version": "1.246.0",
       "license": "Apache-2.0",
       "workspaces": [
         "web",
@@ -20445,7 +20445,7 @@
     },
     "packages/switchboard": {
       "name": "@coreplane/switchboard",
-      "version": "1.245.0",
+      "version": "1.246.0",
       "license": "Apache-2.0",
       "dependencies": {
         "@earendil-works/pi-ai": "0.85.1",

package/dist/assets/package.json

@@ -1,6 +1,6 @@
 {
   "name": "switchboard",
-  "version": "1.245.0",
+  "version": "1.246.0",
   "private": true,
   "description": "Mention it in Slack and an agent reviews the PR, ships the fix, or answers the question — on the model you choose, with its tools running where you decide.",
   "license": "Apache-2.0",

package/dist/assets/source.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.245.0",
-  "commit": "5cc6e0f8a25dfb2406f9248a2245c7412e381da6",
-  "builtAt": "2026-09-17T19:32:54.666Z"
+  "version": "1.246.0",
+  "commit": "62e4e9ad464820900b07bed176e140af6682c598",
+  "builtAt": "2026-09-18T01:06:13.947Z"
 }

package/dist/assets/src/agents/registry.ts

@@ -209,6 +209,14 @@ Text stays in your message; do not attach what you can say.`;
 // belongs in the agent's notes for the thread, and why — the one thing sure to
 // survive a compaction and reach the next run there — beside the reach `recall`
 // gives into every earlier turn. Said once so the prompts cannot drift on it.
+/** The one rule every preset carries about the length of what it says: the
+ *  answer is read in a chat thread, so it leads with the outcome and stops
+ *  when the outcome is said. Spelled the same in every prompt; the registry
+ *  test pins it. A review's verdict and findings are rendered by code from the
+ *  typed verdict, so there the rule governs the write-up alone. */
+export const BREVITY_RULE =
+  "SAY LESS. Your answer is read in a chat thread, often on a phone: lead with the answer or the outcome in one sentence, then only what the reader needs to act on it. Never restate the question or recap what was asked, never describe your method or list what you checked (that is your notes' job), never list options you are not recommending, never end with an offer or a question about what to do next — when the answer is complete, stop. One idea per sentence; a bullet only for items that are truly parallel, one line each; no headings. A question gets a few sentences; a refusal gets one sentence and the nearest thing you can do; a report gets its findings and nothing around them. Length is right only when the person asked for depth or the content is the list they asked for (a table, a diff, a plan).";
+
 /** The one rule every preset carries about text it did not receive from the
  *  person (record 0037): a linked thread, a stored record, a page someone
  *  else wrote, arrives inside the untrusted fence and is quoted data. Spelled
@@ -265,6 +273,7 @@ ${statusCardRule('"Clone repo and read the diff", "Run the test suite"')}
 
 If the request doesn't name a repository and you can't infer it, ask for it instead of guessing.
 Report outcomes faithfully: if tests fail or a step was skipped, say so plainly.
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack — keep it readable, lead with the outcome.`;
 
@@ -310,6 +319,7 @@ ${NOTEPAD}
 ${statusCardRule()}
 
 Report outcomes faithfully: if tests fail or a step was skipped, say so plainly.
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack — keep it readable, lead with the outcome.`;
 
@@ -352,6 +362,7 @@ ${NOTEPAD}
 ${statusCardRule()}
 
 Report outcomes faithfully: if tests fail or a step was skipped, say so plainly.
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack — keep it readable, lead with the outcome.`;
 
@@ -359,7 +370,13 @@ Your final message is posted to Slack — keep it readable, lead with the outcom
 // (docs/reference/specs/agent-ship.md item 6) lives here once — stable ids, the severity
 // vocabulary, the severity gate's downgrade (agent-review.md item 5a) — so the
 // sandbox and resident variants can never drift apart on it.
-const REVIEW_VERDICT_INSTRUCTION = `VERDICT: before your final message, call the submit_verdict tool exactly once with \`approve\` (no finding at or above the severity to address remains — the level in force for this run, \`minor\` by default: a major or a minor finding means \`request_changes\`; nits alone never block) or \`request_changes\`, a one-line summary, \`head\` = the output of \`git rev-parse HEAD\` in the checkout you reviewed, and \`findings\` — every issue you report as a structured entry with a stable id you assign in order (F1, F2, …), a severity of exactly blocking|major|minor|nit, the file (plus line when it points at one), and a one-line title. The findings array is the index of your review: the full explanation of each finding stays in your prose, keyed by the same ids. Switchboard writes the verdict as the first line of the GitHub comment itself and lists the findings under it; a review with no submitted verdict is posted as not approving, so never skip it. An \`approve\` carrying a finding at or above the severity to address is downgraded to \`request_changes\` and the tool's ack says so — approve only when every finding sits below the level. Do not write "LGTM" in your own text — the verdict line carries it.`;
+// The write-up is the review's text alone (docs/reference/specs/agent-review.md
+// item 5b): the verdict line and the findings list are rendered by code from
+// the submit_verdict call — on GitHub as the comment's head, in Slack as the
+// whole reply — so the prose never repeats them and never pads around them.
+const REVIEW_FINAL_MESSAGE = `YOUR FINAL MESSAGE IS THE REVIEW'S TEXT, NOTHING ELSE. Switchboard renders the verdict line and the findings list from your submit_verdict call — on GitHub as the head of the comment, in Slack as the whole reply — and folds your final message under them on GitHub as the full review. So write only what the list cannot carry: one short paragraph per finding, keyed by its id (what is wrong, the concrete failure, the fix). Do not restate the verdict or the findings, do not summarize what you read, do not list what you verified clean, do not describe your method — what you checked belongs in your notes, which the run page shows. A change with no findings needs one sentence, not a tour.`;
+
+const REVIEW_VERDICT_INSTRUCTION = `VERDICT: before your final message, call the submit_verdict tool exactly once with \`approve\` (no finding at or above the severity to address remains — the level in force for this run, \`minor\` by default: a major or a minor finding means \`request_changes\`; nits alone never block) or \`request_changes\`, a one-line summary, \`head\` = the output of \`git rev-parse HEAD\` in the checkout you reviewed, and \`findings\` — every issue you report as a structured entry with a stable id you assign in order (F1, F2, …), a severity of exactly blocking|major|minor|nit, the file (plus line when it points at one), and a one-line title. The findings array is the index of your review: the full explanation of each finding stays in your prose, keyed by the same ids. Switchboard writes the verdict as the first line of the GitHub comment itself, lists the findings under it and folds your text below them as the full review; a review with no submitted verdict is posted as not approving, so never skip it. An \`approve\` carrying a finding at or above the severity to address is downgraded to \`request_changes\` and the tool's ack says so — approve only when every finding sits below the level. Do not write "LGTM" in your own text — the verdict line carries it.`;
 
 // The diff-gated spec review (docs/reference/specs/agent-review.md item 14) and
 // the test guard under it (item 16; specs-coverage.md item 6), one text for
@@ -416,8 +433,9 @@ ${NOTEPAD}
 
 ${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
-Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
+${REVIEW_FINAL_MESSAGE}`;
 
 // Resident-path variant for review (docs/reference/specs/resident-repos.md): same
 // gather-once discipline, but against the ready worktree with git — the
@@ -449,8 +467,9 @@ ${NOTEPAD}
 
 ${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
-Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
+${REVIEW_FINAL_MESSAGE}`;
 
 // Seeded-sandbox variant for review (docs/reference/specs/execution.md item 26):
 // the gather-once discipline against a checkout that is already at the PR
@@ -483,8 +502,9 @@ ${NOTEPAD}
 
 ${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
-Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
+${REVIEW_FINAL_MESSAGE}`;
 
 // Research agent: no repo, no workspace — just web search + URL
 // reading, so a user can drop a link or ask a research question and get an
@@ -492,7 +512,7 @@ Your final message is posted to Slack. Lead with a one-line verdict, then the fi
 // fast and tool-less.
 const RESEARCH_SYSTEM = `You are Switchboard's research agent, answering a request from Slack.
 
-You have no workspace and cannot run commands or clone repos. Your tools: \`web_search\` (find sources), \`web_fetch\` (read a public URL — pages as text; image and PDF links come back as the image/document itself), and the GitHub tools — \`github_repos\` (the org repositories you can reach, private ones included), \`github_tree\` / \`github_file\` (browse and read their files at any ref), \`github_search_code\`, and \`github_issue_list\` / \`github_issue_get\`. They use Switchboard's own GitHub credential, so a private repo of ours is readable — never conclude a repo is inaccessible from a public-web 404; use the GitHub tools.
+You have no workspace and cannot run commands or clone repos. Your tools: \`web_search\` (find sources), \`web_fetch\` (read a public URL — pages as text; image and PDF links come back as the image/document itself), and the GitHub tools — \`github_repos\` (the org repositories you can reach, private ones included), \`github_tree\` / \`github_file\` (browse and read their files at any ref), \`github_search_code\`, \`github_issue_list\` / \`github_issue_get\`, and \`github_actions_run\` / \`github_actions_job_log\` (a GitHub Actions run, its jobs, a job's errors and log tail). They use Switchboard's own GitHub credential, so a private repo of ours is readable — never conclude a repo is inaccessible from a public-web 404; use the GitHub tools.
 
 How to work:
 1. If the user gave a URL, read it first — a github.com URL to one of our repos with github_file/github_tree (web_fetch cannot see private repos), anything else with web_fetch. If they asked about Switchboard or one of our repos, read the repo (README, AGENTS.md, \`docs/reference/specs/*.md\` specs, the code) with github_tree / github_file / github_search_code before answering. For a general question, web_search for good sources, then web_fetch the most promising 1-3 to read the actual content — don't answer from snippets alone when the page is readable.
@@ -501,6 +521,7 @@ How to work:
 
 ${statusCardRule('"Search the sources", "Write the answer"')}
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Use Slack-friendly formatting (no markdown headers; *bold*, bullets, code blocks). Your final message is posted to Slack — lead with the answer, then supporting detail and sources.`;
 
@@ -510,10 +531,11 @@ Use Slack-friendly formatting (no markdown headers; *bold*, bullets, code blocks
 // everyday asks ("open an issue on X", "what does our resident system do?",
 // "what's in that link?") are answered here instead of bounced to a directive.
 const GENERAL_SYSTEM = `You are Switchboard, a helpful assistant answering requests from Slack.
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Answer directly and concisely. Use Slack-friendly formatting (no markdown headers; use *bold*, bullets, and code blocks).
 
-Your tools work without a workspace: the GitHub tools — \`github_repos\` (the org repositories you can reach), \`github_tree\` / \`github_file\` / \`github_search_code\` (browse, read, search their code and docs, private repos included), \`github_issue_list\` / \`github_issue_get\` (read issues), \`github_issue_create\` / \`github_issue_update\` / \`github_issue_comment\` / \`github_issue_delete\` (act on issues) — and \`web_fetch\` (read a public URL). Use them: when the user names a repo loosely ("the switchboard app"), resolve it with github_repos (or the thread) rather than asking; when asked about one of our repos, read it before answering. Report exactly what a tool did (issue number + URL) — never claim an action you did not perform, and never fabricate file contents, URLs, or command output.
+Your tools work without a workspace: the GitHub tools — \`github_repos\` (the org repositories you can reach), \`github_tree\` / \`github_file\` / \`github_search_code\` (browse, read, search their code and docs, private repos included), \`github_issue_list\` / \`github_issue_get\` (read issues), \`github_actions_run\` / \`github_actions_job_log\` (a GitHub Actions run, its jobs, and a failed job's errors and log tail — "why did this run fail?"), \`github_issue_create\` / \`github_issue_update\` / \`github_issue_comment\` / \`github_issue_delete\` (act on issues) — and \`web_fetch\` (read a public URL). Use them: when the user names a repo loosely ("the switchboard app"), resolve it with github_repos (or the thread) rather than asking; when asked about one of our repos, read it before answering. Report exactly what a tool did (issue number + URL) — never claim an action you did not perform, and never fabricate file contents, URLs, or command output.
 
 ${statusCardRule('"Read the issue and its thread", "Post the comment"')} A one-step answer needs no checklist; post one when the request has steps the person would wait on.
 
@@ -548,6 +570,7 @@ ${statusCardRule('"Clone and install", "Time the full suite"')}
 
 ${NOTEPAD}
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Report outcomes faithfully: a check you could not run is "could not check", never a guess. Use Slack-friendly formatting (no markdown headers; *bold*, bullets, code blocks — render the claim table as aligned rows inside a code block). Your final message is posted to Slack: lead with the overall verdict in one line, then the claim table, then what a follow-up should do.`;
 
@@ -576,7 +599,7 @@ function conductorSystem(siblings: readonly AgentDef[]): string {
   );
   return `You are Switchboard's conductor: you coordinate other runs instead of doing the work yourself, answering a request from Slack.
 
-You have no workspace and no shell. Your tools: \`spawn_run\` (start a child run), \`send_to_run\` (steer a live child: your text reaches it as a follow-up at its next step), \`await_runs\` (wait for your children to end and get each end — its status and final reply — back as data), \`list_runs\` (the runs you may see — your own children by default), \`get_run_status\` (one run: whether it is running, what it is doing, and its final reply once it finished), the GitHub reads — \`github_repos\`, \`github_tree\` / \`github_file\` (browse and read our repositories), \`github_search_code\`, \`github_issue_list\` / \`github_issue_get\` — \`web_fetch\` (read a public URL), and \`update_status\`.
+You have no workspace and no shell. Your tools: \`spawn_run\` (start a child run), \`send_to_run\` (steer a live child: your text reaches it as a follow-up at its next step), \`await_runs\` (wait for your children to end and get each end — its status and final reply — back as data), \`list_runs\` (the runs you may see — your own children by default), \`get_run_status\` (one run: whether it is running, what it is doing, and its final reply once it finished), the GitHub reads — \`github_repos\`, \`github_tree\` / \`github_file\` (browse and read our repositories), \`github_search_code\`, \`github_issue_list\` / \`github_issue_get\`, \`github_actions_run\` / \`github_actions_job_log\` (an Actions run, its jobs, a job's log) — \`web_fetch\` (read a public URL), and \`update_status\`.
 
 WHAT A CHILD IS. A child is an ordinary Switchboard run started as the person who asked you — exactly the run they could start by hand with \`agent:<preset>\` — in a thread of its own in this channel, visible to everyone there, with its own status card and run page, and under their permissions: a preset they may not run, a repository they may not use, or a profile a boundary caps is refused in the child's thread, and the refusal comes back to you as the tool result naming the gate. Children cannot spawn children. You may have a few live at once (the deployment's \`spawn.maxChildren\`, three by default); a spawn past the cap is refused until one finishes. A child's wall clock is capped by what is left of yours.
 
@@ -593,6 +616,7 @@ A CHILD IS ITS THREAD. People can reply in a child's thread. While the child run
 
 Maintain the user-facing status card with the update_status tool: one item per child (○ pending, ✱ running, ✓ finished — only once await_runs or get_run_status said so).
 
+${BREVITY_RULE}
 ${FENCED_CONTENT_RULE}
 Use Slack-friendly formatting (no markdown headers; *bold*, bullets, code blocks). Your final message is posted to Slack: lead with the outcome, then one line per child — its preset, its thread, its status and its result in a sentence — and what is still running, if anything.`;
 }

package/dist/assets/src/core/budgets.ts

@@ -42,6 +42,24 @@ export const CONFIRMATION_TTL_MS = 10 * MINUTE_MS;
  *  inside it runs to the attach's own timeout. The run's own stop ends any of
  *  it at once. Read by the executor factory. */
 export const FIRST_ATTACH_WAIT_MS = MINUTE_MS;
+/** The least an attach REQUEST is opened with (docs/reference/specs/execution.md
+ *  item 9): a re-attach that recreates the worktree clones from the resident's
+ *  local mirror and may install deps, so a bound under this could not finish
+ *  and a request cut mid-clone is struck as a rollout — the strike this floor
+ *  exists to stop counting. A run with less than this left past its write-up
+ *  reserve opens no attach at all (`attachBoundWithinRun`: `exhausted`). Half
+ *  a minute: the one-second floor a COMMAND keeps (`BASH_TIMEOUT_MIN_MS`) is
+ *  the model's to choose; an attach is opened on the run's behalf. */
+export const ATTACH_REQUEST_MIN_MS = 30_000;
+/** How long a harness's one more command waits for a container that is down
+ *  under a live run to answer (docs/reference/specs/harness-pi.md item 16):
+ *  the platform rebuilt a replaced resident container in about a minute, and
+ *  a run with work in flight should not hang on a container that is not coming
+ *  back for as long as a fresh run may wait for its first container
+ *  (`SANDBOX_START_WAIT_MAX_MS`, ten minutes, execution.md item 23 — a wait
+ *  before anything ran). A wait that runs out decides nothing; the failure
+ *  that opened the question stands. */
+export const HARNESS_PROBE_WAIT_MS = 5 * MINUTE_MS;
 
 /** The presets that run the tool loop, and the one pipeline preset. */
 export const LOOP_PRESETS = ["general", "coding", "review", "research", "explore", "conductor"] as const;

package/dist/assets/src/core/coordinator/contract.ts

@@ -9,7 +9,7 @@
 // routes decide on.
 //
 import type { Grant, GrantSource } from "../budgets.js";
-import type { AddressSeverity, AddressSeveritySource } from "../ship/coordinator.js";
+import { isAddressSeverity, type AddressSeverity, type AddressSeveritySource } from "../ship/coordinator.js";
 
 // A coordinator is a Workflow instance in the shim Worker whose children are
 // ordinary `dispatch()` runs as the requesting user. It holds no credential of
@@ -215,6 +215,12 @@ export interface UnitSegment {
  *  reaches it — its thread, its pull request, the round boundaries the card
  *  drew and how it ended. One row a person can read for "what happened to this
  *  unit". */
+/** What the severity gate caught on a round: the level in force and the gated findings as `id (severity)`. */
+export interface RoundGate {
+  level: AddressSeverity;
+  findings: string[];
+}
+
 export interface CoordinatorUnit {
   instanceId: string;
   /** `U<n>` as the plan spells it. */
@@ -251,8 +257,12 @@ export interface CoordinatorUnit {
    *  renews the same segment twice. `from` is the sha the segment continues
    *  from, `runId` the coding run whose write-up briefs it. */
   segments?: UnitSegment[];
-  /** The round boundaries the coordinator reported, oldest first (the `ship_round` vocabulary). */
-  rounds: Array<{ index: number; agent: string; outcome: string; at: number }>;
+  /** The round boundaries the coordinator reported, oldest first (the `ship_round`
+   *  vocabulary). `gate` rides an approve the machine's severity check caught
+   *  carrying a finding at or above the level in force ([agent-ship](../../../docs/reference/specs/agent-ship.md)
+   *  item 9) — a mismatch to be seen, since the child's parser holds an approve
+   *  to the same level. */
+  rounds: Array<{ index: number; agent: string; outcome: string; at: number; gate?: RoundGate }>;
   /** How the unit ended: the ending's kind and the thread's report, when it has. */
   ending?: { kind: string; report: string; at: number };
   startedAt?: number;
@@ -303,6 +313,13 @@ export function isCoordinatorInstance(v: unknown): v is CoordinatorInstance {
 }
 
 /** Structural check on a unit row from outside the process. */
+/** A round's gate: a level on the ladder and string findings. */
+const isRoundGate = (v: unknown): boolean =>
+  isObject(v) &&
+  isAddressSeverity(v.level) &&
+  Array.isArray(v.findings) &&
+  v.findings.every((f) => typeof f === "string");
+
 const isSegment = (v: unknown): boolean =>
   isObject(v) &&
   typeof v.index === "number" &&
@@ -328,7 +345,15 @@ export function isCoordinatorUnit(v: unknown): v is CoordinatorUnit {
   if (
     !Array.isArray(r.rounds) ||
     r.rounds.length > MAX_ROUNDS ||
-    !r.rounds.every((x) => isObject(x) && isFinite(x.index) && isText(x.agent) && isText(x.outcome) && isFinite(x.at))
+    !r.rounds.every(
+      (x) =>
+        isObject(x) &&
+        isFinite(x.index) &&
+        isText(x.agent) &&
+        isText(x.outcome) &&
+        isFinite(x.at) &&
+        (x.gate === undefined || isRoundGate(x.gate)),
+    )
   )
     return false;
   if (

package/dist/assets/src/core/coordinator/driver.ts

@@ -539,7 +539,13 @@ async function runUnit(
     state = transition.state;
     for (const note of transition.notes) {
       if (note.type === "round") {
-        const body = { ...tag, index: note.index, agent: note.agent, outcome: note.outcome };
+        const body = {
+          ...tag,
+          index: note.index,
+          agent: note.agent,
+          outcome: note.outcome,
+          ...(note.gate !== undefined ? { gate: note.gate } : {}),
+        };
         await step.do(`${prefix}/note/${++notes}`, STEP_CONFIG, () => call(bot, "round", body));
       } else {
         // A merge_ready ending names the pull request as it is at the APPROVED

package/dist/assets/src/core/reviewVerdict.ts

@@ -247,14 +247,146 @@ export function formatDisposition(d: FindingDisposition): string {
   return `${d.findingId}: ${d.disposition}${d.note ? ` — ${d.note}` : ""}`;
 }
 
+/** Where the posted body's file links point: the PR's repository and the
+ *  head the review is pinned to (the post-step's `commitId`). */
+export interface ReviewBodyTarget {
+  /** `owner/name` */
+  repo: string;
+  /** The pinned head, full sha. */
+  head: string;
+}
+
+/** The verdict word the callout carries, per verdict kind (or its absence). */
+function verdictWord(verdict: ReviewVerdict | undefined): string {
+  if (!verdict) return "No verdict";
+  return verdict.verdict === "approve" ? "Approved" : "Changes requested";
+}
+
+/** GitHub's alert callout kind per verdict: an approve is a note, changes
+ *  requested a warning, a missing verdict a caution. */
+function calloutKind(verdict: ReviewVerdict | undefined): "NOTE" | "WARNING" | "CAUTION" {
+  if (!verdict) return "CAUTION";
+  return verdict.verdict === "approve" ? "NOTE" : "WARNING";
+}
+
+/** `2 findings: 1 minor, 1 nit` — counted on the ladder, most severe first;
+ *  an empty array is `no findings`, no array `findings not itemized`. */
+function findingCounts(findings: readonly Finding[] | undefined): string {
+  if (findings === undefined) return "findings not itemized";
+  if (findings.length === 0) return "no findings";
+  const by = FINDING_SEVERITIES.map((sev) => [sev, findings.filter((f) => f.severity === sev).length] as const)
+    .filter(([, n]) => n > 0)
+    .map(([sev, n]) => `${n} ${sev}`)
+    .join(", ");
+  return `${findings.length} finding${findings.length === 1 ? "" : "s"}: ${by}`;
+}
+
+/** A table cell: pipes escaped so the row holds, already one line. */
+const cell = (text: string): string => oneLine(text).replace(/\|/g, "\\|");
+
+/** Whether a finding's `file` is a path a blob URL can point at: no
+ *  whitespace, no backtick, not a URL. */
+const isRepoPath = (file: string): boolean => /^[^\s`]+$/.test(file) && !/^[a-z][a-z0-9+.-]*:\/\//i.test(file);
+
+/** The `Where` cell: the location in code, linked at the pinned head when the
+ *  file is a path and a target is known. */
+function whereCell(f: Finding, target: ReviewBodyTarget | undefined): string {
+  const location = f.line !== undefined ? `${f.file}:${f.line}` : f.file;
+  const label = `\`${cell(location)}\``;
+  if (!target || !isRepoPath(f.file)) return label;
+  const path = encodeURI(f.file).replace(/#/g, "%23").replace(/\?/g, "%3F");
+  const url = `https://github.com/${target.repo}/blob/${target.head}/${path}${f.line !== undefined ? `#L${f.line}` : ""}`;
+  return `[${label}](${url})`;
+}
+
+/** The machine-readable marker the body ends with — the verdict, the head and
+ *  the findings index as JSON inside an HTML comment, for a scanner that would
+ *  otherwise parse the token line. `-->` can never occur inside it. */
+function verdictMarker(verdict: ReviewVerdict | undefined, target: ReviewBodyTarget | undefined): string {
+  const head = target?.head ?? verdict?.head;
+  const payload = {
+    verdict: verdict?.verdict ?? "none",
+    ...(head ? { head } : {}),
+    ...(verdict?.findings
+      ? {
+          findings: verdict.findings.map((f) => ({
+            id: f.id,
+            severity: f.severity,
+            file: f.file,
+            ...(f.line !== undefined ? { line: f.line } : {}),
+          })),
+        }
+      : {}),
+  };
+  return `<!-- switchboard:verdict ${JSON.stringify(payload).replace(/-->/g, "--\\u003e")} -->`;
+}
+
 /**
- * Build the body posted to GitHub: the deterministic verdict line, the
- * compact findings list (when present), a blank line, then the model's
- * review text. Never starts with "LGTM" unless the verdict is `approve`.
+ * Build the body posted to GitHub, rendered from the typed verdict
+ * (docs/reference/specs/agent-review.md item 5b): the deterministic verdict
+ * line first (the auto-approve contract — never `LGTM:` unless the verdict is
+ * `approve`), a GitHub alert callout with the verdict word, the pinned head
+ * and the finding counts, the findings as a table (severity, id + title, the
+ * file linked at the head), the model's text folded under `Full review`, and
+ * the machine-readable marker last. The prose decides nothing above the fold.
  */
-export function buildReviewPostBody(answer: string, verdict: ReviewVerdict | undefined): string {
-  const head = [verdictLine(verdict), ...(verdict?.findings ?? []).map((f) => `- ${formatFinding(f)}`)];
-  return `${head.join("\n")}\n\n${answer.trim()}`;
+export function buildReviewPostBody(
+  answer: string,
+  verdict: ReviewVerdict | undefined,
+  target?: ReviewBodyTarget,
+): string {
+  const facts = [
+    `**${verdictWord(verdict)}**`,
+    ...(target ? [`head \`${target.head.slice(0, 7)}\``] : []),
+    verdict ? findingCounts(verdict.findings) : "the run ended without a submit_verdict call",
+  ];
+  const parts: string[] = [verdictLine(verdict), `> [!${calloutKind(verdict)}]\n> ${facts.join(" · ")}`];
+  const findings = verdict?.findings ?? [];
+  if (findings.length > 0) {
+    parts.push(
+      [
+        "| Severity | Finding | Where |",
+        "| --- | --- | --- |",
+        ...findings.map((f) => `| ${f.severity} | **${cell(f.id)}** ${cell(f.title)} | ${whereCell(f, target)} |`),
+      ].join("\n"),
+    );
+  }
+  const prose = answer.trim();
+  if (prose) parts.push(`<details>\n<summary>Full review</summary>\n\n${prose}\n\n</details>`);
+  parts.push(verdictMarker(verdict, target));
+  return parts.join("\n\n");
+}
+
+/**
+ * The channel reply for a review run, rendered from the typed verdict
+ * (agent-review.md item 5b): the verdict line, one bullet per finding, then
+ * where the review was posted and the run link. The model's write-up rides
+ * along only when it landed nowhere else — no GitHub post (Slack-only, an
+ * opt-out, a guard refusal) or findings not itemized (a list that says
+ * nothing is no substitute) — so the review's text is always somewhere a
+ * person reads it. No verdict → the bare answer with the link, as before.
+ */
+export function buildReviewChannelReply(input: {
+  answer: string;
+  verdict: ReviewVerdict | undefined;
+  /** The PR the post landed on, or undefined when nothing was posted. */
+  posted: { repo: string; number: number } | undefined;
+  liveUrl: string | undefined;
+}): string {
+  const { answer, verdict, posted, liveUrl } = input;
+  const tail = [
+    ...(posted && verdict ? [`Posted to ${posted.repo}#${posted.number}`] : []),
+    ...(liveUrl ? [`[Live run](${liveUrl})`] : []),
+  ].join(" · ");
+  const blocks: string[] = [];
+  if (!verdict) blocks.push(answer);
+  else {
+    blocks.push([verdictLine(verdict), ...(verdict.findings ?? []).map((f) => `- ${formatFinding(f)}`)].join("\n"));
+    const compact = posted !== undefined && verdict.findings !== undefined;
+    if (!compact && answer.trim()) blocks.push(answer.trim());
+  }
+  if (tail) blocks.push(tail);
+  return blocks.join("\n\n");
 }
 
 // --- Dispositions (the coding side's answer to findings) -------------------

package/dist/assets/src/core/runEvents.ts

@@ -94,6 +94,10 @@ export type RunNoteKind =
   | "sandbox_restarted"
   | "stop_requested"
   | "stopped"
+  /** A stop the loop or turn had to ask pi for again reached it: the series a
+   *  failed abort's write opened (its `harness_error` line) closes here with
+   *  the count of re-asks (harness-pi item 16). Written by the pi harness. */
+  | "stop_landed"
   /** Setup spans the request's stream sink had to drop before this run was
    *  bound (docs/reference/specs/tracing.md): `summary` says how many, `from`/`to` the
    *  interval, which the partition reports as not recorded. */
@@ -142,6 +146,16 @@ export type RunNoteKind =
    *  after the attach, before the first turn, so the run page explains a
    *  sandbox run that shows resident steps. */
   | "cold_sandbox"
+  /** The run ledger would not track this run (docs/reference/specs/run-history.md
+   *  item 54): its reservation met the row of a run this process was closing
+   *  (a restart from its request, or the fresh turn for its follow-ups), waited
+   *  for that finish, and the row still stood — the finish failed or was
+   *  refused — so no handoff, resume or reclaim reaches this run, and its
+   *  record reaches the store when it finishes. The summary names that run and
+   *  how its finish ended; published by the dispatcher right after the
+   *  reservation, before the attach, and carried on the card's label — the bot
+   *  log's warning is not the only witness. */
+  | "ledger_untracked"
   /** The resident kept this thread's binding where it was instead of moving
    *  it onto the branch the thread's own run opened a pull request on
    *  (docs/reference/specs/resident-repos.md item 16): the summary names the
@@ -248,6 +262,7 @@ export const RUN_NOTE_KINDS = [
   "sandbox_restarted",
   "stop_requested",
   "stopped",
+  "stop_landed",
   "spans_dropped",
   "head_moved",
   "run_failed",
@@ -258,6 +273,7 @@ export const RUN_NOTE_KINDS = [
   "description_turn",
   "verdict_turn",
   "cold_sandbox",
+  "ledger_untracked",
   "rebind_refused",
   "work_left_behind",
   "workspace_torn_down",
@@ -373,6 +389,7 @@ export function isHeadMaterial(event: RunEvent): boolean {
         event.kind === "mcp_unavailable" ||
         event.kind === "spans_dropped" ||
         event.kind === "cold_sandbox" ||
+        event.kind === "ledger_untracked" ||
         event.kind === "rebind_refused"
       );
     case "span_start":
@@ -794,7 +811,18 @@ export type RunEvent =
    *  round and its fix round share an index. Published by the ship pipeline
    *  straight to the registry (like `pr_opened`), never through the runner.
    *  Additive: unknown → ignored. */
-  | { type: "ship_round"; index: number; agent: string; outcome: ShipRoundOutcome; seq?: number; at?: number }
+  | {
+      type: "ship_round";
+      index: number;
+      agent: string;
+      outcome: ShipRoundOutcome;
+      /** The severity gate fired on this approve (agent-ship item 9): the level
+       *  in force and the gated findings as `id (severity)` — a mismatch the
+       *  child's own parser should have made impossible, kept visible. */
+      gate?: { level: string; findings: string[] };
+      seq?: number;
+      at?: number;
+    }
   /** The request router's decision (docs/reference/specs/routing-and-config.md
    *  item 21): the preset a plain message was routed to, the one-line reason
    *  the router gave (redacted, capped — the same text the card's `routed:`