@coreplane/switchboard 1.240.0 → 1.242.0

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

@@ -87,8 +87,10 @@ import {
   SEED_ABANDONED_RESTORE_WAIT_MS,
   seedFixupScript,
   seedMarkerText,
+  type RestorePhases,
   type SandboxSeed,
   type SeedAnswer,
+  type SeedPhases,
   type SeedStep,
 } from "../../src/execution/seedPlan.js";
 import { shellQuote } from "../../src/execution/shellQuote.js";
@@ -450,12 +452,13 @@ export class SwitchboardSandbox extends Sandbox<Env> {
       // marker for another handle.
       await this.runRoot(["sh", "-c", `${unmountAllRestoresScript()}\n${this.seedSweep()}`], 60_000);
       let t = systemClock();
-      await this.restoreSeedInto(seed.checkoutBackupId, SEED_CHECKOUT_DIR, deadline, "checkout");
+      const checkout = await this.restoreSeedInto(seed.checkoutBackupId, SEED_CHECKOUT_DIR, deadline, "checkout");
       steps.restore = systemClock() - t;
+      const phases: SeedPhases = { checkout, deps: null };
       if (seed.depsBackupId) {
         step = "deps";
         t = systemClock();
-        await this.restoreSeedInto(seed.depsBackupId, SEED_DEPS_STAGING_DIR, deadline, "deps");
+        phases.deps = await this.restoreSeedInto(seed.depsBackupId, SEED_DEPS_STAGING_DIR, deadline, "deps");
         steps.deps = systemClock() - t;
       }
       step = "fixup";
@@ -480,9 +483,27 @@ export class SwitchboardSandbox extends Sandbox<Env> {
       );
       const ms = systemClock() - t0;
       console.log(
-        JSON.stringify({ event: "sandbox.seeded", slug: seed.slug, ref: seed.fetchRef ?? seed.ref, sha, steps, ms }),
+        JSON.stringify({
+          event: "sandbox.seeded",
+          slug: seed.slug,
+          ref: seed.fetchRef ?? seed.ref,
+          sha,
+          steps,
+          phases,
+          ms,
+        }),
       );
-      return { seeded: true, cached: false, slug: seed.slug, ref: seed.fetchRef ?? seed.ref, sha, from, steps, ms };
+      return {
+        seeded: true,
+        cached: false,
+        slug: seed.slug,
+        ref: seed.fetchRef ?? seed.ref,
+        sha,
+        from,
+        steps,
+        phases,
+        ms,
+      };
     } catch (err) {
       const shape = thrownShape(err);
       // A half seed never survives either: the run that follows goes cold
@@ -510,7 +531,12 @@ export class SwitchboardSandbox extends Sandbox<Env> {
    *  a staging sibling, the wait is judged by bytes arriving (the SDK's call
    *  takes no timeout) against the seed's one deadline, then the extract
    *  script puts a real tree in place and the target appears last. */
-  private async restoreSeedInto(id: string, targetDir: string, deadlineMs: number, what: string): Promise<void> {
+  private async restoreSeedInto(
+    id: string,
+    targetDir: string,
+    deadlineMs: number,
+    what: string,
+  ): Promise<RestorePhases> {
     const attempt = crypto.randomUUID().slice(0, 8);
     const mountDir = restoreMountDir(targetDir, attempt);
     const backup: DirectoryBackup = { id, dir: mountDir };
@@ -535,11 +561,18 @@ export class SwitchboardSandbox extends Sandbox<Env> {
       const verdict = judgeRestoreProgress({ startedMs, nowMs: systemClock(), samples, deadlineMs });
       if (verdict.verdict !== "wait") throw new Error(`${what} restore ${verdict.verdict}: ${verdict.detail}`);
     }
+    const download = systemClock() - startedMs;
+    const extractStartedMs = systemClock();
     const r = await this.runRoot(
       ["sh", "-c", extractRestoreScript({ mountDir, backupId: id, archivePath: restoreArchivePath(id), targetDir })],
       Math.max(60_000, deadlineMs - systemClock()),
     );
     if (r.exitCode !== 0) throw new Error(`${what} extract exited ${r.exitCode}: ${tail(r.stderr || r.stdout)}`);
+    const extract = systemClock() - extractStartedMs;
+    console.log(
+      JSON.stringify({ event: "sandbox.seed-restore", what, id, download, extract, method: r.stdout.trim() }),
+    );
+    return { download, extract };
   }
 
   /** Restores this object started that have not settled: what a failure

package/dist/assets/deploy/secrets.manifest.json

@@ -40,6 +40,12 @@
       "optional": true,
       "note": "JSON bearer→identity map for POST /ingress and POST /mcp: `{ subject, channel?, email? }` per entry. Self-minted (openssl rand -hex 32 per entry). Optional: without it /ingress and /mcp are disabled and `deploy restart` has no bearer. The `cron` entry fires schedules; a `coordinator` entry (granted `coordinator:step`) is the ship coordinator's, rotated apart from cron. An `email` binds the token to a person: their runs, their grants untouched (authorization.md item 15)."
     },
+    {
+      "name": "GITHUB_WEBHOOK_SECRET",
+      "workers": ["bot"],
+      "optional": true,
+      "note": "GitHub webhook signing secret for POST /webhooks/github (the check-run intake). Set the same value on the repo's webhook. Optional: without it the intake answers 503 disabled and the merge wait falls back to its bounded timeout."
+    },
     {
       "name": "SANDBOX_TOKEN",
       "workers": ["bot", "sandbox"],

package/dist/assets/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "switchboard",
-  "version": "1.240.0",
+  "version": "1.242.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "switchboard",
-      "version": "1.240.0",
+      "version": "1.242.0",
       "license": "Apache-2.0",
       "workspaces": [
         "web",
@@ -20445,7 +20445,7 @@
     },
     "packages/switchboard": {
       "name": "@coreplane/switchboard",
-      "version": "1.240.0",
+      "version": "1.242.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.240.0",
+  "version": "1.242.0",
   "private": true,
   "description": "Mention it in Slack and an agent reviews the PR, ships the fix, or answers the question — on the model you choose, with its tools running where you decide.",
   "license": "Apache-2.0",

package/dist/assets/project.json

@@ -204,11 +204,11 @@
       "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": {

package/dist/assets/source.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.240.0",
-  "commit": "dd69a6edcfaa523c998ff1059f47b8ef1675ebe9",
-  "builtAt": "2026-09-17T00:22:24.645Z"
+  "version": "1.242.0",
+  "commit": "c0dc26a1590c854d944c451829e9b21f6ce7d721",
+  "builtAt": "2026-09-17T05:42:17.412Z"
 }

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

@@ -133,6 +133,23 @@ export interface AgentDef {
 // and rendered against the head sha at render time, so a repush is a
 // re-render by Switchboard — the agent only resubmits when the CONTENT (line
 // numbers included) changed.
+/** The status-card rule every tool-running preset carries (docs/reference/specs/run-visibility.md
+ *  item 2). One sentence in one place: the card shows the command running right
+ *  now beside the checklist, so the checklist's markers must be facts — ✱ from
+ *  the item's first command, ✓ only once its result has been read — or the two
+ *  contradict each other on the card. `examples` are the preset's own outcome
+ *  phrasings; the rule itself never varies by preset. */
+export function statusCardRule(examples = '"Implement the fix", "Run the test suite"'): string {
+  return (
+    "Maintain the user-facing status card with the update_status tool. Post your plan as a checklist (○ pending) as soon as you have it, " +
+    "then keep it truthful at every moment: the markers are facts, not intentions. Mark an item ✱ when you issue the first command that does it, " +
+    "and ✓ only after you have read the result that proves it happened — never in the same turn as the command, never because you intend to run it next, " +
+    "never for a reporting or posting step you have not done. The order is: mark the item ✱, run its commands, read the result, then mark it ✓ and the next item ✱. " +
+    "The card shows the command running right now beside your checklist, so a ✓ item whose command is still running reads as a lie. " +
+    `Items are short outcomes (${examples}), never commands. This is the only progress the user sees while you work.`
+  );
+}
+
 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.
 - **title**: the PR title — one line naming the change, specific enough to pick out of a PR list.
@@ -206,6 +223,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}
@@ -220,10 +245,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}
 
@@ -237,7 +265,7 @@ ${SHOW_FILES}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: right after you decide your plan, post it as a checklist (○ pending items), then update it whenever an item starts (✱) or finishes (✓). Items are short outcomes ("Clone repo and read the diff", "Run the test suite"), never commands. Mark an item ✓ only after it has actually happened — never pre-mark reporting/posting steps. This is the only progress the user sees while you work.
+${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.
@@ -262,11 +290,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}
 
@@ -280,7 +311,7 @@ ${SHOW_FILES}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: right after you decide your plan, post it as a checklist (○ pending items), then update it whenever an item starts (✱) or finishes (✓). Items are short outcomes ("Implement the fix", "Run the test suite"), never commands. Mark an item ✓ only after it has actually happened — never pre-mark reporting/posting steps. This is the only progress the user sees while you work.
+${statusCardRule()}
 
 Report outcomes faithfully: if tests fail or a step was skipped, say so plainly.
 ${FENCED_CONTENT_RULE}
@@ -301,11 +332,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}
 
