Answer A-340: a process's bus may name what its module consumes; the writer's three events

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-13 09:10:36 +01:00
parent 325bf80f19
commit 20a04f0226
1 changed files with 5 additions and 0 deletions
@@ -665,3 +665,8 @@ the principle that settles it, cited as "design 47 G A-n".
  `mesh-conditions.findings-asked`), and the root follower runs G's writer over the keeper; its manifest gains the
  `finding-events` stream and that `consumes`. The follower keeps writing its findings, since it is the part that sees
  them; nothing else of the keeper's list widens.
+- **A-340** (sharpens A-339; design 42's V5 and G1; principle 7) A process's `bus` may name, under `consumes`, an event its
+  module's `consumes` names, as V5 lets it name what its module's `requires` asks; the manifest validator judges it as V5
+  does, and the grants part gives that process's account the hear and the consumer of exactly those events, as G1 gives
+  the publish. The zfs keeper names `mesh-conditions.findings-asked` there. "Exactly what G's writer needs" is its three
+  events on the module's `finding-events` stream: `finding-written`, `finding-cleared`, `findings-stated`.