Fix design 47 G's batches 6 and 7 by the review round, and drop every named caller list

The four reviewers' musts on §587 to §676 are written into the lines they name: the snapshot sent on its call's own session with its digest recorded, warrants matched to the current ask and its digest, the gate's copy at every start, the recovery module's hand tools as seat verbs, the catalog half's pending entries and the node-engine following no branch, the keeper following a moved finding stream, the builder's republish queue and its toolchain wait, and more. The operator's answer of about 16:10 CET ends every named caller list: every verb takes its class's default, and a module's process that calls a marked verb carries the operator's warrant for that one call (§677). Develop's D-16 to D-18 are §678 to §680, in a new part G-18 so that G-17 stays under 60 KB. Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
2026-11-11 20:16:47 +01:00
parent d004b90e49
commit 9381cde1b4
9 changed files with 357 additions and 165 deletions
@@ -277,7 +277,7 @@ that round are written into the lines they name, here. Questions that an earlier
    on `wait-ended`; a `composed` whose fingerprint is not the want's is covered by that same wait or by the put's
    wait (§498).
  - **The healers' attempts.** The seat `mesh-healers` says `attempt-changed` on
-    `mesh.seat.mesh-healers.event.attempt-changed.<condition>`, the condition's key escaped as a key's name is (§73),
+    `mesh.seat.mesh-healers.event.attempt-changed.<condition>.<attempt>` (§665), each token escaped as a key's name is (§73),
    carrying the attempt's value whole as its key in `attempts` holds it and `until`, the end of that key's
    lifetime, or `removed: true` when the healer ends the attempt; the seat's definition, in its contracts module,
    keeps it last per subject, 7 days and 16 MiB (§396). The healers say it again for every open attempt at their start. The
@@ -48,7 +48,7 @@ are written into the lines of G-12 they name.*
    restores into the live bus. The bus module's snapshot before its own `recreate` or `drop` (ADR 0595 §5, ADR 0626
    §4) and the nightly dump (ADR 0626 §2) stay theirs. The restore ADR 0667 §12 tests of the snapshot `drop` takes is
    the recovery module's `recovery_restore` naming that snapshot, which it reads through the bus module's tool
-    `nats_snapshot_get` (class `read`, callers `holder:mesh-recovery@same-node` alone).
+    `nats_snapshot_get` (class `read`, taking its default, §610; its arguments and answer §666).
  - **Its seat, module and node.** The seat `mesh-recovery`, held once for the mesh, is defined in mesh-contracts
    beside `mesh-broker`, and the module `mesh-recovery`, in mesh-catalog, claims it; its glossary word is the
    *recovery module*. It runs on the node of the holder of `mesh-broker`, read from the catalog half and the seat
@@ -68,21 +68,21 @@ are written into the lines of G-12 they name.*
    `<module>.<kept>`, and `expiry-ended`, their fields as §560 gives them. The node agent wakes only on the ending
    event of its own act, and its wait for `ended` or `restored` is bounded at 90 minutes from its first ask (§405,
    §560), past which its have says the wait and the watchman's `delivery-waits` raises it.
-  - **Who calls it.** `snapshot-kept` and `restore-kept` are called by a node-engine holder (`seat:node-engine`): the
+  - **Who calls it.** `snapshot-kept` and `restore-kept` are of class `act` and take its default (§610, the operator's
-    recovery module takes a call only from an account the bus proves to be a node-engine's, and the identity of who
+    answer of about 16:10 CET: no verb keeps a named list): the bus proves who called, every act is logged with it,
-    asked is the check (the operator, 13:06 CET), every act logged; no want is read for it, since the operator,
+    and the identity of who asked is the check (the operator, 13:06 CET); no want is read for it, since the operator,
    2026-11-11 13:10 CET: "if something asks for a restore, you should do it; he'll have his reasons".
    `kept-points` takes the default of a read (§391). The operator, 2026-11-11 13:06 CET at lead-47's terminal: setting
    aside is a move, not a removal, so deleting the live objects once their aside is whole and checked (§516) needs
    no person's warrant, the data staying in the aside until the operator discards it; setting aside without restoring is
    the operator's hand tool `recovery_aside`, and discarding an aside the hand tool `recovery_discard_aside`, both of
-    class `act`, callers `operator` and `sessions`, written in the hand-act log first; `restore-kept` refuses
+    class `act`, taking its default (§610), written in the hand-act log first, each a verb of the seat (§656); `restore-kept` refuses
    `aside-only` and `discard-aside`, naming them (§516). The hand tools are checked by the identity of who asked: they are taken only from the operator's account as the bus proves it, and from sessions
    acting on it as for every `act` tool (§391), with no warrant asked per act. Each act is written in the hand-act log of the seat `mesh-hand-acts` first, with the caller the
    bus proved and `why`; an act whose log write fails does nothing and answers `error`, naming the log (as §480).
  - **The operator's hand tools.** `recovery_take` (take a point of one module and kept data now), `recovery_restore`
    (restore one point) and `recovery_retry` (ask again the last failed act of a module and kept data), each of class