@@ -319,7 +353,7 @@ ${SHOW_FILES}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: right after you decide your plan, post it as a checklist (○ pending items), then update it whenever an item starts (✱) or finishes (✓). Items are short outcomes ("Implement the fix", "Run the test suite"), never commands. Mark an item ✓ only after it has actually happened — never pre-mark reporting/posting steps. This is the only progress the user sees while you work.
+${statusCardRule()}
 
 Report outcomes faithfully: if tests fail or a step was skipped, say so plainly.
 ${FENCED_CONTENT_RULE}
@@ -384,7 +418,7 @@ ${REVIEW_VERDICT_INSTRUCTION}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: post your plan as a checklist (○ pending), update as items start (✱) and finish (✓ — only after they actually happened; never pre-mark reporting steps). Items are short outcomes, never commands.
+${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
@@ -417,7 +451,7 @@ ${REVIEW_VERDICT_INSTRUCTION}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: post your plan as a checklist (○ pending), update as items start (✱) and finish (✓ — only after they actually happened; never pre-mark reporting steps). Items are short outcomes, never commands.
+${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
@@ -451,7 +485,7 @@ ${REVIEW_VERDICT_INSTRUCTION}
 
 ${NOTEPAD}
 
-Maintain the user-facing status card with the update_status tool: post your plan as a checklist (○ pending), update as items start (✱) and finish (✓ — only after they actually happened; never pre-mark reporting steps). Items are short outcomes, never commands.
+${statusCardRule('"Gather the diff and the files", "Analyze the change", "Post the verdict"')}
 
 ${FENCED_CONTENT_RULE}
 Your final message is posted to Slack. Lead with a one-line verdict, then the findings.`;
@@ -469,7 +503,7 @@ How to work:
 2. Prefer primary sources; corroborate a surprising claim with a second source.
 3. Answer concisely and cite the URLs (or repo paths) you used. If sources conflict or you couldn't verify something, say so plainly. If web search is unconfigured, use web_fetch / the GitHub tools on what you have and say search was unavailable.
 
-Maintain the user-facing status card with the update_status tool: post a short checklist (○ pending) after you plan, and update items as they start (✱) and finish (✓ — only once they actually happened).
+${statusCardRule('"Search the sources", "Write the answer"')}
 
 ${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.`;
@@ -485,6 +519,8 @@ Answer directly and concisely. Use Slack-friendly formatting (no markdown header
 
 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.
 
+${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).`;
 
 // The explore agent (docs/reference/specs/agent-explore.md): a long, read-only
@@ -512,7 +548,7 @@ READ-ONLY: NEVER open a pull request, and never commit or push — no branch, no
 
 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.
 
-Maintain the user-facing status card with the update_status tool: post your plan as a checklist (○ pending) once you have it, and update items as they start (✱) and finish (✓ — only after they actually happened). Items are short outcomes ("Clone and install", "Time the full suite"), never commands.
+${statusCardRule('"Clone and install", "Time the full suite"')}
 
 ${NOTEPAD}
 

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>> = {
@@ -100,6 +103,11 @@ const CHAT_SURFACES: Readonly<Record<string, ActorSurface>> = {
   mcp: "mcp",
   cli: "cli",
   schedule: "schedule",
+  // The web chat (record 0043): a browser session speaks as text, so its
+  // `access:<sub>` is a chat credential too — the browser actor, its baseline
+  // and its entry. A service token never reaches the chat (the dashboard gate
+  // serves it `/api/*` only), so `access:svc:` is no chat surface.
+  access: "access-browser",
 };
 
 /** A chat message's `userId` is already namespaced by its adapter (`slack:U…`,

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/grants.ts

@@ -62,10 +62,20 @@ export const CHAT_OPEN_ACTIONS: readonly string[] = [
   "mcp:write",
 ];
 
-/** What an Access browser session holds implicitly: every registered
- *  group's read — never a write, never an exec. */
-export function browserReadActions(commandGroups: readonly string[]): Set<string> {
-  return new Set(commandGroups.map((g) => `${g}:read`));
+/** The two writes a browser session holds beside its reads (record 0043): the
+ *  same personal writes every Slack user holds (`CHAT_OPEN_ACTIONS`), because
+ *  the web chat makes a browser session a chat user — `memory remember` and
+ *  `mcp add` for its own tier. The tier rows still decide the target: a shared
+ *  tier needs the grant it always needed. */
+export const BROWSER_WRITE_ACTIONS: readonly string[] = ["memory:write", "mcp:write"];
+
+/** What an Access browser session holds implicitly: every registered group's
+ *  read plus the two personal chat writes — never another write, never an exec.
+ *  No groups known (a process that registered no commands) → nothing at all,
+ *  fail-closed: the writes ride with the catalogue they belong to. */
+export function browserActions(commandGroups: readonly string[]): Set<string> {
+  if (commandGroups.length === 0) return new Set();
+  return new Set([...commandGroups.map((g) => `${g}:read`), ...BROWSER_WRITE_ACTIONS]);
 }
 
 // ---- the native `grants` block ----------------------------------------------
@@ -243,8 +253,9 @@ export interface GrantsTable {
   surfaces: Map<string, Grants>;
   /** What every `slack:` user holds, listed or not: the open chat commands and `agent:run:<name>` for every unrestricted agent. */
   everyone: Grants;
-  /** What every Access browser session (`access:<sub>`, never `access:svc:`) holds: each registered group's read. */
-  browserReads: Grants;
+  /** What every Access browser session (`access:<sub>`, never `access:svc:`) holds:
+   *  each registered group's read and the two personal chat writes. */
+  browser: Grants;
   restrict: Restriction;
 }
 
@@ -253,9 +264,9 @@ export interface GrantsTable {
  *  `<group>:read`. Every other namespace (`schedule:`, `access:svc:`, `http:`,
  *  `mcp:`) is a credential or a job that holds exactly what names it — an
  *  unlisted one is `NO_GRANTS` (fail-closed). */
-export function namespaceBaseline(actorId: string, table: Pick<GrantsTable, "everyone" | "browserReads">): Grants {
+export function namespaceBaseline(actorId: string, table: Pick<GrantsTable, "everyone" | "browser">): Grants {
   if (actorId.startsWith("slack:")) return table.everyone;
-  if (actorId.startsWith("access:") && !actorId.startsWith("access:svc:")) return table.browserReads;
+  if (actorId.startsWith("access:") && !actorId.startsWith("access:svc:")) return table.browser;
   return NO_GRANTS;
 }
 
@@ -271,7 +282,7 @@ export function grantsTable(source: GrantsSource): GrantsTable {
   const openAgents = (source.agentNames ?? []).filter((a) => !restrict.agents.has(a)).map(agentRunAction);
   const baselines = {
     everyone: { ...NO_GRANTS, actions: new Set([...CHAT_OPEN_ACTIONS, ...openAgents]) },
-    browserReads: { ...NO_GRANTS, actions: browserReadActions(source.commandGroups ?? []) },
+    browser: { ...NO_GRANTS, actions: browserActions(source.commandGroups ?? []) },
   };
   const grants = new Map<string, Grants>();
   const surfaces = new Map<string, Grants>();

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">;
 }

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

@@ -80,6 +80,22 @@ export function runFinishedEventType(runId: string): string {
   return `${RUN_FINISHED_EVENT_PREFIX}${runId}`;
 }
 
+/** The event the bot's GitHub check-run intake sends a merge-waiting parent:
+ *  the type carries the head sha (hex — inside the platform's alphabet), so a
+ *  driver waiting at that head matches its own event and any other head's is
+ *  buffered harmlessly. */
+export const CHECKS_SETTLED_EVENT_PREFIX = "checks-settled-";
+export function checksSettledEventType(headSha: string): string {
+  return `${CHECKS_SETTLED_EVENT_PREFIX}${headSha}`;
+}
+
+/** What the checks-settled event carries — the head and a clock; the parent
+ *  re-asks the merge door before it acts, so nothing more rides here. */
+export interface ChecksSettledPayload {
+  headSha: string;
+  settledAt: number;
+}
+
 /** What the event carries — ids, a status and a clock; the parent confirms
  *  through `read-record` before it acts, so nothing more rides here. */
 export interface RunFinishedPayload {
@@ -134,6 +150,8 @@ export interface CoordinatorInstance {
   /** The bound credential behind the person (authorization.md item 15), when
    *  there was one: every child is authorized under ITS grants, as the request was. */
   authenticatedAs?: string;
+  /** The app that relayed the request for the person (authorization.md item 14), when one did: every child is authorized under app ∩ person, as the request was. */
+  postedBy?: string;
   channelId: string;
   channelName?: string;
   /** The requesting thread: where the card lives and where a generated plan's
@@ -244,7 +262,7 @@ export function isCoordinatorInstance(v: unknown): v is CoordinatorInstance {
   if (r.kind !== "ship") return false;
   if (!isText(r.userId) || !isText(r.channelId) || !isText(r.threadKey)) return false;
   if (!isOptionalText(r.userName) || !isOptionalText(r.channelName) || !isOptionalText(r.sourceUrl)) return false;
-  if (!isOptionalText(r.authenticatedAs)) return false;
+  if (!isOptionalText(r.authenticatedAs) || !isOptionalText(r.postedBy)) return false;
   if (typeof r.repo !== "string" || !REPO_SLUG.test(r.repo)) return false;
   if (!isText(r.branch) || !isOptionalText(r.base)) return false;
   if (!isFinite(r.createdAt)) return false;
@@ -310,6 +328,27 @@ export type RunFinishedSend =
   | { kind: "no-binding"; instance: string }
   | { kind: "failed"; instance: string; type: string; reason: string };
 
+/** The one send per settled head (http-ingress.md item 12): best effort like
+ *  `sendRunFinished` — a refusal is answered, never thrown, and the parent's
+ *  bounded merge wait times out on its own. */
+export async function sendChecksSettled(
+  workflow: WorkflowSender | undefined,
+  instance: string,
+  headSha: string,
+  settledAt: number,
+): Promise<RunFinishedSend> {
+  if (!workflow) return { kind: "no-binding", instance };
+  const type = checksSettledEventType(headSha);
+  const payload: ChecksSettledPayload = { headSha, settledAt };
+  try {
+    const handle = await workflow.get(instance);
+    await handle.sendEvent({ type, payload });
+    return { kind: "sent", instance, type };
+  } catch (err) {
+    return { kind: "failed", instance, type, reason: err instanceof Error ? err.message : String(err) };
+  }
+}
+
 /** The one send per committed terminal record (run-history item 47). */
 export async function sendRunFinished(
   workflow: WorkflowSender | undefined,