2026-11-13 08:54:30 +00:00
1 changed files with 20 additions and 0 deletions
@@ -659,3 +659,23 @@ the principle that settles it, cited as "design 47 G A-n".
 - **A-338** (A-335, ADR 0233; principle 7; the operator, 2026-11-13 about 03:50 CET: "it's a poc") The two trunk manifests
  the manifest validator refuses once they change, for a written directory with no data declared, declare it in G's
  change: f1-circuits' `cache` and Link2Pay's `logs`, both class `cache`.
+- **A-339** (G §383, §384, §387; design 42 zfs-owns-zfs A-32, A-37, A-39, A-41; principles 1, 7) The zfs module's
+  findings take G's form through the bus path it already has: its keeper's closed list gains exactly what G's generated
+  findings writer needs (the publish of `finding-written` on its stream `zfs-findings`, and a hear of
+  `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`.
+- **A-341** (A-339; design 42 §27; G's findings writer; principle 7) Under G's writer a zfs device's finding is scope
+  `module`, id `zfs.<pool>.<device>` (the pool's own state: `zfs.<pool>.pool`), kind `not-online`, its subject scope
+  `module`, id `zfs`, on the node; `<device>` is the device's own name, the last element of its path. §27's one finding
+  per device not online stands; only its key takes the writer's form.
+- **A-342** (A-339, A-341; principles 2, 7) A process learns its node the way the SDK already reads it: the node-engine
+  sets `MESH_NODE` to its own node's name in the environment of every process it runs, beside the resource's own `env`
+  (a resource's own `MESH_NODE` is refused by the manifest validator, so the mesh's value is the only one). The zfs
+  follower's writer and its `node-service-manager` calls then name the node; no new reference form and nothing special to
+  the keeper.