@coreplane/switchboard 1.245.0 → 1.247.0

package/dist/assets/config/config.example.yaml

@@ -347,7 +347,7 @@ workspaceDir: ./workspaces
 # `ship` fails the load by name.
 # ship:
 #   maxRounds: 3      # review rounds per unit
-#   maxMinutes: 120   # the ship preset's wall-clock budget in minutes (the registry's default)
+#   maxMinutes: 240   # the ship preset's wall-clock budget in minutes (the registry's default)
 
 # Which harness each preset's runs are driven by, deployment-wide
 # (docs/reference/specs/harness.md item 8): a mapping of preset to a harness's

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

@@ -641,8 +641,18 @@ interface ConfirmationRow extends ConfirmationInput {
 }
 /** Why a consume or a cancel refused: the row is gone (`used`), past its expiry (`expired`), or someone else's (`foreign`). */
 type ConfirmationRefusal = "used" | "expired" | "foreign";
-type ConfirmationOutcome = { row: ConfirmationRow } | { refused: ConfirmationRefusal };
+/** A refusal names the row where one still exists — `expired` (deleted here)
+ *  and `foreign` (kept) — so the bot can record the click's refusal against
+ *  the command that was bound (record 0054); `used` has no row to name. */
+type ConfirmationOutcome = { row: ConfirmationRow } | { refused: ConfirmationRefusal; row?: ConfirmationRow };
 type ConfirmationCancelOutcome = { ok: true } | { refused: Exclude<ConfirmationRefusal, "expired"> };
+/** The consume log's word: a refusal may carry the row it names (expired,
+ *  foreign), so the refusal is the discriminant, never the row's presence. The
+ *  parameter is the declared union, where the narrowing holds; the stub's
+ *  return type narrows to `never` across `in`. */
+function consumeWord(outcome: ConfirmationOutcome): string {
+  return "refused" in outcome ? outcome.refused : "consumed";
+}
 
 function isJsonObject(v: unknown): v is Record<string, unknown> {
   return typeof v === "object" && v !== null && !Array.isArray(v);
@@ -718,9 +728,9 @@ export class ConfigDO extends DurableObject<Env> {
       if (!stored) return { refused: "used" };
       if (stored.expiresAt <= now) {
         this.sql.exec(`DELETE FROM confirmations WHERE id = ?`, id);
-        return { refused: "expired" };
+        return { refused: "expired", row: stored };
       }
-      if (!actorIds.includes(stored.requester)) return { refused: "foreign" };
+      if (!actorIds.includes(stored.requester)) return { refused: "foreign", row: stored };
       this.sql.exec(`DELETE FROM confirmations WHERE id = ?`, id);
       return { row: stored };
     });
@@ -1233,7 +1243,7 @@ async function handleConfig(pathname: string, body: unknown, env: Env): Promise<
       const click = confirmationClickOf(b);
       if (click instanceof Response) return click;
       const outcome = await dO.consumeConfirmation(click.id, click.actorIds, systemClock());
