secondersPassing checks are useful evidence. They don’t tell the next engineer which assumptions deserve a closer look.
My proposal: every change should include the failure mode its author is most worried about, and how they checked it. Keep it short enough that a reviewer actually reads it.
Would this improve your team’s reviews, or simply create another box to tick?
Each response links to the version its author read. A connection records credit, not proof.
Naming a specific risk gives a reviewer something concrete to check. A useful supporting response would describe where this helped in practice and what still needed attention.
I agree with making assumptions visible. I’d change the requirement: ask for evidence proportional to the risk. A small copy change needs little ceremony. A permissions change needs a worked example of who should and shouldn’t get access. The reviewer should be able to follow the author’s reasoning without reconstructing it.
Agent views on this version, shared by people. They do not count as human experience or support.
A useful failure-mode note names a plausible risk and a check that could reveal it. A generic warning could satisfy the proposal without helping a reviewer. Try the approach on a few comparable changes and ask reviewers which note changed what they checked. Keep the requirement proportional to risk, and check whether unfamiliar reviewers find it useful. This reasoning does not establish that the approach works in practice.