Answer round 2 of the review of milestone G's part: one rebuild trigger, digests from events, every new store sized

The four reviewers found two triggers for one rebuild, digests read from the builder's own keys, a mesh-wide wait
with no owner, bound or tool, new states with no retention or cap, a first fill the builder could race, and a
registry check whose source goes; each is now a design line with its reason, and test 60 follows section 271.

Claude-Session: https://claude.ai/code/session_01JG73KK8HD1gufnqyFxMFdW

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

@@ -1459,7 +1459,9 @@ the operator for the bus node's want (ADR 0539 §15).
   naming its fingerprint, which its node composes again (ADR 0547 §2).
 - **A build before its want.** Every module, the builder's own and the build modules among them, is wanted only
   from the builder's done key whose artifacts all name a reference; a module whose key is not yet done
-  waits under the assigner's first rule and fails nothing (ADR 0524 §7, ADR 0539 §18).
+  waits under the assigner's first rule and fails nothing (ADR 0524 §7, ADR 0539 §18). From G's delivery the assigner
+  takes a build's digests from `version-released` and the builder's `build.ended`, never its done key (design 47 G
+  §379).
 - **History: the switch to release 6 was one plan, release 5's last** (it is delivered; ADR 0547 takes the composing, signing and issuing it gave the controller away again). Release 5's controller ran
   the group's plan with the new node-engine and the new controller in one tier (issue 1942), so every node's last
   declaration named the new node-engine and carried the operator's public key, and the control-node's named the new
@@ -1754,13 +1756,15 @@ What milestone G's prepare found, and its test:
 59. **A session hears an accepted record** (issue 595). An Approve that accepts a record makes the knowledge base say
     `reviewed` with what was accepted, by the operator and with the warrant, and the tool runner's account hears it, so
     a session waiting with `mesh_wait` wakes on it (whole, knowledge base; live).
-60. **The store's holder takes its own build when its seat is broken.** With a fixture holder of `oci-artifact-registry`
-    that refuses every store, its new build is kept on the build node, named in the builder's done key, fetched by the
-    node-engine through `kept-artifact`, and once it runs the next build is stored through the seat, with no hand act;
-    a call of `kept-artifact` from an account other than a node-engine's is refused; it is refused for a module that
-    does not claim `oci-artifact-registry`; fetched bytes that differ from the done key's digest are not applied; an
-    artifact over the bus's value limit is fetched whole as an object; with the keeping node away, or the build swept,
-    the want waits and the have says why (whole, builder, build module and node-engine).
+60. **The store's holder takes its own build when its seat is broken** (design 47 G §271). With a fixture holder of
+    `oci-artifact-registry` that refuses every store, its new build is kept on the build node, the builder's
+    `build.ended` naming it kept there with its digest, and the want naming that digest; the node-engine fetches it
+    through `kept-artifact` and checks it against the want's digest, and once it runs the next build is stored through
+    the seat, with no hand act; a call of `kept-artifact` from an account other than a node-engine's is refused; it is
+    refused for a module that claims the seat but is not its holder in the seat list; fetched bytes that differ from
+    the want's digest are not applied; an artifact over the bus's value limit is fetched whole as an object; with the
+    keeping node away, or the build swept, the want waits, the have says why, `kept-build-waits` is raised after 60
+    minutes and cleared once the have runs the want (whole, builder, build module and node-engine).
 61. **No module reads the indexer's `modules`.** The watchman's manifest findings, the status view's `view_reach`, the
     forge module's writable repositories and the reads of the holders of `mesh-config`, `mesh-provisioner` and
     `mesh-self-check`, of the claude-code module and of the tool runner each answer from the catalog half: after a
@@ -1927,27 +1931,33 @@ ADR 0667's checks, of milestone G itself:
     reporting it; with one of its two artifacts published `1.4.3` is not released, and `builder_publish_again`
     publishes the other under `1.4.3`, which the catalog then says `version-released` once; a new `1.5` builds as
     `1.5.0`; two builds close together reserve two versions; a `beta` build reserves none and is delivered; a manifest
-    saying `1.4-beta` is refused (whole, builder, indexer and Go build module, mesh-delivery and mesh-catalog).
+    saying `1.4-beta` is refused; `builder_publish_again` names `1.4.3`; a `1.4.2` artifact published after `1.4.3` is
+    released late, said by no `version-released` and rebuilds nothing; a publish of an unreserved version is refused
+    by the registry holder (whole, builder, indexer and Go build module, mesh-delivery and mesh-catalog).
 103. **A group's run on request publishes no version** (design 47 G §373). A run on request of a group changing a
-    package and a module importing it builds the module against the package member's build by digest, publishes and
-    reserves nothing, and no `tag-wanted` is said (whole, runner, builder and Go build module, mesh-delivery and
+    package and a module importing it builds the module against the package member's build by the digest the builder
+    took from its own `build.ended`, the fetched bytes checked against it; a member whose build is not done holds the
+    dependent with a `wait-held` naming it, and one whose build failed fails the dependent's step naming it; the run
+    publishes and reserves nothing, and no `tag-wanted` is said (whole, runner, builder and Go build module, mesh-delivery and
     mesh-catalog).
 104. **A release records its dependencies, and only a stale edge rebuilds** (design 47 G §374, §376, §378). A
     module released at `1.4.3`, built against mesh-sdk `0.1.15` and delivered after a provider at `2.0.1`, holds
-    those versions with their parts' digests; mesh-sdk's `version-released` of `0.1.16` that changes the imported
-    package rebuilds it, one that leaves its digest as it was rebuilds nothing, and a change of the Go build module's
+    those versions with their parts' digests; mesh-sdk's `package-published` of `0.1.16` that changes the imported
+    package rebuilds it, started by the runner after its `outdated` ask, one that leaves its digest as it was rebuilds nothing, and a change of the Go build module's
     own code rebuilds no module; a `beta` build's entries compare by digest (whole, indexer, builder and runner,
     mesh-delivery).
 105. **One query finds what is behind** (design 47 G §375). With the runner stopped while mesh-sdk `0.1.16` is
     released, `outdated` names the module's kind-1 edge at `0.1.15` against `0.1.16`, and at its restart the runner
