@coreplane/switchboard 1.241.0 → 1.243.0

package/dist/assets/project.json

@@ -168,11 +168,11 @@
       "when": "Part of `check:consistency`."
     },
     "clock:gen": {
-      "does": "Regenerates the clock-read allowlist (`src/core/trace/clockAllowlist.json`) from the tree — empty since the ratchet reached zero; a result that is not `{}` names a new direct read.",
+      "does": "Regenerates both clock allowlists from the tree: wall-clock reads (empty) and duration literals outside `src/core/budgets.ts`.",
       "when": "Part of `fix`."
     },
     "clock:check": {
-      "does": "No production file reads the wall clock directly: the allowlist is empty and the tree agrees.",
+      "does": "No production file reads the wall clock directly or gained a duration literal outside `src/core/budgets.ts`; both allowlists match the tree.",
       "when": "Part of `check:consistency`."
     },
     "docs:changed": {
@@ -204,15 +204,15 @@
       "when": "After a `web/` change."
     },
     "screenshots:gen": {
-      "does": "Renders the dashboard's screenshots from the fixture preview, both themes, and records their inputs' hashes in `docs/public/screenshots/manifest.json`.",
+      "does": "Renders the dashboard screenshots whose inputs changed, both themes, recording each surface's input hashes in `docs/public/screenshots/manifest/` (`--force`: all).",
       "when": "After a `web/` or fixture change, once `screenshots:check` names it; needs `npx playwright-core install chromium`, so it is not part of `fix`."
     },
     "screenshots:check": {
-      "does": "The dashboard's source and fixtures still hash to what the screenshots were rendered from — no browser.",
+      "does": "Each surface's inputs still hash to what its screenshots were rendered from — no browser.",
       "when": "Part of `check:consistency`."
     },
     "load": {
-      "does": "Load harness: `-- history|resident|sandbox|e2e|cards|provider|pi|route`.",
+      "does": "Load harness: `-- history|resident|sandbox|e2e|cards|provider|pi|route|door`.",
       "when": "Capacity receipts (docs/reference/specs/load-harness.md)."
     }
   }

package/dist/assets/source.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.241.0",
-  "commit": "645b2a6d20ac39178acdb7c412a6a72f6013771c",
-  "builtAt": "2026-09-17T01:34:41.433Z"
+  "version": "1.243.0",
+  "commit": "abfb780fe3a276f303d13d597ad7c549ba8f49c0",
+  "builtAt": "2026-09-17T07:58:14.271Z"
 }

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

@@ -1,6 +1,7 @@
 // Agent definitions. An agent is a system prompt + toolset + machine class + wall-clock budget.
 import type { Effort } from "../effort.js";
 import { BASH_TIMEOUT_MAX_MS } from "../execution/bashTimeout.js";
+import { ASKS, RUNAWAY_TURNS_PER_MINUTE, runawayTurnCap, type LoopPreset } from "../core/budgets.js";
 import { CONTRACT_HEADING, CONTRACT_SECTION_HEADINGS, PR_TITLE_GUARD } from "../core/ship/contract.js";
 // Which model runs it is resolved separately by the config layers, so any
 // agent can run on any configured provider/model.
