| 1 | **ACCEPT for dormant merge, subject to the normal integrated-tip landing gate; REJECT for flag-on. Keep `CARLOS_SWAP` unset.** |
| 2 | |
| 3 | Reviewed only `4233395f..fcf2eab1`, with the round-2 findings, implementer report and ledger rulings as context. HEAD matches the brief. No files changed or tests run; reported test and simulation results were inspected, not independently reproduced. |
| 4 | |
| 5 | 1. **Finding 5 — ADDRESSED.** At `internal/rollout/queue.go:479`, retries add an entitlement to the host’s per-build map without replacing another build’s entitlement. Admission selects only the requested adoption’s build (`queue.go:356`); starting that adoption deletes only its entry (`queue.go:391`). The B-then-C retry sequence therefore preserves both allowances. |
| 6 | |
| 7 | Proven-unexecuted abandonment restores only the abandoned build’s entitlement (`queue.go:525`), through the existing `SwapAbandoned && !Executed` guard at `scheduler.go:339`. An attempt that ran or may have run does not regain its allowance. The cleanup pass only deletes entries; it cannot recreate a spent entitlement merely because the book still lists the host as retried. |
| 8 | |
| 9 | Cleanup checks the matching account, app, build and host (`failures.go:850`; `manager.go:1148`). A pointer-cleared or pruned record loses its entitlement on the next pass, alongside removal of its halt. A subsequent host failure removes its retried listing; before cleanup, the book blocks adoption even if an entry remains temporarily. I found no still-failing sequence in the changed paths that leaks admission authority, wrongly restores a spent entitlement, or drops an entitlement still needed through a standing halt. |
| 10 | |
| 11 | `finalreview2_test.go:61` covers the two-build sequence and independent spending. The test at line 104 covers pointer-clear and prune cleanup. |
| 12 | |
| 13 | 2. **Item 9 — ADDRESSED.** In `docs/superpowers/plans/2026-10-07-zero-downtime-deploys-6-roll-notes.md`: |
| 14 | |
| 15 | - Lines 63–70 explain the overwrite defect and cite its per-build fix. |
| 16 | - Lines 186–195 qualify the epoch advance as an unenforced bound and distinguish armed startup persistence from declined-box save attempts. |
| 17 | - Lines 74–79 explicitly describe failed declined reconciliation saves. |
| 18 | - Lines 267–274 and 288–295 retain the epoch decision and mixed-version retry sequencing as flag gates. |
| 19 | |
| 20 | The ledger accepts the bounded crash-epoch approach for this wave. That does not establish unconditional uniqueness or close the other flag-on gates. |
| 21 | |
| 22 | 3. **New Critical/Important breakage — none found in the fix diff.** The added cleanup follows scheduler→book lock ordering and introduces no disk write. |
| 23 | |
| 24 | **Dormant merge:** this scoped review has no remaining fix request. The reported focused checks and simulation sweep do not replace the repository’s full landing gate. |
| 25 | |
| 26 | **Flag-on:** remains blocked by the previously recorded code, contract, sequencing and real-box evidence requirements. This wave closes finding 5 and the requested documentation corrections only. |
amadan