Investigate

Project Context

• CLAUDE.md: !find . -maxdepth 1 -name "CLAUDE.md" -type f
• project-discovery.md: !find . -maxdepth 3 -name "project-discovery.md" -type f
• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Investigation Approach

• Trace backward from symptoms — don't guess, follow the code.
• Launch parallel han-core:evidence-based-investigator agents for different angles simultaneously — one for the error path, one for the data flow, one for recent changes.
• Add one or more specialist analysts in parallel with the investigators when the bug type calls for it (concurrency, data flow across boundaries, database or query behavior). Specialist analysts find root causes generalists miss.
• The han-core:adversarial-validator agent handles all three validation strategies (challenge evidence, challenge fix, challenge assumptions) internally.
• Apply the evidence rule from ../../references/evidence-rule.md to every finding. Codebase findings (file path, line number, log line, test output) carry the trust-class label "codebase" and stand on their citation. Web-source context (RFCs, vendor docs, Stack Overflow, blog posts) carries the trust-class label "web" and is subject to the corroboration gate when it drives the proposed fix. When the investigation hits a point where no evidence at any tier resolves a question, label the no-evidence state rather than guessing.
• Lazy-create the output sections. Include a section in the plan file only when the investigation produced meaningful content for it; omit any section that would be empty, and keep the sections that remain in the template's order. Never emit a heading with placeholder or "N/A" content.
• Invoke han-communication:readability-guidance to source the shared readability standard into your context, then apply it as you write the findings, holding the named audience: the engineer who will implement the fix and may be paged on the bug. Scope that frame per section so the technical specifics the engineer needs (function names, exact failing conditions, file:line citations) are preserved, never simplified away.

Investigate

Step 1: Research and Investigation

Always dispatch