[FEATURE] Record the reason for each edit, and use it for review and line-level "why"

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude makes a multi-file change, the reason behind each individual edit exists only for a moment inside the model's turn. Afterwards I review a flat list of hunks with no link back to why each one was made.

Weeks later it's worse: git blame points to a commit that Claude wrote, and there is no way to get back to the conversation that produced a given line.

Reviewing large AI-written changes is now the bottleneck in my workflow. The information that would make review fast is created at edit time, then thrown away.

Proposed Solution

1. Store a reason with every edit. Edit and Write tool calls carry a short, model-written reason (one line), stored in the transcript next to the edit.
2. Review grouped by reason. The diff review groups hunks by reason (for example "Add input validation" or "Rename fetchUser to loadUser"), with Accept / Revert / Explain on each group, not only on each hunk or file.
3. "Why is this line here?" In the IDE extensions, an action on any line Claude wrote that opens the session at the turn that produced it. The session id and turn could be kept in git notes or a local index, so it survives commits.

Alternative Solutions

• Asking Claude to summarize after the fact: the answer is reconstructed rather than recorded, and it loses the mapping from reason to hunk.
• Commit messages: too coarse, since one commit covers many reasons.
• Related: #34086 asked to show the rationale before approving an edit. This request extends it to review afterwards and to tracing a line back to its source.

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

1. Claude refactors 14 files for a feature, producing about 60 hunks.
2. Instead of 60 hunks I see 5 groups, each with a one-line reason.
3. I disagree with one group ("Inline helper into callers"), so I revert just that group. The other 4 stay untouched.
4. A month later a teammate asks why an odd null check exists. They run "Why is this line here?" and land on the turn where Claude explained it guards against an API returning null for deleted users.