Make identity the one check of the recovery module's callers, and give a bundle's finding writer its two runtime calls

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

03-DESIGN/01-to-be/47-milestones/G-14-recovery-module-and-review.md

@@ -70,16 +70,15 @@ are written into the lines of G-12 they name.*
     `size`; and `point-removed.<module>.<kept>` (§551). The node agent wakes only on the event whose `form` and
     `fingerprint` are its ask's. Its wait for `ended` or `restored` is bounded at 90 minutes (§405), 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 the node-engine holder of the node that holds
-    the want moving that module (`seat:node-engine`, proved by the bus as that node's account): the recovery module,
-    which hears `mesh-wants`' `wanted` as §556 reads a stream, answers `error` naming the node unless that node's want
-    names the module at `fingerprint` (for `snapshot-kept`) or moves it back from `fingerprint` (for `restore-kept`).
+  - **Who calls it.** `snapshot-kept` and `restore-kept` are called by a node-engine holder (`seat:node-engine`): the
+    recovery module takes a call only from an account the bus proves to be a node-engine's, and the identity of who
+    asked is the check (the operator, 13:06 CET); no want is read for it.
     `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 `discard-aside`; `aside-only` is the operator's hand tool
-    alone, `recovery_aside` (class `act`, callers `operator`); and `discard-aside` is checked by the identity of who
-    asked it: its caller is `operator`, as the bus proves the calling account, with no warrant asked per discard. The
-    want check above stays for the node-engine, which this line, not the identity, needs. Each act is written in the hand-act log of the seat `mesh-hand-acts` first, with the caller the
+    alone, `recovery_aside` (class `act`, callers `operator`); and `discard-aside` and 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
@@ -88,7 +87,7 @@ are written into the lines of G-12 they name.*
   - **Its account.** Composed by the grants part from the seat's definition and the manifest: the bus's stream
     snapshot and restore subjects with their chunk subjects, a stream's deletion and a durable consumer's creation,
     only for the bus names of a module's kept data; the subjects its seat says and its hand-act log write; its
-    consumers of `node-backup`'s `item-started` and `item-ended` and of `mesh-wants`' `wanted`, each with the ordered
+    consumers of `node-backup`'s `item-started` and `item-ended`, each with the ordered
     consumer §556 needs; its calls of `node-backup`'s `restore` as the caller `holder:mesh-recovery@same-node`, which
     `node-backup`'s definition names for `restore` and which the backup holder takes only for the recovery module's
     own item `points` (the operator, 13:02 CET); and nothing else. The bus names granted are those of every kept data
@@ -126,7 +125,7 @@ are written into the lines of G-12 they name.*
   design's (review rounds 1 and 2; ADR 0672). How it is checked: test 36 with the real backup holder and the recovery
   module; unit (grants part), the recovery module's account holds exactly the grants above, a call outside its names
   refused, both a point's old-section names and a template's binding granted, and the bus module's and the snapshot
-  account's hold no restore; whole (recovery module), a call from a node holding no such want answered `error`, a
+  account's hold no restore; whole (recovery module), a call from an account that is no node-engine's refused, a
   `busy` answer then the act on the other's `ended`, a second form change not woken by the first's `ended`, a dump
   asked during a restore starting after `restored`, a restart during the dump starting no restore, an act whose
   hand-act log write fails doing nothing, and an unrestored aside failing the health check.
@@ -154,8 +153,7 @@ are written into the lines of G-12 they name.*
   `wait-held` and `wait-ended` (the last two kept on the stream `running` is kept on, last per subject, a node's
   module's newer one by `at` standing), by the assigner (§520), the condition keeper (§541), the builder (§546), the
   node-engine and the grants part (§199), and the watchman for `delivery-waits` (§541); `mesh-healers'`
-  `attempt-changed` by the keeper (§541); `node-backup`'s `item-started` and `item-ended` and `mesh-wants`' `wanted`
-  by the recovery module, and the recovery module's `restore-started` and `restored` by the backup holder (§554). The
+  `attempt-changed` by the keeper (§541); `node-backup`'s `item-started` and `item-ended` by the recovery module, and the recovery module's `restore-started` and `restored` by the backup holder (§554). The
   grants part grants each such reader, beside its durable consumer, the creation of an ordered consumer on that
   stream with no durable name (the bus's consumer-create subject for that stream), from the reader's `consumes`. This amends
   §199's "each part's durable consumer starts from the last message per subject". Why: what a part heard must not
@@ -192,3 +190,18 @@ are written into the lines of G-12 they name.*
   (lead-47's question from the operator's "the module graph is for this", 2026-11-11). How it is checked: unit
   (manifest validator), a field the definition lacks refused; unit (delivery plan), the grants part ordered after
   a bus module whose definition gives `binding`, and not before; unit (the release's reader), both forms read.
+- §559 **A bundle's finding writer publishes and hears through two runtime calls.** A bundle, in Go or TypeScript,
+  holds no bus connection, so mesh-sdk's finding writer (§461, §503) in a bundle uses the runtime channel's existing
+  calls, each gaining one argument: `mesh/publish` takes `ack: true`, and the tool runner then publishes the event on
+  the subject the module's membership names for it (its old stream's `mesh.stream.<module>.event.<event>.<node>` or
+  its template binding's, §529; ADR 0363 §8) and answers only once the bus acknowledged it, with its sequence, or
+  `{error}`; `mesh/subscribe` takes `deliver: new`, and the tool runner makes an ordered consumer on the stream that
+  carries the pattern, starting at the next message, and delivers each message to the bundle as a subscription
+  delivers today. The writer says each finding event with `ack: true` (§383's one minute of resending counting from
+  an unanswered or `{error}` publish) and makes its consumer of `findings-asked` with `deliver: new` before its start
+  statement (§485). The tool runner states the capability word `finding-calls` (§488, §545) once it answers both,
+  and the bundle's writer fails at once, naming the word and the node, where it is not stated. Why: one writer in both
+  languages over the one channel a bundle has, as §518 (develop question of 13:08 CET on §461). How it is checked:
+  unit (tool runner), a publish with `ack` answered with its sequence and a refused one with `{error}`, a `deliver:
+  new` subscription given no message older than it; whole (mesh-sdk, TypeScript and Go bundles), a finding written
+  and an ask answered through a tool runner of G.

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

@@ -94,4 +94,4 @@ The part is fourteen files, each read whole, its design lines numbered across th
 - [G-11-develop-answers-review](G-11-develop-answers-review.md): the operator's answers of 2026-11-11 noon, the review of §456 to §479, and develop's next questions (§480 to §515).
 - [G-12-develop-answers-fourth](G-12-develop-answers-fourth.md): the operator's answers of 2026-11-11 noon, round 3's leftovers and develop's fourth batch of questions (§516 to §553).
 - [G-13-review-round-3](G-13-review-round-3.md): the review of §480 to §515, rounds 2 and 3 (§600 on).
-- [G-14-recovery-module-and-review](G-14-recovery-module-and-review.md): the recovery module, the operator's answer of 2026-11-11 12:55 CET, and the review of §516 to §553 (§554 to §558).
+- [G-14-recovery-module-and-review](G-14-recovery-module-and-review.md): the recovery module, the operator's answer of 2026-11-11 12:55 CET, and the review of §516 to §553 (§554 to §559).