Design 52 says how the modules were built: the server's bucket carries each share's path, two root processes, settings default to none

02-DECISIONS/0263-a-share-is-a-provision-a-node-mounts-it-on-demand-and-only-nodes-that-ask-get-it.md

@@ -62,7 +62,8 @@ Rejected:
    so the backups are never exported.
 9. **A provider's paths written into its binding.** A binding carries what the provider's manifest
    `serves`, which is the same for every machine; a share's path is a setting of one assignment. The
-   consumer asks the server for it over the bus instead, so no controller change is needed for it.
+   consumer reads it from the server's bucket on the bus instead, so no controller change is needed for
+   it.
 
 ## Decision
 
@@ -107,10 +108,10 @@ Rejected:
    is absent raises nothing. The server's health is its service and its export table holding every
    declared export.
 9. **Over the bus.** The controller wires the two through the provision: the binding gives the consumer
-   the server's name. The consumer then asks the server's seat, `node-nfs-server.exports`, by request and
-   reply for each share's path and access, so a share's path is said once, on the server. `nfs-server`
-   keeps its exports, and `mounts` keeps each share's state, in their own key-value buckets (ADR 0201).
-   Neither reads the other's files (ADR 0260).
+   the server's name. `nfs-server` keeps its exports in its key-value bucket (ADR 0201), and `mounts`
+   reads it (`reads`) for each share's path and access, so a share's path is said once, on the server.
+   `mounts` keeps each share's state in its own bucket. The seat's `exports` verb answers the same by
+   request and reply. Neither reads the other's files (ADR 0260).
 10. **Taking over a hand-written line is an act.** The `mounts` module's `adopt` comments out one fstab
     line, keeping a copy, only after its own unit pair for that mount point is armed, and only on a
     person's word. The ZFS `sharenfs` property is cleared the same way, by `nfs-server`, once its own