P159 · Evaluation & feedback

Diff-Scoped Review with Named-Risk Escape Hatch

Start review from the diff and expand only for a named cross-cutting risk.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A patch changes F to acquire A then B. An existing caller may hold B before calling F, so the diff alone is insufficient, but an unbounded repository crawl is unnecessary.

Mechanism

Fix baseline and target tree, then read the diff and direct context. Name the risk: a B-holding caller entering F for A may form a cycle with an A→B path. Inspect relevant callers and release/wait conditions, recording expanded files and results. Expand again only for concrete new risks. Disclose unchecked dynamic calls rather than deriving global safety from small scope.

Bad example

Either scan all code for any issue or forbid outside-diff reads and ignore callers’ lock state.

Good example

Start at F’s diff and inspect B-holding callers and A→B paths for the named lock-cycle risk. List checked files, held-lock conditions and consequences, exclude non-overlapping paths and disclose unchecked dynamic calls. Tie every expansion to a risk.

Why the change matters

The diff focuses review while named exceptions permit necessary context. This avoids both missing caller constraints and burying the change in unrelated historical issues.

Observable expectation

Teaching G holds B and calls F while concurrent H holds A waiting for B, creating a candidate cycle. Confirm concurrent reachability and release conditions. If G releases B before F, that risk is excluded. Expansion records should track this criterion.

Limits

Cross-cutting APIs, shared state and generated code may need broader checks. Static paths do not establish observed concurrency; distinguish inference from reproduction. Follow applicable review-scope constraints.

Sources and evidence

Read the editorial criteria

Related methods