@coreplane/switchboard 1.244.0 → 1.246.0

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

@@ -145,7 +145,7 @@ export function statusCardRule(examples = '"Implement the fix", "Run the test su
 
 const PR_DESCRIPTION_TEMPLATE = `PR description — submit it with the submit_pr_description tool for EVERY PR (this is the default, not something to wait to be asked for). Switchboard renders the GitHub body from the object you submit, so never author PR-body markdown yourself. Before submitting, judge your title with the ${PR_TITLE_GUARD} gate — \`npm run check:pr-title -- "<title>"\` — and submit only a title it accepts; the same gate refuses the PR in CI. The body is a fixed-size MAP for the reader with everything for agents collapsed under it; every field is capped in visible characters (a link's URL is not counted) and the tool refuses an object over a cap naming the field and the count — cut and resubmit. Prose is unwrapped — no hard line breaks inside a paragraph. Always hyperlink the triggering issue/request. Never fabricate validation — state exactly what you ran and the real result. BEFORE authoring the pointers, load the \`pr-description\` skill with use_skill — it defines how to choose at most seven pointers, the mechanical anchor rules and what goes below the fold; follow it for every PR.
 EVERY PR includes one that already exists when you push — opened by a person, by dependabot, or by an earlier run. After EVERY push to such a PR: read its current title and body (\`github_issue_get\` with the PR number works for pull requests; \`gh pr view\` where gh exists), judge them against the change as it now stands at the pushed head, and submit the object that describes the PR as it is NOW — carry forward what the existing body says that is still true (a dependency bump's release notes belong in why), add what you changed, and anchor the pointers at the new head. Switchboard replaces the PR's title and body with your rendering. A description that describes an earlier state of its branch is a bug; "it is someone else's PR" is never a reason to leave it.
-- **title**: the PR title — one line naming the change, specific enough to pick out of a PR list.
+- **title** (≤72 characters in all): the changelog line — \`type(scope): what a reader can now do or expect\`, one change, one clause, present tense. The type and the scope spend the same budget as the description, so the description is short; the body carries the rest. The tool refuses a longer title naming the count, and so does the gate in CI.
 - **TL;DR** (\`tldr\`, rendered first, ≤300): two sentences for a reader with zero context — what this PR does and why it matters.
 - **Why** (\`why\`, ≤400): the problem and the motivation, with the triggering issue/request, the record and the stack position hyperlinked. Why, never what: the diff shows what.
 - **Where to look** (\`pointers\`, 1 to 7): the files a reviewer would open first, in reading order, each { label ≤60, text ≤160, optional risk ≤100, anchor } with the anchor a { path, from, to } line range at your pushed head, rendered as a link (never embedded code). One pointer per idea, never per file; when the change has more ideas than seven, keep the seven whose mistake would cost most.
@@ -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,14 +362,21 @@ ${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.`;
 
 // Both review prompts carry this verbatim. The findings contract
 // (docs/reference/specs/agent-ship.md item 6) lives here once — stable ids, the severity
-// vocabulary, the approve-over-blocking downgrade — 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 blocking issues — nits alone are not blocking) 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 blocking finding is downgraded to \`request_changes\` — approve only when nothing blocking remains. Do not write "LGTM" in your own text — the verdict line carries it.`;
+// vocabulary, the severity gate's downgrade (agent-review.md item 5a) — so the
+// sandbox and resident variants can never drift apart on 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/config/profile.ts

@@ -231,7 +231,11 @@ export function boundedByParent(
  *  reply names. */
 export type ProfileRefusal =
   | { axis: "identity"; needs: Identity; cap: Identity; scope: BoundaryScope }
-  | { axis: "machine"; needs: MachineClass; allowed: MachineClass[]; scopes: BoundaryScope[] };
+  | { axis: "machine"; needs: MachineClass; allowed: MachineClass[]; scopes: BoundaryScope[] }
+  /** The minutes axis refuses only under a minimum the caller names (the
+   *  preset's lease minimum, `leaseMinimum` in `src/core/budgets.ts`): a lease
+   *  clipped below it would leave the loop no time at all. */
+  | { axis: "minutes"; needs: number; have: number; scope: BoundaryScope };
 
 /** The effective profile, or the refusal the authorize stage turns into a
  *  named reply. Resolution is pure; the gate judges. */
@@ -252,6 +256,8 @@ export function effectiveProfile(
   preset: Pick<AgentDef, "machine" | "identity" | "maxMinutes">,
   directives: { budget?: number },
   boundary: EffectiveBoundary | undefined,
+  /** The least lease the preset does anything under; absent, the minutes only clip. */
+  minimum?: number,
 ): ProfileResolution {
   if (boundary?.maxIdentity && !identityWithin(preset.identity, boundary.maxIdentity.value)) {
     return {
@@ -285,6 +291,16 @@ export function effectiveProfile(
     minutes = boundary.maxMinutes.value;
     boundedBy = boundary.maxMinutes.scope;
   }
+  // Under the minimum the clip is a refusal, not a run: the write-up and the
+  // post-step take the whole lease and the loop never turns. Attributed to
+  // whatever clipped; a declared ask under its own minimum is the module's
+  // invariant to catch, named as the defaults' here so the switch is total.
+  if (minimum !== undefined && minutes < minimum) {
+    return {
+      kind: "refused",
+      refusal: { axis: "minutes", needs: minimum, have: minutes, scope: boundedBy ?? "defaults" },
+    };
+  }
   return {
     kind: "profile",
     profile: {

package/dist/assets/src/core/authz/types.ts

@@ -66,6 +66,14 @@ export interface Actor {
    * → nothing: fail-closed, exactly today's behaviour.
    */
   readonly memberOf?: ReadonlySet<string>;
+  /**
+   * The person an admin's dashboard session is viewing as (record 0053): set
+   * beside `onBehalfOf` = that person's actor, so the effective grants are the
+   * intersection (the person's) and `self`/`memberOf` are the person's, while
+   * `id` stays the admin's. Identity for the audit line and the banner; the
+   * registry door refuses every non-read effect while it is set. No rule reads it.
+   */
+  readonly viewingAs?: { readonly id: string; readonly name?: string };
 }
 
 /** `<group>:<read|write|exec>` plus the non-command actions. A plain

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

@@ -30,6 +30,37 @@ export const DAY_MS = 24 * 60 * MINUTE_MS;
  *  which stamps the expiry on its own clock. */
 export const CONFIRMATION_TTL_MS = 10 * MINUTE_MS;
 
+/** How long a dispatch's FIRST attach to a resident — a fresh run's, or a
+ *  resumed run's re-attach to its recorded worktree — waits for the resident
+ *  to wake when the Worker typed its refusal as the platform's transient
+ *  (docs/reference/specs/execution.md item 9): a Durable Object reset or lost
+ *  under the attach clears in seconds, so a minute is generous, and far under
+ *  the wake ceiling a mid-run re-attach may take — the card is silent while
+ *  this wait runs, then names it. It bounds the PROBING: past it no further
+ *  probe is made and, with nothing bound, a fresh run falls cold and a resumed
+ *  run is refused, the wait named either way; a re-attach already opened
+ *  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;
 export type LoopPreset = (typeof LOOP_PRESETS)[number];
@@ -127,6 +158,18 @@ export function postStepLease(preset: string, remainingMs: number | undefined):
   return Math.min(allowance, Math.max(1, remainingMs / MINUTE_MS));
 }
 
+/** The least lease under which a loop-running preset does anything: the
+ *  write-up and the preset's post-step are held back from every lease
+ *  (`loopClock`), so a lease of that sum leaves the loop nothing — the run
+ *  goes straight to its write-up and reports a budget it never had. One minute
+ *  above the sum is the least that runs a turn. A profile clipped under this by
+ *  a directive, a boundary or a parent's remainder is refused at the gate
+ *  naming it, the way a ship round is refused under its floor; the floors are
+ *  the larger numbers a round needs to be worth dispatching. */
+export function leaseMinimum(preset: string): number {
+  return ALLOWANCES.writeUp + postStepMinutes(preset) + 1;
+}
+
 /** A follow-up turn's lease, in ms: the lesser of what it asks and what the
  *  run's lease still holds, never under a minute — the grace covers that floor
  *  when the turn starts by the lease's end; later, the bearer may expire under

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