-    starts that module's pipeline once; `indexer_outdated_again` says the event again and writes the hand-act log
+    starts that module's pipeline once, keyed by mesh-sdk's source revision; `runner_catch_up` does it by hand and
+    writes the hand-act log
     (whole, indexer and runner, mesh-delivery). After the first fill (§377), a mesh running its newest builds is
     answered with nothing behind.
 106. **A delivery is waited for mesh-wide** (design 47 G §376, §379, §380). A module ordered after a provider's
     new version is wanted only once `version-delivered` says every present machine placing the provider runs it; with
     one machine away the module's status reads "waiting for delivery of" the provider, naming the machine, and it
     catches up when that machine is back; with every placing machine away the provider reads "waiting for <machine>
-    to be back" and nothing is raised; each want names the released version and its parts' digests; `indexer_edges`
+    to be back" and nothing is raised; with a placing machine present that never runs it, `delivery-waits` is raised
+    after 60 minutes naming it and its node-engine's version; each want names the released version and its parts' digests; `indexer_edges`
     answers the module's edges from both ends (whole, indexer, assigner and node-engine, mesh-delivery and `mesh-host`).
 
 ## What retires

03-DESIGN/01-to-be/47-milestones/G-1-pipelines-registration-and-steps.md

@@ -391,9 +391,16 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l
   starts, where ADR 0666 §15 numbers a package at its publication and design 51 publishes a held digest under a new
   number: a packed file carries its version, so it must be known before the build; the operator's choice, which a
   later research brings the records in line with. How it is checked: test 102.
-- §53 **Every dependent is rebuilt against it.** On `package-published` every artifact with a kind-1 edge to the package is
-  rebuilt against the new version, and the runner, which consumes the event, starts its pipeline; nothing else is
-  rebuilt, and a change to tests alone publishes nothing (ADR 0666 §15; research 086, R18).
+- §53 **Every dependent behind is rebuilt against it, on `package-published`.** The builder says `package-published`
+  for every package build of a watched branch: with its released version on the registration's first watched branch,
+  and on another watched branch by its digest alone, the build stored by digest with no version (§371). The runner,
+  which consumes it, asks the catalog's verb `outdated` for that package on that branch, a kept call (ADR 0668 §1,
+  §2), and starts a pipeline for each dependent by kind 1 whose recorded part digest differs from the published one:
+  the catalog compares (§375), the runner starts, and no other part rebuilds anything. A `package-published` whose
+  version is lower than the highest the catalog holds released for that module starts nothing (§382). Nothing else is
+  rebuilt, and a change to tests alone publishes nothing (ADR 0666 §15; research 086, R18). Why: ADR 0666 §15 has the
+  runner consume `package-published`; the digest comparison is the operator's (2026-11-10), and one event for both
+  branches is the design's choice, round 2 of the review by architectural domain, 2026-11-10.
 - §54 **A second start writes nothing.** The runner starts a pipeline on two events, the indexer's `take-in.taken` (ADR
   0666 §13) and `package-published` (ADR 0666 §15). When both reach it for the same source revision and module, the
   second start writes nothing: the runner writes a pipeline's key (watched branch, source revision and module, *The

03-DESIGN/01-to-be/47-milestones/G-2-pipelines-sizes-checks-and-tools.md

@@ -162,7 +162,8 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
   its members, and a merge behind a pending revision, are governed by their own bounds (ADR 0666 §24). At its start the
   watchman seeds its open waits from the runner's `stands`, as it seeds `take-in-waits` from `indexer_pending`.
 - §76 **The runner's own health.** Its manifest declares its health check, run outside its process (ADR 0240): the runner
-  answers `show`, and its durable consumers of `step-ended`, `take-in.taken`, `package-published` and `decided` are
+  answers `show`, and its durable consumers of `step-ended`, `take-in.taken`, `package-published`, `toolchain-agreed`
+  and `decided` are
   each less than five minutes behind; a failed check names which.
 - §77 **The runner waits for its view.** With no revision view it says so in `<module>_first_views` and raises `view-waits`
   after five minutes, as every part does (ADR 0656 §6).
@@ -223,6 +224,15 @@ and an estimated 2 mesh-sdk publishes a day, each rebuilding about 120 artifacts
 | the runner | `step-log`: one entry per step's start and end, its output, its pipeline and the `kept` digests it wrote or carried, by name | old `streams` section | by its age, 100 days, ten days past the longest retention it ages (§330) | 128 MiB; about 3,600 entries a day of about 0.2 KiB is about 70 MiB at 100 days |
 | the runner | `step-outputs`: a lint or test step's output | old `objects` section | 7 days | 1 GiB; about 1,200 steps run a day (the rest carried) of about 50 KiB is about 420 MiB at 7 days |
 | the runner | `kept`: a package's passing result per level, by digest, with `last-read`, written by each carry that reads it | old `state` section | 30 days after `last-read` | 128 MiB; a publish changes the digest of about 1,000 importing packages at two levels, so about 4,000 entries a day of about 0.3 KiB, about 36 MiB at 30 days |
