Contract-led review and blocking evidence
What this concept is
A review compares a proposed change with an explicit behavioral contract. Separate a verified defect, a question about missing requirements, and a preference. A blocking comment needs a credible consequence and a way to verify the repair; its severity follows impact rather than the reviewer's confidence or seniority.
Why it matters here
Pattern vocabulary cannot reveal whether a lookup returns the wrong person's record. Read the call site, data assumptions and observable result before discussing abstraction. Green tests are evidence about their cases, not evidence that every requirement was tested.
Concrete example
A directory contains (a, 7, Ada) and (b, 7, Bo). get("b", "7") must return Bo even if Ada appears first. Filtering only on id returns Ada. A useful comment is: “Blocking: filtering only on id returns tenant a's record for tenant b when ids overlap. Include tenant in lookup and demonstrate the duplicate-id regression failing before repair and passing afterward.” A missing requirement about case folding is a question, not automatically a defect: this lab specifies exact matching.
Common confusion / misconception
A large number of comments does not establish a thorough review. Conversely, a short diff can violate a critical boundary. A single implementation does not automatically make an interface unjustified; a stable boundary or an independently useful seam may justify it. Ask for the actual pressure and cost.
How to use it
- Restate the promised behavior, trusted inputs and external assumptions.
- Trace one normal and one adversarial case through caller, lookup and cache.
- Write a minimal counterexample for each alleged defect.
- Classify the finding: block, question, or optional improvement.
- Recheck the repaired code and update the verdict; do not keep obsolete objections open.
Check yourself
Which tenant does the failing trace request? What exactly is exposed? If identifiers were globally unique, what assumptions would still need checking? Why does a tenant parameter alone not establish that a caller is authorized to use it?
Mini drill or application
Review candidate.py in the lab. Predict the first lookup result before running it. Write one blocking finding and one requirement question. Do not invent a style defect to fill a quota.
Read this only if stuck
Use Google's review standard for blocking versus optional feedback and Good Code, Bad Code selectively for contracts. These support judgment; the lab's concrete contract determines its expected outputs.