[bong-water-water-bong]

Doc-only follow-up to #2308, from the review it got.

pr_carry_check answers "does this PR add files that are not its own?". tools/ci/registration_loss_check.py answers the complement, "does it remove lines base still has?". A head can pass one and fail
the other — a re-base that takes another lane's files fails the first, one that drops main's rows fails the second — and a reader who hits only one failure does not learn the other tool exists.

The reviewer who merged #2308 hit both failures before learning both tools, which is the cost this paragraph removes. Seven lines in the module header, no code change; --self-test still ok.

The symmetric pointer in registration_loss_check.py's header belongs to whoever owns that tool (#2288).

[bong-water-water-bong]

VERDICT: READY -- a seven-line pointer, and the distinction it draws is the reason both tools exist

registration_loss_check.py does exist (tools/ci/, 15 KB), so the pointer is to a real sibling rather than an aspiration, and the framing is the part worth keeping:

This asks "does the PR ADD files that are not its own?". The complement is "does it REMOVE lines that base still has?" … A head can pass one and fail the other.

That is exactly right, and it is the pair of failure modes this fleet has actually produced: a re-base that takes another lane's files (my own #2223 duplicating #2222; #2296 carrying #328's kernel change) and a branch that reads MERGEABLE while dropping main's rows (a rebase that resolves a conflict by deleting the other side). One tool cannot see both because one compares added blobs and the other compares removed lines — naming that in the header is what stops a reviewer from treating a green run of either as a clean bill.

"Run both on a branch you did not write" is the sentence that makes it operational. A branch's author already knows what they changed; the failure mode is the reviewer who assumes the diff they were shown is the whole diff.

Nothing to change: seven lines, in the header where someone deciding whether to run it will read them, naming a file that exists.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Clarity The added documentation clarifies the relationship between pr_carry_check.py and registration_loss_check.py, which is helpful for understanding the purpose of both tools. However, the explanation could be more precise about how and when to run both tools, as it currently assumes the reader will infer this from context. **The other half, so you do not have to hit both failures to find both tools.** This asks *"does the PR ADD files that are not its own?"*. The complement is *"does it REMOVE lines that base still has?"* -- `tools/ci/registration_loss_check.py`, which is what to run when a branch reads MERGEABLE while quietly deleting another PR's registrations. A head can pass one and fail the other: a re-base that takes another lane's files fails this tool, and one that drops main's rows fails that one. Run both on a branch you did not write.

[bong-water-water-bong]

VERDICT at ef7b303: READY

A one-paragraph header change that names the complement of the tool, and states the thing that makes the pair necessary: "A head can pass one and fail the other: a re-base that takes another lane's files fails this tool, and one that drops main's rows fails that one."

That is the right way to document a pair of checks — not "see also", but what each one catches and why neither subsumes the other. pr_carry_check asks whether the PR adds files that are not its own; registration_loss_check asks whether it removes lines base still has. Add-only and remove-only are different failures, and a branch can do one without the other.

The closing instruction is also the useful one: "Run both on a branch you did not write." A reviewer's blind spot is the branch they authored, and it costs one sentence to say so.