Skip to content
OBSERVE. QUESTION. VERIFY.
03CASE FILE
Diff inspection

Every edit makes a claim.

A diff says that these edits produce a particular outcome. Test that claim against the task and the surrounding code. Start with behavior and dependencies, then examine implementation detail. A small patch can change a broad public contract.

Read around the changed lines

Inspect callers, tests, and nearby error paths. Look for changed defaults, reordered side effects, and branches that now return early. Check whether a new type assertion hides a mismatch rather than resolving it. Generated files and dependency changes deserve an explicit explanation of their role.

Ask what the evidence excludes

A passing happy-path test may say nothing about the reported edge case. Find the check that would fail without the correction. Review whether existing behavior is preserved for a valid neighboring input. If verification was unavailable, describe the gap instead of converting confidence into a success claim.

Is a clean build enough to accept a fix?

A build can establish that the project compiles under that configuration. It does not establish the behavioral claim unless compilation was the original failure.

A question for your assistant

Review this diff without editing. Identify the behavioral claim of each significant change. Check surrounding callers and relevant tests. Report concrete bugs with file references, and distinguish verified outcomes from assumptions or unavailable checks.
Shared reference: a conversation workspace with folder and model selectors. It is not evidence that a code change has been tested. Reference desktop preview; final product screens may differ.
CONTINUE THE INVESTIGATIONDependency clues