Playbook 07: read a verdict's trunk against main at once, because a lagging source revision makes the Approve merge nothing (issue 1726) #474

Merged
jschoubben merged 2 commits from pb/verdict-trunk into main 2026-10-24 19:47:56 +00:00
+6 -1
View File
@@ -222,7 +222,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
1. **The reviewed tree is the tree that was tried**: every feature branch was brought up to the current trunk
before its push and try (step 1). A try and a merge check each run on the merge with the trunk as it is then, so a
trunk that moves later is met by the forge's merge check, not by another merge here.
trunk that moves later is met by the forge's merge check, not by another merge here. Every verdict names the
trunk it merged onto ("pass <head> on <trunk>"), and the lead reads that trunk against the repository's main
at once: a trunk behind main means the source revision (source.main) lags, and every check and try in that
repository is judged on it until it moves, so the operator's Approve will merge nothing. Say it then, not at the
merge (issue 1726: on 2026-10-24 the gate dropped two merges it heard before it held its seat, and a
reviewed, approved pull request in each of the two repositories was refused at its Approve).
2. **One reviewer reads every repository's local commits** together, against the context files and the
decisions. **It is one agent, kept for the whole release** like the fixing agents: the lead continues it by
its id for every later round, for the extra cycle after a failed check (step 3) and for its review record, so it