-      console.log(`[config/confirmations/consume] ${click.id} ${"row" in outcome ? "consumed" : outcome.refused}`);
+      console.log(`[config/confirmations/consume] ${click.id} ${consumeWord(outcome)}`);
       return json(outcome);
     }
     case "/config/confirmations/cancel": {

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

@@ -628,7 +628,7 @@ const ATTACH_MUTEX_WAIT_MS = 60_000;
  *  20-minute ceiling (`BASH_TIMEOUT_MAX_MS`) — clamped server-side by
  *  `clampBashTimeout` in handleExec, never trusting the client's number. The
  *  heartbeat keeps every HTTP hop alive for the whole budget; the ceiling
- *  stays far inside the bot's 45-min run budget. Work beyond 20 minutes
+ *  stays far inside the bot's 90-min coding budget. Work beyond 20 minutes
  *  belongs in background jobs.
  *
  *  /op runs (test/build) get the flat 20-minute ceiling — the deterministic op
@@ -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.247.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "switchboard",
-      "version": "1.245.0",
+      "version": "1.247.0",
       "license": "Apache-2.0",
       "workspaces": [
         "web",
@@ -20445,7 +20445,7 @@
     },
     "packages/switchboard": {
       "name": "@coreplane/switchboard",
-      "version": "1.245.0",
+      "version": "1.247.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.247.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",
@@ -39,14 +39,16 @@
     "cli": "tsx src/cli.ts",
     "verify": "npm run verify:root && npm run verify --workspaces --if-present && npm run check:site",
     "verify:root": "npm run check:consistency && npm run typecheck && npm run lint && npm run format:check && npm test && npm run check:dist",
-    "check:consistency": "npm run check:lockfile && npm run check:sandbox-pair && npm run skills:check && npm run licenses:check && npm run docs:check && npm run specs:check && npm run decisions:check && npm run hygiene:check && npm run check:project-facts && npm run agents:check && npm run clock:check && npm run screenshots:check",
+    "check:consistency": "npm run check:lockfile && npm run check:sandbox-pair && npm run skills:check && npm run licenses:check && npm run docs:check && npm run pr-title:check && npm run specs:check && npm run decisions:check && npm run hygiene:check && npm run check:project-facts && npm run agents:check && npm run clock:check && npm run screenshots:check",
     "ci:gate": "node scripts/ci-gate.mjs",
-    "fix": "npm run docs:gen && npm run agents:gen && npm run clock:gen && npm run hygiene:gen && npm run deploy:gen && npm run skills:sync && npm run lint:fix && npm run format",
+    "fix": "npm run docs:gen && npm run pr-title:gen && npm run agents:gen && npm run clock:gen && npm run hygiene:gen && npm run deploy:gen && npm run skills:sync && npm run lint:fix && npm run format",
     "deploy:gen": "npm run --silent cli -- deploy init",
     "deploy:check": "npm run --silent cli -- deploy init --check",
     "check:lockfile": "node scripts/check-lockfile.mjs",
     "check:sandbox-pair": "node scripts/check-sandbox-pair.mjs",
     "check:pr-title": "node scripts/check-pr-title.mjs",
+    "pr-title:gen": "node scripts/pr-title-vocabulary.mjs --write",
+    "pr-title:check": "node scripts/pr-title-vocabulary.mjs",
     "check:project-facts": "node scripts/check-project-facts.mjs",
     "agents:gen": "tsx scripts/agents-gen.ts",
     "clock:gen": "tsx scripts/clock-allowlist.mts --write",

package/dist/assets/project.json

@@ -100,8 +100,16 @@
       "when": "After bumping either half of a pair."
     },
     "check:pr-title": {
-      "does": "Judges one PR title as the changelog line it becomes: grammar, type, scope, the migration note behind `!`.",
-      "when": "`-- \"feat(scope): …\"` before opening a PR; CI's `title` check runs it."
+      "does": "Judges one PR title as the changelog line: grammar, type, scope, the `!` migration note.",
+      "when": "`-- \"feat(scope): …\"` before opening a PR; CI's `title` check."
+    },
+    "pr-title:gen": {
+      "does": "Writes the title gate's types and scopes from the release config and the code map.",
+      "when": "Part of `fix`."
+    },
+    "pr-title:check": {
+      "does": "The committed title vocabulary equals its two sources.",
+      "when": "Part of `check:consistency`."
     },
     "check:dist": {
       "does": "Builds, then proves the compiled entry points and the web bundle the image needs exist.",

package/dist/assets/source.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.245.0",
-  "commit": "5cc6e0f8a25dfb2406f9248a2245c7412e381da6",
-  "builtAt": "2026-09-17T19:32:54.666Z"
+  "version": "1.247.0",
+  "commit": "713b83c9db0b6f3f10ef6d2cc1a46714b9a23c3c",
+  "builtAt": "2026-09-18T03:41:18.440Z"
 }

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

@@ -143,7 +143,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.
+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, and on Switchboard's own repository the tool refuses the same titles with the gate's own sentence, so fix the title and resubmit rather than pushing on. 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** (≤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.
@@ -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;
@@ -50,12 +68,18 @@ export type Preset = LoopPreset | "ship";
 
 /** What each preset asks for when nothing above it is tighter, in minutes. The
  *  pipeline's (`ship`) is the wall clock one segment of its loop runs under;
- *  a deployment's `ship.maxMinutes` replaces it, held to `fit` below. */
+ *  a deployment's `ship.maxMinutes` replaces it, held to `fit` below. Coding's
+ *  is sized by the ledger's ship children, not its standalone runs: a child
+ *  that pushes at minute 29 and then runs the repo's whole gate (seven to ten
+ *  minutes on a resident) was cut at 45 one run in twelve, so the ask is
+ *  double the 90th percentile (31.5) with the gate inside it. Ship's holds
+ *  its own loop at the default rounds with a fix round at that ask, not at
+ *  its floor (`fit` proves the floor case; the ask leaves room above it). */
 export const ASKS: Readonly<Record<Preset, number>> = {
   general: 5,
-  coding: 45,
+  coding: 90,
   review: 25,
-  ship: 120,
+  ship: 240,
   research: 8,
   explore: 120,
   conductor: 120,
@@ -69,10 +93,13 @@ export type RoundKind = "coding" | "review" | "fix" | "merge";
  *  falls under the floor is refused rather than dispatched: a two-minute
  *  review or fix costs an attach and a model turn and finishes nothing.
  *  Review's is the ledger's 90th percentile of completed reviews (5.1 min over
- *  181); coding's and the merge wait's are guesses until the ledger says. */
+ *  181); coding's is the least a fix round can run the repo's gate in — the
+ *  gate alone takes seven to ten minutes on a resident, and a fix that cannot
+ *  run it finishes nothing its contract asks; the merge wait's is a guess
+ *  until the ledger says. */
 export const PRESET_FLOORS: Readonly<Record<LoopPreset, number>> = {
   general: 2,
-  coding: 10,
+  coding: 15,
   review: 5,
   research: 3,
   explore: 15,
@@ -369,6 +396,9 @@ export type GrantSource = "org" | "channel" | "user" | "run";
 export const DEFAULT_GRANT: Grant = { renewals: 0 };
 
 /** The most renewals one request may carry: thirteen segments of the ship
- *  preset's ask are a day, the longest problem a person hands over in one
- *  message before a plan should carry it. */
+ *  preset's ask are two days. The cap bounds a COUNT a person types
+ *  (`renewals:`) or a scope holds; it did not halve when the ask doubled,
+ *  since every grant already configured is a count of segments and a day's
+ *  hand-over is now `renewals: 5` — the longest problem a person hands over
+ *  in one message before a plan should carry it. */
 export const GRANT_RENEWALS_MAX = 12;

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