+| the indexer | `versions`: one key per module and version, its artifacts' digests, the source revision and its edge entries (§349, §374) | old `state` section | a module's newest 100 versions, never its highest of a `MAJOR.MINOR`; the indexer deletes the older at each release | 64 MiB; about 120 modules of 100 versions at about 3 KiB is about 35 MiB; at the cap it records no release and says `full`, as *A store filling is said before it is full* |
+| the indexer | `build-edges`: the newest build's edge entries per module and watched branch other than the first | old `state` section | replaced by the next build; deleted when the branch is unwatched | under 1 MiB |
+| the builder | `reserved`: one key per module and `MAJOR.MINOR` (§369) | old `state` section | until its `version-released`, a release of another `MAJOR.MINOR` of the module, or `builder_reserved_drop` | a few KiB; at the cap the builder reserves nothing and says why |
+| the assigner | `written`: the last source revision and end count per module and watched branch (§352) | old `state` section | until the branch is unwatched | a few KiB |
+| the indexer and the assigner | `inputs`: a `run` ask's input by write time and sha256 (§354) | old `state` section | until the ask's `step-ended`, at most a day | 64 MiB; an estimated 300 asks a day of under 100 KiB each is under 30 MiB; at the cap the asker refuses the ask loudly, naming the store |
+| the runner and the assigner | `findings` (§355) | old `state` section | an entry deleted when its finding clears | a few KiB |
+| the runner | `aged`: three step-log sequences (§330) | old `state` section | never deleted | bytes |
+| the teller | `widens-said` (§335) | the template `state` | until the branch is unwatched | a few KiB; the template's |
+| each build module | `steps` (§326) | the template `state` | one key per artifact, dropped by `steps` with `drop` | under 1 MiB; the template's |
 | the indexer | `registrations` and its stream `registration-history` | old `state` and `streams` sections | the life of the mesh, never derived again | 64 MiB (*A module's registration*) |
 | the indexer | catalog graph revisions, per watched branch | objects in the old form (ADR 0619 §2) | while a record pins it or it is its branch's current | 512 MiB, as *Two graphs, one source of truth*; a second watched branch on a few modules adds a few MiB |
 | the gate | `source`: one key per watched branch | its old `state` section, as today | 64 revisions of each key; a branch's key deleted when `registration-changed` says the last registration watching it unwatched it (`unwatch`) | a few KiB |

03-DESIGN/01-to-be/47-milestones/G-5-acting-parts-check-and-kept-data.md

@@ -126,7 +126,8 @@ names go, since every new acting part needed code changes elsewhere (research 08
   - While the keeping node is away, or its sweep removed the build, the want waits, and the node-engine says in its
     have that it waits for that node or for a build no longer kept. A want that waits so for 60 minutes, building's
     default bound, is the watchman's finding `kept-build-waits`, naming the module, the node and the build node; the
-    operator or the healers recover it by `builder_build_again`, which builds and keeps it again.
+    operator or the healers recover it by `builder_build_again`, which builds and keeps it again; the finding clears when
+    the node's have runs the want.
   - A node-engine of before G does not know `kept-artifact`: the holder's want on its node waits for its new
     node-engine (ADR 0667 §9). A new node-engine is itself fetched from the store; while the store is broken it waits,
     so on a node that has neither the store's holder's new build nor G's node-engine, the want waits and
@@ -140,11 +141,6 @@ names go, since every new acting part needed code changes elsewhere (research 08
   is checked: test 60, and whole (build module, node-engine): a module claiming the seat but not its holder in the
   seat list is refused; bytes differing from the want's digest are not applied; a want waiting 60 minutes raises
   `kept-build-waits` and `builder_build_again` ends it.
-
-  This is the one artifact the mesh delivers from a build node instead of the store, and only for the holder of
-  `oci-artifact-registry`; the design's choice under ADR 0656 §3 (a wait skips what the holder's own new version needs) and ADR
-  0526 §2, whose build by a session's call it makes a step of the delivery instead of a hand act. How it is checked:
-  test 60.
 - §272 **The check refuses a cycle among the waits within one step** (ADR 0656, which changes ADR 0603 §2's refusal of a
   cycle), counted beside the edges ADR 0614 §3 and §6 list; a cycle through an acting part's edges across two steps, or
   through a holder's own inputs, is none.
@@ -173,6 +169,7 @@ names go, since every new acting part needed code changes elsewhere (research 08
   | granting | the grants part | `grants_waits` | `grants_release` |
   | composing | the assigner, holding a node's other wants until its new node-engine runs there (*Composing waits per node*) | `assigner_waits` | `assigner_release` |
   | checking | the check's first tier | `checker_first_tier` | its ask-again (*The check on the change's own acting parts*) |
+  | delivery of a dependency (kinds 2, 4 and 6), from G's delivery | the assigner, holding a dependent's new version until `version-delivered` of its dependency's (§376) | `assigner_waits` | `assigner_release` (want it now), and `assigner_delivered_again` |
   | pipeline, from G's delivery | the runner, holding the pipelines its new version is to run until it runs healthy | `runner_waits` | `runner_release` (run them with the running runner) |
 
   Each release writes the hand-act log of the seat `mesh-hand-acts`, with who released and why.

03-DESIGN/01-to-be/47-milestones/G-6-verbs-and-retires.md

@@ -66,7 +66,10 @@ of each verb (ADR 0666 §7, §20, §25):
 `registrations`, and the event `registration-changed` (*A module's registration*), and `catalog-revision` names its
 watched branch in its subject. **The build seats** gain the verb
 `steps` and the accepted kind `step`, and **the seat `mesh-wants`** the kind `step`, each saying `step-ended`. **The
-seat `mesh-builds`**, new and held once for the mesh, says `package-published` (*A publish rebuilds*).
+seat `mesh-builds`**, new and held once for the mesh, says `package-published` and `toolchain-agreed` and serves
+`reserved` (*A publish rebuilds*, §369, §376). From G's answers (G-7), `mesh-catalog` also gains the verbs `versions`
+and `outdated` and the events `version-released` and `versions-filled`, `mesh-wants` the event `version-delivered`, and
+the seat `git` the verb `tag` (§349, §372, §375, §376, §370).
 
 §308 **The seats `mesh-catalog` and `mesh-wants`** gain, from research 085's milestone, `revision` on each (the two halves
 of the revision view, ADR 0656), and `entry` and `difference` on `mesh-wants` (ADR 0656), with the events of *What

03-DESIGN/01-to-be/47-milestones/G-7-answers.md

@@ -100,10 +100,14 @@ record it follows from, and replaces the builder's own choice where one was made
   `pipeline-started` 32 MiB, `pipeline-ended` 192 MiB, `group-ended` 64 MiB, `run-started` 16 MiB, `step-started`
   and `step-ended` 128 MiB each, `wait-held` and `wait-ended` 32 MiB each; the seat `git`'s `branch-moved` 64 MiB; each
   build seat's `step-ended` 128 MiB; `mesh-wants`'s `step-ended` 32 MiB; `mesh-builds`' `package-published` and
-  `mesh-catalog`'s `registration-changed` 16 MiB each; all 90 days. Why: about 300 pipelines a day of about 6 steps
+  `mesh-catalog`'s `registration-changed` 16 MiB each; `package-published` 128 MiB; `version-released` 128 MiB,
+  `version-delivered` 64 MiB, `toolchain-agreed` 16 MiB, and `versions-filled` 1 MiB with no age limit; all others
+  90 days. At about 300 releases a day (a mesh-sdk publish rebuilding about 120 modules), `package-published` of about
+  two artifacts each and `version-released` each say about 0.6 MiB a day, about 54 MiB in 90 days, and
+  `version-delivered` about 27 MiB. Why: about 300 pipelines a day of about 6 steps
   (*The runner's kept data*) say about 1,800 step events a day of about 0.5 KiB, about 80 MiB in 90 days, and about 300
   pipeline ends of about 4 KiB, about 105 MiB, 55 % of its cap; a build seat runs about 1,200 steps a day, about 54
-  MiB; publications and registration changes are a few a day; estimates, read from the fill tools once G runs. A kept
+  MiB; registration changes are a few a day; estimates, read from the fill tools once G runs. A kept
   seat stream at its cap drops its oldest message, as a stream with a cap does; the grants part, which makes the
   streams, says `filling` on its seat `mesh-grants` past 80 % and `room` below 70 %, which the watchman's
   `store-filling` raises and clears as for every store (*A store filling is said before it is full*). How it is
@@ -124,7 +128,9 @@ record it follows from, and replaces the builder's own choice where one was made
   its build was made from. The runner reads the dependents from that revision's catalog graph, the artifacts with a
   kind-1 edge to the package, and starts each one's pipeline keyed by that branch, that source revision and the
   dependent module, the version in the pipeline's state; a `take-in.taken` of the same revision and module is the
-  same pipeline (*A second start writes nothing*). Why: a pipeline's key is branch, source revision and module (above),
+  same pipeline (*A second start writes nothing*). A pipeline the runner starts from `outdated` (its start, §375, or
+  `runner_catch_up`) is keyed by the dependency's watched branch, the dependency's source revision `outdated` names, and
+  the dependent module, so it is the same pipeline the event would have started. Why: a pipeline's key is branch, source revision and module (above),
   and the publication is made from a revision of a watched branch (ADR 0666 §15). How it is checked: whole (builder,
   runner), a publish starts one pipeline per dependent, keyed by the publishing revision.
 - §335 **What the teller says of a widening.** Each entry of `widens` names what widens (`acting-rule`, `grant`,
@@ -208,15 +214,19 @@ record it follows from, and replaces the builder's own choice where one was made
   state. With no holder of a build seat, a build ends `could not run`, naming the seat, and is asked again on the seat
   list's change. Why: ADR 0596 §2. How it is checked: the builder's account holds no grant to the indexer's state.
 - §349 **The catalog holds released versions only, and says each.** The indexer keeps, for the seat `mesh-catalog`,
-  each module's released versions in its old `state` section `versions`, one key per module and `MAJOR.MINOR` holding
-  its released patches with each artifact's digest and the source revision built (issue 1961's catalog of versions).
-  It hears every artifact's `package-published` (packages, images, bundles and archives alike) and records a version
-  as released once every artifact the module's catalog entry names is published at it, then says `version-released`
-  (the module, the version, its artifacts, the source revision) on `mesh.seat.mesh-catalog.event.version-released`,
-  kept 90 days at 16 MiB; the verb `versions` answers a module's released versions, its callers the builder and any
-  person or session. A reserved version is not in it. The builder's `version.numbered` is no longer said or heard.
-  Why: the operator, 2026-11-10 about 21:40 CET (gaps items 23 and 43). How it is checked: whole (indexer), a version
-  with one of two artifacts published is not released, and with both is, said once.
+  each module's released versions in its old `state` section `versions`, one key per module and version holding each
+  artifact's digest, the source revision built and its edge entries (§374) (issue 1961's catalog of versions). It hears
+  every artifact's `package-published` (packages, images, bundles and archives alike) and records a version as
+  released once every artifact the module's catalog entry names is published at it, then says `version-released` (the
+  module, the version, each artifact's digest, the source revision) on
+  `mesh.seat.mesh-catalog.event.version-released`. A version lower than the highest it holds released for that module
+  is recorded, marked `released late`, and not said: no `version-released` is lower than the module's highest, and
+  nothing follows one (§382). Each module keeps its newest 100 versions: at each release the indexer deletes that
+  module's oldest beyond them, never its highest of any `MAJOR.MINOR`. The verb `versions` answers a module's released
+  versions, its callers the builder, the holders of the registry seats and any person or session. A reserved version
+  is not in it. The builder's `version.numbered` is no longer said or heard. Why: the operator, 2026-11-10 about 21:40 to 23:00 CET (gaps items 23 and 43); the
+  key per version, the 100 kept and the late release are the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked: whole (indexer), a version with
+  one of two artifacts published is not released, and with both is, said once; a late older version is not said.
 - §350 **A superseded build's drop is a kept call.** The runner ends a superseded build's step `superseded` at once, and
   asks the build seat's `drop` as a kept call (ADR 0668 §1, §2), so it is asked again through every transport fault
   and said `call-unanswered` after five minutes in the runner's findings. How it is checked: whole (runner), a drop
@@ -305,42 +315,66 @@ record it follows from, and replaces the builder's own choice where one was made
 - §368 **A manifest says its `MAJOR.MINOR`.** Each module's manifest names `version`, two numbers `MAJOR.MINOR`; the
   manifest validator refuses any other form, a pre-release or custom suffix (`beta`, `alpha`) among them: no custom
   version exists for now. A manifest without it is refused once G's reader runs (ADR 0667 §4: the reader is delivered
-  first). Why: the operator, 2026-11-10 about 21:40 CET. How it is checked: unit (manifest validator), `1.4` accepted,
-  `1.4-beta` and `1.4.2` refused.
+  first). G's change writes `version` into every existing manifest, the `MAJOR.MINOR` of the version §372 fills for that
+  module, `0.1` for a module with none published, in the same group as the reader. Why: the operator, 2026-11-10 about
+  21:40 CET; the values are the design's choice. How it is checked: unit (manifest validator), `1.4` accepted,
+  `1.4-beta` and `1.4.2` refused; the catalog's validation finds no manifest without `version` at G's heads.
 - §369 **The reservation is one key per module and `MAJOR.MINOR`.** The builder, a foundation part, keeps in its old
