Playbook 07: a change the new merge script must judge ships the script first (issue 895)

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

@@ -174,6 +174,11 @@ never into the running one, unless it blocks the running one.
    on 2026-10-17 it showed a store test's `FAIL` without its cause, and a fix was first guessed from the code.
    **A change to `merge-check.sh` is judged by main's version of it**, so a test the change adds must pass under
    either version: one that runs the new script's behaviour runs a file of its own, never `merge-check.sh` itself.
+   **So a change that needs the new script to judge it ships the script first, as a small fix of its own**, and the
+   rest waits for its delivery: on 2026-10-17 milestone 3 of design 47 moved its integration tests behind a build
+   tag in the same pull request as the script that runs that tag, and main's script would have skipped every
+   tagged test, its acceptance tests among them. The prepare step looks for this: a change to `merge-check.sh` or to
+   what it selects (build tags, the store-tests list) is cut ahead of the milestone.
 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