memtrace-incident-investigationlisted

## 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`: ```json { "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"`: ```json { "repo_id": "<affected-repo>", "from": "<same as step 2>", "to": "<same as step 2>", "mode": "compound" } ``` Review `top_changed_files` and `top_touched_sy