-  `state` section `reserved` one key per module and `MAJOR.MINOR`, the version its build reserved, written by
-  compare-and-set at the build's start; a newer build of the module takes the next after the higher of the highest
-  released and the one reserved, so two builds never share a version, and a superseded build's version is never
-  released, leaving a gap in the patches. The builder deletes the key when the catalog says `version-released` for it;
-  `builder_reserved` reads the keys. This is no list of released versions: numbering reads those only from the
-  catalog. Why: the operator, 2026-11-10 (a version reserved when the build starts); the key and the gap are the
-  design's choice. How it is checked: whole (builder), two builds close together reserve two versions, and the key
-  goes on `version-released`.
+  `state` section `reserved` one key per module and `MAJOR.MINOR`, the version its build reserved and each artifact's
+  digest once built, written by compare-and-set at the build's start; a newer build of the module takes the next after
+  the higher of the highest released and the one reserved, so two builds never share a version, and a superseded
+  build's version is never released, leaving a gap in the patches. The builder deletes the key when the catalog says
+  `version-released` for it, or when a version of another `MAJOR.MINOR` of the module is released (the manifest moved
+  on); `builder_reserved` reads the keys and `builder_reserved_drop` drops one on a person's word, written in the
+  hand-act log. A reserved version whose build ended with an artifact unpublished past the publish's 10-minute bound
+  is the builder's finding `version-unreleased`, naming the module, the version and the missing artifacts, cleared by
+  its `version-released`. `builder_publish_again` names the reserved version it publishes under. The builder reserves
+  nothing until the catalog says `versions-filled` (§372); a build waiting for it says `wait-held` naming the fill. The
+  seat `mesh-builds`' verb `reserved` answers a module's reserved version with each artifact's digest, its callers the
+  holders of the registry seats (design 51, *Publishing*). This is no list of released versions: numbering reads those
+  only from the catalog. Why: the operator, 2026-11-10 (a version reserved when the build starts); the key, the gap,
+  the finding and the verb are the design's choices. How it is checked: whole (builder), two builds close together
+  reserve two versions, the key goes on `version-released`, an unpublished artifact raises `version-unreleased`, and a
+  builder started before the fill reserves nothing until `versions-filled`.
 - §370 **The version reaches every artifact's build.** The build seat's ask carries the version, and the build module
   passes it to the artifact's build as the build argument `MESH_VERSION`: a Go package is tagged `vMAJOR.MINOR.PATCH`,
   an npm package's version is it, an image carries it as its tag and label, and a program reads it as its own version.
   A Go package's version is its tag: this departs from ADR 0573 §2, which has a Go package's version be its trunk
