A review receipt survives a redesign the reviewer never saw

[topij]

The gap

--record-review binds a receipt to the current headRefOid, and any push invalidates it. That is the right invariant for "was this exact code reviewed", but it says nothing about which reviewer saw what, so a receipt can be re-recorded at a new head after a material redesign that the primary reviewer never reviewed.

Observed twice

• Split the watch-loop predicate from the merge gate (additively) #22. CodeRabbit's only completed review was bound to the first commit; the design then changed materially (a fail-open rework) and the rate limit never lifted. The PR merged with a fallback receipt.
• Resolve the queued-vs-unavailable ambiguity on both surfaces (#19 + #23) #25. Same shape, smaller: CodeRabbit fully reviewed 954b93f, then was rate-limited across four re-requests while three further commits landed. Those commits were each verified by an independent panel, so the gap was covered — but nothing in the receipt records that the primary bot's last-reviewed SHA was three commits behind.

Distinct from #23 (detecting the outage) and #19 (a queued bot). Both of those are now fixed — this is about what a receipt should mean once an outage outlasts a redesign.

Sketch

Cheap interim, and probably enough: have pr_watch surface each configured bot's last-reviewed SHA next to the current head, so the gap is visible at merge time rather than reconstructible from the PR thread. gh pr view --json reviews carries commit.oid per review submission.

review coverage:
  coderabbit  last reviewed 954b93f  (head is 321907e, 3 commits behind)

Fuller version: invalidate a receipt when the diff changes shape rather than only when the head moves — e.g. require a fresh receipt when a later push touches a file the recorded review never saw. More faithful, but needs care not to become a wedge on a repo whose bot is permanently unavailable.

Note on scope

The mechanism now added in #25 (review_bots.signal, bot_signal on the receipt, the override key) records why a guard did not run. This issue is the neighbouring question: recording how far behind the reviewer that did run actually is.

Graduated from docs/kit-friction-log.md (2026-07-25 inbox).