From f522c2114d1748a1937b7cdbebc03f9c055a270e Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 19:29:44 +0100 Subject: [PATCH] Answer A-300: the view's tools read the wants through the holder's first-view tool Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md b/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md index d8b35b66..91f034db 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md +++ b/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md @@ -469,3 +469,6 @@ 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...view`, `restore....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.