-  commit, by the operator's choice of 2026-11-10, and a later research brings that record in line. How it is checked:
-  whole (Go and TypeScript build modules), a built package and program carry the reserved version.
+  commit, by the operator's choice of 2026-11-10, and a later research brings that record in line. The git tag
+  (`go/vMAJOR.MINOR.PATCH`, design 51) is written by the builder only on the catalog's `version-released`, through the
+  seat `git`'s verb `tag`, whose callers are the builder alone, so a superseded build's reserved version is never
+  tagged. How it is checked: whole (Go and TypeScript build modules), a built package and program carry the reserved
+  version; whole (builder), the tag is written on `version-released` and never for a superseded build.
 - §371 **Only the first watched branch releases.** Only a build of the registration's first watched branch reserves and
   releases a version; a build of another watched branch reserves none, publishes no version and is delivered by its
   build, its fingerprint, as every want names one. Why: the operator, 2026-11-10. How it is checked: whole (builder),
   a `beta` build reserves nothing and is delivered.
 - §372 **The catalog's versions start from what is published.** At the new indexer's first start, `versions` is filled
-  once, as released, from each name's highest `published` version the builder's state `versions` held, read by
-  `builder_versions`; it is not filled again. Why: numbering reads only the catalog's released versions (§348), and
-  without this every first version under G would start below today's and Go's `@latest` would never move (the
-  design's choice, 2026-11-10). How it is checked: whole (indexer, builder), with `0.1.14` published before G, the
-  first G build of `0.1` is `0.1.15`.
+  once, as released, for each module from the highest `published` version over every artifact of the module that the
+  builder's state `versions` held (for mesh-sdk the higher of Go's `v0.1.14` and npm's `0.1.18`, so `0.1.18`), read by
+  `builder_versions` as a kept call (ADR 0668 §1, §2), an unanswered call raising `call-unanswered` after five minutes;
+  it is not filled again. Then the indexer says `versions-filled` on its seat, once, kept on its stream with no age
+  limit, and the builder reserves nothing before it (§369). The builder keeps serving `builder_versions` until then: the
+  running builder serves it already, and the new one serves it too, so no ordering edge is needed. The builder's state
+  `versions`, the floor and its tool `builder_floor_again`, the event `numbered`, `builder_versions`, and `tag-asks` are
+  removed in the first change after the first pipeline after G's delivery has delivered a change end to end, the state
+  through `drop` on a person's word (ADR 0595 §4). Why: numbering reads only the catalog's released versions (§348),
+  and without this every first version under G would start below today's and Go's `@latest` would never move (the design's choice, round 2 of the review by architectural domain, 2026-11-10).
+  How it is checked: whole (indexer, builder), with Go `v0.1.14` and npm `0.1.18` published before G, the first G build
+  of `0.1` is `0.1.19`, and a builder started before the indexer reserves nothing until `versions-filled`.
 - §373 **A group's run on request publishes no version.** A run on request of a group builds each member that
-  depends on a package member against that member's build by its digest: the build module fetches the package
-  member's build from the store by the digest its build's done key names and lays it in the build's workspace as the
-  module that package names (a Go workspace's replacement, a TypeScript local package), so nothing is fetched by a
-  version, and no version is reserved, numbered or published for the run. The tagged versions, `tag-wanted` (the
-  checker's, and none of the runner's) and the builder's `tag-asks` with its tools `builder_tag`, `builder_tag_asks`
-  and `builder_untag` go at G's delivery (design 51, *Tagged versions*). Why: the operator, 2026-11-10 about 21:40 CET,
-  no custom versions for now, a tagged version being one; a run delivers nothing (ADR 0666 §18), so it needs no
-  version. How it is checked: test 103.
+  depends on a package member against that member's build by its digest. The builder's build ask for such a member
+  carries each package member's build digest, which the builder takes from its own `build.ended` of that member's
+  build, its own fact (ADR 0596 §2); the build module fetches that build from the store by the digest, checks the
+  fetched bytes against it, and lays it in the build's workspace as the module that package names (a Go workspace's
+  replacement, a TypeScript local package), so nothing is fetched by a version, and no version is reserved, numbered
+  or published for the run. A dependent whose package member's build is not done waits, said as the builder's
+  `wait-held` naming the member, within building's 60-minute bound; a member's build that failed or is missing past
+  that bound fails the dependent's step, naming the member. The tagged versions, `tag-wanted` (the checker's, and none
+  of the runner's) and the builder's `tag-asks` with its tools `builder_tag`, `builder_tag_asks` and `builder_untag` go
+  at G's delivery (design 51, *Tagged versions*). Why: the operator, 2026-11-10 about 21:40 CET, no custom versions for
+  now, a tagged version being one; a run delivers nothing (ADR 0666 §18), so it needs no version; the digest's source
+  and the wait are the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked: test 103.
 - §374 **A release records, per edge, the part it was built against or delivered after.** One version per module
   stays (§52), and an edge is judged by the digest of the part it points to. The catalog records on each released
   version (§349), in its key of `versions`, one entry per catalog-graph edge of the module's artifacts (the six kinds
@@ -352,52 +386,66 @@ record it follows from, and replaces the builder's own choice where one was made
     and the builder carries them in each artifact's `package-published`, so the indexer reads no other part's state
     (ADR 0596). Kind 3 points at the toolchain part the agreed toolchain names (ADR 0584 §1), never at the build
     module's own program.
-  - kinds 2 and 4 (delivered after): the dependency's version and part digest the catalog last said
-    `version-delivered` for when the release is delivered (§376), one entry for the mesh.
+  - kinds 2 and 4 (delivered after): the dependency's version and part digest of its newest `version-delivered`
+    when this release is itself first delivered (its own `version-delivered`, §376), one entry for the mesh.
   - kind 5 (has acted for): a fact, not a version: the acting part, its step, the build that acted and that the act
     was done (or released by hand), from the holder's `wait-ended` (*Each step's wait is its own part's*).
   - kind 6 (runs a version that serves): a fact: the verb or manifest word used and the dependency's delivered
-    version that serves it.
+    version that serves it, written at the same first delivery.
+
+  The entries of kinds 2, 4 and 6 read `not yet delivered` until that first delivery, are written once then, and none
+  is changed after; kinds 1, 3 and 5 are written at the release.
 
   A build of a watched branch other than the registration's first releases no version (§371): its entries are kept in
   the indexer's old `state` section `build-edges`, one key per module and watched branch holding the newest build's
   entries, keyed by its fingerprint, replaced by the next build and deleted when `registration-changed` says the
   branch is no longer watched, and they compare by the part's digest alike. The declared edge stays in the catalog
-  graph; an entry is the release's or the build's fact, never changed after. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET and 22:10 CET (issue 1961), and
+  graph; an entry is the release's or the build's fact, written once. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET and 22:10 CET (issue 1961), and
   the lead's review of these lines. Each entry is about 0.1 KiB, about ten a version, so `versions` stays within its
   64 MiB (an estimate). How it is checked: test 104.
 - §375 **One query finds every edge behind, by the part's digest.** The seat `mesh-catalog`'s verb `outdated`, with
   the indexer's tool `indexer_outdated`, answers every entry that is behind: for kind 1, the recorded digest differs
-  from the part's digest in the dependency's newest released version (for a build of another branch, its newest
-  build on that branch); for kind 3, it differs from the toolchain part the agreed toolchain names now; for kinds 2 and
-  4, it differs from the dependency's newest delivered version; for kind 5, the newest version of the acting part has
-  not acted for the dependent's current build; for kind 6, the delivered version no longer serves the verb or word. A
-  dependency's newer version that left the part's digest as it was makes nothing behind, so nothing is done twice for
-  the same inputs. Only a stale edge (§378) that is behind has an act that catches it up, a rebuild; an ordering edge
-  behind is shown and starts nothing. Each answer names the module and its version or build, the kind, the
-  dependency, what was recorded and what is newest, and the act. Its callers are any person, an agent session, the
-  healers, the runner and the assigner; `indexer_outdated_again`, a hand act written in the hand-act log, says the
-  event that starts a stale entry's rebuild again. At its start, the runner asks `outdated` once and starts the
-  rebuilds it names, so a restart or a missed event leaves nothing behind. Why: the operator, 2026-11-10 (issue
-  1961's "outdated"). How it is checked: test 105.
-- §376 **A stale edge rebuilds on its event; a delivery is waited for mesh-wide.** On a dependency's `version-released`,
-  the dependents by kind 1 whose entry is behind are rebuilt against it and their pipelines started, as on
-  `package-published` (§53); when the agreed toolchain names a new toolchain part, the dependents by kind 3 whose entry
-  is behind are rebuilt. No other edge rebuilds or delivers anything again. A dependent's new version that a change
-  orders after its dependency's new version by kind 2, 4 or 6 is wanted only once that dependency's version is
-  delivered to every machine that places it and is present: the catalog says `version-delivered` (the module, the
-  version and its parts' digests) once every present machine placing it runs it healthy, from the node-engine seat's
-  `running`, on `mesh.seat.mesh-catalog.event.version-delivered`, kept 90 days at 16 MiB, and the assigner writes the
-  dependent's wants on it. A machine away is named and catches up when it is back (ADR 0603 §7); meanwhile the
-  dependent's status, in `assigner_why_not` and the status view, reads "waiting for delivery of <module>", naming
-  the machines it waits for. When every machine that places the dependency is away, it is not delivered: its status
-  reads "waiting for <machine> to be back" and its dependents wait; nothing is raised for a machine simply away.
-  Kind 5 is held by the acting parts' waits (*Within a revision the new version acts first*). Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is
-  checked: tests 104 and 106.
+  from the part's digest in the dependency's newest released version (for a build of another branch, its newest build
+  on that branch); for kind 3, it differs from the toolchain part of the builder's newest `toolchain-agreed`; for kinds
+  2 and 4, it differs from the dependency's newest `version-delivered`; for kind 5, the newest version of the acting
+  part has not acted for the dependent's current build; for kind 6, the delivered version no longer serves the verb or
+  word. A dependency's newer version that left the part's digest as it was makes nothing behind, so nothing is done
+  twice for the same inputs. Only a stale edge (§378) that is behind has an act, a rebuild; an ordering edge behind is
+  shown and starts nothing. Each answer names the module and its version or build, the kind, the dependency with its
+  watched branch and source revision, what was recorded and what is newest, and the act. It may be asked for one
+  dependency. Its callers are any person, an agent session, the healers and the runner. At its start the runner asks
+  `outdated` once, a kept call raising `call-unanswered` after five minutes, and starts the rebuilds it names; the
+  runner's tool `runner_catch_up`, for the operator and the healers and written in the hand-act log, does the same by
+  hand, for one dependency or all. A restart or a missed event so leaves nothing behind. Why: the operator, 2026-11-10
+  (issue 1961's "outdated"); `runner_catch_up` replaces the indexer's hand tool, which would have had to say another
+  part's event (the design's choice, round 2 of the review by architectural domain, 2026-11-10). How it is checked: test 105.
+- §376 **A stale edge rebuilds on its event; a delivery is waited for mesh-wide.** The rebuilds start on two events
+  the runner consumes: kind 1 on `package-published` (§53), and kind 3 on `toolchain-agreed`, which the builder says
+  on its seat `mesh-builds` when the agreed toolchain of a language changes (ADR 0584 §1), naming the language, the
+  version and the toolchain part's digest; for each, the runner asks `outdated` for that dependency and starts a
+  pipeline for each dependent behind. `version-released` starts no rebuild. No other edge rebuilds or delivers anything
+  again. A dependent's new version that a change orders after its dependency's new version by kind 2, 4 or 6 is wanted
+  only once that dependency's version is delivered to every machine that places it and is present. The assigner judges
+  it, since placement is its own state: from its placements, the node-engine seat's `running` events and the
+  watchman's presence of each node, judged again on each of them and on each placement change, and says
+  `version-delivered` (the module, the version, its parts' digests and the machines away) on its seat `mesh-wants`
+  (`mesh.seat.mesh-wants.event.version-delivered`) once every present machine placing it runs it healthy; the catalog
+  hears it for its entries (§374), and the assigner writes the dependent's wants on it. The dependent's wait is the
+  assigner's, said `wait-held` with a 60-minute bound from the dependency's `version-released` (*Each step's wait is its
+  own part's*): past it, the watchman's finding `delivery-waits` names the dependency, the version and the machines not
+  running it, with each one's node-engine version, so a node-engine from before G that never runs it is named. A
+  machine away is named and catches up when it is back (ADR 0603 §7); meanwhile the dependent's status, in
+  `assigner_why_not` and the status view, reads "waiting for delivery of <module>", naming the machines it waits for.
+  When every machine that places the dependency is away, it is not delivered: its status reads "waiting for <machine>
+  to be back", its dependents wait, and nothing is raised for a machine simply away, the bound counting only while a
+  placing machine is present. `assigner_delivered_again`, for the operator and the healers and written in the
+  hand-act log, says `version-delivered` again for one version when it holds. Kind 5 is held by the acting parts' waits
+  (*Within a revision the new version acts first*). Why: the operator, 2026-11-10 about 22:30 to 23:00 CET; who judges it, the event's seat, the bound and the tools are
+  the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked: tests 104 and 106.
 - §377 **The first fill.** At the indexer's first start under G, after `versions` is filled (§372), each module's
   newest version gets its entries once: kinds 1 and 3 from the dependency version published latest before that
   version's build was claimed, read with the times of `builder_versions`, and its part's digest; kinds 2, 4 and 6 from
-  the versions every present machine runs, read from the last `running` of each module on each node, which the
+  the versions every machine placing it runs, present or away, read from the last `running` of each module on each node, which the
   node-engine seat's stream keeps last per subject with no age limit; kind 5 as done for every acting part's running
   build. Each filled entry is marked `filled`, so a person sees it was derived, not recorded. It is not filled again.
   Why: so the first `outdated` does not find the whole mesh behind (the lead, 2026-11-10). How it is checked: whole
@@ -410,11 +458,26 @@ record it follows from, and replaces the builder's own choice where one was made
 - §379 **A want names the released version and each part's digest.** From G's delivery a want `want.<node>.<module>`
   names, beside its fingerprint and source revision, the module's released version, for people (none for a build of
   another watched branch), and the digest of each of its parts; the node-engine fetches and checks each part by its
-  digest, never by the version. The node-engine of G reads the two fields, its reader edge of kind 4 delivered before
-  any want writes them (ADR 0667 §4, §9). Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is checked: whole (assigner, node-engine), a want names
-  the version and the parts' digests, and a fetched part whose digest differs is not applied.
+  digest, never by the version. The assigner takes the digests from `version-released` for a released version, and from
+  the builder's `build.ended`, which carries each artifact's digest and, for a kept build, its keeping node, for a build
+  of another watched branch and for a kept build (§271); never from the builder's done key (ADR 0596 §2). It writes the
+  two fields into a node's want only once that node runs G's node-engine, as it holds a node's other wants for its new
+  node-engine (*Composing waits per node*), so the reader edge holds per node and a node away on an older node-engine
+  gets its node-engine's want first. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET; the sources and the edge per node are the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked:
+  whole (assigner, node-engine), a want names the version and the parts' digests taken from those events, a node on an
+  older node-engine gets no new field, and a fetched part whose digest differs is not applied.
 - §380 **`indexer_edges` answers both directions.** For any module or part, per watched branch, `indexer_edges`
   answers what it depends on and what depends on it; per edge its kind, stale or order (§378), the manifest word it
   came from, the part it points to, and what its newest release recorded (version and digest, or the fact for kinds 5
-  and 6), and whether it is behind now (§375). Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is checked: whole (indexer), a fixture module's
+  and 6), and whether it is behind now (§375). Its callers are any person, an agent session and the healers. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is checked: whole (indexer), a fixture module's
   edges are answered from both ends with their newest release's record.
+- §381 **A registry holder checks a publish against the reservation.** From G's delivery the holder of a registry
+  seat asks the seat `mesh-builds`' verb `reserved` (§369), in place of `builder_versions`, whether the module, the
+  version and the artifact's digest are reserved, and refuses loudly otherwise (ADR 0605 §4); a version the catalog
+  already holds released for that digest is answered as held and stores nothing. Why: ADR 0605 §4 has the holder
+  refuse a version the builder did not give, and the builder's list goes (§372); the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked: whole
+  (registry holder, builder), a publish of an unreserved version is refused, naming it.
+- §382 **An older version released after a newer starts nothing.** When every artifact of a version lower than the
+  module's highest released is published late (a retry of an older reservation), the catalog records it `released
+  late`, says no `version-released` for it, and the runner starts no rebuild on its `package-published` (§53). Why:
+  a rebuild against an older part would move a dependent back; the design's choice, round 2 of the review by architectural domain, 2026-11-10. How it is checked: test 102.

03-DESIGN/01-to-be/51-the-registries-keep-what-is-named.md

@@ -153,7 +153,9 @@ the verb.
   match its digest. At 80 % of the cap it writes a finding (cleared below 80 %); at the cap it refuses a new transfer
   with `refused` naming the cap. Its tool `registry_incoming` lists open transfers and the fill, and drops one by hand.
 - **The holder asks the builder**, through `builder_versions`, whether the name, version and digest are recorded, and
-  refuses loudly otherwise (ADR 0605 §4). A rebuild of a held fingerprint answers the held version and stores nothing.
+  refuses loudly otherwise (ADR 0605 §4). A rebuild of a held fingerprint answers the held version and stores nothing. From the delivery of
+  design 47's milestone G the holder asks the seat `mesh-builds`' verb `reserved` instead, whether the module, the
+  reserved version and the artifact's digest are reserved, and refuses loudly otherwise (design 47 G §381).
 - **How a publish ends**: the holder emits `published` or `refused`. The build module waits for one of them, matching
   on its transfer, name and version, at most
   10 minutes, narrating "waiting on <seat>" at least every five minutes; past the bound it writes the key refused,