investigation-case

Investigation Case -- Deep Forensic Investigation

Phase 0: Vault RAG (MANDATORY, BEFORE ANYTHING ELSE)

Before ANY file reads, grep, or codebase exploration, call query_vault with relevant keywords and service_filter. This is non-negotiable and must be the FIRST action after reading the task. The vault contains pitfalls, business rules, review learnings, and patterns that prevent rework. Skip = rework.

Purpose

Comprehensive investigation of bugs, incidents, or reported problems. Goes beyond triage (is it ours?) into deep forensic analysis: WHY it was built this way, WHAT business rules are involved, WHEN it broke, WHO touched it, and HOW to fix it using established company patterns.

Language

The Investigation-Case.md document MUST be written in English. All narrative text, section titles, analysis, and explanations must be in English. Technical terms (code snippets, file paths, PR titles, error messages, variable names) remain as-is. Tables use English headers.

Working Directories

1. Obsidian workspace: __VAULT_ROOT__
2. Codebase: __CODEBASE_ROOT__
3. Investigation output: Development/BUG/{TICKET-ID}/ in the Obsidian workspace

References

File	Content
references/channel-map.md	Full Slack channel (4 tiers) and Confluence space (3 tiers) maps with IDs
references/evidence-agents.md	Detailed prompts for the 7 parallel evidence collection agents
references/report-template.md	Investigation Case document template
references/learnings.md	Lessons from past investigations (review before starting)

Common Agent Mistakes

These mistakes have been observed across investigations and led to shallow reports, incorrect root causes, or wasted routing.

1. Stopping too early: Concluding investigation with fewer than 10 evidence items. Why: shallow investigations miss the root cause and produce fix plans that address symptoms. The 10-item minimum forces breadth before depth.
2. Ignoring service chain: Investigating only the reported service without resolving the full chain. Why: bugs in LE often span 3-5 services (e.g., www-le-customer -> svc-order -> svc-experiences -> svc-ee-offer). Investigating only one misses the actual failure point.
3. Timestamp blindness: Collecting evidence without cross-referencing timestamps. Why: the timeline is the primary tool for identifying "what changed when it broke." Without timestamps, correlation is impossible.
4. Single-source bias: Finding one strong lead in Slack and stopping the sweep. Why: Slack conversations often contain incomplete or incorrect assumptions. Cross-referencing with code, Datadog, and Confluence validates or invalidates the lead.
5. Fixing instead of investigating: Starting to write fix code during investigation. Why: investigation produces a report and fix plan, not code. Premature fixing without full context often introduces new bugs. Use /debug-mode for implementation.
6. Missing the human context: Not checking who was working on related code/tickets recently. Why: git blame, PR authors, and Slack thread participants often reveal critical context (e.g., "I changed this because of X constraint" in a PR body).