@@ -41,24 +42,16 @@ export function machineNeedsRepo(machine: MachineClass): boolean {
 export const IDENTITIES = ["none", "read", "write"] as const;
 export type Identity = (typeof IDENTITIES)[number];
 
-/** The pace that marks a run as looping rather than working: a model turn
- *  every ten seconds, sustained for the whole wall clock. A busy run takes
- *  20–40 s a turn (a model think plus a tool call), so a run that averages six
- *  a minute from start to end is re-issuing calls, not making progress — and
- *  its turn cap ends it before the wall clock would, with a write-up that
- *  says so (docs/reference/specs/harness-pi.md item 15). */
-export const RUNAWAY_TURNS_PER_MINUTE = 6;
-
-/** The turn cap a wall clock implies: `maxMinutes × RUNAWAY_TURNS_PER_MINUTE`.
- *  Every preset that runs the loop derives its `maxTurns` from this, so the
- *  cap is never a number a good run reaches — the minutes are the budget. */
-export function runawayTurnCap(maxMinutes: number): number {
-  return maxMinutes * RUNAWAY_TURNS_PER_MINUTE;
-}
+/** The wall clocks live in `src/core/budgets.ts` (docs/decisions/0046): a
+ *  preset's ask, the turn cap derived from it and every allowance are rows
+ *  there, and this registry reads them. Re-exported for the readers that
+ *  learned them here. */
+export { RUNAWAY_TURNS_PER_MINUTE, runawayTurnCap };
 
-/** A loop-running preset's budget as one fact: the wall clock, and the runaway
- *  guard derived from it. */
-function loopBudget(maxMinutes: number): Pick<AgentDef, "maxMinutes" | "maxTurns"> {
+/** A loop-running preset's budget as one fact read from the module: the wall
+ *  clock it asks for, and the runaway guard derived from it. */
+function loopBudget(preset: LoopPreset): Pick<AgentDef, "maxMinutes" | "maxTurns"> {
+  const maxMinutes = ASKS[preset];
   return { maxMinutes, maxTurns: runawayTurnCap(maxMinutes) };
 }
 
@@ -150,15 +143,18 @@ 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. Content contract per field (each renders as its own section): 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. Keep each field concise, not padded.
-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 whatWhy), add what you changed, and anchor the Tour 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.
+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.
-- **TL;DR** (\`tldr\`, rendered first): two sentences for a naive reader with zero context — what this PR does and why it matters.
-- **What & why** (\`whatWhy\`): the change and its motivation, linked to the triggering issue/request.
-- **Tour** (\`tour\` + \`remaining\`): the guided walkthrough of the change, replacing any prose list of changes — ordered steps of { title, description, optional lookFor, anchor }, each anchor a { path, from, to } line range at your pushed head; every touched file no step covers goes in \`remaining\` as { path, note }. BEFORE authoring the Tour steps, load the \`pr-tour\` skill with use_skill — it defines the reader-first step shape, the anchor rules, and the Remaining-changes catch-all. Follow it for every PR; if a later push changes what the steps point at, resubmit the description with corrected anchors.
-- **Decisions** (\`decisions\`): non-obvious choices as { title, rationale } — alternatives considered and rejected, trade-offs.
-- **Risks & implications** (\`risks\`): what could break, the blast radius, and any migration/rollout/compatibility concerns (or "none" — and why).
-- **Validation** (\`validation\`): what you tested and the actual results as { criterion, proof } rows (commands run, pass/fail), plus how the reviewer can verify it themselves; the optional summary line carries the overall result.`;
+- **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.
+- **Feedback wanted** (\`feedbackWanted\`, ≤200): the one or two things you want the reviewer's judgement on.
+- **Risk** (\`risk\`, ≤300): what breaks if this is wrong, the blast radius, the rollback; over 400 changed lines, say so and name the split you considered.
+- **Verified** (\`verified\`, ≤200): one line for a person — which suites ran and passed, what is still human-gated.
+- **Decisions** (\`decisions\`, 0 to 10, collapsed): non-obvious choices as { title, rationale ≤400 } — the alternative rejected and the fact that decided it.
+- **Validation** (\`validation\`, 1 to 30 criteria, collapsed): what you tested and the actual results as { criterion ≤200, proof ≤300 } rows (test ids, commands run, pass/fail), plus how the reviewer can verify it.
+- **For agents** (\`agentNotes\`, optional, ≤2000, collapsed): what a reviewing agent needs that a person does not — the rebase you did, generated files to skip, the command that reproduces the bug.`;
 
 // Both coding prompts carry this verbatim: coding runs hold a write-scoped
 // token where a merge is one command away, so the boundary is spelled out the
@@ -223,6 +219,14 @@ export const FENCED_CONTENT_RULE =
 const NOTEPAD = `YOUR NOTES AND YOUR REACH BACK. This thread's conversation outlives your context window and this run: every turn — yours, the person's, every tool call and its output, from this run and the runs before it in this thread — is kept in a log you can search with the \`recall\` tool (words → the matching turns with their numbers; a turn number → that turn whole). When something you need is no longer in front of you, recall it instead of redoing the work or guessing.
 Keep notes with the \`notes\` tool: one short document, replaced whole each time, at most 8 KiB — decisions and their reasons, the names of things you found (files, tests, commits, the head your tests were green at), what is not yet proven. They are the one thing sure to survive a compaction and to reach the next run in this thread: they ride your system prompt at its start and come back to you right after a compaction. A person reads them too, on the run's page, so write them as a document and never as one paragraph: Markdown, a \`##\` heading per section — \`Done\`, \`In progress\`, \`Next\`, \`Facts\` (names, ids, heads, the reasons behind decisions), leaving out a section with nothing in it — one bullet per item, one line per bullet, no prose walls. Write them when you decide something worth keeping, not only at the end.`;
 
+// Every coding prompt carries this verbatim (docs/reference/specs/agent-coding.md
+// item 13): the order of checks and the push. Three plan children died at their
+// budget in one evening with finished work unpushed because each ran the
+// project's most expensive checks first; the rule is the runner's to hold, not
+// a line every requester remembers to paste. Stack-agnostic on purpose — the
+// classes are by duration, the project's own scripts and CI say which is which.
+export const CHECKS_BY_COST = `CHECKS BY COST — push before the expensive ones. Every check you might run has a cost class: seconds (a formatter or a linter on the files you touched, one test file, a docs, link or spec check, the typecheck of one package) or minutes (the whole test suite, a build, a dependency install, an end-to-end or full verification). Know a command's class before you run it — from the project's own scripts and CI configuration, from how long it took last time, or by the class above when you have nothing better. Prove each change with the cheapest check that can prove it, matched to the change's scope: a documentation change gets the documentation checks, one module gets its own tests, a shared type gets the typecheck. As soon as the change exists and those checks pass, commit and push — the pushed branch is the deliverable, and an unpushed tree does not survive the run's end. Only then run the expensive checks, once, and fix forward with further commits and pushes. Never start an operation whose expected duration does not fit the time you have left minus what a commit, a push and the description need: push what there is and say plainly what is unverified instead. The description's validation names exactly what ran; what did not run is CI's to gate, and you say so.`;
+
 const CODING_SYSTEM = `You are Switchboard's coding agent, operating from a Slack request.
 
 You work inside a dedicated workspace directory with bash, read_file, and write_file tools. ${SANDBOX_TOOLCHAIN}
@@ -237,10 +241,13 @@ Workflow for shipping a PR:
 1. Clone the repo into the workspace if it's not already there (use gh or git; both are authenticated on this host). Orient with a few BATCHED commands (tree + the relevant files in one call), not file-by-file exploration.
 2. Create a branch with a descriptive name.
 3. Implement the change. Match the surrounding code's style and conventions.
-4. Run the project's tests/linters if they exist and are quick enough to run.
-5. Commit with a clear message and push the branch.
-6. Call the submit_pr_description tool with the typed description object (content contract below) — every time, bringing forward the context you gained while implementing. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with \`gh\` or any API call.
-7. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+4. Prove the change with the cheapest checks that can (CHECKS BY COST below): the linter and the tests nearest the files you touched, the documentation checks for a documentation change.
+5. Commit with a clear message and push the branch — before any full suite, build or full verification.
+6. Then, if the budget allows, run the project's expensive checks once and fix forward with further commits and pushes.
+7. Call the submit_pr_description tool with the typed description object (content contract below) — every time, bringing forward the context you gained while implementing. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with \`gh\` or any API call.
+8. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+
+${CHECKS_BY_COST}
 
 ${NEVER_MERGE}
 
@@ -279,11 +286,14 @@ Environment notes:
 Workflow for shipping a change:
 1. Create a branch with a descriptive name off the bound branch.
 2. Implement the change. Match the surrounding code's style and conventions.
-3. Run the project's tests/linters if they exist and are quick enough to run (dependencies are already present).
-4. Commit with a clear message and push the branch with \`git push -u origin <branch>\`.
-5. Call the \`diff_digest\` tool to get a distilled summary of your change — per-file churn, totals, and risky-file flags. It is a distilled summary, not the raw diff: use it to shape the description you submit next — which files the Tour must walk, what belongs in risks.
-6. Call the submit_pr_description tool with the typed description object (content contract below) — every time. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with any API call.
-7. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+3. Prove the change with the cheapest checks that can (CHECKS BY COST below): the linter and the tests nearest the files you touched, the documentation checks for a documentation change (dependencies are already present).
+4. Commit with a clear message and push the branch with \`git push -u origin <branch>\` — before any full suite, build or full verification.
+5. Then, if the budget allows, run the project's expensive checks once and fix forward with further commits and pushes.
+6. Call the \`diff_digest\` tool to get a distilled summary of your change — per-file churn, totals, and risky-file flags. It is a distilled summary, not the raw diff: use it to shape the description you submit next — which files the Tour must walk, what belongs in risks.
+7. Call the submit_pr_description tool with the typed description object (content contract below) — every time. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with any API call.
+8. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+
+${CHECKS_BY_COST}
 
 ${NEVER_MERGE}
 
@@ -318,11 +328,14 @@ THE REPOSITORY IS ALREADY CLONED at \`/workspace/checkout\` — seeded from the
 Workflow for shipping a change:
 1. Create a branch with a descriptive name off the current branch.
 2. Implement the change. Match the surrounding code's style and conventions.
-3. Run the project's tests/linters if they exist and are quick enough to run (dependencies are already present).
-4. Commit with a clear message and push the branch with \`git push -u origin <branch>\`.
-5. Call the \`diff_digest\` tool to get a distilled summary of your change — per-file churn, totals, and risky-file flags. It is a distilled summary, not the raw diff: use it to shape the description you submit next — which files the Tour must walk, what belongs in risks.
-6. Call the submit_pr_description tool with the typed description object (content contract below) — every time. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with \`gh\` or any API call.
-7. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+3. Prove the change with the cheapest checks that can (CHECKS BY COST below): the linter and the tests nearest the files you touched, the documentation checks for a documentation change (dependencies are already present).
+4. Commit with a clear message and push the branch with \`git push -u origin <branch>\` — before any full suite, build or full verification.
+5. Then, if the budget allows, run the project's expensive checks once and fix forward with further commits and pushes.
+6. Call the \`diff_digest\` tool to get a distilled summary of your change — per-file churn, totals, and risky-file flags. It is a distilled summary, not the raw diff: use it to shape the description you submit next — which files the Tour must walk, what belongs in risks.
+7. Call the submit_pr_description tool with the typed description object (content contract below) — every time. Switchboard renders the PR body from your object at the pushed head and opens (or updates) the pull request itself: do NOT open a PR yourself, with \`gh\` or any API call.
+8. Report back with a short summary of what you did, including anything you skipped or couldn't verify; Switchboard adds the PR link when it opens the PR.
+
+${CHECKS_BY_COST}
 
 ${NEVER_MERGE}
 
@@ -504,7 +517,7 @@ Your tools work without a workspace: the GitHub tools — \`github_repos\` (the
 
 ${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.
 
-You cannot run commands, clone repositories, edit code, or review pull requests, and you cannot search the web. Other Switchboard agents can: for code changes or PRs tell the user to re-send with \`agent:coding\`; for a PR review, \`agent:review\`; for a web-research question, \`agent:research\` (e.g. "\`agent:coding fix the failing login test in acme/api\`", "\`agent:research compare X and Y\`"). Delete an issue only when the user explicitly asked to delete it (closing is an update).`;
+You cannot run commands, clone repositories, edit code, or review pull requests, and you cannot search the web. Other Switchboard agents can: for a code change or a pull request tell the user to re-send with \`agent:ship\` (it makes the change, opens the PR and loops review); for a PR review, \`agent:review\`; for a web-research question, \`agent:research\` (e.g. "\`agent:ship in acme/api: fix the failing login test\`", "\`agent:research compare X and Y\`"). Delete an issue only when the user explicitly asked to delete it (closing is an update).`;
 
 // The explore agent (docs/reference/specs/agent-explore.md): a long, read-only
 // investigation — "run our CI locally and validate the claims", "how long does
@@ -527,7 +540,7 @@ THE DELIVERABLE IS A CLAIM TABLE. Turn the request into the claims it makes or a
 
 TIME. Your budget is up to two hours — less when a boundary or the request's \`budget:\` directive clipped it, which the runtime-config block above says — and the wrap-up warning tells you when to stop starting new checks. A single command is capped at ${BASH_TIMEOUT_MAX_MS / 60_000} minutes (pass the bash tool's \`timeoutMs\`, up to ${BASH_TIMEOUT_MAX_MS} ms, for a long one). A job that needs longer — a full suite, a build, a pipeline run — is started detached and polled across tool calls: \`setsid -f sh -c '<command> > /tmp/job.log 2>&1; echo $? > /tmp/job.exit'\`, then \`tail -n 40 /tmp/job.log\` and \`cat /tmp/job.exit\` on later calls (a plain background job dies with the command that started it; a \`setsid -f\` job outlives it). Batch commands into few tool calls; never explore file by file.
 
-READ-ONLY: NEVER open a pull request, and never commit or push — no branch, no \`gh pr create\`, no PR or issue write of any kind. You hold a read credential and your job is to find out, not to change. If the investigation shows a change is needed, say exactly what and where in your write-up and point the user at \`agent:coding\`.
+READ-ONLY: NEVER open a pull request, and never commit or push — no branch, no \`gh pr create\`, no PR or issue write of any kind. You hold a read credential and your job is to find out, not to change. If the investigation shows a change is needed, say exactly what and where in your write-up and point the user at \`agent:ship\` (it makes the change, opens the PR and loops review).
 
 You cannot attach or post files: your whole answer is text. Never say a file is attached or below — name its path in the workspace and describe it (what it shows, its size) instead; a person who needs the file itself asks \`agent:coding\`, which can attach.
 
@@ -621,7 +634,7 @@ const WORK_PRESETS = {
     machine: "none",
     identity: "none",
     maxTokens: 16000,
-    ...loopBudget(5),
+    ...loopBudget("general"),
   },
   coding: {
     name: "coding",
@@ -631,7 +644,7 @@ const WORK_PRESETS = {
     seededSystem: CODING_SYSTEM_SEEDED,
     toolset: "full",
     maxTokens: 64000,
-    ...loopBudget(45),
+    ...loopBudget("coding"),
     // No built-in effort: the deployment decides (`defaults.efforts.coding`,
     // `config set channel efforts.coding=…`, or `effort:` per request).
     machine: "repo-resident",
@@ -652,7 +665,7 @@ const WORK_PRESETS = {
     machine: "repo-resident",
     identity: "read", // a read-scoped token and a read-only worktree: it cannot post or push from inside
     maxTokens: 64000,
-    ...loopBudget(25), // a safety net — typical reviews land in ~5 minutes
+    ...loopBudget("review"), // a safety net — typical reviews land in ~5 minutes
     effort: "medium", // fast turns; one big-context pass does the deep work
   },
   ship: {
@@ -681,7 +694,7 @@ const WORK_PRESETS = {
     // reviewed pull request, never code landing on main.
     maxTurns: 1,
     maxTokens: 16000,
-    maxMinutes: 120,
+    maxMinutes: ASKS.ship,
   },
   research: {
     name: "research",
@@ -692,7 +705,7 @@ const WORK_PRESETS = {
     machine: "none", // web I/O only; no workspace is provisioned
     identity: "none",
     maxTokens: 24000,
-    ...loopBudget(8),
+    ...loopBudget("research"),
     effort: "medium",
   },
   explore: {
@@ -706,7 +719,7 @@ const WORK_PRESETS = {
     machine: "repo-cold",
     identity: "read", // a read-scoped token: it can clone and read, never push — whatever the caller holds
     maxTokens: 64000,
-    ...loopBudget(120),
+    ...loopBudget("explore"),
     // No built-in effort: the deployment decides, as for coding.
   },
 } satisfies Record<string, AgentDef>;
@@ -731,7 +744,7 @@ export const AGENTS: Record<string, AgentDef> = {
     // spawn exactly those — so no child runs that the record did not name.
     routable: false,
     maxTokens: 32000,
-    ...loopBudget(120), // long enough to outlast a coding child; every child is capped by what remains of it
+    ...loopBudget("conductor"), // long enough to outlast a coding child; every child is capped by what remains of it
     // No built-in effort: the deployment decides, as for coding.
   },
 };

package/dist/assets/src/config/profile.ts

@@ -73,10 +73,40 @@ export function budgetedAgent(agent: AgentDef, profile: RunProfile): AgentDef {
 
 // ---- boundaries: a scope caps, never grants -----------------------------------
 
+/** The blast-radius classes a scope may name as its `confirm`
+ *  (docs/decisions/0044-a-routed-write-is-confirmed-in-proportion-to-its-blast-radius.md):
+ *  the first class on the ladder the door hands back instead of running.
+ *  `exec` is on the ladder for the comparison but not settable — a test or
+ *  build never asks — and `never` is refused until the door's write misbind
+ *  rate has been measured; the validator names both reasons. */
+export type ConfirmClass = "write" | "destructive";
+export const CONFIRM_CLASSES: readonly ConfirmClass[] = ["write", "destructive"];
+
+/** The classes on the door's ladder — the command registry's `BlastRadius`,
+ *  spelled here rather than imported: a type import still drags the registry's
+ *  whole graph into every program that compiles this near-leaf module, the
+ *  Workers included. The door indexes the ladder with the registry's type
+ *  (`routedRunsAtOnce`), so a class added there without a rung here fails to
+ *  compile at the one place the two vocabularies meet. */
+export type ConfirmLadderClass = "read" | "exec" | "write" | "destructive";
+
+/** The ladder the door compares on, `read < exec < write < destructive`: among
+ *  the last three, from asking most to asking least — a `confirm` of `write`
+ *  hands back every write and every destructive write, `destructive` only the
+ *  destructive ones. A read is on the order so the comparison is total, but the
+ *  door never asks for one. */
+export const CONFIRM_ORDER: Record<ConfirmLadderClass, number> = { read: 0, exec: 1, write: 2, destructive: 3 };
+
+/** The door's confirm class when no scope sets one: every routed write is
+ *  handed back, a read or a test run at once — the door as it was before the
+ *  axis existed. Attributed to `built-in`, a word that appears in no config. */
+export const BUILT_IN_CONFIRM: ConfirmClass = "write";
+
 /** A cap on the three axes that any scope may set (`defaults`, `channels.<id>`,
- *  `users.<id>`; docs/reference/specs/routing-and-config.md item 2). An absent
- *  axis caps nothing. A boundary never grants: it is not a fourth grants axis,
- *  and the policy table's one question (who may run a preset) is unchanged. */
+ *  `users.<id>`; docs/reference/specs/routing-and-config.md item 2), and the
+ *  door's `confirm` beside them. An absent axis caps nothing. A boundary never
+ *  grants: it is not a fourth grants axis, and the policy table's one question
+ *  (who may run a preset) is unchanged. */
 export interface Boundary {
   /** The most a run may have, in minutes; at least 2 (the bash tool keeps a 60 s reserve). */
   maxMinutes?: number;
@@ -84,6 +114,11 @@ export interface Boundary {
   maxIdentity?: Identity;
   /** The machine classes a run may execute on; a preset's class must be in every layer's set. */
   machines?: MachineClass[];
+  /** The first blast-radius class a command the router bound is handed back
+   *  at instead of run (record 0044). Not a run cap: it rides the boundary for
+   *  its scopes and its intersection-toward-caution, is read by the door alone
+   *  (`effectiveConfirm`), and never enters `intersectBoundaries` or a profile. */
+  confirm?: ConfirmClass;
 }
 
 /** One layer's boundary with the scope it came from, in resolution order:
@@ -143,6 +178,36 @@ export function intersectBoundaries(layers: readonly ScopedBoundary[]): Effectiv
   return out.maxMinutes || out.maxIdentity || out.machines ? out : undefined;
 }
 
+/** Where the door's confirm class came from: a scope that set it, or the
+ *  built-in default when none did. Local to the confirm axis — `BoundaryScope`
+ *  itself is unchanged, since no run cap is ever attributed to `built-in`. */
+export type ConfirmScope = BoundaryScope | "built-in";
+
+/** The door's decision on the confirm axis: the class and the scope it names. */
+export interface EffectiveConfirm {
+  value: ConfirmClass;
+  scope: ConfirmScope;
+}
+
+/**
+ * The confirm axis intersected over a request's path, apart from the run caps:
+ * the earliest class on `CONFIRM_ORDER` any layer named — the most cautious,
+ * since a scope's value is the most permissive answer it allows and the org's
+ * is therefore a floor no layer below it can loosen — attributed to the layer
+ * that set it (on a tie the first layer named keeps it, the least specific
+ * scope, as `intersectBoundaries` does). No layer set one: the built-in
+ * `write`, attributed to `built-in`. Pure over the same layers `intersectBoundaries` takes.
+ */
+export function effectiveConfirm(layers: readonly ScopedBoundary[]): EffectiveConfirm {
+  let out: EffectiveConfirm | undefined;
+  for (const { scope, boundary } of layers) {
+    if (boundary.confirm !== undefined && (!out || CONFIRM_ORDER[boundary.confirm] < CONFIRM_ORDER[out.value])) {
+      out = { value: boundary.confirm, scope };
+    }
+  }
+  return out ?? { value: BUILT_IN_CONFIRM, scope: "built-in" };
+}
+
 /**
  * The boundaries on a child's path with its parent's remaining wall clock as
  * one more layer (docs/reference/specs/routing-and-config.md item 20): the

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

@@ -83,15 +83,18 @@ interface BoundFields {
   userName?: string;
 }
 
-/** The actor id whose grants govern a chat message: the credential that
- *  authenticated it when it was bound to a person (`authenticatedAs`), else
- *  the sender. Every `canRunAgent` / `canUseRepo` / `canManageRepos` /
- *  `canEditChannelConfig` question in the dispatch path asks about THIS id,
- *  never `msg.userId`: naming the person on a run must not lend the run the
- *  person's grants (authorization.md item 15). A relayed message (`postedBy`)
- *  is out of scope here — its gates are item 14's. */
-export function grantsSubject(msg: { userId: string; authenticatedAs?: string }): string {
-  return msg.authenticatedAs ?? msg.userId;
+/** The actor every gate in the dispatch path decides on: `resolveChatActor`
+ *  over the message, with config's grants lookup. Every `canRunAgent` /
+ *  `canUseRepo` / `canManageRepos` / `canEditChannelConfig` question asks
+ *  about THIS actor, never `msg.userId`: a relayed message (`postedBy`,
+ *  authorization.md item 14) decides on the app ∩ the person, a bound
+ *  credential (`authenticatedAs`, item 15) on the credential alone — naming
+ *  a person on a run never lends the run the person's grants. */
+export function chatActorOf(
+  config: { grantsFor: GrantsLookup },
+  msg: { userId: string; channelId: string; threadKey: string; postedBy?: string } & BoundFields,
+): Actor {
+  return resolveChatActor(msg, (id) => config.grantsFor(id));
 }
 
 const CHAT_SURFACES: Readonly<Record<string, ActorSurface>> = {

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

@@ -63,6 +63,14 @@ export function principalOf(actor: Actor): Actor {
   return current;
 }
 
+/** The channels the decision's person is in: the root principal's
+ *  `memberOf`, as `selfIdsOf` reads its `self` — a fact from the channel
+ *  directory, never a grant; absent → the empty set. */
+export function memberChannelsOf(actor: Actor): ReadonlySet<string> {
+  return principalOf(actor).memberOf ?? EMPTY_SET;
+}
+const EMPTY_SET: ReadonlySet<string> = new Set();
+
 /** The ids that mean "me" for a decision (record 0042): the root principal's
  *  `self` when it carries one — its own id and the person a dashboard session
  *  is linked to — else its id alone. Never read by a grant check. */
@@ -117,6 +125,7 @@ export function evaluateCondition(
   grants: Grants,
   selfIds: readonly string[],
   attributes: ResourceAttributes,
+  memberOf: ReadonlySet<string> = EMPTY_SET,
 ): boolean {
   switch (condition.kind) {
     case "has-grant": {
@@ -124,11 +133,13 @@ export function evaluateCondition(
       return grant !== undefined && hasAction(grants.actions, grant);
     }
     case "member-of":
-      // Granted the channel, or the channel is public (a run's stamped
+      // Granted the channel, in the channel (the directory's fact on the
+      // actor), or the channel is public (a run's stamped
       // visibility). `unknown` — no stamp, a directory failure — is never
       // public: fail-closed.
       return (
-        (attributes.channelId !== undefined && holds(grants.channels, attributes.channelId)) ||
+        (attributes.channelId !== undefined &&
+          (holds(grants.channels, attributes.channelId) || memberOf.has(attributes.channelId))) ||
         attributes.channelVisibility === "public"
       );
     case "is-self":
@@ -154,7 +165,8 @@ export function evaluateRule(rule: Rule, actor: Actor, resource: Resource): bool
   if (rule.originVisibility && !rule.originVisibility.includes(attributes.visibility)) return false;
   const grants = effectiveGrants(actor);
   const selfIds = selfIdsOf(actor);
-  return rule.when.every((condition) => evaluateCondition(condition, grants, selfIds, attributes));
+  const memberOf = memberChannelsOf(actor);
+  return rule.when.every((condition) => evaluateCondition(condition, grants, selfIds, attributes, memberOf));
 }
 
 /** `authorize` over an explicit (validated) table. Tests use it to drive
@@ -173,9 +185,10 @@ export function authorizeWith(rules: readonly Rule[], actor: Actor, action: Acti
   if (forOrigin.length === 0) return deny("origin-visibility");
   const grants = effectiveGrants(actor);
   const selfIds = selfIdsOf(actor);
+  const memberOf = memberChannelsOf(actor);
   let reason: DenyReason | undefined;
   for (const rule of forOrigin) {
-    const failed = rule.when.find((condition) => !evaluateCondition(condition, grants, selfIds, attributes));
+    const failed = rule.when.find((condition) => !evaluateCondition(condition, grants, selfIds, attributes, memberOf));
     if (!failed) return ALLOW;
     reason ??= FAILURE_REASON[failed.kind];
   }

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

@@ -82,6 +82,10 @@ export const POLICY: readonly Rule[] = [
   { action: "friction:write", resource: "command", when: [grant("friction:write")] },
 
   // ── costs ────────────────────────────────────────────────────────────────
+  // `costs by` reads the snapshot's arithmetic: what every browser session
+  // holds (every group's read) and what a Slack user or a token is granted —
+  // never a chat baseline, since a by-user table names who spent what.
+  { action: "costs:read", resource: "command", when: [grant("costs:read")] },
   // `costs snapshot` reads both billing providers and replaces what every
   // viewer of the costs page sees: the grant, never a baseline (the admins'
   // `all` and a named `grants` entry hold it).

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

@@ -57,6 +57,15 @@ export interface Actor {
   readonly self?: readonly string[];
   /** The linked person, for display and the audit line (`asUser`); absent when unlinked. */
   readonly asUser?: { readonly id: string; readonly name?: string };
+  /**
+   * The channels the platform says the actor's person is in: the
+   * channel directory's `channelsOf`, resolved once with the actor — a fact
+   * about the person, never a grant from config. `member-of` reads it beside
+   * `grants.channels`, so a private channel's runs and config open to the
+   * people in it. Absent (no directory, a lookup failure, an unlinked session)
+   * → nothing: fail-closed, exactly today's behaviour.
+   */
+  readonly memberOf?: ReadonlySet<string>;
 }
 
 /** `<group>:<read|write|exec>` plus the non-command actions. A plain
@@ -184,4 +193,7 @@ export type Predicate =
 export interface ChannelDirectory {
   info(channelId: string): Promise<{ visibility: ChannelVisibility }>;
   isMember(actorId: string, channelId: string): Promise<boolean | "unknown">;
+  /** Every channel the actor is in, platform-namespaced — what the resolver puts on
+   *  `Actor.memberOf`; `unknown` when the adapter cannot say (fail-closed). */
+  channelsOf(actorId: string): Promise<ReadonlySet<string> | "unknown">;
 }