diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md
index 7aa7f7ef..ea6c0e52 100644
--- a/00-META/process/07-feature-branches.md
+++ b/00-META/process/07-feature-branches.md
@@ -318,7 +318,10 @@ answer is written down before the code; 2026-11-11: the lead answers it against
 
 1. **The lead answers each question against the principles**, in one line in the milestone's lead-answers file
    (beside the milestone part, cited as "design NN M A-n"), naming the principle that settles it (step 0, *Who answers
-   a design question*). One no principle settles the lead sends on: to the operator, one per ask, as playbook
+   a design question*). **Before an answer names a field, a key, a bucket, a subject or a function, the lead reads it
+   where it lives** (the code at the join head, or the seat definition) and checks the answer against what is there,
+   not against the question's words (2026-11-12: three answers that day named a structure from memory and needed a
+   correction once a developer read the code). One no principle settles the lead sends on: to the operator, one per ask, as playbook
    [02](02-graduation.md), *Answering a design question*, says, each ask added to its wait list, when its answer
    changes what the operator sees or how they work, removes data or needs the operator's terminal; every other one to
    `hq-design-writer` in its handover. A question the writer finds is the operator's it hands back.
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 8d235e9f..8608d572 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
@@ -480,7 +480,8 @@ the principle that settles it, cited as "design 47 G A-n".
   claimant of mesh-module-assigner read from its own catalog (it holds the catalog seat), so buildrun's 5-second
   holder loop goes for every part.
 - **A-303** (§717, A-302; principles 2 and 7) The status view names its followed pictures in the seat form
-  (`<seat>_<state>`); where a name must be the holder's real bucket (the watchdogs' stuck key, which matches what the
-  watchman writes, and the reach history's bucket names, whose kept entries stay readable), the view takes it at run
-  time from the holder FollowSeat follows, through one accessor of the SDK's process reader; no code names the
-  assigner's module.
+  (`<seat>_<state>`), the reach's watches (`reachBuckets`, its history watch included) too, since they match the names
+  the followed pictures are told; where a name must be the holder's real bucket (only the watchdogs' stuck key, which
+  matches what the watchman writes), the view takes it at run time from the holder FollowSeat follows, through one
+  accessor of the SDK's process reader; no code names the assigner's module. *Corrected 2026-11-12: it first named the
+  reach history's bucket names as real buckets too, for kept entries' sake; the view's kept reach holds no bucket name.*