Correct A-300: the view's tools keep assigner_read_wants, since a first view does not read by key or history

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 20:00:56 +01:00
parent f522c2114d
commit 4fa5891697
1 changed files with 4 additions and 3 deletions
@@ -469,6 +469,7 @@ the principle that settles it, cited as "design 47 G A-n".
  form per kind of mesh-wants' `asks` forms with `.view` after it (`hold.<module>.<fingerprint>.view`,
  `restore.<node>.<module>.<fingerprint>.view`, and so for each), so its generated reader reads every real key; the
  kinds are the seven the asks package writes (hold, restore, backup, record, outside, revert, assignments), not eight.
- **A-300** (§717, A-131, A-210; principle 7) The status view's tools read the wants through the first-view tool
-  `wants` of the holder A-210 finds (the one they ask for differences), naming mesh-delivery-view among its callers;
-  the invoke `assigner_read_wants` goes with the other two, and no tools program keeps a module-named invoke of its own.
+- **A-300** (§717, A-131, A-210; principles 4 and 7) The status view's process follows the wants by its seat-form
+  first view; its tools program keeps the invoke `assigner_read_wants`, because the view's tools read a want by its
+  key and its history (`view_tiers`' since of a want, `assigner_want`), which a first-view tool (pages after a
+  position) does not answer; `assigner_read_asks` and `assigner_read_assignments` go as §717 says.