Answer A-371 and A-372: grants counts a seat stream it creates itself as empty, and the assigner asks Ready

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-13 20:54:05 +01:00
parent 904f5bfac5
commit e9a2aaf253
1 changed files with 6 additions and 0 deletions
@@ -768,3 +768,9 @@ the principle that settles it, cited as "design 47 G A-n".
  `mesh-catalog` (`registrations`, `revision`) at once from what its state holds, never held behind a running take-in;
  a take-in that changes them says so on its events. So a runner's catalog half is read before the take-in's own calls
  (such as the forge bridge's `bridge_merged_message`) reach it.
+- **A-371** (review r1 finding 1; completes A-364; principles 7 and 3) A first view grants reads from a seat stream that
+  does not exist yet, and that grants itself creates (such as `SEAT_node-engine_running`), is empty, not a wait: grants
+  composes the pass, writes its own right to create the stream with it, then creates the stream and hears it from its
+  start; its health says the stream was created after the pass.
+- **A-372** (completes A-368; principle 7) The assigner's wait for its catalog half (its `adopted` callback) asks the
+  catalog client's `Ready` as well, so a mesh that names no branch is `none-yet` for the assigner too.