176: Machine Coding - Review and Hardening
Assessment
Revisit the 130 or 131 implementation as a reviewer. Add tests for invalid, empty, concurrent, and failure cases; fix one deliberate defect; and write a short design note.
Hardening exercise
Seed one defect before reviewing: for example, evict the wrong LRU node, commit a stale autocomplete response, or leave focus on a removed option. Reproduce it with the smallest failing test, state the violated invariant, fix the smallest surface, and rerun the full suite. Then inspect input validation, error messages, cleanup, keyboard reachability, and unbounded memory/request growth.
Review rubric
Score 20 points: 4 for a precise contract and exclusions, 4 for invariant/state model, 4 for correctness and failure recovery, 4 for deterministic tests including the defect, and 4 for accessibility/performance explanation. Require evidence for every claimed optimization. A review passes at 16 with no open correctness or keyboard-blocking defect; cosmetic gaps belong in the follow-up list.
Required evidence
- requirements and exclusions;
- public interfaces and state model;
- tests and accessibility/performance notes;
- a retrospective naming what was cut and why.
Review questions
Which requirement is protected by a test? Which optimization has a measurement? What happens when the dependency is slow, returns malformed data, or fails after the user has changed the input? A strong review names the recovery behavior rather than only the happy path.