Skip to main content

Review Workbench: Evidence to Decision

This route makes the existing review and documentation work inspectable. It reuses the tenant lookup kit, the three supplied review samples, original design practice and the required HCI/accessibility lab. It is not another application project. Keep Module 5 at 90–130 hours: original concepts/workshops/documentation 30–44 can be planned as lessons 12–18, workshop practice 14–20 and documentation 4–6. The existing extension 20–28, HCI 30–44 and assessment 10–14 remain unchanged. Record actual effort and additional repairs separately.

P01–P05 — Establish a claim before a verdict​

  • P01: before reading candidate.py, write expected results for tenant A/id 7 and tenant B/id 7 using different names. Identify the authorized-caller assumption separately from tenant filtering.
  • P02: preserve candidate behavior for A→B and B→A lookup order. Compare the two failures; explain why merely putting tenant in a cache key does not fix a predicate that ignores tenant.
  • P03: mutate input after construction and a returned row after lookup. Demonstrate the two distinct ownership defects with separate minimal checks.
  • P04: inspect the checkout-total sample. Classify rounding, discount range and tax order as specified requirements or questions. Do not claim integer truncation from Python's / operator.
  • P05: inspect the layered UserFetcher sample. Compare a direct collaborator with the current indirection. Decide whether the simplification blocks a correctness repair or belongs in a separate cleanup; justify from actual coupling/change pressure.

P06–P10 — Tests that support the stated finding​

  • P06: write a failing regression before changing the lookup. Retain the assertion's expected/actual values, not only a red test count.
  • P07: restore one targeted defect after repair; show your regression fails for the intended reason, then restore the repair. An import or syntax failure does not validate the regression.
  • P08: compare cached and uncached implementations under the same contract and request sequence. Evaluate correctness before measuring lookup cost.
  • P09: for the promotion sample, write an explicit two-redemption schedule in which both read one remaining use. State which storage atomicity guarantee is missing from the snippet rather than pretending a local test proves database behavior.
  • P10: add a deterministic clock/ID boundary to a design sketch and define expiry equality. Explain why an injected clock alone does not repair concurrent redemption or uncertain external effects.

P11–P15 — Review and migration decisions​

  • P11: write one supported blocking finding with location, trigger, impact and a verifying check; write one unresolved question and one optional suggestion only where evidence warrants them.
  • P12: answer a fictional disagreement without inventing a real reviewer. State what new evidence would change your view. Label solo rehearsal.
  • P13: keep a local diff separating a tenant-scope repair from variable renames. Explain the review and rollback consequences; do not rewrite shared history.
  • P14: write a decision record comparing scan, tenant-keyed cache and a prebuilt index. Include scope, memory/update assumptions and a reconsideration trigger. Reuse the existing ADR assignment.
  • P15: draft a recovery plan that preserves isolation. Explain why reverting to a known-leaking version is not safe containment and cannot undo already disclosed data.

P16–P20 — Product evidence and transfer​

  • P16: turn a feature request into a falsifiable user/task assumption. Identify the actual observation needed; authored scenario text is not an interview.
  • P17: use the real HCI task protocol to distinguish independent completion, helped completion and critical error. Document participant availability honestly.
  • P18: pair an automated accessibility finding with a manual check and the applicable criterion. Preserve keyboard/focus/reflow observations; a scanner's green report does not establish the entire workflow.
  • P19: change one interaction based on evidence, then retest. Reuse the before/after record for the project; do not count the same session twice.
  • P20: after the required delay, review a changed identifier or ownership requirement unaided. Preserve the new contract and an independently chosen test. This must be actual learner work, not copying this page's example.

Three review experiments​

E1 — Order sensitivity: run all three-request sequences over a tiny set containing both tenants, a missing identifier and repeated lookups. Relate a counterexample to the candidate's predicate/key/ownership separately. Use existing public enumeration as a baseline, then add one changed case.

E2 — Review cost: compare bug-fix-only and fix-plus-cleanup diffs. Record changed public behaviors, tests needed and actual review effort if observed. If no reviewer is available, report only a self-review and predicted effort, not an independently measured improvement.

E3 — Evidence substitution: replace a real trace with a polished summary or generated assertion. Name exactly what the replacement no longer proves. Apply the same rule to source claims, accessibility scans and the public lab checker.

Submit one decision packet​

Link contract, original finding, before/after regression, repaired implementation, alternatives/ADR, recovery boundary, actual HCI records, help and changed-case evidence. Keep actual human review distinct from solo rehearsal. The AR1–AR6 gates and HCI requirements remain mandatory; this route does not create a second score or waive missing participants.

After attempting, use practice solutions and the existing AR calibration. Google's review standard informs the distinction between improving code health and demanding perfection; it is not an authority to accept demonstrated regressions.