Investigation should end in constraints
A useful investigation maps the systems a change can touch, identifies protected behaviour and names the evidence that would prove success. It does not begin by editing the first file returned by search. The output is a bounded problem another agent can implement without rediscovering the whole repository.
For a Caveman Taxi input change, those constraints include keyboard parity, pointer cancellation, orientation, pause state and every release target. For a Super Air Hockey collision change, they include the fixed step, moving mallets, posts, rails and repeatability. That map is already a form of quality control.
Implementation gets a narrow licence
The coding task should say what may change, what must remain stable and what evidence is required. This reduces the agent's incentive to tidy unrelated code or redesign a system while solving a local bug. Fast implementation is useful only when the blast radius stays legible.
SaratogaKit carries the original intent into that task. The agent can still propose a better boundary when the code reveals one, but the proposal is visible. Architectural changes do not arrive disguised as incidental refactoring.
Review the claim, then review the screen
A code review asks whether the implementation matches the stated constraint. A visual review asks whether the player can understand and use the result. Those are different examinations. A perfect state transition can still hide its button under a thumb or crop the message explaining what happened.
I capture the relevant screens at real desktop and mobile sizes, inspect them, then play the interaction. Screenshots expose hierarchy and cropping. Play exposes timing, feel and interruption. Neither form of evidence replaces the other.
Ask the reviewer to disprove success
A review prompt that asks whether the work looks good invites agreement. A stronger review asks for the smallest counterexample: the old save that fails, the second pointer that stays held, the frame rate that changes the result, or the target build carrying a forbidden service.
The reviewer should know the acceptance criteria and remain free to challenge them. Sometimes the code satisfies a weak specification. Finding that gap before deployment is more valuable than celebrating a clean test run.
The final reviewer is the compiled product
Source tests can pass while a static asset is missing from the build or the wrong output folder is deployed. The compiled artifact needs its own smoke test, manifest check and visual pass. That is the product the browser will execute.
SaratogaKit keeps investigation, implementation, review and release evidence connected without pretending they are the same job. The system is designed to create disagreement early, while changing direction is still cheap.
A fresh reviewer should be able to challenge the claim, reproduce the evidence and inspect the compiled game. The implementing agent's confidence is never the acceptance test.