Designs 25, 51: follow review round 2 (decided via uses, spend record apart, fix checks, genesis gap, kept answer)

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

03-DESIGN/01-to-be/25-the-bus-on-nats.md

@@ -935,11 +935,12 @@ that the warrant binds exactly this act on this entry (ADR 0259 §6), as the mai
 without a valid warrant it refuses, deleting nothing and writing why into its answer; with one, it takes the entry's
 stream snapshot first. **The process wakes on the warrant, never on a timer**: a warrant is said on the operator
 channel's `decided` for the asker that raised the ask (ADR 0259 §6; ADR 0620 §2), here the bus module itself, which
-hears its own `decided` through `consumes` on a durable consumer and runs its pass over the waiting `recreate` and
+hears its own `decided` on a durable consumer of the process, whose filter the grants part derives from the
+process's `uses` of the operator channel seat (not from a `consumes`, which a process has none of), and runs its pass over the waiting `recreate` and
 `drop` requests when one arrives, so a warranted `drop` acts within seconds of the operator's answer, and one given
 while the process was down is heard when it is back. **A warrant acts once** (ADR 0259 §6): before it acts, the
-process claims the warrant's ask id by writing the key `acted.<ask id>` in its own state `requests` (no new state),
-created by compare-and-set after the snapshot and before any deletion, and a request naming an ask it already
+process claims the warrant's ask id by writing the key `acted.<ask id>` in a state of its own, apart from `requests` (a person's request and the record
+of what it spent are never in one bucket), created by compare-and-set after the snapshot and before any deletion, and a request naming an ask it already
 acted on is refused, deleting nothing and saying which act that warrant already performed. **An ask lasts 12 hours**,
 shorter than the 24 hours `requests` keeps a request: a request whose ask ended unanswered is ended and said, and a
 warrant is not acted on once its ask ended; the tool raises the ask before it hands the request over. A request
@@ -1071,6 +1072,7 @@ issue 1966.
 | `manifest-accepted` is never lost silently | unit tests of the indexer: a failed publish is published again, and one still failing writes the finding; `indexer_say_accepted` says it again for one module from the verdict held, and refuses a module with no accepted verdict |
 | A person's request goes through `requests`, and the process verifies the warrant itself and acts on it once (ADR 0626 §4, ADR 0259 §6) | the process's unit tests: a `recreate` and a `drop` written to `requests` with no warrant, with a warrant for another act or entry, with a warrant the operator channel's record does not hold, and with a warrant whose ask id the process already acted on are each refused, delete nothing and say why; a `create` or the seat's `apply` for an entry no accepted manifest asks for is refused; the stamp is the caller the tool runner proved, whatever the request's body names |
 | The process's account, and the bus module's only bus declaration (ADR 0626 §1 to §3) | the judge's unit test: the bus module's manifest with its process's `bus` and `keeps` is accepted; `keeps` on any other process or module, any other bus declaration of the bus module, and a subject of its process on which a tool is answered are refused; the composition test: the process is granted the create, update, delete and snapshot subjects under modules' names, nothing on which a tool or a verb is answered, and no subscription to a restricted stream's subjects beyond the snapshot request, its acknowledgements and its inbox; the snapshot account is granted the same subjects as before; no tool runner and no tool of the bus module holds the bus's create, update or delete subjects |
+| The process's fixes of review round 1 hold | the nats module's whole-module integration test and unit rows: an event or condition the bus did not take is kept, named by the health tool and said again at the next fill pass; a second accepted manifest asking for an entry raises no overdue condition; the warrant's wake on `decided` acts within seconds without a call to the pass by the test; a second request naming a spent ask is refused naming the act it spent; an ask past 12 hours is not acted on |
 | Drift and orphans, live | live, made only by a manifest change: a manifest that shrinks a setting raises `drifted`; the conditions clear as above. Nothing is filled on the live bus, and no orphan is made there |
 | Overdue and stopped are loud | live, carried by the change of the first module that moves in step 5, never by a merge made for the test alone: with the bus module's process stopped, an accepted manifest asking for an entry raises the overdue condition within five minutes, from the watchman, and a later `created` clears it; the bus module's health turns unhealthy when its pass is more than three minutes old |
 | A person's tools reach the process, and only by role | live: a role without the dangerous grant is refused `drop`'s tool; the tool runner's account holds no grant of the bus's create, update or delete subjects |

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

@@ -451,7 +451,10 @@ oldest in its single reference, so a node is held from them only when its engine
 to the store on its node's loopback, with no credential, as the publish contract allows for a write that reaches the
 store from its own node, and records their references under the seat's reach. No one-off credential exists: the
 node-engine writes no push credential and the holder's front keeps no bootstrap token. How the rest of the bootstrap
-goes is research 075's.
+goes is research 075's. **A fresh mesh cannot raise the front of `distribution` by that push alone**: the front is
+the holder's program, a bundle the builder builds and publishes through the front itself (ADR 0605 §7), so the
+bootstrap must also push that bundle to the loopback store, and the holder's node fetch it there, with the first steps
+naming the loopback reference until the front serves. That is the genesis fix of issue 1152, not this milestone's.
 
 ### Acceptance tests
 
@@ -465,8 +468,8 @@ test).
   introducing a new package takes `0.1.0-<tag>.1`; the checker's `tag-wanted` yields `numbered` and `published`, and
   members are built only after `published`; no `published` in 10 minutes fails the check naming the package;
   `builder_untag` removes a branch's tagged versions with `removed`; a tagged version whose digest another tag names
-  keeps its tag on the store pinned today (a registry that cannot remove a tag alone), `removed` is said with that
-  reason and the builder records it gone, and its bytes go with the other tag's removal, the move to a registry that
+  keeps its tag on the store pinned today (a registry that cannot remove a tag alone), the holder answers `kept` with
+  that reason, `removed` is not said and the builder records the version gone, and its bytes go with the other tag's removal, the move to a registry that
   removes a tag alone being the next milestone's; a `remove` while the holder is down is retried and
   past 15 minutes writes its finding; a late `published` after the bound writes the done key; `builder_publish_again`
   after the build's file is gone builds again under the same number; with the seat's holder stopped at a first claim
@@ -550,8 +553,13 @@ test).
   `mesh.seat.node-engine.event.manifest-reads-changed`, and no other module's subscriptions hold it.
 - **Checker.** A changed build module invoking a verb no running holder serves is not run, and the verdict names the
   modules composed from their manifests instead, and the verb.
-- **Vault.** Reverting the milestone's merge mints the build modules' credentials again; the bootstrap's one-off
-  credential is gone once the holders serve `publish`.
+- **Vault.** Reverting the milestone's merge mints the build modules' credentials again; the bootstrap holds no
+  credential of its own to revert.
+- **Round 1's fixes, unit and integration cases of the modules' existing tests.** A shared-digest tagged `remove` on the
+  store's 2.8 form answers `kept`; the idle drop fires on the key's expiry, including one that fell due while the holder
+  was stopped (checked at its start); `family-not-heard` is raised when a family stays silent past its bound, and the
+  builder's `publish-refused` and `publish-unanswered` findings name the name and the seat, each cleared when the
+  family or the answer returns.
 - **Live.** The status view shows each build module's new build waiting on its holder's build serving `publish`
   until that runs healthy (ADR 0612 *How it is checked*); no build module's provision key holds a write credential;
   `registry_old_name` names the nodes holding the old name open, an away node among them. After the delivery: