Test Doctor

Treat tests as product protection, not implementation proof. Ask of each test: "If this fails, which user-visible capability or documented contract is probably broken?" If there is no concrete answer, require evidence that the test deserves to remain.

Select the operating mode

• For audit, analysis, diagnosis, or planning requests, inspect and report without editing files.
• For explicit change requests, audit first, then make the smallest test changes that preserve or improve regression protection.
• Do not change production behavior merely to satisfy a test unless the user explicitly requests that fix.
• Read repository instructions and the relevant design or contract documents before evaluating intended behavior. Report a contract mismatch instead of guessing which side is correct.

Build an evidence base

1. Locate test files, fixtures, helpers, configuration, package scripts, and CI workflows.
2. Identify source-package boundaries and public entry points.
3. Read relevant feature, architecture, API, and bug-fix documentation.
4. Inspect focused git history when it explains why a suspicious test exists.
5. Record the available test commands and their scope. Run only commands needed to verify a finding or requested change.