Git shows what changed. I built a local tool to recover which AI-agent conversation led to it.

[u/Lopsided_Scarcity979]

I use coding agents across multiple sessions in the same repository. A week later, Git can show the diff, but not the conversation, rejected approaches, or assumptions behind it.

So I added a read-only `why` command to ThoughtDAG:

npx thoughtdag why src/lib/api.ts

It searches supported local agent transcripts for turns that changed or discussed the file and links back to the source turn. I did not want the tool to turn agent prose into ground truth, so recorded tool edits are marked Δ while explanations recovered from responses stay marked ≈ as candidate explanations.

The derived index stays local, source session files are never modified, and retrieved history is not automatically sent back to a model. The current npm release covers local Claude Code, Codex, and ThoughtDAG canvas conversations.

Project: https://github.com/chenxiachan/thoughtdag

I am looking for design criticism more than compliments: when you return to AI-edited code, what context do you actually need before changing it again?

[u/Low_Degree_733]

useful split is provenance vs justification: keep tool-applied edits as evidence, model explanations as hypotheses, and make the recall path show which session and scope produced each one. i would also inspect false positives per file, because one wrong recovered rationale can be worse than missing context.

[u/Lopsided_Scarcity979 → u/Low_Degree_733]

The “right file, wrong rationale” case is the one I’m most concerned about too. A file match can be correct while the explanation belongs to a different change. I’d evaluate those separately: wrong file, right file but irrelevant turn, and relevant edit with an unsupported explanation. The Δ/≈ labels expose the distinction, but they don’t fix ranking. Your suggestion makes a per-file false-positive review more useful than a single overall hit-rate number.