Merge pull request 'Try before the review, fail first on behaviour, survey every reader of a changed value (playbooks 07 and 08)' (#433) from docs/review-speed into main

Research 063 graduated into ADR 0429 and this design (playbook 02 step 3).
The design names the parts and the releases; its other sections hold until
each release is delivered and are rewritten as each is prepared (issue 1130).
The words the plans use are marked as going at release 6, not struck: they
stay true until that release is delivered.

00-META/glossary.md

@@ -227,7 +227,7 @@ every other domain has something to run on. **Recorded by** the controller and t
   the two and raises `mirror-drifted` on any difference
   (ADR 0289, ADR 0356). Builds, rollouts and assignments are no mirrors: they are
   the chain, kept on the bus as their only source (ADR 0408). Shortened to *mirror* where the
-  text is about the controller's records; the builder's *mirrored* `upstream` image (Change and delivery) is
+  text is about the controller's records; the builder's *mirrored* `upstream` image (Delivery) is
   a different thing, a copy of an outside image in the artifact store.
 
 ## Placement — what runs on which node
@@ -343,7 +343,7 @@ and vault (Identity and access).
 
 **Purpose.** To issue, hold, rotate and check the credentials and grants by which modules, nodes, agents
 and the operator act. **Recorded by** the controller's `identity` and `licences` databases and the vault.
-**Upstream of** Provisioning, Change and delivery, and Operator and conversation.
+**Upstream of** Provisioning, Delivery, and Operator and conversation.
 **Decided by** ADR 0085, 0113, 0183, 0225, 0234, 0386, 0387, 0388, 0411, 0413, 0414.
 **Uses:** module, node, seat, tool (Module), operator, consumer and provision (Provisioning), agent and ask (Operator and conversation).
 
@@ -397,12 +397,13 @@ and the operator act. **Recorded by** the controller's `identity` and `licences`
   agent can run as that account: the control-node, and a node whose agents run under an account of their own
   (ADR 0272).
 
-## Change and delivery — a commit on its way to the nodes
+## Delivery — a commit on its way to the nodes
 
 **Purpose.** To take one commit from its pull request to every node that should run it, and to put it
-back when it fails. **Recorded by** the `mesh-delivery` module (deliveries) and the controller (the
+back when it fails. The domain is continuous integration and delivery, named **delivery**, and its parts live in
-planner, the rollout). **Downstream of** Module, Core, Health and repair and Data.
+the repository `mesh-delivery` (ADR 0429 §2). **Recorded by** the `mesh-delivery` module (deliveries) and the
-**Decided by** ADR 0162, 0218, 0236, 0237, 0238, 0239, 0250, 0267, 0270, 0276, 0323, 0401–0408.
+controller (the planner, the rollout) until release 6 of ADR 0429; from each release on, by the parts it builds. **Downstream of** Module, Core, Health and repair and Data.
+**Decided by** ADR 0162, 0218, 0236, 0237, 0238, 0239, 0250, 0267, 0270, 0276, 0323, 0401–0408, 0428, 0429.
 **Uses:** module, node, declaration and send (Placement), health (Health and repair), person.
 
 - **merge check** — the two statuses a pull request carries before it may merge: the **merge gate**
@@ -473,24 +474,58 @@ planner, the rollout). **Downstream of** Module, Core, Health and repair and Dat
 - **delivery plan** — what a delivery does to the mesh: its **build plan** (the modules it moves and
   their dependents, in tiers), its **deploy plan** (per node, what it receives and what waits for a
   person) and its verdict (the composed nodes, the replays). Computed by the controller's planner from a
-  diffset; the controller's verb `delivery-plan` shows it. *Deploy* is used in this one place.
+  diffset; the controller's verb `delivery-plan` shows it. *Deploy* is used in this one place. Deleted at
+  release 6 of ADR 0429 (§8): the word stays in use until that release is delivered, and then retires.
   *Not:* ~~change plan~~, ~~release plan~~
 - **merge window** — the rolling wait in which the controller collects merges before it plans them: each
   merge restarts it, and it closes when none arrived for its length (90 seconds by default) or at the latest
   10 minutes after its first merge (ADR 0276). Kept as two keys with a time to live on the bus; the first to
-  expire closes the batch (ADR 0407).
+  expire closes the batch (ADR 0407). Goes at release 6 of ADR 0429, when nothing collects merges (§12).
 - **batch** — the merges one merge window collected, planned once as one rollout. For a repository merged more
   than once in it, the rollout takes the latest commit, and the earlier merges are answered by it. Not *group*,
