Playbook 07: run every suite as the running checker places it, and let the running parts judge a release that changes them (issue 1126, release sdk1)

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

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

@@ -393,13 +393,18 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    (also in a delivery group that holds the catalog's pull request); the lead runs mesh-controller's unit
    suite with `MESH_CHECK_BESIDE` naming a directory that holds the catalog's branch, as mesh-controller's
    `internal/beside` says.
+   **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.
 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
    the same fixing agents; then push **once** again (the one more push of ADR 0548). The check is **read, never re-asked to see if it passes**: a
    check asked again without a new, reviewed head spends the build capacity for nothing. **The failure is read from the check's whole log**, never
-   reasoned from its summary: `mesh-delivery.show` names the check's build id, and `mesh-controller.builds` with
-   `log` set to that id prints everything the builder said. A check's summary picks only some failing lines;
+   reasoned from its summary: `mesh-delivery-checker.checker_pull` names every failure the verdict holds, one line each, and the full report
+   of the check. A check's summary picks only some failing lines;
    on 2026-10-17 it showed a store test's `FAIL` without its cause, and a fix was first guessed from the code.
    **A failure the check hides or loses** (a verdict naming only the first failed test, a log not kept) is a fault of the
    checking tool: it is fixed there, the same turn (instruction fix-a-bug-met-twice), not asked around.
@@ -411,6 +416,11 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    which tests run at which level is the build tag's (ADR 0445 §2), and hq's checks are Go tests like any repository's
    (ADR 0527). The prepare step looks for this: a change to what the checker's build module selects (its recipe, a build
    tag convention) is cut ahead of the milestone.
+   **The same holds for every part that judges a change**: the checker, the indexer and its judge, the grants part and
+   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.
 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