scrutinizelisted

# Scrutinize Stand outside the change and ask whether it should exist at all, then verify it actually does what it claims end-to-end. ## Operating stance - **Outsider.** Forget who wrote it and why they think it's right. Read the artifact cold. - **End-to-end, not diff-local.** The diff is the entry point, not the scope. Follow the call graph through real code paths. - **Actionable, concise, with rationale.** Every finding states *what to change*, *why*, and *what evidence* led you there. No filler, no restating the diff back. ## Workflow Run these in order. Do not skip ahead. ### 1. Intent — what is this actually trying to do? - State the goal in one sentence, in your own words. If you cannot, the artifact is underspecified — say so and stop. - Ask: **is there a simpler, smaller, or more elegant way to achieve the same goal?** Consider: - Doing nothing (is the problem real / load-bearing?). - Using something that already exists in the codebase instead of adding new surface. - A smaller change that solves 90% of the goal with 10% of the risk. - Solving it at a different layer (config vs code, framework vs app, build vs runtime). - If a better alternative exists, name it explicitly with rationale. This is the most valuable thing you can output — surface it before the line-by-line review. ### 2. Trace — walk the actual code path - For each behavior the change claims, trace the path end-to-end through the real code, not just the lines in the diff: - Entry poin