-  which is a delivery group.
+  which is a delivery group. Goes at release 6 of ADR 0429 (§11, §12).
-- **mesh-delivery** — the module that owns deliveries and delivery groups, holding the mesh-scoped seat
+- **mesh-delivery** — the repository of the delivery domain, holding its parts as modules prefixed
-  of the same name. It records and decides; the controller sends, judges and rolls back when it is asked.
+  `mesh-delivery-` (ADR 0429 §2), made by the forge module from its config (ADR 0428). Until release 3 of
+  ADR 0429 also the module in the catalogue that owns deliveries and delivery groups, holding the mesh-scoped
+  seat of the same name: it records and decides, and the controller sends, judges and rolls back when it is
+  asked. Release 3 splits that module into the parts, and then the name means the repository alone.
+- **part** — one independent process of the delivery domain with its own bus credential, which watches keys
+  and writes keys and never calls another part (ADR 0429 §1). Each key has one writer; the operator's
+  credential may also write a want, the one manual escape. The parts: the **forge bridge** (forge events in,
+  the only caller of the forge), the **indexer** (fingerprints, the candidates of a group, the modules of the
+  trunk), the **builder** (claims and builds one fingerprint once), the **checker** (the merge check on built
+  artifacts), the **gate** (merges a group and moves the source revision; *gate part* where it could be read
+  as another gate, see [Homonyms](#homonyms)), the **teller** (the operator's phone, and the only writer of an
+  ask's answer), the **assigner** (writes each node's wants by its six rules), the **node agent** (the
+  node-engine's own process, applying its wants), the **watchman** (presence and pulses) and the **status
+  view** (`mesh-delivery-cli` and a web view, writing only its answers to asks). The reviewer is the review
+  agent's session, not a part. Built over releases 1 to 6 of ADR 0429.
+- **fingerprint** — what identifies a module's build by its content: a hash over its source files, its
+  manifest and the fingerprints of its build-time inputs, so equal content gives an equal fingerprint whatever
+  the commit (ADR 0429 §5). It is today's source fingerprint with a base entering by its module's
+  fingerprint, the builder by its own module's fingerprint, and a build resolving packages by its lock. From
+  release 4 a build's key, so one source is never built twice.
+- **source revision** — one revision of the key `source.main`, written only by the gate: every repository's
+  merged head and the group that moved it. A group reaches the mesh as one source revision (ADR 0429 §11); a
+  source revision is **delivered** when every want equals its module's fingerprint and every have equals its
+  want and is healthy, derived from the keys and recorded by no part (§1).
+- **canary** — the first node of a module's nodes, ordered by ring then name: a new fingerprint reaches it
+  first and the module's other nodes only once it runs healthy there (ADR 0429 §6). Replaces sending to every
+  machine at once from release 6 (§15).
+- **want** and **have** — a want (`want.<node>.<module>`) is the fingerprint a node should run, written by the
+  assigner; a have (`have.<node>.<module>`) is what the node runs, its phase and health, written by that node's
+  agent (ADR 0429 §4, §6). A node's facts that no module owns are its node key. They replace assignments and
+  rollouts at release 6 (§17); haves are written from release 1.
+- **pulse** — a key the watchman writes for each key whose next move a machine owes, with a time to live; its
+  expiry is a stall, raised as a condition, so no part needs a timer (ADR 0429 §1, research 063). A person's
+  wait carries none.
 - **rollout** — the controller's sending of one batch's builds across nodes, at most one trunk commit per
   repository, tier by tier, to every node that runs each module at once (ADR 0276, ADR 0360). Rollouts that share a
   repository, a module or a graph edge run one after another; others run side by side (ADR 0407). It names every
   merge it answers, and its record is one key of the bus's rollouts bucket, a link of the chain (ADR 0408). A primitive the delivering stage
   asks for, not an object anyone manages. A **tier** is one step of a rollout: a module, then the modules
   built against it. The controller's verb `plans` lists the rollouts. A module is rolled out by its `roll`
-  policy.
+  policy. Rollouts and tiers go at release 6 of ADR 0429 (§8, §15), replaced by wants and haves (§17).
   *Not:* ~~walk~~ (hq)
 - **first-node gate** — the judgement on a delivery's first node: healthy three times, no witness put it
   back, no condition raised since the send (ADR 0236 §2). Not *the gate* bare (see [Homonyms](#homonyms)).
@@ -520,7 +555,7 @@ planner, the rollout). **Downstream of** Module, Core, Health and repair and Dat
 
 **Purpose.** To notice what is wrong with the mesh, say it once, repair what may be repaired unattended,
 and record what was done by hand. **Recorded by** the controller's condition store.
-**Upstream of** Change and delivery (the first-node gate) and Operator and conversation (a condition
+**Upstream of** Delivery (the first-node gate) and Operator and conversation (a condition
 becomes a message). **Decided by** ADR 0227, 0231, 0240, 0252, 0283.
 **Uses:** node, module, node-engine (Core).
 
@@ -562,7 +597,7 @@ becomes a message). **Decided by** ADR 0227, 0231, 0240, 0252, 0283.
 
 **Purpose.** To know every item of data a module holds, how precious it is, and to keep it recoverable.
 **Recorded by** the manifests' `data` declarations and every node's `node-backup` seat.
-**Upstream of** Change and delivery and Health and repair. **Decided by** ADR 0232, 0233, 0235.
+**Upstream of** Delivery and Health and repair. **Decided by** ADR 0232, 0233, 0235.
 **Uses:** module, node, provider and consumer (Provisioning), person.
 
 - **data class** — how precious an item of data is, ranked by the operator: `irreplaceable`,
@@ -609,10 +644,10 @@ it should not. **Recorded by** the controller. **Upstream of** Provisioning and
 
 **Purpose.** To let the mesh and its operator talk: tell, ask, answer, and act only on an answer it can
 trust. **Recorded by** the router (asks, warrants and the operator's identities).
-**Downstream of** Health and repair, Change and delivery, and Identity and access. An authorising
+**Downstream of** Health and repair, Delivery, and Identity and access. An authorising
 answer acts in whichever domain asked, through that domain's own verb; the conversation owns the
 asking, never the act. **Decided by** ADR 0152, 0175, 0234, 0259, 0272, 0383, 0384, 0385, 0390.
-**Uses:** operator, person, node, module, seat, tool (Module), proof and identity (Identity and access), release (Change and delivery).
+**Uses:** operator, person, node, module, seat, tool (Module), proof and identity (Identity and access), release (Delivery).
 
 - **mesh MCP server** — the endpoint on a node's loopback through which every agent and person on that
   node reaches the mesh: the MCP server named `mesh`, with its five tools `mesh_overview`,
@@ -804,22 +839,24 @@ renaming one sense, the old sense moves to a *Not:* line and becomes mechanical.
 | Word | Sense | Say | Domain |
 |---|---|---|---|
 | plan | what the controller would send one node | that node's **declaration** (verb `plan`) | Placement |
-| | what a delivery would do to the mesh | **delivery plan** | Change and delivery |
+| | what a delivery would do to the mesh | **delivery plan** | Delivery |
-| | the sending of one batch of commits across nodes | **rollout** (verb `plans`) | Change and delivery |
+| | the sending of one batch of commits across nodes | **rollout** (verb `plans`) | Delivery |
 | | a step a person starts, like the bus's | **planned step** | Core |
 | membership | the subjects a bus account is issued | **membership** | Provisioning |
 | | an account in a group of the machine | **account group** | Placement |
 | push | the controller giving nodes their declarations | **send** (verb `push`) | Placement |
 | | a git push | **git push** | The record |
 | | a phone notification | **push notification** | Operator and conversation |
-| release | a person letting a held delivery go on | **release** | Change and delivery |
+| release | a person letting a held delivery go on | **release** | Delivery |
+| | one milestone built, checked and delivered as one (playbook 07; releases 1 to 6 of ADR 0429) | **release** of a milestone | The record |
 | | taking a consumer off a licence | **unbind** (verb `release`, to rename) | Identity and access |
 | | a copy of a work an engine can fetch | **media release** | Media |
-| gate | the judgement on a delivery's first node | **first-node gate** | Change and delivery |
+| gate | the judgement on a delivery's first node | **first-node gate** | Delivery |
-| | the pull request status | **merge gate** | Change and delivery |
+| | the pull request status | **merge gate** | Delivery |
+| | the part that merges a group and moves the source revision | **gate part** (`mesh-delivery-gate`) | Delivery |
 | | a failed step stopping its module's later steps (ADR 0136) | *a failed step holds its module* | Placement |
 | tier | a level of the mesh | **layer** | Core |
-| | a step of a rollout | **tier** | Change and delivery |
+| | a step of a rollout | **tier** | Delivery |
 | | how much proof an ask needs | **assurance level** | Identity and access |
 | harness | the part of `mesh-sdk` that serves a tools bundle | **SDK harness** | Module |
 | | the program that runs an agent's sessions | **agent harness** | Operator and conversation |
@@ -827,9 +864,9 @@ renaming one sense, the old sense moves to a *Not:* line and becomes mechanical.
 | role | what a seat names, at a scope | **seat**; the bare word in older designs is tracked by issue 872 | Module |
 | | what an identity may call | **role** | Identity and access |
 | ask | a request for the operator's input | **ask** | Operator and conversation |
-| | an entry in the build queue | **build request** | Change and delivery |
+| | an entry in the build queue | **build request** | Delivery |
 | store | the one database server | **store** | Core |
-| | the OCI registry | **artifact store** | Change and delivery |
+| | the OCI registry | **artifact store** | Delivery |
 | | a node's own copy of its last declaration | **last declaration** | Placement |
 | record | a numbered decision | **decision record** | The record |
 | | the literal reader of this repository, searched first for a symptom | **the record** (the `records` module) | Operator and conversation |
@@ -838,19 +875,19 @@ renaming one sense, the old sense moves to a *Not:* line and becomes mechanical.
 | | the operator's terminal command, `mesh-cli` | **the `nox` command** | Operator and conversation |
 | knowledge base | the module holding the decision records and research efforts whole | **knowledge base** | The record |
 | | the predecessor's operational memory, in older playbooks (issue 430) | none: it no longer exists | — |
-| check | a pull request's two statuses | **merge check**, **merge gate**, **repository check** | Change and delivery |
+| check | a pull request's two statuses | **merge check**, **merge gate**, **repository check** | Delivery |
-| | a delivery group's verdict | **composed check** | Change and delivery |
+| | a delivery group's verdict | **composed check** | Delivery |
 | | the controller's own examination | **self-check** | Health and repair |
 | | a file in `00-META/checks/` | **hq check** | The record |
 | agent | a coding agent | **agent** | Operator and conversation |
-| | the build seat's holder | **builder** | Change and delivery |
+| | the build seat's holder; from release 4 of ADR 0429 the part `mesh-delivery-builder` | **builder** | Delivery |
 | the user | an account of a wrapped program, or of the bus server | **its account**, **bus account** | Identity and access |
 | | a human | **operator** or **person** | words every domain uses |
 | firewall | what the mesh enforces | **packet filter** | Connectivity |
 | | what was found on a machine | **found firewall** | Connectivity |
 | ticket | an answer's one-time token (ADR 0258) | **answer ticket** | Operator and conversation |
 | | a question someone must answer | **issue** | The record |
-| deploy | the per-node part of a delivery plan | **deploy plan** | Change and delivery |
+| deploy | the per-node part of a delivery plan | **deploy plan** | Delivery |
 | | a wrapped program's own deploy | its own word | — |
 | managed | a placed file of which only named keys or a marked block are the mesh's | **managed** (`owner-at-runtime`) | Provisioning |
 | | a file the mesh writes, such as the agent's instruction file or `managed_settings` | the file's own name, or *a file the mesh places* | — |

00-META/process/00-overview.md

@@ -57,7 +57,7 @@ the expensive half.
 | [05](05-constitution-sync.md) | Constitution sync | `how-we-build.md` changed a rule the mesh enforces |
 | [06](06-writing-a-module.md) | Writing a module | Something that runs today must run on the mesh |
 | [07](07-feature-branches.md) | Features | Work that changes code across issues or repositories: prepared context, local development, one review, one check, one delivery |
-| [08](08-small-fixes.md) | Small fixes | One issue in one repository, about an hour of work: one review, one push, one delivery |
+| [08](08-small-fixes.md) | Small fixes | One issue in one repository, about an hour of work: one try, one review, one delivery |
 | [09](09-cleanup.md) | Cleanup | Merged branches, stale pull requests, finished worktrees and folders: read first, delete only what the operator approves, report the rest |
 
 ## The cycle is checked

00-META/process/02-graduation.md

@@ -94,7 +94,10 @@ about an hour, and said to the operator if it runs past.
    deferral no issue tracks. The knowledge base then reviews the proposal itself, through a judgement that
    sees only the record, the records it links and the rules, and answers `approve` or `changes`. On
    `changes` the record stays proposed with the findings: revise it by proposing it again, whole, with `why`;
-   at most three rounds, then the findings go to the operator with a recommendation.
+   after three rounds the lead does not stop to ask, but fixes each further finding itself and proposes again
+   (the operator, 2026-10-18: ADR 0429 went past three rounds, each finding narrower than the last, and asking
+   first only added a wait). Only a finding that would change what was decided, rather than how the record
+   says it, goes to the operator, with a recommendation.
    On `approve` it is accepted, or, when it says `needs-operator`, it waits for the operator's Approve on a
    channel that proves who answered. Nothing proposed is in force. `knowledge-base.get` shows a record's
    reviews and the operator's ask when it waits for one.
@@ -164,3 +167,5 @@ when one fails. In this repository, `records.py` checks that a design's `decisio
 order's six topics, which the knowledge base reads. The three habits of graduating step 2 (side by side, clauses
 from the direction, the pre-check) are the lead's, read by the reviewer; `propose` refuses a link to nothing,
 a deferral no issue tracks and a retired word, and the review returns a record named but not linked.
+The rounds are read in `knowledge-base.get` (its reviews, one per version): a question to the operator about a
+record's wording after its third round is the failure of step 4 of *Writing a decision record*.

00-META/process/04-build-handoff.md

@@ -17,7 +17,11 @@ A design becomes **milestones**, and each milestone becomes **issues**:
 - **Milestones are cut by release order.** A milestone ends where one repository's change must be released before
   another can use it (a new manifest word before the catalogue reads it, an SDK change before its users, until
   design 47's milestones 3 and 6 lift those orders); the lead checks this when cutting, so no milestone needs a
-  second release.
+  second release. The orders to look for are those playbook [07](07-feature-branches.md) step 0 item 6 names (an SDK
+  change before its users, a new wire key before the node that reads it, the first module of a repository the catalogue
+  never built, a part that needs a decision first); a milestone cut by such an order may be usable only by the next one,
+  and says so in its outcome. A milestone the prepare step finds holding such an order is split into milestones in the
+  design, each one release, never carried as parts of one (2026-10-18: design 47's release 1-2 became six).
 - **An issue is one repository's part of a milestone,** sized so a fixing agent finishes it inside the
   milestone's development time. Issues that must land in order are linked `depends-on`.
 

00-META/process/07-feature-branches.md

@@ -30,6 +30,11 @@ A small fix (one repository, one issue, about an hour of work) follows
 - **A green pull request nobody marks.** An approved, green pull request that was not marked ready waited
   12 h 17 min for someone to merge it (mesh-catalog #300, 2026-10-14). There is no ready mark since ADR 0421:
   the operator's Approve is asked as soon as the checks pass.
+- **Review rounds spent on what a run or a search would have shown.** On 2026-10-19 milestone R3b of design 47
+  took two review rounds and one more cycle after a failed try. A test that "failed first" only by not compiling
+  proved nothing, and dropping the field it was for passed every test. A reader of the changed record that the
+  survey never listed ended a module's conditions at each sync. The reviewer judged the bus tests by reasoning, and
+  wrongly, because they ran only after the review.
 - **A module proven only after it reached the machines.** The mail modules were delivered with unit tests
   only, then failed live three times (issues 859, 865, 868) and took five more hours of fixes.
 
@@ -42,13 +47,13 @@ opened **once**, after the review. It runs in five steps, and its time is bounde
 | Step | What happens | Bound |
 |---|---|---|
 | 0. Prepare | the lead settles the open questions and writes one context file per repository | 15 minutes |
-| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit | the milestone's issues, 30 minutes each |
+| 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit; then each branch is pushed and tried | the milestone's issues, 30 minutes each, and one try |
-| 2. Review | one reviewer reads all of it; reports go both ways; at most 3 rounds | 15 minutes |
+| 2. Review | one reviewer reads all of it with the tries' results; reports go both ways; at most 3 rounds | 15 minutes |
-| 3. Check | push; the forge's merge checks run the integration tests; no further review | one check run |
+| 3. Check | push the reviewed heads; a head the review changed is tried again; then the pull requests are opened and the forge's merge checks run the integration tests again; no further review | at most one more try and one check run |
 | 4. Deliver | merge; the delivery plan builds, publishes and sends the whole feature | its delivery plan |
 
-**One milestone is one release** (the operator, 2026-10-17). A milestone is developed whole, reviewed once,
+**One milestone is one release** (the operator, 2026-10-17). A milestone is developed whole, tried before its review, reviewed once,
-pushed once and delivered once. It is never cut into steps for its size or for time: every cut adds a review, a
+opened once and delivered once. It is never cut into steps for its size or for time: every cut adds a review, a
 merge check, an Approve and a delivery plan of waiting, so the fewest cuts is the fastest. Milestones are cut by
 release order when the design is broken up (playbook [04](04-build-handoff.md)); a release-order dependency found
 inside a milestone is a fault of that cut, said to the operator, never a silent extra step.
@@ -87,13 +92,16 @@ never into the running one, unless it blocks the running one.
    - what not to touch, and what lands beside it in other repositories;
    - the local facts: the worktree, the branch, the check commands, a temporary directory for tests outside
      the home (`TMPDIR`), and the unit tests to run (never a database server: tests that need one are
-     integration tests, which the forge's checks run).
+     integration tests, which `mesh-controller.try` and the forge's checks run).
    When the reading is large, a read-only agent on the smaller model answers the lead's exact questions with
    file:line, and the lead writes the file from its answers.
 5. **Write the findings into the issues** (the operator, 2026-10-17: the better the content of the issues, the
    better work the agents do, and the less review is needed). Before any agent starts, each issue carries, with
    `issue-tracker.note`: every file and test that touches the change, found by search and not from memory
-   (file:line); how the change is checked and delivered end to end (which test proves its done-when, which
+   (file:line); **every other reader and writer of each value the change adds or changes** (a field, a key, a kind
+   of record), each with what it does with the new value, and a criterion for each that could treat it wrongly
+   (2026-10-19: the router's sync with the controller ended every condition the controller did not list, and the
+   survey, which followed only the new condition's own path, never named it); how the change is checked and delivered end to end (which test proves its done-when, which
    modules its delivery plan moves, to which machines); and for a group, its merge order. The context file
    points to these notes; an issue reread by another session or a later agent then holds what was found.
    When the reading is large, it starts with a read-only survey agent on the smaller model.
@@ -111,7 +119,19 @@ never into the running one, unless it blocks the running one.
    2026-10-17), into issues of about 30 minutes each, one change each, in the order they land: the bound of a
    fixing agent's issue is then a real bound. On 2026-10-17 one issue held four changes sized at four to six
    hours; it ran past its 30-minute bound for over an hour, and the reports could only say "still on part D".
-6. **Move the issues to `fixing`**, `by` naming the feature's agent for that repository.
+6. **Look for the orders a release hides, before any agent starts** (2026-10-18: design 47's release 1-2 was cut
+   as one milestone and its prepare step found three orders inside it, each a cut of its own). Read, for each
+   repository of the release, what it takes from the others and how: an SDK change still ships before its users
+   (they vendor a pinned SDK, and a pin to a commit no branch holds is a download that fails later, issue 1148);
+   a new key on the wire between the controller and the node-engine is sent only to a node that says it reads it,
+   since the node-engine's decoder refuses an unknown key; the first module of a repository the catalogue has never
+   built registers only by the route the controller allows for it; and a part that needs something the bus or a
+   manifest cannot yet give (an event only a system account hears, a bucket whose keys expire) needs its decision
+   first. Each order found is said to the operator with the cut it asks for, never built around.
+7. **Write fixtures from the shape the other side writes, never from memory** (2026-10-18: a watchman's tests
+   mirrored a build key the controller never writes, and every test passed): copy a value from the writer's code or
+   from the live bus, and name where it came from.
+8. **Move the issues to `fixing`**, `by` naming the feature's agent for that repository.
 
 ## Step 1 — Develop (one fixing agent per repository, smaller model)
 
@@ -121,21 +141,28 @@ never into the running one, unless it blocks the running one.
   the next instruction, so its context is paid for once.
 - **Unit tests only, each well under a second** (how-we-build §5, ADR 0391). **The whole unit suite runs before
   every commit** (the operator, 2026-10-17), not only the tests of what changed: it takes under a second, and a
-  change breaks tests in packages it never touched. Each issue's first test fails before its change and passes
+  change breaks tests in packages it never touched. Each issue's first test fails before its change, on an assertion about what the
-  after; `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's
+  code does, and passes after. **A test that fails only because it does not compile has not failed first**: where
+  the test calls what the change adds, the agent takes out the change's effect (the line that does it, not the new
+  function), sees the test fail, and puts it back (2026-10-19: a check request's new field was proven by a test of
+  its helper alone, and dropping the field from the request passed every test); `gofmt`, `go vet` and the whole unit suite stay green. **The tests are written from the issue's
   acceptance criteria**: one test or more per criterion at the level it names, each test's comment citing
   the criterion it proves by its label (`// 1118/AC2`), and no criterion left without its test; an integration criterion is a test
-  that compiles and waits for the check step. The integration tests (`merge-check.sh` with the store and the
+  that compiles and waits for the try at this step's end. The integration tests (those that start a store, a bus
-  bus) wait for the check step.
+  or a process) are run first by that try, and again by the forge's merge check.
-- **Nothing is pushed** and no pull request is opened in this step. Never land on a red check: run the
+- **No pull request is opened in this step. When every issue is committed, the lead brings each feature branch up
+  to the current trunk (fetch by name, then merge), pushes it and tries it** (`mesh-controller.try`, as step 3 item 1 says), so the review reads the integration tests' real
+  results and judges none by reasoning (2026-10-19: a reviewer reasoned that a warning goes out at once, the
+  router holds it 30 s, and the try after the review found it). A failed try goes back to the same fixing agent
+  with its whole log, read as step 3 item 3 says, before the review starts. Never land on a red check: run the
   checks, read the result, then land in a separate step.
 - **The fixing agent's brief** (the lead gives it with the context file): name your issue in every step and
   message ("issue 805: landing in mesh-catalog"); reach the mesh only through the mesh MCP server, never ssh;
   never push, open, merge or close a pull request; never write to a store's database by hand, a schema change
   is a numbered migration and the consolidated schema; Go only unless the context file says otherwise; never
-  move another issue; **never run an integration test locally** (no `go test -tags integration`, no `merge-check.sh`,
+  move another issue; **never run an integration test on the machine** (no `go test -tags integration`, no `merge-check.sh`,
-  no bus or store test run): compile them with `go vet -tags integration ./...` and leave the running to the
+  no store or bus started by hand): compile them with `go vet -tags integration ./...` and leave the running to
-  forge's merge check. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the
+  the lead's try at the end of this step, where `mesh-controller.try` runs them on the pushed branch. On 2026-10-17 three fixing agents ran them anyway, one for minutes on end, because the
   brief only said they wait for the check (the operator). Report back in under 150 words: commits, tests added and that they failed first, the
   check results, anything you stopped on.
 - **An agent that finds the code differs from its context file stops and reports** (file:line); the lead
@@ -150,8 +177,9 @@ never into the running one, unless it blocks the running one.
 
 ## Step 2 — Review (one reviewer, larger model; at most 3 rounds, about 15 minutes)
 
-1. **Bring every feature branch up to the current trunk** (fetch by name, then merge), so the reviewed tree is
+1. **The reviewed tree is the tree that was tried**: every feature branch was brought up to the current trunk
-   the tree that is pushed.
+   before its push and try (step 1). A try and a merge check each run on the merge with the trunk as it is then, so a
+   trunk that moves later is met by the forge's merge check, not by another merge here.
 2. **One reviewer reads every repository's local commits** together, against the context files and the
    decisions. **It is one agent, kept for the whole release** like the fixing agents: the lead continues it by
    its id for every later round, for the extra cycle after a failed check (step 3) and for its review record, so it
@@ -160,7 +188,7 @@ never into the running one, unless it blocks the running one.
    It says which round it is in ("round 1 of at most 3").
 3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix
    with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not.
-4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086).
+4. **Every new integration test is read against the code it drives and against its try.** Fixing agents only compile it, and its one run before the review is the try (step 1), which shows whether it passed but not whether it proves what it says. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086).
 5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 7 says what a round
    may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation.
 6. **The reviewer reads every acceptance criterion against its test**: each criterion has a test at its level
@@ -174,9 +202,15 @@ never into the running one, unless it blocks the running one.
 
 ## Step 3 — Check (no review)
 
-1. **Push every feature branch and open one pull request per repository, together.**
+1. **Push the reviewed heads, try again a head the review changed, then open one pull request per repository,
-   The integration tests
+   together.** **The integration tests run before the pull requests are opened**, first before the review (step 1)
-   run only in the merge check (the operator, 2026-10-16), never before. Pull requests in two or
+   and again for a head the review changed since its try: `mesh-controller.try` with the
+   repository and the pushed branch runs the repository's `merge-check.sh` (main's version) on the merge, in the
+   toolchain containers and against the throwaway store and bus a merge check gets, and answers with an id to
+   read back. A try that fails goes to step 3 item 3 as a failed check does; the pull requests are opened only
+   when every head's last try passed (the operator, 2026-10-18: three pushes in a row failed their first merge check on
+   faults a try finds in minutes). Never `merge-check.sh`, `go test -tags integration` or a store or bus started
+   by hand on the machine (the operator, 2026-10-18). Pull requests in two or
    more repositories that share the branch name are one delivery group (ADR 0239 §2).
    Where a session pushes through the forge tool `gitea_commit` (one commit on the forge's current base), the
    reviewer first confirms that commit's tree equals the reviewed one. **Each pull request's description carries
@@ -184,7 +218,7 @@ never into the running one, unless it blocks the running one.
    `Reviewed-by: <who@node> at <full sha>` (the issue 1022 note gives its form). mesh-delivery reads it at every new
    head and puts it in the Approve's ask; a missing line, or one naming another commit, is said first in the ask.
    It is never a gate.
-2. **The forge's merge checks run the integration tests once** (`mesh/merge-gate`, `mesh/repo-check`). No
+2. **The forge's merge checks run the integration tests again, as the gate** (`mesh/merge-gate`, `mesh/repo-check`). No
    second review: step 2 reviewed this tree.
 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with
    the same fixing agents; then push once again. **The failure is read from the check's whole log**, never

00-META/process/08-small-fixes.md

@@ -18,8 +18,8 @@ hour is a feature.
 
 ## The aim
 
-A small fix spends its time on the fix, and runs the long part once: **one review, one push, one check run,
+A small fix spends its time on the fix, and runs the long part once: **one try before the review, one review, one check run,
-one delivery**. Everything before the push is local and fast.
+one delivery**. Everything before the try is local and fast.
 
 ## Steps
 
@@ -34,26 +34,28 @@ one delivery**. Everything before the push is local and fast.
 2. **Move the issue to `fixing`** with `by` as who@node.
 3. **Build on a local branch** `fix/<issue>-<slug>`, in a worktree of its own branched from `main`, never in
    the repository's own clone, which stays on `main` (playbook [07](07-feature-branches.md), step 0, item 2). Write the
-   test that fails today first; make the change; keep `gofmt`, `go vet` and the repository's whole unit suite green
+   test that fails today first, on an assertion about what the code does: a test that fails only because it
+   does not compile has not failed first (playbook [07](07-feature-branches.md) step 1); make the change; keep `gofmt`, `go vet` and the repository's whole unit suite green
    before every commit (each test well under a second; never a merge check or a database locally: how-we-build §5, ADR 0391).
    The tests are written from the acceptance criteria, at least one per criterion at its level, each citing the
    criterion it proves by its label (`<issue>/AC<n>`, playbook 07 step 0 item 5). Commit, naming the issue. For a playbook or design edit, run the repository's own checks (in hq,
-   `sh merge-check.sh`).
+   `sh merge-check.sh`). Then push the branch and run `mesh-controller.try` on it, so the review reads the
-4. **One review of the local commit, before anything is pushed** (a reviewer that did not write it, larger
+   integration tests' real results; a failed try goes back to the same agent before the review.
+4. **One review of the commit and its try** (a reviewer that did not write it, larger
    model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; it reads each acceptance criterion
    against its test, as playbook 07 step 2 item 6; a finding outside the issue's done-when and its acceptance
    criteria is opened as an issue of its own, never asked as a change). The reviewer's findings go back to the same agent that wrote the fix, continued by
    its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
    operator's Approve of its merge is its review, and the review record says so.
-5. **Push once and open the pull request.** The trunk is what runs and nothing holds merged work back
+5. **Push the reviewed head, try it again if the review changed it, and open the pull request.** The trunk is what runs and nothing holds merged work back
-   (ADR 0401), so a fix waits for no other change's delivery. The forge's merge
+   (ADR 0401), so a fix waits for no other change's delivery. `mesh-controller.try` on the pushed branch runs
-   check runs the integration tests, the only
+   the integration tests, and the pull request is opened only when the head's last try passed; the forge's merge check runs
-   place they run (the operator, 2026-10-16). A failed check
+   them again as the gate (playbook [07](07-feature-branches.md) step 3). They are never run on the machine. A
-   goes back to the same agent with the failure, and the reviewer reads only the change it makes.
+   failed try or check goes back to the same agent with the failure, and the reviewer reads only the change it makes.
 6. **The pull request's description carries the review record** (`Reviewed-by: <who@node> at <full sha>`,
    playbook [07](07-feature-branches.md) step 3), and mesh-delivery asks the operator's Approve as soon as its
    checks pass and merges the approved head (ADR 0421); nobody marks, labels, comments or rechecks. A fix to a module that changes how it runs carries an
-   integration test starting the module whole against the real bus and store, run by the forge's checks
+   integration test starting the module whole against the real bus and store, run by `mesh-controller.try` and the forge's checks
    (ADR 0391 §1, §6); unit tests alone are not that proof, and the lab is not used. The operator's word is waited for only when the fix changes what the operator sees, removes data,
    or needs the operator's terminal.
 7. **Follow its delivery plan to done** (`mesh-controller.plans` with `wait` and `until: done`), prove the fix on

00-META/repos.md

@@ -36,6 +36,7 @@ one-for-one — `mesh-catalog`, `mesh-sdk` and `mesh-tools` exist where the tabl
 | `mesh-surfaces` | 3 | tools, web, cli |
 | `mesh-sdk` | — | the stable spine modules build against — the tool-serving SDK harness, the messaging/event framework, the contracts and core primitives. Holds nothing per-module and nothing volatile (ADR 0039). |
 | `mesh-lab` | — | **exists.** The lab — scenario lifecycle, networking, placement. Ships to nobody; runs on a workstation. |
+| `mesh-delivery` | — | the delivery domain: the parts that build, check and deliver a change by watching and writing keys on the bus, nine modules each whole in it, prefixed `mesh-delivery-` (ADR 0429). Made by the forge module from its config (ADR 0428). |
 
 Tier 4's shape is open, and deliberately so: see ADR 0019 and
 research 005.

03-DESIGN/00-as-is/16-logins-on-the-bus.md

@@ -2,9 +2,11 @@
 layer: as-is
 status: implemented
 code: [mesh-controller, mesh-tools]
-updated: 2026-10-16
+updated: 2026-10-19
 decisions:
   - "ADR 0106"
+  - "ADR 0436"
+  - "ADR 0438"
 ---
 
 # Logins on the bus, as they run
@@ -25,6 +27,16 @@ Nothing marks what a tool does.** Read from the controller's and the tool runner
 - **The caller is in the address.** A call's address carries the caller's name, so the runtime takes the caller
   from the address, never from the message. For a seat every machine holds, the address also names the machine.
 
+- **A module's process may have a login of its own** (ADR 0436, delivered 2026-10-19 in mesh-controller #390 and
+  mesh-sdk #36). A `process` resource that declares `bus` runs as a user its module makes and gets one login per
+  machine, named by machine, module and process. It may emit its declared events, take work from its module's own
+  work-queue stream through the one consumer the controller makes for it, use its module's states, read the
+  router's records of its module's asks, call the verbs it declares, and listen only on its own inbox. It can
+  answer no call and hold no seat. `module issue` delivers its password as the module's own secret
+  `broker-<process id>`, readable by that user alone. mesh-mail's sender is the first such process: it holds the
+  mail passwords that the tool runner may not read, and sends each mail the operator approved, which the tools
+  record as queued before they put it on its work queue (ADR 0438).
+
 ## What it cannot do
 
 - **No expiry.** A login lives until its record is deleted and the list rewritten on the bus's node.

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

@@ -1,9 +1,16 @@
 ---
 layer: to-be
 status: in-progress
-code: [mesh-controller, mesh-catalog modules/mesh-delivery]
+code: [mesh-controller, mesh-catalog modules/mesh-delivery, mesh-delivery, mesh-host, mesh-sdk]
-updated: 2026-10-18
+updated: 2026-10-19
 decisions:
+  - "ADR 0437"
+  - "ADR 0435"
+  - "ADR 0434"
+  - "ADR 0433"
+  - "ADR 0431"
+  - "ADR 0429"
+  - "ADR 0428"
   - "ADR 0426"
   - "ADR 0421"
   - "ADR 0420"
@@ -62,6 +69,42 @@ commit's journey, in what order the steps are allowed, and where each fact of it
 2026-10-16 from the decisions of research 055, which replaced the "release branches", the toolchain image, the
 controller's delivery tables and the timers that polled them.
 
+## Where it goes: parts that watch and write keys
+
+ADR 0429 (accepted on 2026-10-18, from research 063) takes building and delivering out of the controller. They
+become independent **parts**, each a process with its own bus credential that watches keys and writes keys:
+no part calls another, there is no plan object and no orchestrator, and each key has one writer. A delivered
+source revision is derived from the keys: every **want** equals its module's **fingerprint**, and every
+**have** equals its want and is healthy.
+
+- **The forge bridge** turns the forge's events into stream messages and is the only part that calls the
+  forge.
+- **The indexer** computes each module's fingerprint at the merge preview and writes the candidates of each
+  group and the modules of the trunk.
+- **The builder** claims a build by creating its key, once per fingerprint, and builds it; build-agent becomes
+  this part.
+- **The checker** runs the merge check on built artifacts.
+- **The gate** merges a group's pull requests once check, review and the operator's Approve agree on the same
+  heads, and then moves the mesh's source revision in one write.
+- **The teller** carries conditions and asks to the operator's phone and is the only writer of an ask's answer.
+- **The assigner** writes which fingerprint each node should run, by six rules: the build is done, the
+  fingerprint is not held, the node is the module's **canary** or the canary runs it healthy, at most `step`
+  other nodes are ahead when `step` is above zero, every provider runs healthy, and the module's credential for that fingerprint exists.
+- **The node agent**, the node-engine's own process, applies its wants one module at a time, backs up a data
+  module first, and writes its haves.
+- **The watchman** turns the bus's connections into presence and mirrors every key whose next move a machine
+  owes into a **pulse**, whose expiry is a stall.
+- **The status view** is the operator's command `mesh-delivery-cli` and a web view; it reads every bucket and
+  writes only its own answers to asks.
+
+Nine of these are modules of the repository `mesh-delivery`, prefixed `mesh-delivery-` (ADR 0429 §2); the
+repository is made by the forge module from its config (ADR 0428; issue 1128 makes the config value reach the
+node at once). The reviewer stays the review agent's session.
+
+It lands in six releases, each leaving the mesh working, each one milestone below (ADR 0429 §7). Until the
+release that replaces it is delivered, each section from here to *The bootstrap* stays this design and its rule
+(ADR 0429 §21); each is rewritten when the release that replaces it is prepared (issue 1130).
+
 ## The parts
 
 ```
@@ -525,6 +568,25 @@ What the build proves before this design is implemented (research 055's directio
     with no person's release and nothing held in mesh-delivery.
 12. No table in the controller's store holds builds, rollouts or assignments.
 
+From ADR 0429 (research 063's done-when, and the live proof each of its releases names):
+
+13. The status view shows every module on every node from the have keys, and agrees with the controller's own
+    read of the nodes' reports.
+14. A part stopped by hand shows stuck within two minutes, and no part holds a timer.
+15. A group of two repositories merges as one source revision, and every module's fingerprint the indexer
+    writes equals the controller's source fingerprint.
+16. A merge builds nothing its check built, and a hotfix's build waits for no other build.
+17. A day of deliveries shows no difference between the assigner's wants and what the controller sent that the
+    six rules do not explain.
+18. On the live mesh a milestone of three repositories reaches every node through the keys alone (research 063's
+    scenario A), and the assigner replaced in the middle of it resumes with nothing lost or repeated (scenario
+    D, once).
+19. Plans, batches, the merge window, tiers, the plans hold and node declaration holds, the push of whole
+    declarations, their retries, takeovers and healers, and the node-engine's handling of whole declarations are
+    deleted from the code, and no verb that starts, stops, retries or closes a plan remains.
+20. Each release's pull request reports the controller's code lines against research 063's baseline (111,386
+    lines on 2026-10-18).
+
 ## What retires
 
 - The "release branches" and the controller's judge of them (ADR 0358, superseded by ADR 0401).
@@ -544,8 +606,12 @@ What the build proves before this design is implemented (research 055's directio
 
 ## Milestones
 
-Confirmed by the operator on 2026-10-17 (playbook 04). Each is one release of playbook 07; the next starts
+Milestones 1 to 6 were confirmed by the operator on 2026-10-17 (playbook 04), and 5b on 2026-10-18. Releases 1
-when the previous one's delivery is done.
+to 6 of ADR 0429 follow milestone 5b in its order, releases 1 and 2 first confirmed as one milestone (ADR 0429 §7 allows it:
+they need nothing of each other) and then split by their release orders into R1a to R2d (below), and milestone 6 folded into release 4: confirmed by the operator on 2026-10-18
+(playbook 04 step 5). The issues of R1a to R2d are opened; each later release's are opened when it is prepared. Each milestone is one release of playbook 07; the next starts when the
+previous one's delivery is done, and a release's clauses of ADR 0429 hold from its delivery (§21). Every
+release reports the controller's code lines against research 063's baseline (acceptance test 20).
 
 | # | Outcome | Acceptance tests | Repositories | Issues |
 |---|---|---|---|---|
@@ -556,10 +622,24 @@ when the previous one's delivery is done.
 | 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980, split into 1065, 1066, 1067, 1068 |
 | 3 fix | A group approved together merges in one pass and goes out in one delivery plan, also when its members' tests read each other's repositories | 1 | mesh-catalog (mesh-delivery, gitea) | 1082, 1049, 1047, 1083, 1079 (1084 closed as its duplicate) |
 | 5 | One read of a module on a node names the commit, build and rollout that put it there | 10, 12 | mesh-controller, mesh-catalog (mesh-config, nats) | 981 |
-| 5b | The controller makes no build or deploy plan: building and delivering a change are done outside it, driven by events on the bus, and the controller receives only what each node should run | — (its decision names them) | mesh-controller, mesh-catalog (mesh-delivery) | 1117 |
+| 5b | Decided: building and delivering leave the controller for parts that watch and write keys in the repository `mesh-delivery`, landing in six releases (ADR 0429); the forge module makes that repository from its config, protected before any team reaches it (ADR 0428) | — (ADR 0429 names them: 13 to 20) | hq, mesh-catalog (gitea) | 1117, 1124, 1128 |
-| 6 | Builds use installed toolchains with no container, builders fetch over SSH with their own key, and an SDK change ships in one group with its users | 2, 4 | mesh-catalog (build modules, build-agent, ssh-client, gitea), mesh-controller, mesh-sdk | 979, 971 |
+| 6 | Folded into release 4 by ADR 0429 §10: installed toolchains, builders fetching over SSH with their own key, and an SDK change shipping with its users are built in the builder's new home, so the builder is changed once | (2, 4: proved by release 4) | — | 979, 971 (moved to release 4) |
+| R1a | The node-engine, the controller and the parts can read one layout of the have, presence, pulse and stuck keys: mesh-sdk ships it before its users | — (13, 14 need it) | mesh-sdk | 1131 (key layouts) |
+| R1b | Every node writes what it runs of each module, on its own keys and nobody else's, and the bus says to one part when a connection opens and closes | 13 in part | the node-engine (`mesh-host`), mesh-controller | 1132 (have keys), 1142 (the node-engine's check, its tests half), 1136 (the have bucket and its grants), 1145 (a module and a build per resource), 1146 (a new repository's first module registered at its merge's Approve), 1147 (the bus's connect events for the watchman), 1160 (a plan passes a machine silent at a middle tier), 1162 (the have bucket takes a node's facts) |
+| R1c | The operator sees every module on every node, with its build, phase and health, in `mesh-delivery-cli` (aliased `nox-delivery`) and its web view | 13 | mesh-delivery (view) | 1134 (the view), 1137 (the alias, in the view's manifest) |
+| R2a | The watchman and the controller can read one layout of the stuck keys: mesh-sdk ships it before its users | — (14 needs it) | mesh-sdk | 1153 (the stuck keys) |
+| R2b | A part, node or check that stops moving is raised as a condition within two minutes, with no timer in a part | 14 | mesh-delivery (watchman), mesh-controller | 1135 (the watchman), 1154 (a bucket whose keys expire), 1155 (running checks readable, with their start), 1156 (stuck keys raised; the silent check from presence), 1157 (a refused send key raised), 1159 (a long check is not stuck) |
+| R2c | The controller says when it last heard each machine from presence alone, and no longer hears the alive message | 14 | mesh-controller | 1183 (every reader of last heard takes presence; the controller's alive side deleted) |
+| R2d | The node-engine sends no alive message | 14 | the node-engine (`mesh-host`) | 1158 (the node-engine's alive side deleted) |
+| R3a | The gate, the bridge, the indexer and the teller can read one layout of the source revision, candidates, modules, merges, asks, answers, owed acts, forge messages and conditions, and one function computes the source fingerprint: mesh-sdk ships them before their users (ADR 0437) | — (15 needs it) | mesh-sdk | 1200 (source revision, candidates, modules, forge messages), 1201 (merges, asks, owed acts, answers), 1202 (a condition on its one subject), 1203 (the source fingerprint, proven against three fingerprints the live builder recorded); ahead of it in mesh-controller, so those could be read: 1204 and 1208 (`builds` says each build's source fingerprint) |
+| R3b | The controller finds the delivery seat's holder by its claim and records each build's fingerprint inputs; the router takes conditions on their one subject; the operator sees no change (ADR 0437) | — | mesh-controller, mesh-catalog (messenger) | 1210 (the controller's own path and the merge gate's rule by the seat's claim), 1211 (a merge's announcement heard from the seat's holder), 1212 (the pull requests' keys read from the holder's bucket), 1213 (a merge's warrant read under the asker the announcement names: the teller, or mesh-delivery until R3d), 1214 (the builder computes the source fingerprint with mesh-sdk's function), 1215 (a build record carries its fingerprint's inputs), 1216 (a module may say a condition only under its own name, proven on the controller's grant); in the messenger: 1217 (the router takes a condition on its one subject), 1218 (the same over the bus); one delivery group. Its prepare step found that the controller hears no `transition` or `group` event, and that the router cannot refuse a condition under another module's name, the grant does: both go into R3c's insight on ADR 0437 with 1209 |
+| R3c | The forge bridge, the indexer and the teller run beside today's mesh-delivery and write their keys; the view shows modules against the controller's source fingerprints; nothing is merged by them yet (ADR 0437) | 15 in part | mesh-delivery (forge bridge, indexer, teller, view) | opened when it is prepared; its prepare step first settles 1209 (an image that compiles a Go program enters the fingerprint by the hash of its build source, which git trees alone do not give) |
+| R3d | A group reaches the mesh as one source revision written by the gate; the merge's Approve is asked by the teller and answered on the phone until issue 953; the view shows the open asks; today's module mesh-delivery is carried over into the gate and ends (ADR 0437) | 15 | mesh-delivery (gate, forge bridge, teller), mesh-catalog (mesh-delivery removed, mesh-issues) | opened when it is prepared |
+| R4 | The controller asks no build: a build is keyed by its fingerprint, so a merge builds nothing its check built; with milestone 6, toolchains are installed, builders fetch over SSH, and an SDK change ships with its users | 16, 2, 4 | mesh-delivery (builder, checker), mesh-controller (build dispatch deleted; build-agent leaves), mesh-catalog (build modules, ssh-client, gitea), mesh-sdk | 979, 971; the rest opened when it is prepared |
+| R5 | The assigner writes what each node should run by its six rules, compared with what the controller sends, and the view shows every difference; the operator answers the asks that need no proof of who answered in the view (ADR 0437 §10) | 17 | mesh-delivery (assigner), mesh-controller (grants keys) | opened when it is prepared |
+| R6 | Each node applies from its wants, a new version reaches the module's canary first and the rest once it is healthy there, and the plans are deleted from the code | 18, 19 | the node-engine (`mesh-host`: the node agent), mesh-controller (plans deleted), mesh-delivery (the gate's delivery states go) | opened when it is prepared |
 
-The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. Milestone 3's first live group (milestone 4's, on 2026-10-17) held one Approve but merged in two passes and went out in two delivery plans: a member's tests read the other member's repository, so the first merge made the second's verdict out of date, and a closed group never asked its composed verdict again (issues 1049, 1082). The operator put a fix of milestone 3 after milestone 4 and before milestone 5 on 2026-10-18; acceptance test 1 is proved again by it. The operator put milestone 5b after milestone 5 and before milestone 6 on 2026-10-18, as an issue rather than a research effort; where the planning goes is settled by a decision record before it is built (issue 1117), and milestone 6's build changes are read against it. Milestone 2b was
+The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. R3's prepare step on 2026-10-19 found ADR 0429 §20 contradicting itself and four release orders; ADR 0437 (accepted, the operator's Approve) cuts release 3 into R3a to R3d, each one release, and moves answering asks in the view to R5. R2c's prepare step on 2026-10-19 found one more order: the alive message is the only source of when the controller last heard a machine, which `nodes`, `node` and `status` read, so the controller takes that from presence (1183, R2c) and is delivered before the node-engine stops sending (1158, R2d); 1158 depends on 1183. In release 1-2, 1132 and 1136 depend on 1131, 1134 and 1135 on 1136, 1134 also on 1132 and 1128, and 1137 on 1134. Release 1-2 was confirmed as one milestone; its prepare step on 2026-10-18 found the release orders hidden in it, and the operator chose at 18:52 to cut it by them, so it is the milestones R1a to R2d above, each one release (the operator, 2026-10-19: a milestone is one release): an SDK change still ships before its users until release 4 (ADR 0429 §10); a new key on the wire goes only to a node that says it reads it; a new repository's first module registers at its merge's Approve (ADR 0432, issue 1146); the bus gives the watchman connect events only through a system account (ADR 0431); and release 2's other gaps are settled by ADR 0433 and ADR 0434. A node that is down has no effect on a delivery and plays what it missed when it returns (ADR 0435, the operator, 2026-10-18; issues 1160, 1161). Milestone 3's first live group (milestone 4's, on 2026-10-17) held one Approve but merged in two passes and went out in two delivery plans: a member's tests read the other member's repository, so the first merge made the second's verdict out of date, and a closed group never asked its composed verdict again (issues 1049, 1082). The operator put a fix of milestone 3 after milestone 4 and before milestone 5 on 2026-10-18; acceptance test 1 is proved again by it. The operator put milestone 5b after milestone 5 and before milestone 6 on 2026-10-18, as an issue rather than a research effort; where the planning goes is settled by a decision record before it is built (issue 1117), and milestone 6's build changes are read against it. Milestone 2b was
 put before milestone 3 by the operator on 2026-10-17. Milestone 3 builds ADR 0418, ADR 0419 and ADR 0421
 (issues 977, 978 and 1022), and splits mesh-controller's unit tests from its integration tests (issue 895, the
 operator on 2026-10-17), so the unit level holds its bound of ADR 0391; the integration level's sixty seconds

03-DESIGN/01-to-be/49-the-mesh-in-domains.md

@@ -2,8 +2,9 @@
 layer: to-be
 status: in-progress
 code: [hq 00-META/checks/words.py, mesh-catalog merge-check.sh]
-updated: 2026-10-11
+updated: 2026-10-18
 decisions:
+  - "ADR 0429"
   - "ADR 0244"
   - "ADR 0006"
   - "ADR 0008"
@@ -31,7 +32,7 @@ shape — what each is for, where its records live, and how they depend on one a
 | **Placement** | to decide, send and apply what each node runs, and say why | the controller's `inventory` database |
 | **Provisioning** | to resolve which module serves a provision for which consumer, and wire the two | the controller |
 | **Identity and access** | to issue, hold, rotate and check credentials and grants | the controller's `identity` and `licences` databases, and the vault |
-| **Change and delivery** | to take one commit from its pull request to every node that should run it, and put it back when it fails | the `mesh-delivery` module, and the controller's planner and rollout |
+| **Delivery** | to take one commit from its pull request to every node that should run it, and put it back when it fails | the `mesh-delivery` module and the controller's planner and rollout today; from each release of ADR 0429 on, the parts of the repository `mesh-delivery` it builds |
 | **Health and repair** | to notice what is wrong, say it once, repair what may be repaired unattended, and record what was done by hand | the controller's condition store |
 | **Data** | to know every item of data a module holds, how precious it is, and keep it recoverable | the manifests' data declarations, and every node's `node-backup` seat |
 | **Connectivity** | to make every node and module reachable by name where it should be, and unreachable where it should not | the controller |
@@ -61,7 +62,7 @@ a change of meaning upstream ripples down, never up. Arrows point downstream.
         +------------->  Health and repair <-------------------+
                            |          |
                            v          v
-                 Change and delivery  Operator and conversation
+                 Delivery             Operator and conversation
                            |                   ^
                            +-------------------+
                      (a held delivery waits for a person's word)
@@ -70,7 +71,7 @@ a change of meaning upstream ripples down, never up. Arrows point downstream.
 Media stands beside the diagram, below Module alone: its words are about what a person watches, not
 about the mesh's machinery, and no other domain reads them.
 
-Change and delivery sits low because it reads health and data; in time it runs first, and asks Placement
+Delivery sits low because it reads health and data; in time it runs first, and asks Placement
 to send. An authorising answer acts in whichever domain asked, through that domain's own verb: the
 conversation owns the asking, never the act.
 
@@ -84,7 +85,7 @@ ADR 0006 named seven contexts of the controller. Each is a domain now, under the
 | config | split: settings to Module and Placement, secrets to Identity and access |
 | connectivity | Connectivity |
 | provisioning | Provisioning |
-| delivery | Change and delivery — owned by the `mesh-delivery` module, not by the controller (ADR 0239) |
+| delivery | Delivery — owned by the `mesh-delivery` module, not by the controller (ADR 0239); named so by ADR 0429 §2, its parts living in the repository `mesh-delivery` |
 | observability | Health and repair: the mesh built conditions, not "alerts", and half of the domain is repair |
 | identity | Identity and access, with the licences store the seven did not name |