Design 42 zfs-owns-zfs: A-42, a tools bundle publishes onto its own events stream by name

2026-11-13 01:46:09 +01:00
parent 230dc73bc1
commit ca142d4b98
1 changed files with 12 additions and 0 deletions
@@ -155,3 +155,15 @@ settles it (`00-META/principles.md`), cited as "design 42 zfs-owns-zfs A-n". The
  acknowledges, on `mesh.bus.<module>.<local>.<event>`, the subject named by a new mesh-sdk helper
  `process.Account.BusSubject(local, event)` beside `EventSubject` and `StreamSubject`; never `process.Conn.Emit`,
  which publishes on the module's old event subjects.
+- **A-42** (§25, A-12, A-41, review round 2; principles 1, 3 and 7; the operator's "a case the delivery cannot handle
+  is a gap in the build and delivery system") A tools bundle has no way onto the events stream its module asks for by
+  template: the tool runner's `mesh/publish` publishes on the module's old event subjects and reads no binding (the
+  tool runner's `PublishAs`, `eventSubject`), and its `mesh/subscribe` hears only the old streams. This milestone
+  builds the one path it lacks, by name, beside the bus-state calls a bundle already makes: a call
+  `mesh/stream.publish` {stream (the local name), event, body, id} in mesh-sdk's `buscalls`, which the tool runner
+  answers for the bundle's own bound stream alone by an acknowledged JetStream publish on the binding's subject plus
+  `.<event>`, the id as the message id, under the grant the tool runner's account already holds (`boundOf`). The zfs
+  tools say every event of §25 with it, never `stdio.Emit`. A hand act's tool hears its act's event by reading its own
+  events stream with the calls it has (`mesh/stream.fill` for the last sequence before it starts the act, then
+  `mesh/stream.read` from the next one with the act's subject), for at most the 30 seconds of A-12. The other modules
+  whose bundles emit onto a template events stream (messenger) move to the call in a change of their own.