From 12489d580c7d59704fc0b7bea0c2198cc592a252 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 6 Nov 2026 22:08:31 +0100 Subject: [PATCH] Design 47's B0 names the trunk's homes and runs the checking program on every check MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Row B0 named mesh-delivery-contracts for the ask `run`, but the registry group creates that module and joins milestone G, after B0; on every trunk before G the seat's types are mesh-sdk's go/delivery and go/composer, which G's merge moves (ADR 0634 §4, ADR 0635 §4). The bootstrap section now says every check runs the checking program (a lone pull request a group of one, a carried verdict included), that the program makes the heads' seat list, and carries the seams review's three findings on B0's prepare as the design's own choices with their reasons: a dropped `run` ask fails by name within a bound, kept programs have tools and a sweep, and the input goes by reference with a size bound. The glossary gains "seat list", used as a term by ADR 0635, ADR 0636 and design 47 without an entry, retiring "seat set" in hq; four designs take the word, and issue 299's narrative keeps its day's word by an allowance row. Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i --- 00-META/checks/words-allowed.md | 1 + 00-META/glossary.md | 7 + 03-DESIGN/01-to-be/26-the-seats.md | 6 +- .../29-a-node-has-operator-accounts.md | 4 +- .../30-the-mesh-updates-itself-on-a-push.md | 4 +- .../46-the-conversation-with-the-operator.md | 6 +- .../47-delivery-from-commit-to-delivered.md | 133 ++++++++++++------ 7 files changed, 111 insertions(+), 50 deletions(-) diff --git a/00-META/checks/words-allowed.md b/00-META/checks/words-allowed.md index 00573fc1..739608b2 100644 --- a/00-META/checks/words-allowed.md +++ b/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 | diff --git a/00-META/glossary.md b/00-META/glossary.md index 7f676c51..d3740f38 100644 --- a/00-META/glossary.md +++ b/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 diff --git a/03-DESIGN/01-to-be/26-the-seats.md b/03-DESIGN/01-to-be/26-the-seats.md index e31702ed..6fb58ecc 100644 --- a/03-DESIGN/01-to-be/26-the-seats.md +++ b/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 diff --git a/03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md b/03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md index a6c2c31d..a1e7f63d 100644 --- a/03-DESIGN/01-to-be/29-a-node-has-operator-accounts.md +++ b/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: diff --git a/03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md b/03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md index 13e81d70..93900f8d 100644 --- a/03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md +++ b/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. diff --git a/03-DESIGN/01-to-be/46-the-conversation-with-the-operator.md b/03-DESIGN/01-to-be/46-the-conversation-with-the-operator.md index 1dc7ecc1..140fe027 100644 --- a/03-DESIGN/01-to-be/46-the-conversation-with-the-operator.md +++ b/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 diff --git a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md index e3cee7bb..e3aa61da 100644 --- a/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md +++ b/03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md @@ -728,20 +728,22 @@ 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.`), 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 digest in the + build seat's objects, laid as a file, and writes the program's exit, and its output by digest, 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.`), 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 +1243,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 +2376,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..` 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 +2411,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 +2420,60 @@ 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, built at the + heads the carry merged onto the new trunk; the running checker's own rules judge no check after B0's delivery. The + program is built at the change's mesh-delivery member's head when it has one, else at mesh-delivery's trunk, as the + manifest validator is chosen today, and once per build: a trunk move that leaves the checking program unchanged asks + no new build. 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 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 no build module begins within the first tier's bound (*What ADR 0656 leaves to this design*) is put again once; when that one is not begun either, the check fails naming the missing job `run` | 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 old build modules run beside the new checker until B0 reaches every build node, because `run` is a job inside the accepted kind `check`, not a served verb, and so no edge of the module graph orders the two. 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: a tool lists them (key, size, last use), a tool drops one, and old ones are swept as its workspaces are | 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) and its answer (the seat list, the verdict) go by reference, by digest in the build seat's objects as a compose ask carries its manifests, and an input over its bound is refused before the ask, naming its size | a group's facts grow with its members, and an ask or a step key 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 `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 form is versioned, and a program that does not read the version it is given fails the check, naming the version | milestone G's own check is run by B0's checker, 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. The build module's step tools read a + `run` ask's step as they read every step, and its new tools 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 @@ -2441,13 +2483,18 @@ order inside one milestone, for this one case (ADR 0644). 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. + 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; a fixture build module that + drops a `run` ask fails the check within the bound, 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, 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 its tools list, drop and sweep kept programs (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 +2533,12 @@ 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. + 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