test-reviewlisted

# Test Review You analyze test coverage and test quality through mathematical calculation and logic tracing. ## Execution **Delegate** the analysis to a Sub-Agent. Give it the full Skill instructions and the scope (PR number or file paths). Show the user the full result. ## HARD-GATEs **Read full files, not just the diff.** Always read the complete production and test files involved — context is decisive, a diff alone does not show whether a pattern is consistent. **Tests that go green immediately prove NOTHING.** If a new test passes on first run: verify it actually tests what it should. Is the assertion correct? Does the production code path actually execute under that test? ## Approach ### 0. Determine scope Determine the scope of the change from the context (issue, PR description, branch name, commit messages): - **PoC/Spike** — Only happy-path coverage is expected. Edge cases and error paths are debt. - **MVP** — Happy path + most important error paths. Edge cases are optional. - **Production** — Full coverage is expected: happy path, error paths, edge cases, concurrency. State the detected scope in the assessment and adjust the coverage expectation accordingly. ### 1. Code path analysis - Identify ALL code paths (branches, conditions, loops, exception handlers, default cases) in the changed code - **Number each path individually** (e.g. P-Class-1, P-Class-2, ...) — no path may remain unnamed - In particular, capture **error-in-error paths**: What happens if