-    `act`, callers `operator` and `sessions` (§391), written in the hand-act log; they are checked by identity, as above.
+    `act`, taking its default (§610), written in the hand-act log, each a verb of the seat (§656); they are checked by identity, as above.
    §566 adds `recovery_restore_aside` and `recovery_cancel`.
  - **Its account.** The operator, 2026-11-11 about 14:15 CET at lead-47's terminal (the knowledge base's review of
    ADR 0672, R3): the recovery module is one process with a bus account of its own (ADR 0436 §1, as ADR 0626 §1 has
@@ -119,7 +119,7 @@ are written into the lines of G-12 they name.*
    holder `backup-waits`, each naming the item or the act it waits on, and `kept-points` lists the act that runs
    with since when and what it waits on. The recovery module consumes the item events that G's backup holder adds,
    an edge of kind 6 from that holder to it, so a backup holder of before G, which says none, is never relied on.
-  - **Its health.** Its declared health check calls `kept-points`, and fails only while an aside's record ends at
+  - **Its health.** Its declared health check names the tool `recovery_kept_points` (§657), and fails only while an aside's record ends at
    `removed` (§516) and no running act holds it, so a restore under way never fails it; it then also writes the
    finding `aside-unrestored` (§561), which `recovery_restore_aside` (§566) clears.
  - **Its order.** The node-engine's `invokes` of its verbs gives the edge of kind 6 from the recovery module to the
@@ -217,7 +217,7 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line;
  `kept-points` unanswered keeps a point's names it granted before, and a point's old-section names are added after
  an `ended` and taken away after its `point-removed`.
 - §566 **Two more hand tools: put an aside back, and cancel a waiting act.** (§554, §516) Each is of class `act`,
-  with callers `operator` and `sessions`, checked by the identity of who asked (§554), written first in the hand-act
+  taking its default (§610), checked by the identity of who asked (§554), written first in the hand-act
  log of the seat `mesh-hand-acts` with the caller the bus proved and `why`, and an act of its own that runs one at a
  time (ADR 0672):
  - `recovery_restore_aside` (`module`, `kept`, `id`, `why`) restores an aside under the live names it was taken from,
@@ -515,7 +515,7 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line;
  - **Its tools.** `indexer_pins` reads each kept revision with the records that pin it, whether it is current and
    why, and the store's fill against its cap. `indexer_consumer` reads each of the indexer's durable consumers: its
    stream, name, acknowledged sequence, the messages pending, and the last event applied with its `at`. Both are
-    of class `read`. `indexer_unpin` (`revision`, `record`, `why`; class `act`, callers `operator` and `sessions`,
+    of class `read`. `indexer_unpin` (`revision`, `record`, `why`; class `act`, taking its default (§610),
    written in the hand-act log first) removes one record's id from a revision's list, for a `freed` that was lost,
    and the removal rule then applies.
@@ -546,7 +546,7 @@ form only. A note that corrects a line of G-12 or G-14 is written in that line;
  each `seen` key's value, the time of the `step-ended` that wrote it. On each `step-ended` it handles, and at its
  start, it deletes the `seen` keys whose `at` is more than 30 days old, at most 100 for each event, the oldest first,
  so the bus keeps no key time-to-live and no template option is added; its tool `git_seen_expire` (class `act`,
-  callers `operator` and `sessions`, written in the hand-act log) runs the same removal now. The forge module being a foundation part
+  taking its default (§610), written in the hand-act log) runs the same removal now. The forge module being a foundation part
  (§584), its state `failed-steps` is in its old `state` section, and a bundle reaches it through the tool runner's
  state call by its name, as every old section is reached. Why: §487's 30 days needed
  a trigger, and an event the module already handles is one (develop question of the forge module's developer). How
@@ -28,8 +28,8 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
 [G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
 *§587 to §594 answer develop's sixth batch (lead-47's input of 2026-11-11, met in the join and develop after §560 to
-§586). Each is of internal form only, within what the records and the lines it cites decide; §588 leaves one question
+§586). Each is of internal form only, within what the records and the lines it cites decide; §588 carries the operator's
-to the operator, said in it. A line of another file that one of them corrects is corrected in that line (§169, §170,
+answer of 2026-11-11, between 15:14 and 15:42 CET. A line of another file that one of them corrects is corrected in that line (§169, §170,
 §171, §177, §226, §404, §462, §513, §568, and the event table of G-4); here only what is new.*
 ## The ledger's upkeep calls
@@ -63,42 +63,46 @@ to the operator, said in it. A line of another file that one of them corrects is
 ## The builder's publishes and its reads
- §588 **`builder_publish_again` publishes again every reserved version left unpublished, one module at a time.**
+- §588 **A reserved version left unpublished is published again, by the builder on an event or by a person's tool.**
-  (§52, §369, §381; *Tools are how a module is spoken to*) The builder's tool `builder_publish_again` (class `act`,
+  (§52, §369, §381, §590, §610, §633; ADR 0673 §2; *Tools are how a module is spoken to*) A publish sends the
-  its callers and its writing in the hand-act log as they are) takes `module`
+  artifacts the build stored, by their digests, to the holder of the registry seat of their kind, under the same
-  and `version`, each optional, and `why`:
+  version, and builds nothing, so it takes no build capacity.
-  - **With both**, it publishes again that reserved version's missing artifacts, as §52 has it.
+  - **By itself, on an event.** The operator, 2026-11-11 between 15:14 and 15:42 CET at lead-47's terminal, decided by
-  - **With `module` alone**, it publishes again each reserved version of that module whose artifacts are not all
+    the record of the builder's publish again (number to come), which extends ADR 0673 to publishes: the builder
-    published: at most one per `MAJOR.MINOR`, since §369 keeps one key per module and `MAJOR.MINOR` and a
+    publishes again, by itself, every reserved version `version-unreleased` names (§369), on the node-engine seat's
-    superseded build's version is never released.
+    `running` of a module whose catalog graph entry claims the registry seat of the missing artifacts' kind, on any
-  - **With neither**, it does so for every module whose reserved version the finding `version-unreleased` names
+    node, and on the node-engine seat's `manifest-reads-changed` with `why` `returned` of the node that holder runs on
-    (§369), one module after another, the newest key first.
+    (ADR 0673 §2, §590); one with `why` `started`, or with none, publishes nothing. No timer. The builder's manifest
-  - **Its bound.** A publish sends the artifacts the build stored, by their digests, to the holder of the registry
+    `consumes` both events (it does for ADR 0673 already).
-    seat of their kind, and builds nothing, so it takes no build capacity. An artifact no store holds is not built
+  - **Each event once.** The builder acts on a message of those subjects at most once, by its stream sequence: it
-    by this tool: the tool names it, and its build key is built again by `builder_build_again`. The builder sends one
+    keeps, in its old `state` section `acted`, the last sequence it acted on per subject, so the read of §556 at its
-    publish at a time to each registry seat holder, each bounded by §369's 10 minutes. The tool answers at once with
+    start acts on each subject's last message only when that is newer than the kept one, and a message read again
-    the versions it started, and each outcome is said as `package-published`, or left in `version-unreleased` with
+    after a restart starts nothing.
-    the holder's words.
+  - **One queue per holder.** Each registry seat holder has one queue of versions to publish, sent one at a time,
-
+    each bounded by §369's 10 minutes; a version already queued or being published is not queued again. One event
-  Why: §369 gave the tool one version, and a recovery of a registry holder away for hours left many (lead-47 in the
+    queues at most `republish-max-versions` versions (a setting, §633, 50 unless set), at most one per `MAJOR.MINOR`
-  registry recovery, issue 1966 note 206). How it is checked: whole (builder, with a fake registry holder), a holder
+    of each module (§369's key), the newest keys first; the rest wait for the next event or the tool.
-  that refused three modules' publishes, then answers: one call with neither argument publishes the three, one at a
+  - **An artifact no store holds.** It is named once in `version-unreleased` as not stored, and is not tried again on
-  time, and clears their `version-unreleased`; an artifact no store holds is named and not built.
+    events: its build key is built again by `builder_build_again`, which reserves anew.
-
+  - **The failure still said.** A publish that fails again keeps `version-unreleased` with the holder's words and
-  - **By itself, on an event.** The operator, 2026-11-11 between 15:14 and 15:42 CET at lead-47's terminal, answering
+    waits for the next such event.
-    this line's question, decided by the record of the builder's publish again (number to come), which extends ADR
+  - **By a person's tool.** `builder_publish_again` (class `act`, §610, written in the hand-act log) takes `module`
-    0673 to publishes: the builder also publishes again, by itself, every reserved version `version-unreleased` names,
+    and `version`, each optional, and `why`: with both, that reserved version's missing artifacts (§52); with `module`
-    on the node-engine seat's `running` of a module whose catalog graph entry claims the registry seat of the
+    alone, each reserved version of that module whose artifacts are not all published, at most one per
-    missing artifacts' kind, on any node, and on the node-engine seat's `manifest-reads-changed` with `why` `returned`
+    `MAJOR.MINOR`; with neither, every version `version-unreleased` names, one module after another, the newest key
-    of the node that holder runs on (ADR 0673 §2, §590); one with `why` `started` publishes nothing. On each such
+    first. It queues as the events do and answers at once with the versions it queued; each outcome is said as
-    event it publishes at most one version per `MAJOR.MINOR` of each module (§369's key), one publish at a time to
+    `package-published`, or left in `version-unreleased` with the holder's words.
    each holder, at most once per event heard. A publish that fails again keeps `version-unreleased` with the
    holder's words and waits for the next such event. No timer. The builder's manifest `consumes` both events (it
    does for ADR 0673 already). How it is checked: unit (builder), a version left unreleased is published again on
    the holder's `running` and on its node's `returned`, not on `started`, once per event and one at a time; whole
    (builder, a fake registry holder away and back), every unreleased version published with no hand act.
  - **Before develop.** These lines rest on the record of the builder's publish again, accepted before G's builder
    is built from them; its number replaces "number to come" here.
  Why: the operator's answer; §369 gave the tool one version, and a recovery of a registry holder away for hours
  left many (issue 1966 note 206); the queue, the sequence, the cap and the unstored artifact are the design's
  (review: health and events 5, running and testing 4 and 7). How it is checked: unit (builder), a version left
  unreleased is published again on the holder's `running` and on its node's `returned`, not on `started` or no
  `why`, once per message: a restart reading the same last message starts nothing; a version queued is not queued
  twice; one event queues at most the setting's number; an unstored artifact is named once and not tried on the next
  event; whole (builder, a fake registry holder away and back), every unreleased version published with no hand act,
  one at a time; one call with neither argument publishes three modules' versions.
 - §589 **`builder_build` answers a module's build keys whole.** (§348, §568, §575; *one-question-one-tool*) The
  builder's tool `builder_build` (class `read`) takes `module` and, optional, `fingerprint`. With `fingerprint`, it
  answers that key whole; with `module` alone, the module's build keys newest first, at most 20, each with its
@@ -129,6 +133,8 @@ to the operator, said in it. A line of another file that one of them corrects is
    new assignment graph revision only when the capabilities answered differ from those its newest revision placed
    on, so a `returned` that changes nothing makes no revision.
  - **The builder** consumes it as ADR 0618 §4 and §568 have it, and builds a key again only on `returned`.
  - **An older node-engine's event.** A `manifest-reads-changed` with no `why`, from a node-engine of before G, is
    read as `started`, so it builds and publishes nothing again.
  Why: two events of one fact, one decided (ADR 0618 §4) and one the design's (§226), are a second source of the
  same fact, and ADR 0673 §2 builds on the decided one's `why` (lead-47, on ADR 0673). How it is checked: unit
@@ -165,6 +171,10 @@ to the operator, said in it. A line of another file that one of them corrects is
  - **What was owed at the switch.** Each `owed` key the old bridge had not performed becomes an act (§169). Each
    `merges` key it had not performed is said once as `approval-carried` (§542) and becomes no act. The gate writes
    `merges` no more (§156) and reads it no more, and keeps it until §97's removal (§542).
  - **A carried approval nobody uses is seen.** For each `approval-carried` it says, the gate writes the finding
    `approval-carried-open` (scope the gate, id `<repository>.<pull>`, each escaped as a key's name is, §73), naming the
    head the Approve named, and clears it when it hears the seat `git`'s `pull-merged` or `pull-closed` of that pull
    request, which its manifest `consumes`.
  - **The approval.** No Approve is asked per merge (§150); an `approval` step's answer is the runner's (ADR 0666
    §10, §542).
@@ -173,7 +183,8 @@ to the operator, said in it. A line of another file that one of them corrects is
  four places (join of the gate). How it is checked: unit (gate's manifest), no `invokes` of `merge-pull` and no
  `consumes` of `merged` or `pushed`; the code review finds no module name of the forge bridge in the gate's code
  and no act `merge`; whole (gate, bridge), a merge made through `merge-pull` opens one record from `take-in.taken`,
-  and a `merges` key at the switch is said `approval-carried` and performed by nobody.
+  and a `merges` key at the switch is said `approval-carried` and performed by nobody, its `approval-carried-open`
  raised and then cleared by that pull request's `pull-merged`.
 - §593 **The gate hears neither the teller's answers nor the view's reach.** (§150, §431, §512) The gate's reads of
  the teller's `answered` and the status view's `reached`, and its calls of `teller_answers` and `view_reach`, served
  the Approve per merge, which goes at G's delivery (§150, §431): the gate's `asks` go with it. So the gate's
@@ -41,26 +41,33 @@ for several build maps is answered once, and the maps' names for it are given in
 ## The operator's answers
- §610 **Every class's default admits the modules that invoke it, and sessions call `warrant` and `accept`.** (§391,
+- §610 **No verb keeps a list of named callers: every verb takes its class's default.** (§391, §392, §394; ADR 0286;
-  §394, §405, §555; ADR 0666 §20, ADR 0286) The operator, 2026-11-11 about 15:40 CET at lead-47's terminal: "the
+  the records this ends are named below) The operator, 2026-11-11 about 15:40 CET at lead-47's terminal: "the operator
-  operator and agents may do everything, we might make it more strict and start asking for additional checks for
+  and agents may do everything, we might make it more strict and start asking for additional checks for agent stuff,
-  agent stuff, modules can get as many permissions as they want". §391's defaults become:
+  modules can get as many permissions as they want"; and about 16:10 CET: "we can always lock it down later, but we
-  - `read`: `invokers`, `persons` and `sessions`, as before;
+  most definitely don't want stupid things like 'named lists'".
-  - `act`: `operator`, `sessions` and `invokers`;
+  - **The defaults.** A verb's definition names its class, and its callers are its class's default, which the
-  - `warrant`: `operator`, `sessions` and `invokers`, and it still carries the approval mark, so each call runs only on
+    seat-definition reader applies: `read` takes `invokers`, `persons` and `sessions`; `act`, `warrant` and `accept`
-    the operator's Approve of that one call, whoever made it (ADR 0286, which this line does not change);
+    take `operator`, `sessions` and `invokers`. `invokers` is every module whose manifest names the verb in `invokes`
-  - `accept`: `operator`, `sessions` and `invokers`. The runner's `accept` (§30, §394) is no longer the operator's
+    (§391). A module tool's callers are its class's default alike.
-    alone.
+  - **No list.** A seat definition and a manifest name no `callers`: the seat-definition reader and the manifest
    validator refuse the field, naming the verb or tool, and every `callers` G's heads carry goes in G's change. So
    `git`'s `tag` (§370), the build seats' `run` (§229), `node-backup`'s `now`, `restore`, `aside` and `discard-aside`
    (§405, §555), `restore` taking any module's item (no own-item limit), `mesh-recovery`'s `snapshot-kept` and
    `restore-kept` (§554, §659), the bus module's `nats_snapshot_get` (§554, §666), the node-engine's eleven verbs
    (§393), `operator-channel`'s `ask-again` (§394), the indexer's `indexer_unpin` (§579) and every hand tool of G
    take their class's default. §392's prefixed forms and `holder:<seat>@same-node` (§336) are no longer written in
    a definition; a part that must tell callers apart reads the account the bus proved (`by-caller`, ADR 0259 §3).
  - **What stays.** Who may publish an event or a step's result stays its owner's alone (ADR 0363 §2, ADR 0666
    §21), and a verb's own judgement of its input stays (`restore-kept` refusing `aside-only`, §516; `merge-pull`
    counting a rerun only by the operator or the healers, ADR 0666 §11, §585).
  - **The approval mark stays** (ADR 0286), so a `warrant` verb, or any verb a manifest marks, runs only on the
    operator's Approve of that one call, whoever calls (§677).
-  `invokers` is every module whose manifest names the verb in `invokes` (§391). A verb whose definition names its own
+  This amends §391, §392, §393 and §394, and every line naming `callers`. Why: the operator's answers. How it is
-  `callers` keeps them (§391); §394's verbs, which take their class's default, take the new one. So `node-backup`'s
+  checked: unit (seat-definition reader, manifest validator), a definition or manifest naming `callers` refused, and
-  `now` and `restore` (§405, §555), which take `act`'s default, are called by the operator, sessions and every
+  a table row per class giving its default; whole (backup holder, recovery module), a `restore` from a session and
-  module that invokes them: the assigner, the node agent, the bus step's grant and the recovery module, today's
+  from the recovery module for another module's item taken, and a `snapshot-kept` from a session taken.
  callers among them [mesh-contracts DQ-6]. This amends §391 and §394. Why: the operator's answer; no accepted record
  makes a `warrant` or `accept` verb the operator's alone (ADR 0286 has the operator approve each marked call and
  alone answer its ask). How it is checked: unit (seat-definition reader), the table's rows for `act`, `warrant`
  and `accept` give their new callers, and a verb with `callers` of its own keeps them; whole (backup holder), a
  `now` from the assigner's account and a `restore` from the recovery module's are taken.
 - §611 **Five parts move only their findings to templates in G.** (§529, §577) The operator, 2026-11-11 between 15:14
  and 15:42 CET at lead-47's terminal: in G only the state `findings` and the finding stream of the teller, the
  status view, the watchman, enrolment and the forge bridge move to `requires` templates (§529). Their other old
@@ -86,16 +93,23 @@ for several build maps is answered once, and the maps' names for it are given in
    `orphans` lists, removed only by the operator's `drop` (ADR 0595 §4).
  - `merges` and `source` stay in the old `state` section (§542, §15).
  - `deliveries`, `groups`, `owed` and `conditions` move to `requires` entries of the template `state`, under the same
-    names. At its first start, before it serves anything, the gate of G copies every key of the old section of each
+    names. The old sections' keys stay, read no more, so a revert's gate of before G finds them, until the operator's
-    into its template entry, from its own data alone, says in its journal and in `gate_records` how many keys it
+    `drop`.
-    copied of each, and leaves a key already in the template as it is (as §584 copies the image registry's). The old
+  - **Copied at every start that finds the old section changed.** The gate of G keeps, in a template state of its
-    sections' keys stay, read no more, so a revert's gate of before G finds them, until the operator's `drop`.
+    own `copies`, one key per state with the old section's last revision it copied and when. At each start, before it
    serves anything, for each of the four whose old section's last revision is newer than that key, it copies every
    key changed since: a key whose write in the old section is newer than its template key's replaces it, a key
    deleted in the old section after its template key's write is deleted in the template, and an older one is left.
    It then writes the mark, and says in its journal and in `gate_records` how many keys it copied and deleted of
    each. So forward, a revert (whose gate of before G writes the old sections), and forward again carry every change
    made while reverted, and nothing older overwrites a newer write.
  [mesh-catalog Q-G1.] This corrects §15's "the gate's other kept data stay in ADR 0595's templates". Why: the
-  operator's answer. How it is checked: unit (manifest validator), the gate's manifest of G's heads declares `merges`
+  operator's answer; the copy at every start is the design's (review: security and upgrade 5, running and testing 2).
-  and `source` old and the four templates; whole (gate), a first start with keys in the four old sections copies
+  How it is checked: unit (manifest validator), the gate's manifest of G's heads declares `merges` and `source` old
-  them, says how many, and serves them.
+  and the five templates; whole (gate), forward, then a revert's write and deletion in the old sections, then
-
+  forward: the template holds the reverted gate's write, the key it deleted is gone, and a key written in the
  template after the revert is kept.
 ## Reading the catalog half, every part alike
 - §614 **How a part reads the catalog half per watched branch, once for every part.** (§196, §199, §443, §459, §479,
@@ -110,7 +124,11 @@ for several build maps is answered once, and the maps' names for it are given in
    reader of the seat: the registrations' watched branches, read by `registrations` at the start and followed by
    `registration-changed` (§532); before the first registrations, the branches the gate's `source` answers, read at
    the start and followed by the gate's `source-moved` (§507), which it stops following at the first
-    `registration-changed`. mesh-sdk's `go/views` adopts and drops the views (§532) and holds no seat's verb.
+    `registration-changed`. The gate's `source` given no branch answers `{branches}`, the branch of each
    `source.<branch>` key it keeps, and given a branch that branch's source revision. mesh-sdk's `go/views` adopts and
    drops the views (§532) and holds no seat's verb. The forge module, in TypeScript, follows the branches the same
    way through the TypeScript form of `meshcatalogclient`, beside the seat's generated TypeScript contract in
    mesh-delivery's contracts, on mesh-sdk's TypeScript view follower (§196).
  - **The manifest entries every such part declares.** In `consumes`: `mesh-catalog.catalog-revision`,
    `mesh-catalog.registration-changed` and `mesh-delivery.source-moved`. In `invokes`:
    `seat:mesh-catalog.revision` (with the field `none-yet`, §617), `seat:mesh-catalog.registrations`,
@@ -120,13 +138,26 @@ for several build maps is answered once, and the maps' names for it are given in
    `running` or a `wanted` naming a fingerprint that no branch's newest revision lists and it does not hold, it asks
    `entry` once, as a kept call (ADR 0668 §1), and keeps the answer; it removes one when no `running` or `wanted` it
    holds names that fingerprint any more. The reader it passes to a pure function (§459) answers from the views and
-    those entries alone, and reads no bus; an entry not yet answered is answered as none, which §459 says.
+    those entries alone, and reads no bus. Each kept entry is `asked`, `answered` or `not-found`:
    - **asked**: the reader answers it as pending, a state apart from none; the part's health says it waits on that
      fingerprint, and the node-engine's have says the phase `held` with its detail opening `entry-asked:` (§421's
      `entry-missing` is said only once `entry` answered not found);
    - **answered**: the answer starts a new pass at once;
    - **not-found**: the part writes the finding `entry-not-found` (scope the part, id the fingerprint), cleared when
      nothing it holds names that fingerprint or a later ask answers it.
    `<module>_first_views` lists these entries with their state and since when, and the part's tool
    `<module>_entry_again` (`fingerprint`; class `act`) asks one again now.
  - **A branch at `none yet`.** A view whose `revision` answered `none-yet` (§530) is ready and empty: the reader's
    answer for that branch lists no entry.
  - **The first pass.** A part acts on nothing until every branch it follows has its first view, `none-yet`
    counting as one; until then `<module>_first_views` says each branch `waiting` and its health says it waits (§200,
    §556). After its first views it acts on what it holds, and a view behind is read again by §196.
-  - **A dropped branch.** When `go/views` drops a branch's view (§532), it clears, through the part's writer (§639),
+  - **The node-engine follows no branch.** It reads the catalog half only by the fingerprints its wants name
    (§421), through the entries above, and declares none of the branch entries; it never waits on a branch's view, the
    registrations or the gate's `source`, so it composes the gate (and every part) before any of them answers, and no
    cycle runs through it at G's delivery.
  - **A dropped branch.** When `go/views` drops a branch's view (§532), it clears, through the part's mesh-sdk writer (§639: a views reader writes its findings through the part's writer, never a writer of its own),
    every finding that view raised (`first-view-unanswered`, `view-waits`, `view-unsaid`, `view-too-large`), says the
    drop and each cleared finding in the part's log, and removes the view's row of `<module>_first_views` [D-12].
@@ -136,8 +167,10 @@ for several build maps is answered once, and the maps' names for it are given in
  §532. Why: the same question came from five build maps, each about to build its own form (develop's D-5). How it
  is checked: unit (`meshcatalogclient`), a branch added by `registration-changed` and one by `source-moved` before
  the first registrations are followed, an entry asked once on a `running` of an unlisted fingerprint and dropped
-  when nothing names it, a `none-yet` branch read as empty; whole (grants part, tool runner), a part started with one
+  when nothing names it, a pending entry read apart from none and a not-found one raising `entry-not-found`, a
-  branch at `none-yet` acts once every first view is in; a dropped branch's findings are cleared.
+  `none-yet` branch read as empty; unit (gate), `source` with no branch lists the branches; whole (grants part, tool
  runner), a part started with one branch at `none-yet` acts once every first view is in; a dropped branch's findings
  are cleared; whole (node-engine), a want composed with no branch view and no `source` answered.
 - §615 **The tool runner's and the Go build module's manifests come from the entry too.** (§594, §614, §443, §445,
  test 61) The mesh MCP server of the tool runner takes each module's manifest from its catalog graph entry, through §614's
  reader; its first view of the indexer's `manifests` and its `consumes` of `mesh-delivery-indexer.views.manifests`
@@ -145,14 +178,17 @@ for several build maps is answered once, and the maps' names for it are given in
  names, by `seat:mesh-catalog.entry` (§506's `manifest-digest` naming the entry's), and its `invokes` of
  `mesh-delivery-indexer.indexer_read_manifests` goes [mesh-catalog Q-B1]. Both join §594's readers. Why: test 61, and
  `manifests` is kept only for node-engines of before G (§445). How it is checked: test 61, a row each.
- §616 **The owner of the assigner's views is read from the catalog half.** (§428, §7) The tool runner's code reads the
+- §616 **The assigner's views are named by the seat, in the code and in the manifest.** (§428, §7) The tool runner's
-  module that holds `mesh-module-assigner` from the catalog half's claims of that seat (§614), and names the views
+  code reads the module that holds `mesh-module-assigner` from the catalog half's claims of that seat (§614) and
-  `<that module>.assignments` and `<that module>.seat-holders` from it, never by a name fixed in code. Its manifest's
+  names the views `<that module>.assignments` and `<that module>.seat-holders` from it, never by a name fixed in code.
-  `consumes` keeps `mesh-delivery-assigner.views.assignments` and `views.seat-holders`, the module's own declaration of
+  Its manifest's `consumes` names them by the seat, `mesh-module-assigner.views.assignments` and
-  what it hears, as a manifest may name a module. Design 46 7-approval-mark §19's holder of `operator-channel` is read
+  `mesh-module-assigner.views.seat-holders`, which the grants part resolves to the seat's holder from the catalog
-  from that view so found. [mesh-tools Q-R3, Q-R17.] Why: §428 removes the name from code, and the catalog half
+  half as it resolves a seat's events, so a new holder is granted with no change of the manifest. Design 46
-  says who claims a seat. How it is checked: unit (tool runner), a fixture catalog half naming another holder of the
+  7-approval-mark §19's holder of `operator-channel` is read from that view so found. [mesh-tools Q-R3, Q-R17.] Why:
-  seat gives views of that name; the code review finds no assigner name in the tool runner's code.
+  §428 removes the name from code, and the catalog half says who claims a seat (review: seams and tools' note). How
  it is checked: unit (tool runner), a fixture catalog half naming another holder of the seat gives views of that
  name; unit (grants part), a seat-named view granted for the seat's new holder; the code review finds no assigner
  name in the tool runner's code or manifest.
 - §617 **The long form of an `invokes` entry stands beside `*`.** (§558, §545) A manifest's `invokes` may hold `*`
  and long-form entries together: the tool runner's is `*`, then `{verb: "seat:mesh-catalog.revision", fields:
  ["none-yet"]}` and `seat:mesh-catalog.entry` with no fields named [mesh-tools Q-R4, Q-R18]. The manifest validator
@@ -214,13 +250,14 @@ for several build maps is answered once, and the maps' names for it are given in
  its start (§205), the fingerprint the node-engine's `running` says of it; the tool runner consumes nothing more for
  it. Design 34 every-event §35 is corrected so. [mesh-tools Q-R14.] Why: the node-engine hands each process its own
  build (§205). How it is checked: unit (tool runner), the act carries the fingerprint of its environment.
- §626 **A module ends G with no more tests than it starts with.** (§419, test budget) §419 holds for the tool runner's
+- §626 **A module ends G with no more tests than it starts with.** (§419, test budget) §419's count starts, for each
  module, at the commit of its repository's main from which G's branch of that repository starts (its merge base with
  that branch), and the check compares the module's count at G's heads against it. This holds for the tool runner's
  work of design 34 every-event and design 46 7-approval-mark: the new tables and the whole test of design 46
-  7-approval-mark §22 and design 34 every-event §19 replace existing tests, and every test they delete counts.
+  7-approval-mark §22 and design 34 every-event §19 replace existing tests, and every test they delete counts. A test
-  Their "New test functions are allowed within each module's budget" is corrected to say so. [mesh-tools Q-R16.] Why:
+  moved with its code (§655) counts in the module it moves to, as no new test there, and as deleted in the module it
-  §419 is milestone G's rule and both parts ship in G's release. How it is checked: the check counts the tool runner's
+  left. [mesh-tools Q-R16.] Why: §419 is milestone G's rule and both parts ship in G's release. How it is checked: the
-  tests against its count at G's start.
+  check counts each module's tests against its count at that commit.
 ## The node-engine and the node agent
 - §627 **The node-engine is a foundation part.** (§6, §529, §577; ADR 0619 §1 to §3) The node-engine composes every
@@ -291,10 +328,13 @@ for several build maps is answered once, and the maps' names for it are given in
  (`view-waits`, `first-view-unanswered`, `view-unsaid`, `view-too-large`) are written through the part's mesh-sdk
  writer as kinds of their own (§580), and the writer's statement covers them beside `observe`'s. [mesh-sdk 7.] How it
  is checked: unit (writer), a statement keeps the reader's open findings.
- §640 **The writer keeps its copy of the finding layout, held equal to the generated types.** (§439, §452) mesh-sdk's
+- §640 **The finding writer reads the generated types; it keeps no copy of the layout.** (§439, §452) mesh-sdk's
-  writer keeps its own `FindingBody`, `FindingCleared`, `FindingsStated` and `FindingsAsked`, in Go and TypeScript, and
+  writer, in Go and TypeScript, defines the small interface it needs of a finding's body (its key's parts, its
-  a test in mesh-contracts holds them field for field equal to the types the seat generator emits. [mesh-sdk 8.] Why:
+  `since`, its kind) and takes the types the seat generator emits for `findings` through it; it holds no
-  one layout, checked, without changing which package imports which. How it is checked: that test.
+  `FindingBody`, `FindingCleared`, `FindingsStated` or `FindingsAsked` of its own, so there is one layout and nothing
  to keep equal. [mesh-sdk 8.] Why: a copy held equal by a test in another repository is not checked on a change of
  mesh-sdk alone, and the TypeScript copy by none (review: running and testing 6). How it is checked: unit (writer,
  both languages), a generated body written and stated; the code review finds no copy.
 - §641 **A stream kept last per subject: where it is read and how it is told.** (§396, §556) mesh-sdk's
  `HearSeatEvents` makes §556's read at the start with an ordered consumer, then follows the durable, and names the
  stream `waiting` in `<module>_first_views` until the read ends [mesh-sdk 9]. The grants part tells such a stream by
@@ -341,79 +381,134 @@ for several build maps is answered once, and the maps' names for it are given in
 ## mesh-catalog's parts
- §654 **The readers of the forge module's old events and tools move to the seat `git`.** (§310, §311, §313, §431)
+- §654 **The readers of the forge module's old events and tools move to the seat `git`.** (§310, §311, §313, §431;
-  mesh-config consumes `git`'s `pull-merged` and `pull-closed` in place of `gitea.pull.merged`, `gitea.pull.closed`
+  ADR 0659 §1) [mesh-catalog Q-F1.]
-  and `gitea.forge.pull-request.closed`, and invokes `seat:git.pull` in place of `gitea.gitea_get_pull_request`; the
+  - **mesh-config** consumes `git`'s `pull-merged` and `pull-closed` in place of `gitea.pull.merged`,
-  records module consumes `git.pull-merged`; mesh-issues invokes `seat:git.pull` and `seat:git.contains`, and reads a
+    `gitea.pull.closed` and `gitea.forge.pull-request.closed`, and invokes `seat:git.pull` in place of
-  pull request's checks and reviews from the delivery record's `show` (its steps' results, the review step's among
+    `gitea.gitea_get_pull_request`; **the records module** consumes `git.pull-merged`.
-  them), in place of `seat:mesh-delivery.checks` and `gitea_pull_reviews`. [mesh-catalog Q-F1.] How it is checked:
+  - **The order.** Main's forge module says its own `pull.merged`, not the seat's events, so each consumer of
-  unit (manifest validator), each manifest of G's heads names none of the old events or tools.
+    `git.pull-merged` or `pull-closed` is ordered after the forge module's version that says them, by the edge of kind
    6 its `consumes` gives (§558); its durable consumer is made from the stream's first message, so no merge said
    before it began is missed, and no catch-up through `git.pull` is needed.
  - **mesh-issues** invokes `seat:git.pull` and `seat:git.contains`, and reads a pull request's steps from the
    runner's `show` given the repository and the pull request's head commit (`seat:mesh-pipeline-runner.show` in its
    `invokes`), which answers that commit's pipelines with each step's result, the review step's among them (ADR
    0666 §22); a commit with no pipeline is answered `none`, which mesh-issues shows as "no run". The forge's own
    reviews are read nowhere: G keeps no review record (ADR 0659 §1). Its read of `seat:mesh-delivery.checks` and
    `gitea_pull_reviews` go.
  How it is checked: unit (manifest validator), each manifest of G's heads names none of the old events or tools;
  unit (mesh-config, records), each acts on a `git.pull-merged` fixture; unit (mesh-issues), a commit with no
  pipeline shown as "no run".
 - §655 **The take and restore of one stream is shared code in mesh-sdk.** (§554, §464; ADR 0672 §1) The code that
  takes and restores one stream's snapshot moves whole from the bus module's `bussnap` into mesh-sdk's `go/bussnap`,
-  imported by the bus module (its snapshot before `recreate` and `drop`) and by the recovery module (its points and
+  imported by the bus module (its snapshot before `recreate` and `drop`), by the recovery module (its points and
-  restores); no module imports another module's package. [mesh-catalog Q-R1.] Why: code two modules share lives in
+  restores), and by any part that takes the nightly dump's stream snapshots; no module imports another module's
  package, and no third copy is kept. The edge of kind 1 from mesh-sdk's package (§47) orders its publication before
  the bus module's and the recovery module's builds. [mesh-catalog Q-R1.] Why: code two modules share lives in
  mesh-sdk (§464's reason). How it is checked: the code review finds one copy.
- §656 **The hand tools are the recovery module's own tools, answered by its process.** (§554, §566; ADR 0672 §3, §7)
+- §656 **The hand tools' acts are verbs of the seat `mesh-recovery`.** (§554, §566; ADR 0672 §7) Each hand tool's act
-  Each hand tool is a module tool on the process's own `by-caller` subject, the bundle passing the call through, so
+  is a verb of the seat `mesh-recovery`, `by-caller`, answered by the process: `take`, `restore`, `retry`, `aside`,
-  the bus proves the tool runner's account; the seat `mesh-recovery` gains no verb. [mesh-catalog Q-R2.] How it is
+  `discard-aside`, `restore-aside`, `cancel` and `expire-points`, each of class `act` (§610), beside `snapshot-kept`,
-  checked: whole (recovery module), a hand tool from another account is refused by the bus.
+  `restore-kept` and `kept-points`, all defined in mesh-contracts. The tools bundle's `recovery_*` tools call them,
- §657 **The recovery module's health check is a tool.** (§554, §468) The recovery module serves the read tool
+  named in its `invokes`, and hold no grant of their own; the bus proves the tool runner's account, as ADR 0672 §7
-  `recovery_kept_points`, answering what `kept-points` answers, and its declared health check names it.
+  has the bundle call the seat's verbs. [mesh-catalog Q-R2.] Why: ADR 0672 §7 (review: seams and tools 2). How it is
-  [mesh-catalog Q-R3.] How it is checked: unit (manifest validator), the check names a served tool.
+  checked: unit (mesh-recovery's contract), each verb read; whole (recovery module), each hand tool acts through its
  verb.
 - §657 **The recovery module's health check is a tool.** (§554, §468, §561) The recovery module serves the read tool
  `recovery_kept_points`, answering what `kept-points` answers, its bundle naming `seat:mesh-recovery.kept-points` in
  `invokes`, and its declared health check names it. The check fails while an aside's record ends at `removed` and no
  running act holds it, as §554 has it, which `recovery_kept_points` answers. §554's "calls `kept-points`" is
  corrected so. [mesh-catalog Q-R3.] How it is checked: unit (manifest validator), the check names a served tool;
  whole (recovery module), an unrestored aside fails the check.
 - §658 **A module new in G starts with the tests its lines name.** (§419) A module new in G counts from none: its
  tests are the checks its design lines name (for the recovery module, its one whole test and the unit rows of its
  lines), within the per-module budget. [mesh-catalog Q-R4.]
 ## mesh-contracts' seat contracts
- §659 **`snapshot-kept` and `restore-kept` are of class `act`.** (§554; ADR 0672 §3) Class `act`, their callers
+- §659 **`snapshot-kept` and `restore-kept` are of class `act`.** (§554, §610) Class `act`, taking its default, as
-  `seat:node-engine` alone, as §554 names them. [mesh-contracts DQ-5.]
+  every verb does (§610). [mesh-contracts DQ-5.]
 - §660 **A finding's key and value.** (§461, §437, §439) The state `findings` keeps the key `<scope>.<id>.<kind>` and the
  value `#/bodies/Finding`. [mesh-contracts DQ-7.]
 - §661 **`list` shows the caps.** (§547) The seat `mesh-broker`'s `list` answer gains `caps {sum-mib,
  account-limit-mib, server-limit-mib}`, an absent limit meaning unlimited. [mesh-contracts DQ-10.]
 - §662 **A subject function with parts can fail.** (§523) A generated subject function with `<part>` tokens answers
  `(string, error)` in Go and throws in TypeScript for an empty part, `.` or `..`. [mesh-contracts DQ-11.]
- §663 **The condition keeper's sources are the bus module's `created` events.** (§515, §529) The keeper takes a
+- §663 **The condition keeper's sources are the bus module's `created` events, and it follows a moved stream.** (§515,
-  source when it hears the seat `mesh-broker`'s `created` of a part's `finding-events` entry, and a foundation part's
+  §529, §611, §612) The keeper takes a source when it hears the seat `mesh-broker`'s `created` of a part's
-  old finding stream from the catalog half (§614); at its start it reads both by `list` and the catalog half. §515 is
+  `finding-events` entry, named in its `consumes`, and a foundation part's old finding stream from the catalog half
-  corrected so. [mesh-contracts DQ-12; D-7's COND9.] Why: the grants part makes the consumers (§386), and no binding
+  (§614); at its start it reads both by `list` and the catalog half. When a part's catalog graph entry no longer
-  names one. How it is checked: whole (keeper, bus module), a part declaring finding events is asked once its entry
+  declares the stream the keeper follows for it (its findings moved to a template, §611, or to an old section, §612),
-  is `created`.
+  the keeper drops that source and its consumer, keeps the part's open conditions, and asks `findings-asked` on the
  new stream once it is a source; the part's statement there settles them (§384). §515 is corrected so.
  [mesh-contracts DQ-12; D-7's COND9.] Why: the grants part makes the consumers (§386), and no binding names one; a
  moved stream must neither raise twice nor leave a condition open (review: health and events 1). How it is
  checked: whole (keeper, bus module), a part declaring finding events is asked once its entry is `created`; a part
  whose findings move keeps its condition raised once and clears it from the new stream.
 - §664 **`backed-up` needs no contract change.** (§563) The backup holder's answer carries a put-off item's `act` and
  since when in its own fields. [mesh-contracts DQ-14.]
- §665 **`attempt-changed` is keyed by condition and attempt.** (§541) The subject is
+- §665 **`attempt-changed` is keyed by condition and attempt.** (§541, §73) The subject is
-  `mesh.seat.mesh-healers.event.attempt-changed.<condition>.<attempt>`, kept last per subject, so two attempts on one
+  `mesh.seat.mesh-healers.event.attempt-changed.<condition>.<attempt>`, each token escaped as a key's name is (§73),
-  condition both stay. [mesh-contracts DQ-15.] How it is checked: unit (healers' contract).
+  kept last per subject, 7 days and 16 MiB (§541), so two attempts on one condition both stay. At about 0.5 KiB a
-
+  message, 16 MiB holds about 30,000 attempts, far more than seven days have seen (an estimate). The stream discards
  nothing new: a publish past its cap fails, and the healers say it in their health and write the finding
  `attempt-unsaid` (scope the healers, id the condition), cleared by that subject's next publish taken. §541's
  subject is corrected so. [mesh-contracts DQ-15.] How it is checked: unit (healers' contract), two attempts of one
  condition kept; whole (healers), a full stream raises `attempt-unsaid`.
 ## Met in develop
- §666 **`nats_snapshot_get`'s arguments and answer.** (§554, §567; ADR 0672 §1, §8; ADR 0666 §16) It takes `request`,
+- §666 **`nats_snapshot_get`: the snapshot recorded with its digest, and sent on the call's own session.** (§554,
-  the id of the bus module's `drop` or `recreate` request whose snapshot is asked, as the keeper's requests record it.
+  §567, §518, §620; ADR 0672 §1, §8; ADR 0667 §12) [D-1.]
-  It answers `{request, module, local, stream, size, digest, at, object}`: `digest` the `sha256:` digest of the
+  - **When it is taken.** The bus module's keeper, taking the snapshot before a `drop` or `recreate` (ADR 0595 §5),
-  snapshot's bytes, and `object` the name of the snapshot in the bus module's sent store (§59), which the recovery
+    writes into that request's record in its state `requests` the snapshot's `path` (under its snapshots directory),
-  module reads by the standing grant of that answer; a snapshot larger than the sent store's cap (§591) answers
+    `size` and `digest` (`sha256:` of its bytes) before it touches the live data. A snapshot it cannot write whole and
-  `error`, naming its size and the cap. `recovery_restore` names it by `request`, and the recovery module checks the
+    record so makes the `drop` or `recreate` refuse, naming why, before anything is removed.
-  bytes against `digest` before it takes any aside, as §567. [D-1.] Why: the snapshot crosses the bus as every large
+  - **Who deletes it.** The keeper alone: the snapshot file and its record are kept 90 days (ADR 0667 §12, as the
-  answer does, never as a shared file. How it is checked: whole (bus module, recovery module), a `drop`'s snapshot
+    delivery records), its setting `snapshot-keep-days`, and removed at the keeper's start and at each new request
-  restored by `recovery_restore` with its `request`, and one with altered bytes refused.
+    once older, each removal written in its journal.
- §667 **Where a trusted change and the seed wait for their warrant.** (§3, §8; ADR 0666 §2, §12; ADR 0259) [D-2, D-3.]
+  - **The call.** It takes `request`, the request's id. It reads the file, computes its digest, and answers `error`
    `snapshot damaged`, naming the request, when it differs from the recorded one, or `snapshot missing` when no file
    is there. Otherwise it answers `{request, module, local, stream, size, digest, at, chunked: true}` and sends the
    file on the call's own get session, `<the tool's call subject>.get.<call id>`, in chunks under the bus's
    per-message limit, each acknowledged by the caller before the next, as §518 and §620 have a get session; only the
    bus module's account publishes the chunks and only the caller's account answers them, granted so (§489). No size
    limit applies and nothing goes through the sent store.
  - **Its use.** `recovery_restore` names it by `request`, and the recovery module checks the bytes it received
    against `digest` before it takes any aside (§567).
  Why: a snapshot larger than the sent store's cap, or asked after its 7 days, could never be restored, and the
  sent store's read grant is wider than this one caller (review: all four domains). How it is checked: whole (bus
  module, recovery module, with small settings), a snapshot larger than 256 MiB restored whole; one asked eight days
  after its `drop` with `snapshot-keep-days` 90 restored; a file altered on disk after the `drop` refused `snapshot
  damaged`; a `drop` whose snapshot cannot be written refuses before it removes anything.
 - §667 **Where a trusted change and the seed wait for their warrant.** (§3, §8; ADR 0666 §2, §12; ADR 0259 §6; ADR
  0286 §10) [D-2, D-3.]
  - **Kept.** The indexer keeps each change of `register`, `policy`, `watch` and `unwatch` awaiting its warrant in its
    old `state` section `proposals`, one key `<verb>.<module>` (`<verb>.<module>.<branch>` for `watch` and
-    `unwatch`, each token escaped as a key's name is, §73), holding the change whole, the ask's id, its caller and
+    `unwatch`, each token escaped as a key's name is, §73), holding the change whole, its `digest` (`sha256:` of the
-    when it was asked; the seed's key is `seed`. Capped at 4 MiB.
+    change in RFC 8785's canonical form), the current ask's id, its caller and when it was asked; the seed's key is
    `seed`. Capped at 4 MiB.
  - **Asked.** Through `operatorchannelclient`, kind `ask`, level `approve`, its `about` the key, so a newer change of
-    the same key replaces the open ask (ADR 0666 §12).
+    the same key replaces the open ask (ADR 0666 §12); the ask names every value the change moves (§3) and carries the
-  - **Heard.** By the indexer's durable consumer of `mesh.seat.operator-channel.event.decided.<the indexer's module>`.
+    change's `digest`, so the warrant approves those exact values (ADR 0286 §10).
-    A warrant writes the version by compare-and-set and deletes the key; a Decline, an expiry or a refusal deletes it
+  - **Heard.** The indexer's manifest `consumes` `operator-channel.decided`, on
-    and writes nothing, said in its journal and its answer to the caller; the seed's keeps `seed-waits` (§8).
+    `mesh.seat.operator-channel.event.decided.<the indexer's module>`, through a durable consumer. A warrant is
-  - **A restart.** At its start the indexer reads each key and the seat `operator-channel`'s `asks` for its ask:
+    applied only when its ask's id is the key's current ask and its digest the key's: it writes the version by
-    a decided one is applied as above, an open one waited on, and one the router no longer holds deleted, said.
+    compare-and-set and ends the key `applied`. A warrant of a replaced ask writes nothing, said in its journal. A
-  - **Its tools.** `indexer_proposals` (class `read`) lists the keys with their asks; `indexer_seed_again` raises
+    Decline, an expiry or a refusal ends the key with that outcome; the seed's keeps `seed-waits` (§8).
-    the seed's ask again from its key (§8).
+  - **Ended keys stay readable.** An ended key keeps its outcome, its ask and when, until the next change of the same
    key replaces it.
  - **A restart.** At its start the indexer reads each open key and the seat `operator-channel`'s `asks` for its
    ask: a decided one is applied or ended as above, an open one waited on, and one the router no longer holds ended
    `lost`, said.
  - **Its tools.** `indexer_proposals` (class `read`) lists the open and ended keys with their asks and outcomes;
    `indexer_proposal_drop` (`key`, `why`; class `act`, in the hand-act log) cancels the key's open ask and ends it
    `dropped`; `indexer_seed_again` raises the seed's ask again from its key (§8).
-  How it is checked: whole (indexer), a `policy` applied on its warrant after a restart while open, a decline
+  How it is checked: whole (indexer), a `policy` applied on its warrant after a restart while open; a decline ends
-  writes nothing, and two `policy` changes of one module leave one ask.
+  the key `declined`, read by `indexer_proposals`; two `policy` changes of one module leave one ask, and the first
  ask's late warrant writes nothing; a dropped key's ask is cancelled.
 - §668 **`manifest-accepted`'s `problems`.** (§500; ADR 0579 §1) The event gains `problems`, a list of `{rule,
  words}`: each problem the indexer's re-judgement finds in a manifest it keeps accepted because its digest is
  unchanged (ADR 0579 §1), the same items its verdict writes as warnings; an empty list when none. It is defined in
@@ -438,16 +533,25 @@ for several build maps is answered once, and the maps' names for it are given in
  §526 gives the want's field; every artifact of the build is kept on that node, and each artifact in `made` keeps its
  digest as now. A build not kept carries no `kept-on`. [D-9.] How it is checked: unit (builder), a kept build's
  `build.ended` names its node, and the assigner writes it into the want (§526).
- §672 **The builder's toolchain wait.** (§267, §276, §472, §629) The builder holds an entry while its fingerprint
+- §672 **The builder's toolchain wait.** (§267, §276, §472, §557, §629, §633) The builder holds an entry while its
-  names a toolchain version of its language other than the one the builder's newest `toolchain-agreed` of that
+  fingerprint names a toolchain version of its language other than the one the builder's newest `toolchain-agreed`
-  language names (§267). It keeps each wait in its old `state` section `waits`, one key `<module>.<fingerprint>`
+  of that language names (§267).
-  (escaped as a key's name is, §73), capped at 4 MiB, deleted when the wait ends. It says `wait-held` and
+  - **Its state.** Each wait is kept in the builder's old `state` section `waits`, one key `<module>.<fingerprint>`
-  `wait-ended` on its own stream, on `mesh.stream.mesh-delivery-builder.event.wait-held` and `.wait-ended` (G-4's
+    (each token escaped as a key's name is, §73), capped at 4 MiB, deleted when the wait ends.
-  table), the body the fields of §629's wait with `step` `building`, `on` `toolchain:<language>@<version>`, `module`
+  - **Its events.** It says `wait-held` and `wait-ended` on its own old `streams` section `waits`, on
-  and `fingerprint`, and `wait-ended` its `how` (`ran` when a `toolchain-agreed` names that version, `released` by
+    `mesh.stream.mesh-delivery-builder.event.wait-held.<module>.<fingerprint>` and `.wait-ended.<module>.<fingerprint>`,
-  `builder_release`). `builder_waits` reads the state, and `builder_release` builds the entry with the running build
+    kept last per subject, 7 days, 16 MiB; the body the fields of §629's wait with `step` `building`, `on`
-  module, written in the hand-act log (§276). [D-10.] How it is checked: whole (builder), an entry held until
+    `toolchain:<language>@<version>`, `module` and `fingerprint`, and `wait-ended` its `how` (`ran` when a
-  `toolchain-agreed` names its version, then built, the wait ended `ran`; one released by hand ended `released`.
+    `toolchain-agreed` names that version, `released` by `builder_release`). At its start it says `wait-held` again
    for every key of `waits`. G-4's table reads so.
  - **Its bound.** 60 minutes, its setting `toolchain-wait-minutes`; past it the builder writes the finding
    `toolchain-waits` (scope the builder, id `<module>.<fingerprint>`), cleared when the wait ends.
  - **Its tools.** `builder_waits` reads the state, and `builder_release` builds the entry with the running build
    module, written in the hand-act log (§276).
  [D-10.] How it is checked: whole (builder, with small settings), an entry held until `toolchain-agreed` names its
  version, then built and ended `ran`; one released by hand ended `released`; one past its bound raises
  `toolchain-waits`; a restart says the open wait again.
 - §673 **`package-published`'s one `dependencies` list holds both kinds.** (§374, §466) The contract's `dependencies`
  in each artifact of `package-published` is §466's `resolved` and `toolchain` in one list: each item `{kind,
  part, version, digest}`, kind 1 for each `resolved` package (its part the package's artifact reference, §504) and
@@ -476,10 +580,15 @@ for several build maps is answered once, and the maps' names for it are given in
    `<node>.<module>` whose want or running build names it, written by compare-and-set, capped at 4 MiB. An entry
    object is removed only at the first revision after no kept revision lists it and its `named` set is empty; a
    `wanted` or `running` that moves on removes its `<node>.<module>` from the old fingerprint's set.
-  - **Its tool.** `indexer_entries` (class `read`) reads a fingerprint's key, its object's digest and its `named` set.
+  - **A node that leaves.** A `running` stays on its stream for ever, so a member a `running` put in the set leaves it
    also when the want of that node and module is removed (`wanted` saying it removed: the node left or the module was
    unplaced), whatever that node last said running.
  - **Its tools.** `indexer_entries` (class `read`) reads a fingerprint's key, its object's digest and its `named` set;
    `indexer_named_drop` (`fingerprint`, `member`, `why`; class `act`, in the hand-act log) removes one member.
  How it is checked: unit (indexer), an entry no revision lists is answered by `entry` while a want names it and
-  removed after the want moves on; a restart reads `named` whole before it removes anything.
+  removed after the want moves on; a member whose want is removed leaves the set; `indexer_named_drop` removes one;
  a restart reads `named` whole before it removes anything.
 - §676 **Each entry carries its artifacts' package names.** (§491, §478, §504, §412) At take-in the indexer reads each
  artifact's package name from the revision's own files at the artifact's path (the `module` of its `go.mod` for a Go
  package, the `name` of its `package.json` for an npm package, the manifest's image name for an image) and writes it
@@ -0,0 +1,71 @@
 ---
 layer: to-be
 status: in-progress
 design: 47
 milestone: G
 updated: 2026-11-11
 decisions:
  - "ADR 0673"
  - "ADR 0672"
  - "ADR 0668"
  - "ADR 0667"
  - "ADR 0666"
  - "ADR 0660"
  - "ADR 0656"
  - "ADR 0626"
  - "ADR 0619"
  - "ADR 0618"
  - "ADR 0596"
  - "ADR 0595"
  - "ADR 0579"
  - "ADR 0573"
  - "ADR 0448"
  - "ADR 0429"
  - "ADR 0363"
  - "ADR 0286"
  - "ADR 0283"
  - "ADR 0259"
 ---
 # 47, milestone G: the fix round of batches 6 and 7
 One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
 [G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
 *§677 to §680 come from the fix round of the review by architectural domain of §587 to §676 (lead-47's input of
 2026-11-11): the approval mark once no verb names its callers (the operator's answer of about 16:10 CET, §610), and
 develop's D-16 to D-18, of internal form only. The round's other fixes are written in the lines they correct.*
 ## The approval mark, with no named callers
 - §677 **A module's process that calls a marked verb carries the operator's warrant for that one call.** (§610; ADR
  0286, ADR 0259 §6, ADR 0626 §4) A call through the tool runner is asked, judged and claimed by the tool runner as
  ADR 0286 and design 46 7-approval-mark have it. A module's process may now call a marked verb directly (§610); then:
  - **The caller asks.** It makes the act of that call as ADR 0286 §10 and §11 make one (the address, the node that
    serves it, the build and every argument, digested with `ActDigest`), asks it through `operatorchannelclient`
    under its own module's name, at level `approve`, and calls only once the warrant is given, naming the ask in the
    call.
  - **The holder checks.** The marked verb's holder takes the call only with a warrant whose act's digest is the
    digest of the call it received, claims it once (`Take`), and refuses any other call before acting, naming the
    ask the caller must make, as the bus module's keeper checks a warrant (ADR 0626 §4). mesh-sdk's seat server does
    this for every marked verb, read from the definition's or the manifest's mark, so no holder builds it.
  Why: the mark stays while no caller list does (O-6; review: security and upgrade 2). How it is checked: whole
  (a fixture marked verb, its holder and a module's process), a call with no warrant refused, one with a warrant for
  other arguments refused, one with its warrant run once, and the same warrant used twice refused.
 ## Develop's D-16 to D-18
 - §678 **The forms of a finding's `owner` and `waiting-on`.** (§451, §540, §580) Each is one of three forms, written as
  patterns in the finding layout's definition: a session `^[a-z0-9][a-z0-9._-]*@[a-z0-9][a-z0-9-]*$` (who@node), a seat's
  name `^[a-z][a-z0-9-]*$`, or a commit's author `^forge:[A-Za-z0-9._-]+$`. mesh-sdk's finding writer (§580) refuses any
  other, naming the field; the contract's fixtures read each form. [D-16.] How it is checked: unit (writer), each form
  written and another refused.
 - §679 **`reserved`'s answers.** (§582, §586) `reserved` answers `{module, version, artifacts, released}`, `released` a
  boolean (as §530's `none-yet`), or `{error}`, a string; `module`, `version` and `artifacts` are required only without
  `error`. [D-17.] How it is checked: unit (`mesh-builds`' contract), the three answers read.
 - §680 **Where the seat generator and the build modules' conformance kit live.** (§464, §495) §495's "the seat
  generator is imported by no running module" reads "by no running module but through `steprun`'s regenerate and
  compare". The build modules' shared conformance kit is `sdk/steprun/conformance` in the delivery SDK, which
  mesh-catalog's build modules and their checks import. [D-18.] How it is checked: the code review.
@@ -285,7 +285,7 @@ say another runs a build (ADR 0363 §2); the gate's events are granted to the ga
 | an entry wanted | `wanted` | `mesh-wants`, the assigner | `mesh.seat.mesh-wants.event.wanted` | the seat's definition in `mesh-delivery-contracts` (ADR 0641 §2) |
 | an entry composed, and running healthy | `composed`, `running` | `node-engine`, the node-engine on each node | `mesh.seat.node-engine.event.composed.<node>`, `.running.<node>.<module>`, the latter on a stream kept last per subject with no age limit | the seat's definition in `mesh-contracts` |
 | a node's capabilities changed, or its node returned | `manifest-reads-changed` (ADR 0618 §4; §590) | `node-engine`, the node-engine on that node | `mesh.seat.node-engine.event.manifest-reads-changed.<node>` | the same |
-| a wait held, and ended | `wait-held` (step, acting part, its version, the entry, since when, its bound), `wait-ended` (the same, and how: ran, released) | each holder: `mesh-wants` for the assigner (placing, wanting and composing), `mesh-grants` for the grants part, the builder's own stream | `mesh.seat.<seat>.event.wait-held`, `.wait-ended`; `mesh.stream.mesh-delivery-builder.event.wait-held`, `.wait-ended` | each seat's definition; the builder's manifest |
+| a wait held, and ended | `wait-held` (step, acting part, its version, the entry, since when, its bound), `wait-ended` (the same, and how: ran, released) | each holder: `mesh-wants` for the assigner (placing, wanting and composing), `mesh-grants` for the grants part, the builder's own stream | `mesh.seat.<seat>.event.wait-held`, `.wait-ended`; `mesh.stream.mesh-delivery-builder.event.wait-held.<module>.<fingerprint>`, `.wait-ended.<module>.<fingerprint>` (§672) | each seat's definition; the builder's manifest |
 | a store filling, full, and back below its cap | `filling`, `full`, `room` | `mesh-catalog`, `mesh-wants`, `mesh-delivery` | `mesh.seat.<seat>.event.filling`, `.full`, `.room` | each seat's definition |
 | a record pins or frees a revision; a candidate's heads replaced; a record ended | `pinned`, `freed`, `heads-replaced`, `record-ended` | `mesh-delivery`, the gate | `mesh.seat.mesh-delivery.event.<event>` | the seat's definition in `mesh-delivery-contracts` |
 | a milestone's ask asked, withdrawn and answered, until G's delivery | `milestone-asked`, `milestone-withdrawn`, `milestone-answered` | `mesh-delivery`, the gate | `mesh.seat.mesh-delivery.event.<event>`, the milestone in the event, on the seat's family stream, apart from each delivery's `transition` | the same |
@@ -60,10 +60,10 @@ line says so.*
  from the node-engine's code: the definition is the one source (§68). Why: the design's choice (Q-H8). How it is checked: unit (definition reader), each of the eleven names
  its callers; the code review finds no callers table in the node-engine.
 - §394 **The callers of G's new trusted acts.** (§482) `mesh-catalog`'s `register`, `policy`, `watch` and `unwatch`, and
-  `mesh-delivery`'s `recovery`, are of class `act`: the operator and sessions; `registrations` is a `read`.
+  `mesh-delivery`'s `recovery`, are of class `act`, taking its default (§610: the operator, sessions and invokers); `registrations` is a `read`.
  `mesh-pipeline-runner`'s `review` is called by sessions, refusing none for authorship in G (§482); its `accept` by
-  its class's default (§610), which amends §30's "a person". `operator-channel`'s `ask-again` is a seat verb, its callers the
+  its class's default (§610), which amends §30's "a person". `operator-channel`'s `ask-again` is a seat verb of class `act`, taking its
-  operator and the healers (§83, §40). Why: the operator, 2026-11-11 02:56 CET on Telegram, "As proposed" (S4, S10,
+  default (§610), the healers among its invokers (§83, §40). Why: the operator, 2026-11-11 02:56 CET on Telegram, "As proposed" (S4, S10,
  C18, D2, D3, D4). How it is checked: whole (indexer, runner, operator-channel), a call from any other caller is
  refused by the bus; unit (definition reader), each verb's class and callers.
 - §395 **An accepted kind naming no callers keeps today's grant.** `operator-channel`'s kinds `ask` and `condition`
@@ -82,7 +82,7 @@ file on 2026-11-10, and is cited as "design 47 G §n". A sentence that holds a d
 stayed in the main file, and G builds what it says from G's delivery. A section named in italics is in this part, or,
 when it is not here, in the main file.
-The part is seventeen files, each read whole, its design lines numbered across them:
+The part is eighteen files, each read whole, its design lines numbered across them:
 - [G-1-pipelines-registration-and-steps](G-1-pipelines-registration-and-steps.md): pipelines per module: registration, watched branches, steps and policy, what holds a delivery, approval, groups, dependencies, a publish.
 - [G-2-pipelines-sizes-checks-and-tools](G-2-pipelines-sizes-checks-and-tools.md): pipelines per module: any size, the pipeline makes the check, who may say what, health, recovery, tools, kept data, how G itself is delivered, the choices under ADR 0666 and ADR 0667.
@@ -101,5 +101,6 @@ The part is seventeen files, each read whole, its design lines numbered across t
 - [G-15-develop-answers-fifth](G-15-develop-answers-fifth.md): develop's fifth batch, round 3's notes on §516 to §559, the knowledge base's review of the recovery module's record, and the operator's answers of 2026-11-11 about 14:05, 14:15 and 14:30 CET (§560 to §586).
 - [G-16-develop-answers-sixth](G-16-develop-answers-sixth.md): develop's sixth batch: the ledger's upkeep calls, the builder's publishes again and its read of a module's builds, one event of a node's capabilities, the object stores' caps, the gate's merge path from G's delivery, and the readers of a module's manifest (§587 to §594).
 - [G-17-develop-answers-seventh](G-17-develop-answers-seventh.md): develop's seventh batch: the operator's answers of 2026-11-11 15:14 to 15:42 CET (callers by class, the five parts' findings, the forge and image registry's other entries, the gate's kept data), how every part reads the catalog half per watched branch, and the refreshed build maps' questions (§610 to §676).
 - [G-18-fix-round-six-seven](G-18-fix-round-six-seven.md): the fix round of §587 to §676: the approval mark once no verb names its callers, and develop's D-16 to D-18 (§677 to §680).
 Design 34's milestone [every-event](../34-milestones/every-event.md) and design 46's milestone [7-approval-mark](../46-milestones/7-approval-mark.md) ship in milestone G's release, built in its repositories beside G's lines (lead-47, 2026-11-11 15:30 CET); where one of their lines and a line of G differ, G's later line holds and the other is corrected in place (§624 to §626).