Playbook 07 and design 47: say how the two new rules are checked; glossary words; name where the bus module has no want

Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL

00-META/process/07-feature-branches.md

@@ -396,8 +396,10 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    **Before the push, every member's suites run as the running checker runs them**: each sibling repository placed
    beside it by main's beside rules, the node-engine at the commit the machines run, and the running indexer's judge
    over every manifest the change touches. On 2026-11-02 release sdk1 failed four checks one fault at a time (test
-   globals left set, a sibling placed otherwise, the checker's manifest archive, a composer the old checker could not
-   build), each of which a run as the checker places things would have shown before the first push.
+   globals left set, a sibling placed otherwise, the checker's manifest archive, a composition step the old checker could not
+   build), each of which a run as the checker places things would have shown before the first push. How it is
+   checked: the pull request's description names the placement, the node-engine commit and the judge run used
+   locally; a check that fails on a placement the local run did not use is named by the lead at the next report.
 2. **The checker's merge check runs the integration tests once, as the gate** (its one status, `mesh/check`). No
    second review: step 2 reviewed this tree.
 3. **A check that fails** goes back to the same reviewer, continued by its id, with the failure, for **one more cycle** of step 2 with
@@ -420,7 +422,9 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    the build modules. A release that changes one of them is judged by the version that runs, so whatever the running
    version cannot judge is delivered first as a change of its own, or left out and added back once the new part runs.
    On 2026-11-02 release sdk1 delivered the build module's relative replaces first, and took the checker's new
-   composition call out of the release, adding it back in the next pull request once the new node-engines answered it.
+   composition call out of the release, adding it back in the next pull request once the new node-engines answered it. How it is checked: the prepare step's
+   milestone file lists every judging part the release changes and how each is delivered first or left out; the review
+   refuses a group that holds one without that line.
 4. **The milestone's acceptance is proven by its check.** A milestone that adds or changes a module
    carries an integration test that starts the module whole, its process against the real bus and store, and
    shows the milestone's acceptance sentence; the forge's checks run it (ADR 0391 §1, §6). Unit tests alone are not