diff parser broke on renamed-file hunks: agent misattributed line comments

TL;DR: Renamed files carry rename-from and rename-to headers plus a similarity index, and a parser that ignores them treats the rename as a delete plus an add - so comments get the wrong path and wrong lines. Teach the parser to record renames as path mappings, keep following the content through the rename, and always post comments against the new path at the new head SHA.

diff parser broke on renamed-file hunks: agent misattributed line comments

1. Confirm the misattribution. Find a comment the agent posted on a renamed file and check which path and line it used versus where the code actually lives now.

Expected: the comment references the old path or a line number from the pre-rename file.

1. Inspect the raw diff headers for that file. Look for the rename-from / rename-to header pair and the similarity index line.

Expected: you see the rename the parser skipped.

1. Update the parser: when a file header contains a rename pair, record a mapping from old path to new path and parse the following hunks as belonging to the new path.

Expected: hunks after a rename header are attributed to the new file path.

1. Make comment posting use the mapping. Every comment position computed from diff content must resolve through old-path to new-path before the API call, and must reference the PR head SHA.

Expected: comments land on the new path at valid positions.

1. Handle the partial-rename case: when similarity is low, the diff may show the rename plus large content changes. Still map the path, but re-verify each comment's target line against the new file content.

Expected: no comment lands on a line that does not exist in the new file.

1. Test with a PR that renames a file and edits it in the same commit.

Expected: all comments appear on the new path with correct lines.

Use this when

• Comments land on the old path after a file rename
• Line numbers are wrong on renamed files
• The parser treats renames as delete-plus-add
• Reviewing PRs that move files around

Not for this skill when

• Comments fail with 422 on outdated hunks without any rename involved (that is a stale-SHA problem)
• The parser breaks on binary sections (different header pattern, different fix)
• The parser fails on collapsed generated-file markers (different marker, different fix)
• Paths are wrong because of a base-path stripping bug rather than renames

Variant phrasings

• "review comments on wrong file after rename"
• "diff parser ignores rename headers"
• "line comments misattributed on moved files"
• "handle renamed files in unified diff parser"

Why it happens

Most hand-rolled diff parsers split on the file header and then read hunks, assuming one header equals one path. A rename header breaks that assumption: the content that follows belongs to the new path, but the parser keeps the old one. Everything downstream - line mapping, comment positions - inherits the wrong path.

Edge cases

• A rename plus a mode change or permission change adds extra header lines. The parser must skip unknown header lines instead of choking on them.
• Copies (copy-from / copy-to) look like renames but the old file still exists. Map the path for the new file without invalidating comments on the old one.
• Some diffs abbreviate the rename when similarity is 100 percent and show no hunks at all. That is fine - there is nothing to comment on line-wise; note the rename at file level.
• Case-only renames on case-insensitive filesystems can confuse path mapping. Normalize case when comparing paths.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F6r2qmWAp6WGxFu8hG-gCA