/memtrace-incident-investigation

name: memtrace-incident-investigation
description: "Investigate source-code bugs, incidents, regressions, production issues, and failures to root cause with Memtrace symbol search, impact, call graph, and temporal history. Use when the user asks about root cause analysis, what broke, or what changed when debugging a failure. Do not start with Grep, Glob, rg, find, or manual file search for code causes. For plain what-changed questions without a failure, use memtrace-evolution."

Overview

Root cause investigation workflow for incidents, regressions, and production issues. Uses `get_evolution` to list changes near the incident time, then traces blast radius and execution flows to identify the likely cause.

Steps

1. Establish the timeline

Determine:

• **Incident time** — when did the problem start? (This becomes the `to` parameter)
• **Lookback window** — how far back to search? Start with 24 hours, expand if needed.
• **Repo(s)** — which services are affected? Call `list_indexed_repositories` to get repo_ids.

2. List changes near the incident

Call `get_evolution`:

{
  "repo_id": "<affected-repo>",
  "from": "<incident_time minus lookback, e.g. 24h before>",
  "to": "<incident_time ISO-8601>",
  "mode": "recent",
  "limit": 100
}

**Why `recent` mode?** Returns a chronological per-episode changelog. Focus on episodes whose `reference_time` is closest to the incident — especially those with high `nodes_added` + `nodes_removed` or that touch files in the failure area.

Paginate with `cursor` if `next_cursor` is present in the response.

**Success criteria:** A list of episodes in the window, with touched files and change counts for each.

3. Identify hotspot files and symbols

Call `get_evolution` again on the same window with `mode: "compound"`:

{
  "repo_id": "<affected-repo>",
  "from": "<same as step 2>",
  "to": "<same as step 2>",
  "mode": "compound"
}

Review `top_changed_files` and `top_touched_symbols`. Cross-reference with the failure area (endpoint, module, error stack).

**Decision:** Prioritize symbols/files that appear in both the recent episode list (step 2) and the compound hotspots (step 3).

4. Check for unexpected changes to stable code

For hotspot symbols from step 3, resolve each with `find_symbol`:

{ "repo_id": "<affected-repo>", "name": "<symbol>", "limit": 10 }

Then call `get_timeline` — stable code that suddenly changed is suspect:

{ "repo_id": "<affected-repo>", "scope_path": "<from find_symbol>", "file_path": "<from find_symbol>" }

5. Assess the blast radius

For the top 3–5 symbols, call `get_impact`:

{ "repo_id": "<affected-repo>", "target": "<symbol>", "direction": "upstream" }

• How many downstream consumers were affected?
• What execution flows pass through this symbol?

**Decision:** Prioritize symbols where the blast radius overlaps with the reported failure area.

6. Trace execution flows

Use `get_symbol_context` on the top suspects to see which processes (HTTP handlers, background jobs, etc.) they participate in.

**Decision:** If the incident is in a specific endpoint/flow, focus on suspects that are members of that process.

7. Build the full timeline for the suspect

Once you have a primary suspect, call `get_timeline` with `repo_id`, `scope_path`, and `file_path`:

• What changed in each episode?
• When was the last "stable" version?
• Was the change a modification, or was it newly added?

8. Correlate adds vs removes per episode

From the step 2 `recent` response, inspect each episode's `nodes_added` and `nodes_removed`:

• High `nodes_added` — new code introduced (potential new bugs)
• High `nodes_removed` — deleted code (potential missing functionality)
• Both moderate — changed behaviour (potential regressions)

9. Check historical coupling (cochange)

For the primary suspect, call `get_cochange_context`:

{ "repo_id": "<affected-repo>", "target": "<symbol>", "limit": 10 }

• Which symbols historically co-change with this one?
• If the blast radius from `get_impact` doesn't explain the failure area, check cochange partners — the coupling may be behavioral, not structural.

**Decision:** If a cochange partner is in the failure area but has no direct call relationship to the suspect, it's a hidden dependency — investigate both.

10. Replay the sub-commit implementation history (if needed)

If the suspect's episode isn't clear, call `get_episode_replay`:

{
  "repo_id": "<affected-repo>",
  "episode_index": 0,
  "symbol": "<suspect>",
  "mode": "graph_summary"
}

• Look for `attempted_and_reverted` hints — approaches tried and rolled back within the episode often explain why the committed state looks the way it does.

Report: Root Cause Analysis

1. **Incident Timeline** — when it started, what was observed 2. **Most Likely Cause** — episodes and symbols closest to the incident with blast radius confirmation 3. **Supporting Evidence** — timeline sparsity (stable code suddenly changed?), blast radius overlap, process membership overlap 4. **Change History** — full timeline of the suspect symbol 5. **Affected Scope** — all processes and downstream consumers impacted 6. **Remediation** — revert the change, fix forward, or mitigate

Tool selection guide for incidents

| Phase | Tool / mode | Why | |---|---|---| | Initial triage | `get_evolution` `recent` | Per-episode changelog near the incident | | Hotspot identification | `get_evolution` `compound` | Top changed files and symbols in the window | | Scope assessment | `get_impact` | Blast radius of suspect symbols | | Hidden coupling | `get_cochange_context` | Behavioral coupling not in the call graph | | Symbol history | `get_timeline` | Full version history of a suspect | | Sub-commit intent | `get_episode_replay` | What was tried before the committed state | | Quick window check | `get_evolution` `overview` | Totals only — use before narrowing the w