Playbook 07: a new integration test enters through the path the live trigger takes (issue 1086)
mesh/merge-gate head 17c27ddf834f merged into trunk 5c6b645c6ba9 — pass: the change touches no module of the mesh's graph
mesh/repo-check head 17c27ddf834f merged into trunk 5c6b645c6ba9 — pass: its merge-check.sh passed
mesh/delivery delivered

Milestone 4's test saved its plan by hand, skipped the cut from a batch, and passed while the backup step never ran.
This commit is contained in:
2026-10-18 02:19:20 +02:00
parent 5c6b645c6b
commit 17c27ddf83
+1 -1
View File
@@ -146,7 +146,7 @@ never into the running one, unless it blocks the running one.
It says which round it is in ("round 1 of at most 3").
3. **The report goes to the same fixing agents** that wrote the code, continued by their ids, so they fix
with the context they already hold. Each answers the reviewer: what it changed, per finding, or why not.
4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too.
4. **Every new integration test is read against the code it drives before the first push.** It has never run: fixing agents only compile it, and its first run is the merge check, so each fault it hides costs a whole check. The reviewer traces each step of each new integration test through the code (fixtures against the manifest rules, what the store keeps and reads back, who holds a seat), and says which steps it could not trace. On 2026-10-17 a new test failed on its first two runs, on a fixture and then on a fault of the change; reading it against the code after the first failure found another fault, which would have failed a run too. The reviewer also checks that each new integration test enters through the same path the live trigger takes, not through a state it writes by hand: on 2026-10-17 milestone 4's test saved its delivery plan directly, so it skipped the cut from a batch that every live plan takes, and it passed while the backup step never ran (issue 1086).
5. **The reviewer reads the answers and the new commits**, and approves or reports again (step 6 says what a round
may ask). After round 3 the lead stops and brings the operator what is left, with a recommendation.
6. **A finding outside the issues' done-when is never a change asked, in any round.** More hardening, a