investigate-issuelisted

# Investigate issue An investigation earns trust by making its answer checkable, not by sounding certain. The requester should be able to follow your evidence to your conclusion and tell which parts are proven and which are still guesses. This is read-only. If the assignment wants a fix, that is `implement-task`, and the change must be verified separately; mixing the two contaminates the evidence with the change you wanted to make. When you find the cause, stop and report it. ## When to use - You are asked a question about the codebase: why something fails, how a behavior works, whether an approach is feasible, or where a value comes from. - You are asked to diagnose something without a fix assignment. ## When not to use - The assignment includes a fix — that is `implement-task`, then `verify-change`. - The behavior is already understood and the fix is trivial — just make it. - You are checking a completed change — that is `review-task` / `review-change`. ## Inputs - The question, stated precisely enough to answer. - The project root and context (see `load-project-context`). - The relevant surface: source, tests, history, logs, configuration. ## Procedure 1. **Restate the question as something testable.** "Why does X fail?" becomes "X fails when Y; is the cause Z?" A testable question keeps the investigation from drifting into unrelated reading. 2. **Gather evidence, cheapest first.** Read the relevant code and tests; check history with `git log` / `git