Playbook 07: read a failed check's whole log; a change to merge-check.sh is judged by main's version

2026-10-17 17:29:43 +02:00
parent cf73f96797
commit 0e7eb9c2da
1 changed files with 6 additions and 1 deletions
@@ -143,7 +143,12 @@ never into the running one, unless it blocks the running one.
 2. **The forge's merge checks run the integration tests once** (`mesh/merge-gate`, `mesh/repo-check`). No
   second review: phase 2 reviewed this tree.
 3. **A check that fails** goes back to the reviewer with the failure, for **one more cycle** of phase 2 with
-   the same fixing agents; then push once again.
+   the same fixing agents; then push once again. **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 build machine said. 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 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.
 4. **The milestone's acceptance is proven before it is marked ready.** 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