Expose reconciliation status for saved notes after review reloads #1150

Activity

1. officialparacite commented on Oct 19, 2026

   

   officialparacite

   on Oct 19, 2026

   More actions

   Related case: notes stay on their original line number after an edit only shifts the code below them

   This is the case where the anchored line's content didn't change at all; it just moved.

   Steps (Hunk v0.23.0, macOS)

   1. hunk diff on a file with two methods.
   2. Add a note on line 52 ("implement this") and another on line 62 ("explain this method"); line 62 is def apply_interest.
   3. An agent edits the file, inserting 11 lines above line 62, then runs hunk session reload.
   4. The second note now sits on line 62, which shows get_balance. apply_interest has moved to line 73.

   Expected: on reload, notes whose anchored lines were only shifted (not changed) move with them, using the old→new line mapping from the diff. If an anchored line itself was changed, keep the note where it is and flag it, as this issue proposes.

   Why it matters: in agent workflows, the agent edits the file and then replies to the user's notes, so line drift is common. Agents can't move user notes (only remove them), so a client-side workaround would turn user notes into agent notes.
2. squad-joey commented on Oct 19, 2026

   

   squad-joey

   on Oct 19, 2026

   Contributor

   More actions

   I can reproduce the display drift after an unchanged line moves on both v0.23.0 and current source, using a smaller Linux fixture.

   I saved a native user note on export function apply_interest() at new-file line 5, inserted eleven comment lines immediately above it, then ran a real session reload. The method's text stayed identical and moved to line 16, but the note still rendered beneath the newly inserted line-5 comment:

   new line 5:   // SHIFT1150_1
                Your note: EXPLAIN_APPLY_INTEREST_1150
                ...
   new line 16:  export function apply_interest() {
   

   The note ID, body, authored source and newRange: [5,5] also remained unchanged in session comment list --type user and session review --include-notes. With no file edit, reloading kept the note correctly beside the method at line 5 on both revisions. No reconciliation warning appeared in the captured UI.

   This distinguishes two concerns: preserving the original saved anchor can be intentional, while displaying it as though it still applies to unrelated current text needs reconciliation or a separate display mapping. This result doesn't establish that the stored original range should simply be overwritten, especially for ambiguous or changed content.

   Reproduction scope

   • Source revisions: v0.23.0 7991d303, current main 88f8dbed.
   • Linux x86_64, Bun 1.4.2, each revision's frozen dependencies, isolated daemon and 140×40 unified PTY.
   • Reduced input was diff --files before.ts after.ts, with two functions and changed return values. The note was authored and saved through the real composer; only the second file was edited before reloading the same file pair.
   • Shift and no-edit control were exercised on each revision. This is a file-pair reproduction, not an independent check of the original Git working-tree/macOS workflow.
   • Changed/deleted/ambiguous anchors, an active verdict in internal state, installed binaries, and a fix remain unverified.

   This comment was generated by Pi using GPT-6.1 Sol
3. officialparacite commented on Oct 20, 2026

   

   officialparacite

   on Oct 20, 2026

   More actions

   Thanks for reproducing this. Agreed on the split: I'm mainly after the display side (show the note at the moved line, or flag it as stale), and keeping the original anchor stored makes sense.