toolroll 0.9.75 → 0.9.77

package/CHANGELOG.md

@@ -1,5 +1,246 @@
 # Changelog
 
+## 0.9.77 — 2026-10-29
+
+- **CI finishes in about a third of the time.** The unit suite runs in four
+  shards per Node version instead of one 14–21 minute job. The required
+  checks keep their names ("node 22 · ubuntu-latest", "node 24 ·
+  ubuntu-latest") and pass only when every shard passed on the tested commit
+  and the shards together ran every test file once, so main's branch
+  protection needs no change. A flaky shard reruns in minutes, not twenty.
+- **The release check's real-model journeys start sooner.** They run in the
+  browser lanes as soon as the scripted journeys end, instead of also waiting
+  for the unit suite; the check's load budget is unchanged.
+- **An automatic release checks while CI runs.** With "Approve automatically
+  when checks pass" on, the release files its task and runs its check beside
+  CI instead of after it. Toolroll approves it only once every pull request
+  check passed on the commit.
+- **A release asks for your approval while CI runs.** `toolroll release` files
+  the release task and asks you right away instead of waiting for GitHub's
+  checks; after you approve, the release check runs beside CI. The approval
+  says "GitHub's checks are still running; nothing deploys until they pass."
+  Nothing is deployed, merged, tagged or published until every required check
+  passed on the exact commit, read again right before the deploy; if one
+  fails, the release stops before the deploy. A check that already failed
+  still stops the release before anyone is asked.
+- **The console stays responsive while builds and checks run.** `toolroll up`
+  now runs two processes: the console (pages, sign-in and approvals) and the
+  worker (builds, checks, follow-ups and housekeeping). On a copy of a real
+  database, the slowest console answer during a heavy check fell from about
+  5–6 seconds to under 0.3 seconds. A worker that crashes is started again
+  and recovers its interrupted work as a restarted `up` does; a stop still
+  lets running builds finish first. A running check's progress is saved at
+  most once a second, and its final result at once. `--single-process` keeps
+  the old one-process layout.
+- **Console pages open faster and stay quick while work runs.** The sidebar,
+  the Tasks count and the crew list are read once per database change for each
+  person instead of up to four times per page, and before a page is drawn they
+  are read on a background thread so the console keeps answering meanwhile.
+  The chat landing's lists are kept the same way, and the task page reuses its
+  "behind main" line for 15 seconds instead of asking Git twice per view. On a
+  copy of a real database: /board 348 → 26 ms, /agents 320 → 4 ms, /chat 905 →
+  19 ms, a task page 1.5 s → 0.2 s; with the database changing 40 times a
+  second, pages take 0.27–0.47 s and the console answers other requests in
+  about 1 ms (before: 0.35 s typical, up to 1.4 s). A page that re-reads after
+  a live update gets "unchanged" when nothing it shows changed.
+- **Fixes from the first review of the above.** CI's required checks now
+  judge the shards with the verifier from the base branch, run none of the
+  change's code, and fail when a shard executed no tests, its counts don't
+  add up, or it skips tests the base always ran; a required check counts only
+  from the CI workflow, never a same-named job elsewhere. A release filed
+  while CI runs can't be approved by anyone until Toolroll itself saw CI pass,
+  and you're asked only then. A worker that crashes while a removed project is
+  still finishing recovers that project's work before anything new starts. A
+  deploy waits until the console and the worker have both exited. A worker or
+  console that refuses to start again stops `toolroll up` instead of
+  restarting forever. A check's final progress is kept until it's saved.
+
+
+- **Sandboxed commands no longer hang on macOS 26.5.** The fence denies most
+  macOS system services and, by default, asked macOS to report each denial; on
+  macOS 26.5.2 about one denied lookup in 70 never returned while that report
+  was made, so a sandboxed `npm ci`, `npm pack` or any Node program setting up
+  DNS could hang forever (a release carry until its 20-minute timeout). Denials
+  are now made without the report; nothing the fence allows or denies changed.
+- **The console is fast again.** 0.9.76's release-approval setting was read by
+  walking a project's whole action ledger once per task row, and every page's
+  sidebar runs that list four times, so each page blocked the console for about
+  3 seconds (more with tabs open while anything builds). It now reads the
+  setting rows through an existing index: pages went from about 2 s to about
+  0.4 s on a real database. Sizing build checkouts every half hour no longer
+  freezes the console either.
+- **A release check's result is always saved.** The release check's streamed
+  part lines now carry a tag no Toolroll version misreads as a journey's own
+  line; an older console counted them twice, built a progress snapshot it then
+  refused, and the refusal stopped the check's log and result from being saved
+  (the check read as "unavailable"). A progress update that fails to save can
+  no longer stop sealing, and a result that can't be saved says so on the run.
+- **A renamed or dropped CI job no longer hides its failure.** Every failed
+  attempt on a commit is judged before newer runs replace older ones, so a
+  job a newer run renamed or dropped can't erase a test failure from an
+  automatic approval. The Windows containment repeat job keeps one name
+  whatever its count.
+- **Toolroll decides what a Full release check owes.** Before the check runs,
+  Toolroll works out from its own record of the last release which parts it
+  owes (units, scripted and real-model journeys, upgrades), seals that, and
+  tells the check, which runs at least those. Every owed part needs a result,
+  whatever the check's report says it selected. CI never stands in for a
+  release's unit suite, and a journey or upgrade run that listed nothing it
+  ran is no result.
+- **Missing evidence is unknown, not clean.** What passed only on a retry is
+  sealed in the check's receipt. If a check's report is lost or damaged, its
+  retries are unknown and nothing approves itself; the receipt's report and
+  inventory files are checked byte for byte. A check that passed only when
+  rerun after the approved setup counts as a retry, and the setup rerun only
+  happens when the check never started.
+- **Merging checks main on GitHub itself.** A release reads main's head and
+  compares the branch through GitHub's API, never a local ref, and reads
+  main again right before merging. Releases approve themselves only while
+  main's branch protection requires branches to be up to date before
+  merging; without it, a person's release says which setting to turn on.
+  Toolroll only reads that setting.
+- **No lazy fetch on any supported git.** Protected Git reads (the release's
+  object reader and extraction, project knowledge and learning, the task
+  base, release coverage, review screenshots, grants) run through a frozen
+  copy of the repository's config on every git version, refuse every
+  network transport and are time-bounded, so an include, a partial clone or
+  a planted filter can't fetch, run or hang anything. The deployment script
+  reads a commit's files with no filter or attribute applied. CI's oldest-git
+  lane now tests git 2.41.0 exactly.
+- **Main's protection must actually hold.** A release now reads main's whole
+  branch protection and rulesets and counts them only when they require
+  branches to be up to date, require the release's CI checks, and can't be
+  bypassed by the account that merges ("Do not allow bypassing the above
+  settings"; no ruleset bypass for a role, team, app or organization admin).
+  A person's release names exactly what is missing, and says which new CI
+  checks main's protection doesn't require yet.
+- **Deployment reads only verified objects, with none of the repository's
+  config.** The deployment script hashes the commit and every tree as well
+  as every file against their ids, and runs git on a copy of the
+  repository's layout with a config of its own, so a corrupted tree, a
+  config change mid-read or a custom transport helper can't substitute files
+  or fetch anything.
+- **An unreadable last release never shrinks a check.** When the last
+  release Toolroll recorded can't be verified, the release check doesn't
+  run and says so, and the release card's change list reads "couldn't be
+  read", instead of acting as if there were no previous release.
+- **Setup recovery needs proof the check never started.** The approved setup
+  reruns a check only when Toolroll itself found the check's program missing
+  before starting it and the shell said exactly that and nothing else. Any
+  other failure is the check's own result for a person to judge, and a
+  release after a setup rerun says why the first attempt failed.
+- **Dispatch and coding handoffs can't be held up by a project's Git
+  config.** The worktree binding reads Git's registry as plain files, and the
+  handoff's branch read is bounded and runs outside its database
+  transactions.
+- **A release check that's cut short still leaves its evidence.** Every
+  part of the release check (typecheck, build, units, journeys, upgrades)
+  now prints its output as it runs, each line tagged with its part (and
+  upgrade version), instead of only at the very end. Each part's end is
+  recorded with its start time, exit code, signal, timeout and whether it
+  was stopped, and a failing upgrade version's own log is printed the moment
+  it fails. Release check 3261 was stored as "exit 1" with nothing but its
+  header: a signal had ended it, the plane recorded the signal as a plain
+  exit 1, and the parts' output was still waiting to be printed. A command
+  ended by a signal, or by Toolroll's own shutdown, now says so.
+- **No complete result, no pass.** A release's Full check counts only with
+  its valid report (carrying that run's secret), a result for every part,
+  unit file, journey group and upgrade version it owed, and a successful
+  exit. A missing, malformed, cut-short or incomplete report is an error
+  ("no result"), never a pass.
+- **Failures are classed, and only Toolroll's own infrastructure is rerun.**
+  The flat "two flakes" allowance is gone. A failing test, typecheck, build,
+  attack test or upgrade is never rerun to pass: fix the branch. A failure
+  Toolroll itself confirms as infrastructure (the check never started, the
+  worker lost the build, Toolroll's shutdown stopped it, or a GitHub job
+  whose runner failed before any of its steps ran) is checked again on the
+  same commit under the same approval, at most once per incident and twice
+  per commit, with no new approval. An unexplained failure blocks: a
+  diagnostic rerun may run, but its pass doesn't erase the failure, so you
+  decide. Real-model journeys are counted, never rerun until they pass, and
+  one that passed only on a retry is now reported (an automatic approval
+  won't approve it). `toolroll release` says which of these happened and
+  what to do next, instead of always asking for `--new`.
+- **A password that starts with "--" works on the command line.** About one
+  minted password in 4096 began with "--", and `toolroll release publish-ok`
+  (and other commands) read it as a missing value. A `--token` or
+  `--password` value is now always the next argument, `--token=<value>`
+  works everywhere, and new passwords, invites and tokens never start with
+  "-".
+- **CI tests the commit a release trusts.** Every pull-request job now checks
+  out the pull request's own head commit, not the merge commit GitHub makes,
+  and proves it before building.
+- **Git 2.41 or newer is required, and tested.** Toolroll's hardened git reads
+  need `git --attr-source`, which arrived in git 2.41. `toolroll up`, `serve`
+  and `watch` won't start on an older git, and `toolroll doctor` names it,
+  each with the installed and the required version. Git 2.41 to 2.44 has no
+  `--no-lazy-fetch`: there Toolroll leaves it out and instead refuses a
+  project that is a partial clone for protected reads ("this project is a
+  partial clone; protected reads need git 2.45 or newer"), judged from the
+  frozen copy of the config git then runs with (never checked, then run),
+  and every read still refuses all network protocols.
+  Two CI jobs run the git attack and worktree tests on git 2.41 and 2.47, as
+  an unprivileged user, fail if any test is skipped, and are now required
+  for a release.
+- **A release branch must contain main.** CI tests the pull request's own
+  commit, so `toolroll release` refuses a branch that doesn't contain main's
+  head ("the branch is behind main; update it and push"), at the gate before
+  anything is filed and again right before the merge.
+- **Tests can't lean on a guessed git identity.** Each test's home tells git
+  never to guess a name and email from the host, so a test that commits
+  without setting one fails on a Mac just as it would on Linux CI.
+- **Two timing-sensitive tests now wait for events.** The read-worker test and
+  the watch recovery test no longer fail when a busy machine runs slowly.
+
+## 0.9.76 — 2026-10-28
+
+- **Releases can approve themselves when they're green.** A new per-project
+  setting, **Release approval: Ask me / Approve automatically when checks
+  pass**, is off by default. Turning it on takes your typed password;
+  turning it off takes one click and withdraws every automatic approval not
+  yet merged. When it's on, a release task first reads "Checking
+  automatically" (`auto-check`), which lets its release check run and
+  nothing else. Once GitHub CI and the release check both pass on the exact
+  candidate, it approves itself (`auto-green`) and the release continues as
+  after your yes. You're told, not asked.
+- **What an automatic approval must prove.** Up to two failed attempts per
+  CI job, and two failed release-check builds on the same commit, are
+  tolerated as flakes. Past that it asks you. The change must touch only
+  allowed paths: product code and its tests, test files under `test/`,
+  docs, the changelog and a version-only `package.json` bump. Scripts, CI,
+  configuration, dependencies, policy files and test helpers (found from the
+  tests' own imports) need a person. CI is read again before the deploy, the
+  CLI switch, the merge and the tag. Anything not green stops the release,
+  withdraws the approval and tells you.
+- **A red CI after the merge holds publishing.** No tag, npm publish or
+  Homebrew update happens until a person runs
+  `toolroll release publish-ok <task>` with their password.
+- **Stricter CI verdicts on every release, yours too.** Only checks on the
+  exact head count. Required checks must come from GitHub Actions, so
+  another app's same-name success can't hide a failure. A newer run of the
+  same workflow supersedes its older runs on the commit.
+- **Toolroll's own git on agent checkouts runs against a frozen view.**
+  Every git command the plane runs on a checkout an agent wrote (staging,
+  committing, cleanup, pool refresh, scouts, planners, coding sessions, page
+  reads) runs against a private copy of the repository's settings taken
+  once. Changes the agent makes to them afterwards are never read.
+- **Git settings are denied by default.** Only audited config sections and
+  variables pass. Aliases, URL rewrites that reach remote helpers, empty
+  filter names and `hook.*` are refused. Writes allow no network transport.
+  Local git-lfs installs still work.
+- **Writes are bound to the project's recorded repository.** A checkout
+  whose `.git` points anywhere else is refused. Before git writes through a
+  view, every path it could write is walked for links and hard links. Plane
+  git writes on one checkout run one at a time. On git before 2.48, a
+  checkout added through the view is pointed at its repository, not at the
+  view.
+- **A git incident is recorded and you're notified.** A swap seen after git
+  ran is logged and raised as an attention notification. The notification
+  names the project by Toolroll's own record, never by a path the agent
+  chose.
+- **`discover --dirty` reads repositories through the same hardened git.**
+- Database: schema v136 (unchanged).
+
 ## 0.9.75 — 2026-10-27
 
 - **Opening a page only shows it.** Pages no longer run checks, tidy up or

package/README.md

@@ -34,7 +34,7 @@ npx toolroll up
 ```
 
 That starts the app and a builder for your projects, then opens the console
-at http://127.0.0.1:4180. Runs on macOS or Linux with Node.js 22.13+ and git.
+at http://127.0.0.1:4180. Runs on macOS or Linux with Node.js 22.13+ and git 2.41+.
 Try the sandbox first with `npx toolroll demo`: ask its scripted lead for a
 change in Chat, approve the plan, and watch it land Ready. It never calls a
 model, spends or reaches outside.
@@ -275,9 +275,16 @@ npx toolroll up --project-root ~/Projects    # or: bunx toolroll up
 
 That is the install and the setup. It needs Node 22.13 or newer on the
 machine (Bun's runtime has no `node:sqlite`; `bunx` hands the shebang to
-Node, so it works too). `npm install -g toolroll` gives you the
-bare `toolroll` command for later (`standing-orders`, the older name, still
-works).
+Node, so it works too), and git 2.41 or newer: Toolroll reads agent-written
+checkouts with `git --attr-source`, which older git refuses, and `toolroll
+up`, `serve`, `watch` and `doctor` say so when the installed git is older.
+Ubuntu 24.04 ships 2.43, which works; Debian 12 ships 2.39: install a newer
+one there. On git older than 2.45 (no `git --no-lazy-fetch`), a project that
+is a partial clone (`git clone --filter=…`) is refused for Toolroll's
+protected reads: use git 2.45 or newer for those, or a full clone. CI runs
+the git tests on 2.41 and on 2.47.
+`npm install -g toolroll` gives you the bare `toolroll` command for later
+(`standing-orders`, the older name, still works).
 
 `up` prints your login once (and saves it beside the database as
 `up-login.txt`), opens the app in your browser, and connects this machine as

package/THIRD_PARTY_NOTICES.md

@@ -247,14 +247,14 @@ limitations under the License.
 
 ## shadcn/ui — MIT
 
-Button and Dialog composition in `src/browser/ui/primitives.tsx` adapts:
+Dialog composition in `src/browser/ui/primitives.tsx` adapts:
 https://github.com/shadcn-ui/ui/tree/a87a63b2ca25143d26c8bd0903e4e9bc77b3f824/apps/v4/registry/new-york-v4/ui
 
 Source inspected 20 September 2026, revision
-`a87a63b2ca25143d26c8bd0903e4e9bc77b3f824`, files `button.tsx` and
-`dialog.tsx`. Adaptations replace Tailwind/CVA with local class variants, use
-individual Radix packages, default buttons to type=button, and leave dialog
-close controls to the calling surface. Radix supplies focus and dismissal behavior.
+`a87a63b2ca25143d26c8bd0903e4e9bc77b3f824`, file `dialog.tsx`. Adaptations
+replace Tailwind/CVA with local class variants, use individual Radix packages,
+and leave dialog close controls to the calling surface. Radix supplies focus
+and dismissal behavior.
 
 The rebuilt views (23 September 2026) add `src/browser/components/ui/`:
 button, badge, card, tabs, radio-group, select, switch, label, input,

package/dist/agent-fence.js

@@ -25,13 +25,14 @@ import { INSTANCE_DIR } from "./console-instance.js";
 import { ACP_AGENTS, ACP_PROVIDER_IDS } from "./acp-agents.js";
 import { spawnSync } from "node:child_process";
 import { createHash } from "node:crypto";
-import { existsSync, lstatSync, mkdirSync, readdirSync, readFileSync, realpathSync, statSync, writeFileSync } from "node:fs";
+import { closeSync, constants as fsConstants, existsSync, fstatSync, lstatSync, mkdirSync, openSync, readdirSync, readFileSync, realpathSync, statSync, writeFileSync } from "node:fs";
 import { createRequire } from "node:module";
 import { fileURLToPath } from "node:url";
 import { homedir, tmpdir } from "node:os";
 import { basename, dirname, isAbsolute, join, relative, resolve, sep } from "node:path";
 import { readMonitoring } from "./monitoring-settings.js";
 import { existingFolders } from "./names.js";
+import { ensureGitViewsRoot, gitViewsRoot } from "./git-views.js";
 import { DEPS_FOLDER, linkedKey, readyCopy, sharedCopies } from "./shared-deps.js";
 import { SEATBELT_PROBE, sandboxRuntimeProblem, srtSpawn } from "./sandbox-runtime.js";
 import { protectedStorageDenies, protectedStorageNames } from "./protected-storage.js";
@@ -52,6 +53,22 @@ function inside(child, parent) {
 }
 export class CheckoutBindingError extends Error {
 }
+/** One small file read only as the regular file it is: never through a link, never blocking on a FIFO; null otherwise. */
+function regularText(path) {
+    let fd = null;
+    try {
+        fd = openSync(path, fsConstants.O_RDONLY | fsConstants.O_NOFOLLOW | fsConstants.O_NONBLOCK);
+        const held = fstatSync(fd);
+        return held.isFile() && held.size <= 64 * 1024 ? readFileSync(fd, "utf8") : null;
+    }
+    catch {
+        return null;
+    }
+    finally {
+        if (fd !== null)
+            closeSync(fd);
+    }
+}
 export const HARDENED_GIT_ARGS = ["--no-optional-locks", "-c", "core.fsmonitor=false", "-c", "core.hooksPath=/dev/null"];
 const GIT_ENV_NAMES = ["PATH", "HOME", "TMPDIR", "TMP", "TEMP", "SystemRoot", "LANG", "LC_ALL", "CODEX_HOME"];
 export function checkoutGitEnv(base = process.env) {
@@ -85,18 +102,20 @@ export function trustedWorktreeBinding(repository, worktree, poolRoots = []) {
         }
         if (!lstatSync(join(main, ".git")).isDirectory() || !lstatSync(registry).isDirectory())
             throw fail();
-        // Query the trusted checkout, never the candidate's configurable Git pointer.
-        const listed = spawnSync("git", [...HARDENED_GIT_ARGS, "worktree", "list", "--porcelain", "-z"], { cwd: main, env: checkoutGitEnv(), encoding: "utf8" });
-        if (listed.status !== 0 || !listed.stdout.split("\0").includes(`worktree ${checkout}`))
-            throw fail();
+        // The trusted checkout's own worktree registry, never the candidate's configurable Git pointer — read as files, with
+        // no git at all (eval-harness review 2, finding 6): the repository's config is shared with every build, so an
+        // include naming a FIFO could hold a git read (and dispatch) up; a FIFO or link planted as a registry file is never
+        // opened as one (regularText).
         for (const entry of readdirSync(registry)) {
             const path = join(registry, entry);
             if (!lstatSync(path).isDirectory() || !inside(real(path), real(registry)))
                 continue;
-            if (real(readFileSync(join(path, "gitdir"), "utf8").trim()) !== join(checkout, ".git"))
+            const pointer = regularText(join(path, "gitdir"));
+            if (pointer === null || real(pointer.trim()) !== join(checkout, ".git"))
                 continue;
             const gitdir = real(path);
-            if (worktreeGitDir(checkout) !== gitdir || real(join(gitdir, readFileSync(join(gitdir, "commondir"), "utf8").trim())) !== real(join(main, ".git")))
+            const common = regularText(join(gitdir, "commondir"));
+            if (common === null || worktreeGitDir(checkout) !== gitdir || real(join(gitdir, common.trim())) !== real(join(main, ".git")))
                 throw fail();
             return { main, gitdir };
         }
@@ -175,6 +194,13 @@ export function agentFence(options) {
                 fence.add(join(state, entry));
         }
     }
+    // The plane's private views of repositories for its own git (git-views.ts): made first, so no build is the one to
+    // create them, and denied by name whether or not that worked (a sandbox that can't cover the path refuses to launch).
+    try {
+        ensureGitViewsRoot(home);
+    }
+    catch { /* fenced by name below either way */ }
+    fence.add(gitViewsRoot(home));
     for (const secrets of existingFolders(home, { dot: true }))
         fence.add(secrets);
     // v104: the folder the audit stream writes to holds the whole instance's history.
@@ -662,7 +688,9 @@ export function fencedGitEnv(base = process.env) {
 /** The repository a git worktree belongs to (its `.git` file names the main repository's git folder). */
 function worktreeGitDir(worktree) {
     try {
-        const pointer = /^gitdir:\s*(.+)$/m.exec(readFileSync(join(worktree, ".git"), "utf8"))?.[1]?.trim();
+        // The candidate's own pointer file: a FIFO or link there is never opened (review 2, finding 6).
+        const text = regularText(join(worktree, ".git"));
+        const pointer = text === null ? undefined : /^gitdir:\s*(.+)$/m.exec(text)?.[1]?.trim();
         return pointer === undefined ? null : real(isAbsolute(pointer) ? pointer : join(worktree, pointer));
     }
     catch {

package/dist/approval-authority.js

@@ -4,7 +4,9 @@
  *
  * An allowlist, never a deny-list: a person's yes (`password`, `chat`) stands unless a machine made that seal; a mode
  * or a flow grant stands while its signature does; a standing order's firing (`schedule`, or an old firing stored as
- * `password`) stands while its approver can still approve in the project. Everything else — the lead (`lead`, which
+ * `password`) stands while its approver can still approve in the project; an automatic release seal (`auto-check`,
+ * `auto-green`: docs/plans/auto-approve-green.md) stands on its own evidence row while the project's setting is on and
+ * the person who turned it on can still approve there. Everything else — the lead (`lead`, which
  * phase 1 never lets stand), a null basis, a word this code doesn't write — stands on nothing.
  *
  * The seal's origin is read from the acts recorded AT the seal's own instant, exactly as scope.ts sealOriginOf reads
@@ -12,6 +14,7 @@
  */
 import { grantStandsSql } from "./flow-unattended.js";
 import { accountReachesSql } from "./project-access.js";
+import { autoSealSql } from "./release-authority.js";
 /** The proofs a person gives (src/person-proof.ts), as an SQL list. */
 const PERSON_PROOFS = "('password-now', 'sso-now', 'fresh-password', 'fresh-sso', 'session', 'cli-login', 'chat', 'passkey')";
 /** SQL over a `task_scope` alias and a repo expression: whether that row's approval authority stands at `now` (an SQL
@@ -25,7 +28,8 @@ export const authorityStandsSql = (scope, repo, now) => `COALESCE((((COALESCE(${
          WHERE om.repo = ${repo} AND om.revoked_at IS NULL AND om.absolute_expiry > ${now} AND om.digest = ${scope}.mode_digest
            AND signer.revoked_at IS NULL AND signer.role = 'approver' AND ${accountReachesSql("signer", repo)}))
     OR (${scope}.approval_basis = 'grant' AND ${grantStandsSql(`${scope}.mode_digest`, now, repo)})
-    OR (${scope}.approval_basis = 'schedule' AND ${approverStandsSql(scope, repo)}))
+    OR (${scope}.approval_basis = 'schedule' AND ${approverStandsSql(scope, repo)})
+    OR (${scope}.approval_basis IN ('auto-check', 'auto-green') AND ${autoSealSql(scope, repo)} AND ${approverStandsSql(scope, repo)}))
     AND ${releaseStandsSql(scope, now)}), 0)`;
 /** SQL: a `carried` seal stands only on its own carry row — this task, this approved digest, this candidate, and the
  * reference `<authority>:<carry>` the carry transaction wrote (release-once.md). */

package/dist/approval-rules-ui.d.ts

@@ -6,6 +6,8 @@
  */
 import { type Html } from "./html.js";
 import type { ApprovalRules } from "./approval-policy.js";
+/** The rules' style, and the same for the Releases section under its own class (so a page holds one `.approval-rules`
+ * form, not two). */
 export declare const APPROVAL_RULES_CSS: string;
 export type ApprovalRulesView = {
     repo: string;
@@ -20,6 +22,15 @@ export type ApprovalRulesView = {
 };
 /** The rules in plain words, for anyone who can see the project. */
 export declare function rulesSummary(rules: ApprovalRules): string;
+/** Settings → Approval rules → Releases (docs/plans/auto-approve-green.md): who approves this project's releases. */
+export type ReleaseApprovalView = {
+    repo: string;
+    auto: boolean;
+    setBy: string | null;
+    at: string | null;
+    canChange: boolean;
+};
+export declare function releaseApprovalHtml(view: ReleaseApprovalView): Html;
 export declare function approvalRulesHtml(view: ApprovalRulesView, notice: {
     said?: string | null;
     problem?: string | null;

package/dist/approval-rules-ui.js

@@ -5,11 +5,14 @@
  * ledger, before → after.
  */
 import { html, postForm, reauth } from "./html.js";
-export const APPROVAL_RULES_CSS = `.approval-rules{max-width:720px;min-width:0}.approval-rules fieldset{border:0;padding:0;margin:18px 0 0;min-width:0}` +
+const RULES_CSS = `.approval-rules{max-width:720px;min-width:0}.approval-rules fieldset{border:0;padding:0;margin:18px 0 0;min-width:0}` +
     `.approval-rules legend{font-weight:600;font-size:.875rem;margin-bottom:8px}.approval-rules .choice{display:grid;grid-template-columns:auto minmax(0,1fr);gap:10px;align-items:start;margin:0 0 10px;font-weight:400}` +
     `.approval-rules .choice input{margin:.2rem 0 0}.approval-rules .choice strong{display:block;font-size:.875rem;font-weight:500}.approval-rules .choice small{display:block;color:var(--muted-foreground);font-size:.8125rem;margin-top:2px}` +
     `.approval-rules textarea{min-height:88px;font-family:var(--font-mono);font-size:.8125rem}.approval-rules .paths{margin:4px 0 0 26px}` +
     `.approval-rules .current{margin:0 0 4px}.approval-rules .step-up{margin-top:16px}.approval-rules button[type=submit]{margin-top:14px}`;
+/** The rules' style, and the same for the Releases section under its own class (so a page holds one `.approval-rules`
+ * form, not two). */
+export const APPROVAL_RULES_CSS = RULES_CSS + RULES_CSS.replaceAll(".approval-rules", ".release-approval");
 /** The rules in plain words, for anyone who can see the project. */
 export function rulesSummary(rules) {
     const parts = [];
@@ -21,6 +24,15 @@ export function rulesSummary(rules) {
         parts.push(`Work touching ${rules.protectedPaths.join(", ")} is protected: two people approve it, never a subagent or an operating mode.`);
     return parts.length === 0 ? "No approval rules: anyone who can approve on this project can approve its work, including their own." : parts.join(" ");
 }
+export function releaseApprovalHtml(view) {
+    const since = view.setBy === null ? "" : html ` <span class="meta">Changed by ${view.setBy} on ${(view.at ?? "").slice(0, 10)}.</span>`;
+    const current = html `<p class="current">${view.auto ? "Releases approve themselves once the pull request's CI and the release check pass on the exact commit. Anything red still asks you." : "Every release waits for your approval."}${since}</p>`;
+    const heading = html `<h2>Release approval</h2>`;
+    if (!view.canChange)
+        return html `<section class="release-approval">${heading}${current}<p class="meta">An approver of this project sets this.</p></section>`;
+    const choice = (value, title, hint) => html `<label class="choice"><input type="radio" name="action" value="${value}"${(view.auto ? "auto" : "ask") === value ? html ` checked` : ""}><span><strong>${title}</strong><small>${hint}</small></span></label>`;
+    return html `<section class="release-approval">${heading}${current}${postForm("/settings/release-approval", html `<fieldset aria-label="Release approval">${choice("ask", "Ask me", "A release deploys only after you approve it.")}${choice("auto", "Approve automatically when checks pass", "You're told when a release approves itself. A failed check, red CI or a CI failure after the deploy still stops and asks you.")}</fieldset><div class="step-up"><label>Your Toolroll password (to approve automatically)<input type="password" name="password" autocomplete="current-password"></label></div><button type="submit">Save</button>`, { hidden: { repo: view.repo } })}</section>`;
+}
 export function approvalRulesHtml(view, notice) {
     const note = notice.problem ? html `<p class="problem" role="alert">${notice.problem}</p>` : notice.said ? html `<p role="status">${notice.said}</p>` : "";
     const changed = view.rules.updatedBy === null ? "" : html ` <span class="meta">Changed by ${view.rules.updatedBy} on ${(view.rules.updatedAt ?? "").slice(0, 10)}.</span>`;

package/dist/assignment.js

@@ -140,6 +140,9 @@ function buildChecks(store, root, runId) {
         if (receipt.result.failure === "coverage-incomplete")
             return { status: "failed", exitCode: null, command: receipt.command.command, logArtifactId: receipt.log.artifactId, level,
                 detail: "Checks didn't cover everything this release owed, or a required test went missing." };
+        if (receipt.result.failure === "no-result")
+            return { status: "failed", exitCode: null, command: receipt.command.command, logArtifactId: receipt.log.artifactId, level,
+                detail: "Checks gave no complete result, so they can't count as a pass." };
         // The sealed receipt names the grant that ran: the quick one, or the full one.
         const sealedLevel = typeof receipt.command?.repo === "string" && receipt.command.repo.startsWith("quick:") ? "quick" : "full";
         const words = sealedLevel === "quick" ? "Quick checks" : "Checks";

package/dist/batch-checks.js

@@ -3,6 +3,7 @@ import { mkdtempSync, rmSync } from "node:fs";
 import { tmpdir } from "node:os";
 import { join } from "node:path";
 import { run as execRun } from "./exec.js";
+import { hardenedGit } from "./teardown-git.js";
 import { approvedCommandShell, SETUP_ENV_ALLOWLIST, SETUP_ENV_DENYLIST } from "./builder.js";
 import { runWithIsolatedDatabase } from "./child-database.js";
 import { boundStreamHeadTail, redactSecretLines, scanForSecrets, storeEvidence } from "./evidence.js";
@@ -86,7 +87,8 @@ function finishOne(store, one, repo, task, status, detail, at) {
 async function checkCohort(store, root, repo, cohort, deps) {
     const now = deps.now ?? (() => new Date());
     const runner = deps.runner ?? execRun;
-    const git = deps.git ?? execRun;
+    // The project's repository and checkouts of builds' commits, both agent-writable: the hardened git (teardown-git.ts).
+    const git = deps.git ?? hardenedGit(execRun);
     const command = store.liveVerifyCommand(repo);
     if (command === null)
         return 0;

package/dist/browser/THIRD_PARTY_NOTICES.txt

@@ -247,14 +247,14 @@ limitations under the License.
 
 ## shadcn/ui — MIT
 
-Button and Dialog composition in `src/browser/ui/primitives.tsx` adapts:
+Dialog composition in `src/browser/ui/primitives.tsx` adapts:
 https://github.com/shadcn-ui/ui/tree/a87a63b2ca25143d26c8bd0903e4e9bc77b3f824/apps/v4/registry/new-york-v4/ui
 
 Source inspected 20 September 2026, revision
-`a87a63b2ca25143d26c8bd0903e4e9bc77b3f824`, files `button.tsx` and
-`dialog.tsx`. Adaptations replace Tailwind/CVA with local class variants, use
-individual Radix packages, default buttons to type=button, and leave dialog
-close controls to the calling surface. Radix supplies focus and dismissal behavior.
+`a87a63b2ca25143d26c8bd0903e4e9bc77b3f824`, file `dialog.tsx`. Adaptations
+replace Tailwind/CVA with local class variants, use individual Radix packages,
+and leave dialog close controls to the calling surface. Radix supplies focus
+and dismissal behavior.
 
 The rebuilt views (23 September 2026) add `src/browser/components/ui/`:
 button, badge, card, tabs, radio-group, select, switch, label, input,