Designs 25, 51: name the spent state; a shared-digest tag is recorded as kept

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

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

@@ -939,8 +939,8 @@ hears its own `decided` on a durable consumer of the process, whose filter the g
 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 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
+process claims the warrant's ask id by writing the key `acted.<ask id>` in the state `spent` of the process's own bus state, which the tools bundle is not given (a person's request and the
+record of what it spent are never in one bucket, and no tool can write the record), 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

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

@@ -469,7 +469,8 @@ test).
   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), 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
+  that reason, `removed` is not said, and the builder records the version as kept on the store under its shared digest,
+  which `builder_versions` names so (it is not recorded as 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