diff --git a/03-DESIGN/01-to-be/42-milestones/zfs-owns-zfs-lead-answers.md b/03-DESIGN/01-to-be/42-milestones/zfs-owns-zfs-lead-answers.md
index 31ba62e5..c9a14463 100644
--- a/03-DESIGN/01-to-be/42-milestones/zfs-owns-zfs-lead-answers.md
+++ b/03-DESIGN/01-to-be/42-milestones/zfs-owns-zfs-lead-answers.md
@@ -167,3 +167,12 @@ settles it (`00-META/principles.md`), cited as "design 42 zfs-owns-zfs A-n". The
   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.
+- **A-43** (corrects A-12 and A-42's wait, met in develop; principles 1 and 7: nothing polls) A hand act's tool does not
+  wait: once its act's key is written and the run's unit started, it answers "started" at once, naming the act and that
+  `zfs_module_events` reads its outcome, as §24 says ("the tool answers from the state and events afterwards"). The
+  bundle has no watch on its events stream, and a repeated read for 30 seconds is a poll.
+- **A-44** (A-42, met in develop; principle 3; the module graph orders the delivery) `mesh/stream.publish` is a family
+  of its own, the capability `stream-publish`, which the new tool runner states; the zfs module's `capabilities` ask
+  for it (and for `bus-state-calls` and `ledger-calls`, the calls it already makes), so the delivery plan places the
+  zfs module's new version only on a machine whose tool runner answers the call, and never one where its events would
+  fail.