00-META/checks/words-allowed.md

@@ -25,3 +25,4 @@ which keeps a record's words as it was imported.
 | `04-ISSUES/310-a-pull-request-ran-its-own-copy-of-its-check/00-report.md` | 2027-04-30 | history: the issue's narrative keeps the word of its day, "judge" (the composition check's program built from a change; the glossary's manifest validator retired the noun); it is not rewritten |
 | `04-ISSUES/343-the-controllers-terminal-has-no-command/01-diagnosis.md` | 2027-04-30 | history: the issue's narrative keeps the word of its day, "judge" (a part of the controller's pull request, named so then; the glossary's manifest validator retired the noun); it is not rewritten |
 | `04-ISSUES/361-the-control-nodes-agent-account-is-never-judged/01-diagnosis.md` | 2027-04-30 | history: the issue's narrative keeps the word of its day, "judge" (the self-check's look at what an account can reach; the glossary's manifest validator retired the noun); it is not rewritten |
+| `04-ISSUES/299-an-optional-verb-makes-a-holder-look-silent/01-diagnosis.md` | 2027-04-30 | history: the issue's narrative keeps the word of its day, "seat set" (the seats compiled into the controller then; the glossary's seat list retired it); it is not rewritten |

00-META/glossary.md

@@ -65,6 +65,13 @@ is listed under [Homonyms](#homonyms), with the qualified form each domain uses.
   (its name, scope, verbs and provision), and every reader of the list of seats learns it from the bus, never from a
   compiled package (ADR 0635 §1, §2).
   *Not:* ~~seat-set package~~ (hq)
+- **seat list** — every seat's definition the mesh holds: the trunks' definitions, served by the seat `mesh-catalog`'s
+  verb `seat-definitions` and followed by its events, which every reader learns from the bus and never from a compiled
+  package (ADR 0635 §1, ADR 0636 §4). A reader with no list acts on nothing new (ADR 0636 §1). Inside a check it is the
+  one list made from the change's heads, by the checking program built from them, and handed to the manifest validator
+  and the composer (ADR 0636 §4 with its insight of 2026-11-06, ADR 0644; design 47). Not a **seat definition**, one
+  seat's file.
+  *Not:* ~~seat set~~ (hq)
 - **operator** — the person who runs the mesh, and the one the mesh talks to.
   *Not:* ~~master~~ (hq)
 - **person** — any human, as against the mesh acting unattended: *a person's word* releases a held

03-DESIGN/01-to-be/26-the-seats.md

@@ -15,7 +15,7 @@ code:
   - mesh-catalog modules/gitea/module.json
   - mesh-controller internal/inventory/migrations/0063-a-machines-names-are-one-seats.sql
   - mesh-controller internal/inventory/migrations/0064-the-resolver-file-is-the-uplinks.sql
-updated: 2026-11-05
+updated: 2026-11-06
 decisions:
   - "ADR 0636"
   - "ADR 0634"
@@ -196,7 +196,7 @@ defined whole or at the seat list's grain (ADR 0635 §2). In the milestone of AD
   contracts module of its domain (*Where a seat's
   code goes*, below). Its Go and
   TypeScript types are generated from it and committed beside it; nobody writes them by hand. The format is JSON, its
-  messages and bodies JSON Schema, as the seat set's verb inputs already are, with the format's own schema checked in;
+  messages and bodies JSON Schema, as the seat list's verb inputs already are, with the format's own schema checked in;
   the fixtures are data, never functions.
 - **A definition names its states** (ADR 0608 §1; ADR 0634 §6 leaves the file's format to this design). A `states`
   entry is what any holder of the seat keeps and what the seat's verbs answer from: its local name, its template of
@@ -727,7 +727,7 @@ condition keeper (health), a pull request's entries are removed when it closes (
 
 The milestone's amendment (ADR 0612, ADR 0613, ADR 0614, ADR 0620: the seats defined whole, the rest at the seat
 list's grain, the contracts marker, out of step learned from the checker's `verdict` and the builder's build end, the
-seat set's one source), with the amendment of 2026-11-04 (ADR 0625, ADR 0627: ten seats defined whole, a package per
+seat list's one source), with the amendment of 2026-11-04 (ADR 0625, ADR 0627: ten seats defined whole, a package per
 seat, a package for the seats at the seat list's grain in `mesh-contracts`, the seven clients and the seat-neutral parts transfer, *Where a
 seat's code goes*), and the amendment of 2026-11-05 (ADR 0634, ADR 0635: shared code with its owner, the domain
 SDK, a module's own package, a contracts module per domain the milestone moves, 25 seats defined whole with their

03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md

@@ -5,7 +5,7 @@ code:
   - mesh-controller internal/inventory
   - mesh-controller internal/catalogue
   - mesh-controller cmd/mesh-controller
-updated: 2026-10-17
+updated: 2026-11-06
 decisions:
   - "ADR 0181"
   - "ADR 0182"
@@ -209,7 +209,7 @@ alias and its trust, and a fresh machine has no operator dotfiles at all — the
 service and leave the human unable to work on the box.
 
 **Why not build it reflexively:** it is a real addition to the node model, the resource model, and
-the seat set, and must be gotten right. The mechanism half is now settled — ADR 0120 is what lets
+the seat list, and must be gotten right. The mechanism half is now settled — ADR 0120 is what lets
 the ssh files be templates with no controller format — so what remains to decide here is the
 model:
 

03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md

@@ -2,7 +2,7 @@
 layer: to-be
 status: in-progress
 code: [mesh-controller]
-updated: 2026-10-17
+updated: 2026-11-06
 decisions:
   - "ADR 0238"
   - "ADR 0221"
@@ -104,7 +104,7 @@ does not know. The old builder cannot build the new builder. Escapes:
 
 Either way, self-update for breaking changes needs a **transition discipline** so a push does not
 auto-freeze: the new controller (and builder) should accept the *old and new* shape together for
-one release — deprecated aliases in the seat set, a schema that reads both — then a later release
+one release — deprecated aliases in the seat list, a schema that reads both — then a later release
 drops the old. With that, a breaking change rolls out on a push like any other: everything reads
 both, the manifests migrate, the compatibility is removed. Without it, self-update would simply
 automate the freeze.

03-DESIGN/01-to-be/46-the-conversation-with-the-operator.md

@@ -2,7 +2,7 @@
 layer: to-be
 status: in-progress
 code: [mesh-controller, mesh-tools, mesh-sdk, mesh-catalog]
-updated: 2026-10-13
+updated: 2026-11-06
 decisions:
   - "ADR 0347"
   - "ADR 0345"
@@ -696,12 +696,12 @@ Each phase ends at its own *done when*. Owning repositories from [`repos.md`](..
 |---|---|---|---|
 | **1 — Fix the first holder in place** | D1–D4 in the output seat's holder and the watcher, then D5–D10; no change of shape. The operator then makes the two bots and the mesh is given their values through the controller | mesh-catalog | the holder's tests for D1–D4 pass; a live test message reaches the phone from both the holder and the watcher |
 | **2 — The desk's actions** | `node-notifier.send` gains actions; the dunst holder emits the chosen one; the launcher's prompt returns typed text; the screen-lock holder emits lock and idle changes | mesh-catalog | a notification with two actions returns the chosen token as an event; locking emits an event |
-| **3 — The seats, and the router** | the kinded bench in the seat set; `kind` and `capabilities` on a claim; `channel-capabilities/1` and its contract tests; publishing on a seat's event subjects and its grant; `channel` and `intake` seats; the output seat's holder becomes the router and holds `channel/desktop` and `intake/desktop`; presence as current state; the operator's identity list and identity check in the controller, the router's `trusted` stamping and untrusted input (§4); the content rule allowing machine names, references and `detail`, refusals naming the offending part (§9) | mesh-controller (seat set, claim fields, registration refusals, grants, the identity list and check); mesh-sdk and mesh-tools (seat-event publishing in the shared library and the tool runner); mesh-catalog (the seats' definitions, the router) | the catalog refuses an unknown capability and a second holder of one kind; a message is routed to the desk by capability and context; an envelope from an identity not on the list is re-emitted untrusted; a path is refused to its sender by name, and travels as a reference the desk opens |
+| **3 — The seats, and the router** | the kinded bench in the seat list; `kind` and `capabilities` on a claim; `channel-capabilities/1` and its contract tests; publishing on a seat's event subjects and its grant; `channel` and `intake` seats; the output seat's holder becomes the router and holds `channel/desktop` and `intake/desktop`; presence as current state; the operator's identity list and identity check in the controller, the router's `trusted` stamping and untrusted input (§4); the content rule allowing machine names, references and `detail`, refusals naming the offending part (§9) | mesh-controller (seat list, claim fields, registration refusals, grants, the identity list and check); mesh-sdk and mesh-tools (seat-event publishing in the shared library and the tool runner); mesh-catalog (the seats' definitions, the router) | the catalog refuses an unknown capability and a second holder of one kind; a message is routed to the desk by capability and context; an envelope from an identity not on the list is re-emitted untrusted; a path is refused to its sender by name, and travels as a reference the desk opens |
 | **4 — Asks, and operator messages** | `ask`, `ask cancel`, `asks`, `answer`; the events; kinds, life, limits, batching, history; escalation; addressing, the register of agents with kept messages, the responder; the untrusted-input rule in every agent module's instructions (§5) | mesh-catalog | the router tests of ADR 0234 pass; live: an agent's question answered at the desk, and with the desk locked, on the phone; `@mesh status` answered; a message to a stopped agent kept and said |
 | **5a — Asks on the bus** (ADR 0259) | the kinded bench, caller-named verbs, `proof` subjects and the records users read (controller); a bundle's seat traffic, compare-and-set state and its own account (tool runner); the asker's and channel's types (shared library); the router's asks, tokens, identities, judging, warrants, expiry and linking with its hour (messenger); `telegram` and `desk-channel`; the controller asking for its conditions' actions and acting on warrants | mesh-controller, mesh-tools, mesh-sdk, mesh-catalog | a held delivery released from the phone; the hand-act reads "the operator, via telegram, user id verified"; a desk Silence goes through an ask |
 | **5 — Authorise, with TOTP** | `authorises` in the verb table; the router's checks for the code; direct calls refused, break-glass; `retire approve` takes `expect`; the hand-act fields; the TOTP seed as the router's state, enrolled at a terminal with ten recovery codes; `factor recover`, `factor status`, the local-only break-glass enrolment; no P2 tier before recovery codes exist; optional key enrolment; the self-check probe for the away channel; agents' grants lose the authorising verbs | mesh-controller; mesh-catalog (agents' grants, the desk's code prompt) | one controller test per refusal passes; at the desk, approve needs a code; a recovery drill re-enrols with a recovery code, and is announced |
 | **6 — Telegram live** | the `telegram` module (built in 5a) with replies and forced-reply codes, under its own account on the control node; the operator's two bots configured; the watcher assigned off the control node; the dead-man ping | mesh-catalog | the self-check says the away channel carries every tier; rehearsals: an approve and a destroy answered on the phone, with the hand-acts read |
-| **7 — A call that needs approval** (ADR 0286) | `needs-approval` in the manifest and the seat set, issued in the membership, withheld from a runner without `approval-mark/1` in its bus permissions (controller); the act's digest in TypeScript beside Go, with shared vectors (shared library); the check, the ask, the runner's `approvals`, the node's used file and `warranted` (tool runner); the controller's own verbs; `execute` marked (the controller's seat set) once issue 418's reads exist | mesh-controller, mesh-sdk, mesh-tools, mesh-catalog | a marked call on a node is asked on the phone, does nothing, runs once when made again after Approve, is refused the third time and asked again, and `hand-acts` shows the warrant |
+| **7 — A call that needs approval** (ADR 0286) | `needs-approval` in the manifest and the seat list, issued in the membership, withheld from a runner without `approval-mark/1` in its bus permissions (controller); the act's digest in TypeScript beside Go, with shared vectors (shared library); the check, the ask, the runner's `approvals`, the node's used file and `warranted` (tool runner); the controller's own verbs; `execute` marked (the controller's seat list) once issue 418's reads exist | mesh-controller, mesh-sdk, mesh-tools, mesh-catalog | a marked call on a node is asked on the phone, does nothing, runs once when made again after Approve, is refused the third time and asked again, and `hand-acts` shows the warrant |
 
 **Switching phase 5a on: the operator's steps, in order** (amended 2026-10-09, ADR 0259). Each line is typed with
 `nox` (`mesh-cli`) on the control-node, from the operator's own account, which is the controller's terminal

03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md

@@ -728,20 +728,23 @@ ADR 0656 leaves how each part is built to this design, under issue 1921; these f
   below), so a module whose runtime reads the value is composed only by a node-engine that hands it.
 - **The build seat's ask that runs a program in the sandbox.** The checker asks the seat `node-build-go` for an ask
   `run` on the build seats' `check` stream: one whole job on one node (ADR 0525 §3), which fetches the named heads,
-  builds the named program at them, runs it in the run step (ADR 0448 §2) with the input the ask carries as a file,
-  and writes the program's output and its exit on the build module's step key named by the ask's id (ADR 0525 §6). It
-  is an accepted ask of the seat, not a request verb, because it is a long job pulled where there is capacity, never
-  a call to a named node. Only the checker's account may publish `run`. Every step key of a `run` ask starts with the
-  asker's name (`checker.<ask id>`), so the checker's read grant is fixed in advance to its own prefix and never
-  follows ask ids one by one (ADR 0363 §2); no other part can have a program run or read its verdict. The seat
-  definition of `node-build-go` in `mesh-delivery-contracts` names it; the checking program, the acting parts and the
-  composer a check builds from a change all run through it (ADR 0656, ADR 0644). A program is built once per
-  fingerprint: the build is the builder's build of that fingerprint (ADR 0498 §1), kept like any build and reused by
-  every later ask naming it, so two checks of changes that leave the checking program unchanged ask one build. Only a
-  build made in a run step that runs nothing but the build is kept and reused: a program's own run happens in a
-  separate run step over a copy, so a program that rewrites its own binary while it runs changes no kept build. A
-  candidate's build is never delivered to a node: a want names only a trunk revision's fingerprint (*Only a trunk
-  revision writes wants*), and a candidate's build is kept only for checks.
+  builds the named program at them, runs it in the run step (ADR 0448 §2) with the input the ask names by its sha256 in
+  the asker's own state (the checker's `inputs`, a day), asked of the seat `mesh-delivery-checker`'s verb `input` and
+  checked against that digest, laid as a file, and writes the program's exit and its answer, carried whole, on the
+  build module's step key named by the ask's id (ADR 0525 §6). It is an accepted ask of the seat, not a request verb, because it is a
+  long job pulled where there is capacity, never a call to a named node. Only the checker's account may publish `run`.
+  Every step key of a `run` ask starts with the asker's name (`checker.<ask id>`), so the checker's read grant is fixed
+  in advance to its own prefix and never follows ask ids one by one (ADR 0363 §2); no other part can have a program run
+  or read its verdict. From milestone G the seat definition of `node-build-go` in `mesh-delivery-contracts` names it; B0
+  brings the ask with its types in mesh-sdk's `go/delivery` and the grants check asks have today (*The bootstrap
+  delivery, and the one milestone after it*). The checking program, the acting parts and the composer a check builds
+  from a change all run through it (ADR 0656, ADR 0644). A program is built once per fingerprint: the build is the
+  builder's build of that fingerprint (ADR 0498 §1), kept like any build and reused by every later ask naming it, so two
+  checks of changes that leave the checking program unchanged ask one build. Only a build made in a run step that runs
+  nothing but the build is kept and reused: a program's own run happens in a separate run step over a copy, so a program
+  that rewrites its own binary while it runs changes no kept build. A candidate's build is never delivered to a node: a
+  want names only a trunk revision's fingerprint (*Only a trunk revision writes wants*), and a candidate's build is kept
+  only for checks.
 - **The first tier's own bound.** A check's first tier has 20 minutes for all its builds together, inside the check's
   one-hour bound of the state table and the checker's step bound (ADR 0639 §5); an acting part not built within it is
   one the first tier cannot build, and the check fails naming it (ADR 0656). The verdict tells two cases apart: `waiting
@@ -1241,9 +1244,10 @@ running versions never check in their place, and a check fails, naming the part,
   built in the first tier, judges the change's manifests besides (ADR 0656). A change fails if either refuses it.
 - **The asking and recording are covered by the checker's whole-module test**, which starts the changed checker on a
   real bus and asks one check of a fixture group end to end (ADR 0391 §1).
-- **One seat list for both readers of a group's heads.** Inside a group's check the checker makes one seat list from
-  the members' heads and hands it to the manifest validator and the composer (ADR 0644, ADR 0636 §4 with its insight
-  of 2026-11-06).
+- **One seat list for both readers of a change's heads.** Inside every check, a lone pull request's as a group of one,
+  the checking program built from the heads makes one seat list from them, and the checker hands it to the manifest
+  validator and the composer (ADR 0644, ADR 0636 §4 with its insight of 2026-11-06); the running checker reads no
+  definition of the heads itself (*The bootstrap delivery, and the one milestone after it*).
 - **Its tools.** The checker's read of a check names the checking program's build that judged it, its fingerprint and
   the heads it was built from, and the rules named changed; `checker_first_tier` lists a check's first-tier builds,
   each with its acting part, its fingerprint and its outcome (`built`, `waiting for a build node`, `did not build`),
@@ -2373,7 +2377,7 @@ release reports the controller's code lines against research 063's baseline (acc
 | L5 | Control records leave the controller, and the controller is not changed (ADR 0565): mesh-config keeps each module's declared config in its state `declared` and publishes the predefined keys, which the indexer reads from the forge bridge's messages with each open pull request's config candidate; config switches to that source only on the operator's take-over, refused while `compare` shows a difference; each node agent writes its node's declared packages (the node seat `node-engine`, verb `packages`); the assigner holds the new seat `mesh-wants` with the upgrade policy a person chose and the bus step; the hand-act log (`hand-act`, `hand-acts`, `warranted`) is the stream of the new seat `mesh-hand-acts`, held by a new module in mesh-catalog, which every recorder calls from this delivery with no switch; the checker and the assigner's composition check read the held values of their pull requests from mesh-config's state `kept`; from the lease write a trusted config value is set only on the operator's Approve; `settings`, `move-config` and `move-placement` end with the lease and nothing replaces them. each person's six policy choices are set through `mesh-wants.upgrade` and recorded as hand acts, `upgrade compare` and the assigner's finding `policy-split` show any split, and the lease write waits for `compare` to be empty (ADR 0565 §8). One delivery group, built before the lease write of L3, which waits for the group delivered, the six choices set, mesh-config's `compare` empty and its take-over done, `mesh-wants.upgrade compare` empty, and the readings of ADR 0565 §12 (ADR 0565 §14; ADR 0348 §9, ADR 0502 §2, ADR 0539 §14, §15, ADR 0547 §11) | — | mesh-sdk, mesh-catalog (mesh-config, mesh-hand-acts, pacman, the forge module, claude-code, mesh-knowledge, mesh-conditions, mesh-healers), mesh-delivery (indexer, assigner, checker, grants part, forge bridge), the node-engine (`mesh-host`); mesh-controller is not a member | 1953 |
 | L6 | Provisioning leaves the controller (ADR 0570): every provision is one key of the seat `mesh-provisioner`, held by mesh-provisioner, holding a reference and never a value, and each placed module's provisioning plan a key of its state `plans`, both composed from placement, the wants and the manifests on change events; each provider acts once all a provision depends on is provided; the assigner moves a want only once its build's provisions are provided; a provision no want needs is retiring, and its account or credential is removed only on the operator's Approve, its data never; the vault mints each provision's secret sealed to the consumer's and the provider's node, and the consumer's node-engine writes it; a wait for a person is a provision's state, which the watchman reads; bus permissions stay with the grants part (ADR 0349, ADR 0230, ADR 0547 §11) | — | mesh-sdk, the node-engine (`mesh-host`), mesh-tools (the tool runner's provisioner client), mesh-catalog (mesh-provisioner, the vault, the provisioner client, postgres, keycloak, gitea, route-adapter), mesh-delivery (assigner, watchman) | 1954 |
 | L7 | History and records leave the controller (ADR 0571): the builder keeps its build log, one entry at a build's start and one at its end, from which build history and durations are read and the module mesh-catalog asks the builds it missed; the artifact sweep is the seat `mesh-artifact-sweep`, held by artifact-store-tools beside the artifact store, its keep set from the store's own listing, the wants and the build log, sweeping at each build's end from the lease write and recording each deletion in the hand-act log; disk readings are disk-load's own state on every node; who holds which seat is the state `seat-holders` of the seat `mesh-placement` (now `mesh-module-assigner`), and tools are found by the tool runners' announcements; what a node runs is its want and its have; the grants part writes `grants.<module>.<fingerprint>` and keeps memberships in its own state; root-free is a probe of the self-check; no manifest but the controller's reads, invokes or consumes `mesh-controller`, but a named list kept to the lease write, so the lease write's check passes (ADR 0189, ADR 0547 §11, ADR 0549 §6) | — | mesh-sdk, mesh-controller (its pin only), mesh-delivery (builder, indexer, assigner, grants part, view), mesh-catalog (artifact-store-tools, disk-load, the backup seat's holder, mounts, nfs-server, minio, mesh-watcher, the messenger, the self-check, the module mesh-catalog, docker), mesh-tools (the tool runner) | 1955 |
-| B0 | The bootstrap delivery: a delivery group's check runs a checking program built from the group's own heads in the build seat's sandbox, and hands the manifest validator and the composer the heads' one seat list; it brings no seat definition, so the running checker checks it (ADR 0644) | 26 needs it | mesh-delivery (checker), mesh-catalog (mesh-build-go), mesh-delivery-contracts (the seat `node-build-go`'s ask `run`) | 1921 |
+| B0 | The bootstrap delivery: every check, a lone pull request's as a group of one and a verdict carried after a trunk move included, is judged by a checking program built from the change's own heads in the build seat's sandbox, which also makes the heads' one seat list that the check hands the manifest validator and the composer; it brings no seat definition and no manifest field, so the running checker checks it (ADR 0644; *The bootstrap delivery, and the one milestone after it*) | 26 needs it | mesh-sdk (`go/delivery`: the seat `node-build-go`'s ask `run` and the checker's record of which checking program judged; `go/composer`: the request's seat list), mesh-catalog (mesh-build-go: the run step, the refused answer, the kept programs' tools and sweep), mesh-delivery (checker: the checking program and its command), hq (this design, the glossary) | 1921 |
 | G | Two graphs and one revision view: the catalog graph and the assignment graph kept per revision, a change delivered as its graph difference, the acting parts' rules on their seats as bounded waits that hold their modules when the new version fails, the check on the change's own acting parts, the revision view and each process's own build, the gate's delivery record, and the trace's links (ADR 0656); the registry milestone's reviewed heads are joined to its group as members | 26 to 49 | mesh-sdk (the runtime: the fingerprint, the view, the definition reader), mesh-contracts and the domains' contracts modules (`acts`, the new verbs and events), mesh-delivery (indexer, assigner, checker, builder, grants part, gate's view, forge bridge), mesh-catalog (the gate, the build modules, mesh-issues, mesh-knowledge, the `node-backup` holder, nats: a module's kept data on the bus as a backed-up item), the node-engine (`mesh-host`), hq | 1966 (with the registry milestone's heads), 1961, 1660, 1962, 1972, 1721, 1783, 1785, 1794, 1791, 1373 |
 
 An issue is in one row only (ADR 0493 §2): where a row named an issue another row names too, the last row keeps it and the
@@ -2408,8 +2412,8 @@ R4d, the three image reworks (route-proxy, nats, automx; n8n left by ADR 0506),
 
 ### The bootstrap delivery, and the one milestone after it
 
-*ADR 0644; ADR 0612 §3, ADR 0603 §10, ADR 0614 §7, ADR 0633 §6, ADR 0636 §4, ADR 0448 §2, §4; research 085,
-Direction.*
+*ADR 0644; ADR 0612 §3, ADR 0603 §10, ADR 0614 §7, ADR 0633 §6, ADR 0634 §1, §4, §7, §8, ADR 0635 §4, ADR 0636 §4,
+ADR 0448 §2, §4, ADR 0525 §3, §6, ADR 0548 §1, §5, ADR 0656 §5; research 085, Direction.*
 
 Milestone G changes the seat definitions and the checker that checks them, so the running checker could never pass
 it, and it could not merge until it passed (ADR 0644, Context). One delivery, B0, goes first, and none after it: from
@@ -2417,21 +2421,72 @@ the milestone's delivery on, nothing of a change is delivered ahead of it. This
 order inside one milestone, for this one case (ADR 0644).
 
 - **What it carries.** Only what the running checker must run to check milestone G: the checking program built from a
-  group's heads, and one seat list handed to the manifest validator and the composer (ADR 0644). The checker builds the
-  checking program from the members' heads and runs it in the build seat's sandbox through the seat `node-build-go`'s
-  ask `run`, with the group's heads as its input, no network and no bus account (ADR 0448 §2, §4); the running checker
-  only asks for the build, reads the program's verdict, records it and publishes it. The seat list is the one ADR 0636
-  §4 decides, with its insight of 2026-11-06; B0 builds its hand-over and decides nothing new about it.
-- **The trunk's validator still judges inside a group's check.** The indexer's new manifest is also validated with
-  the trunk's manifest validator, built from the trunk (ADR 0633 §6).
-- **The running checker checks it.** B0's group changes no seat definition and no contract, so the running checker
+  change's heads, and one seat list handed to the manifest validator and the composer (ADR 0644). The checker has the
+  checking program built and run in the build seat's sandbox through the seat `node-build-go`'s ask `run`, with the
+  change's heads laid read-only in the ask's workspace by the build module's fetch step, no network and no bus account
+  (ADR 0448 §2, §4; ADR 0525 §3); the running checker only asks, reads the program's verdict, records it and publishes
+  it, and reads no file of the heads itself. The seat list is the one ADR 0636 §4 decides, with its insight of
+  2026-11-06; B0 builds its hand-over and decides nothing new about it.
+- **Every check runs it, one path.** A lone pull request is a group of one, and a verdict carried after a move of a
+  trunk or a sibling (*A move of the trunk carries every verdict*) is judged by the checking program too, on the same
+  path as a new check; the running checker's own rules decide no check's outcome after B0's delivery, with the one
+  exception below. The program is built at the commit of the change's mesh-delivery member's head when it has one,
+  else at mesh-delivery's trunk as the check reads it (after a move of that trunk, the new trunk), as the manifest
+  validator is chosen today, and it reads every member's head as pushed. It is built once per build: a build is kept
+  under the program's repository, commit, directory and package, the toolchain and the mesh package versions asked, so
+  a move of another trunk that moves no mesh package version asks no new build, and a move of mesh-delivery's trunk
+  under a change with no mesh-delivery member asks one. Why: a group-only program would leave the running rules
+  judging every lone pull request and every carry, two paths of which one is the old form kept; and a carried verdict
+  must say what a check of the same heads would say (ADR 0548 §1, §5).
+- **The module graph's cycle rule is the program's.** The running checker gathers the edges of the change's module
+  graph and of the trunk's, each edge's two modules and its kind (a base, an awaited provision, a kept verb edge), never
+  the whole manifests, and the checking program refuses a cycle by the rule ADR 0603 §2 decides, as ADR 0656 §5 has
+  every check after B0 judged (the whole catalog's graph is about 50 edges, a few KiB of the input's bound).
+- **One exception, until milestone G.** A checking program that cannot be asked, built or run, or answers no verdict, fails the check naming it, as ADR 0656
+  §5 has it; the verdict's other failures are then worded by the running checker's rules, which word what the facts
+  hold and never decide the outcome, because the program that would word them did not answer. A seat list the program
+  cannot make ends the check there, failed and naming why: no manifest validator, no module graph and no composition is asked, nor the program's verdict, and the verdict is worded by the running checker's rules.
+- **The checking program makes the seat list.** Its first answer in a check is the heads' one seat list: the seats the
+  heads define, resolved, and each it left out with why. The check hands that list to the manifest validator at the
+  heads, to the trunk's manifest validator of ADR 0633 §6, and to the composer at a node-engine member's head, in the
+  field `seats` of the requests their asks already carry. The validator's and the composer's asks keep their form in
+  B0, and milestone G moves them onto `run`. B0's build module keeps `seats` whole when it fills a request; on today's
+  trunk it drops it, so the trunk's validator never received a list. Why the program and not the running checker:
+  the running checker cannot read the definition format milestone G brings, so a list it made would go blind again on
+  the first seat G defines; a program built from the heads reads what the heads define.
+- **Where its types live.** B0 adds the ask `run`, its answer and the verdict's record of which checking program
+  judged it where the seats' types live on today's trunk, mesh-sdk's `go/delivery`, and the request's `seats` where the
+  composer's request lives, mesh-sdk's `go/composer`. `mesh-delivery-contracts` and `mesh-delivery-sdk` are created by
+  the registry group, which joins milestone G (ADR 0634 §7, §8), so they exist on no trunk before G; G's merge carries
+  these types with `go/delivery` into the seats' contracts in `mesh-delivery-contracts` (ADR 0634 §4) and the request
+  with `composer` into `mesh-delivery-sdk` (ADR 0635 §4), and mesh-sdk keeps no copy. The checking program, its rules
+  and its command `mesh-checking-program` are the checker module's own package in mesh-delivery, and the run step is
+  mesh-build-go's own (ADR 0634 §1).
+- **The trunk's validator still judges inside a check.** The indexer's new manifest is also validated with the
+  trunk's manifest validator, built from the trunk (ADR 0633 §6).
+- **The running checker checks it.** B0 changes no seat definition and adds no manifest field, so the running checker
   reads every manifest of it; for B0's own group, what the running checker cannot run is still composed from its
-  manifest and named in the verdict, as ADR 0603 §10 and ADR 0614 §7 have it until milestone G.
-- **Its tool.** The checker's read of a check names the checking program's build that judged it: its fingerprint and
-  the heads it was built from. Asking a check again stays the checker's existing ask-again.
+  manifest and named in the verdict, as ADR 0603 §10 and ADR 0614 §7 have it until milestone G (ADR 0656 §5).
+
+B0's own choices, each checked by the rows of *How it is checked* below:
+
+| Choice | Why |
+|---|---|
+| A `run` ask has a begin bound of 5 minutes per put (a setting of the checker, 5 minutes unless set), inside the first tier's 20 (*What ADR 0656 leaves to this design*): put once, put again after 5 minutes unbegun, and the check fails naming the missing job `run` after a second 5 minutes unbegun; a begun step keeps the first tier's bound | five minutes is long enough for a build node with a free slot to take an ask, and two puts still leave half the first tier's bound to the run itself; a build module on today's trunk drops an ask whose job it does not know from its work queue with a log line and writes no step key, so the checker would wait to its step bound in silence; the build module's `invokes` of the checker's verb `input` orders the checker first, so the new checker runs beside the old build modules until the new one reaches every build node, and a build module that does not know `run` drops its ask. That gap of the build and delivery system is closed by milestone G's acting rule for the build step; in B0 it fails loudly instead |
+| A build module answers an ask whose job it does not know on its step key as refused, naming the job, never only in its log | the kind, not this instance: every ask a build module takes is answered, so no asker waits on an ask nobody will end |
+| The build module's kept checking programs and composers are read, dropped and swept: `build_go_kept` lists them (key, size, last use), `build_go_kept_drop` drops one and answers what it removed, and the sweep the build module's workspace cleaning runs removes one unused for 30 days; in milestone G a drop is written to the hand-act log with G's drop tools | the bound is not the workspace bound, because a workspace is held by one step while a kept program is reused by its key across checks, and 30 days keeps every program a check of the month's trunks asks again; with every check running the checking program, each merge into mesh-delivery or mesh-sdk adds one kept program per build node; a store nothing reads or empties fills the build node unseen, and a module's tools read all it holds and recover without help |
+| The program's input (the facts it judges, or the heads a seat list is asked of) goes by reference: the checker keeps it in its own state `inputs` under the sha256 of its exact bytes for a day, read by no other part; the ask names the verb that answers it, the digest and the size; the Go build module asks the seat `mesh-delivery-checker`'s verb `input` for that digest, over the bus, and refuses bytes that are not the input named. The build module declares the call in its manifest's `invokes`, so the module graph orders it after the checker (*Order without a person*), and the checker declares the verb in its `serves`. An input is bounded by the bus's value limit of 256 KiB, the one this design already uses, and one over it is refused before the ask, naming its size. The program's answer (the seat list, the verdict) is the last line of its output, carried whole on the step key with its exit, and an answer over the same 256 KiB fails the step, naming its size | a group's facts grow with its members, and an ask over the bus's size limits is lost or refused far from its cause; refused before asking, a group too large fails by name. The input is the checker's own kept data, so it lives in the checker's state and another module asks it of the checker's seat verb, never reading that state (ADR 0596 §2); a day outlives every check's step bound. The answer is small beside the facts, one seat list or one verdict, so it rides the step key as every step's answer does |
+| The `run` ask goes on the check stream under the grants check asks have today; the publish grant fixed to the checker's account and the step keys under the asker's name (*What ADR 0656 leaves to this design*) come with milestone G | B0 opens nothing a compose ask does not already allow, since any publisher of check asks can have a composer built and run at a commit today, and ADR 0644 limits B0 to what the running checker must run |
+| The checking program's input carries its version, and a program that does not read the version it is given fails the check, naming the version | B0's checker runs milestone G's checking programs, G's own check first, so G's checking program reads the form B0 writes; that is the form, not an old one kept, and G adds the revision view to it |
+
+- **Its tools.** The checker's read of a check names the checking program's build that judged it: its fingerprint and
+  the heads it was built from, and the seat list it made with what it left out; `checker_inputs` lists the inputs the
+  checker keeps, each digest with its size, and reads one whole, and the seat's verb `input` answers one by its digest. The build module's step tools read a `run` ask's step,
+  its answer included, as they read every step, and `build_go_kept` and `build_go_kept_drop` read and drop its kept
+  programs. Asking a check again stays the checker's existing ask-again.
 - **What it costs.** One more check, Approve and delivery before milestone G; milestone G then has one check, on its own
-  checking program (ADR 0644, Consequences), and a group's check costs one more build in the build seat, within the
-  checker's step bound (ADR 0639 §5).
+  checking program (ADR 0644, Consequences), and every check costs one more ask in the build seat, within the
+  checker's step bound (ADR 0639 §5), the program built once per build and reused.
 - **Milestone G keeps the rest**: the first tier for every acting part, the verdict that fails by name, the revision
   view, the two graphs, the difference, the acting rules, the delivery record and the trace's links, with the
   registry milestone's reviewed heads joined to its group. It is one milestone, one group and one check, its fixtures
@@ -2440,14 +2495,23 @@ order inside one milestone, for this one case (ADR 0644).
 - **The order inside milestone G is the module graph's**, never a delivery ahead: each acting part's new version acts
   first in its own step (ADR 0656; *Order without a person*); the node-engine handing the fingerprint composes the
   modules whose runtime reads it; the indexer's own steps keep *Taken in by the indexer it names*.
-- **How it is checked.** Milestone G's group check runs on the checking program built from that group's own heads,
-  read from the check's record (live; ADR 0644, How it is checked). In the checker's
-  whole-module test, a fixture group whose checker change alters a rule is judged by its own checking program, which
-  has no bus account, a fixture group whose heads add a seat has that seat in the list both the validator and the
-  composer receive, and the check's read names the checking program's build and heads; live, B0's own check passes on
-  the running checker, naming any module composed from its manifest; whole (gate, assigner), built with milestone G
-  and run in its check, a group changing the indexer, the checker and a module is delivered with no delivery ahead of
-  it.
+- **How it is checked.** Milestone G's group check runs on the checking program built from that group's own heads, read
+  from the check's record (live; ADR 0644, How it is checked). In the checker's whole-module test: a fixture group whose
+  checker change alters a rule is judged by its own checking program, which has no bus account; a lone pull request and
+  a carried verdict are each judged by the checking program, and the check's read names it; a fixture group whose heads
+  add a seat has that seat in the list both validators and the composer receive; a checking program that does not build,
+  or builds and does not answer, fails the check naming it, and a seat list it cannot make fails the check with no
+  verdict asked of it; a change whose module graph has a cycle is refused by the checking program from the gathered
+  edges, naming the cycle, and one whose trunk has the same cycle is only noted; a fixture build module that drops a `run` ask is put again
+  after 5 minutes and fails the check after 10, naming the missing job; an input over its bound fails before the ask,
+  naming its size; and the check's read names the checking program's build, heads and seat list. In the build module's
+  tests: a `run` ask on a real bus is answered on its step key, its input asked of a checker answering the verb
+  `input` and bytes that are not the input named refused, an answer over 256 KiB failing the step, a program that dials out fails, an ask with a job it
+  does not know is answered refused naming the job, a compose request's `seats` reaches the program whole, and
+  `build_go_kept` lists kept programs, `build_go_kept_drop` drops one saying what it removed, and the sweep removes one
+  unused for 30 days (unit). Live, B0's own check passes on the running checker, naming any module composed from its
+  manifest; whole (gate, assigner), built with milestone G and run in its check, a group changing the indexer, the
+  checker and a module is delivered with no delivery ahead of it.
 
 ## What is not decided here
 
@@ -2486,6 +2550,16 @@ and what answers it:
 | security | a checking program hiding a removed rule; forged events; the `run` ask's grant; a kept build overwritten by the program it built; the review line retired before the review verb's grant | the running checker names every change of the checking program's fingerprint; the node in event subjects and grants per account; builds kept only from a step that runs nothing; the review verb left to issue 1782 |
 | upgrade | a newer indexer never wanted after milestone G; a revert across a change of kept data's form | the stand-in catalog graph revision; restore points taken before a move across a `form` change, restored at a revert before the reverted build starts, the node-engine back last |
 
+The amendment for milestone B0 (2026-11-06) carries the review of seams and tools of B0's prepare, which did not
+approve on three findings: a `run` ask an old build module drops is silent, the kept programs have no tool, and the
+program's input rides in bus messages unmeasured. Each is answered by a row of B0's choices (*The bootstrap delivery,
+and the one milestone after it*), with the review's note that every check runs the checking program, a lone pull
+request and a carried verdict included. Its review by architectural domain is still to come. The first round of B0's
+code review found that this section did not say what was built: the input in the checker's own state and the answer
+on the step key, the wording of a failed program's verdict as an exception until milestone G, and where a carried
+verdict's program is built; each is now written as built, with its reason. The lead's rulings on that round then moved
+the input onto the checker's verb `input` (ADR 0596 §2) and the cycle rule into the checking program (ADR 0656 §5).
+
 Left as notes on issue 1921, not in this amendment: a conformance check that a changed layout raises its `form`; the
 size and retention of restore points and set-aside data; who may call `restore` for bus data and which manifest grants
 the catch-up call; the hold's bound while a large backup is taken; the granting and placing bound read from the first