Recovering stale source anchors before applying a patch

Goal

Relocate the intended code construct after concurrent edits without turning an outdated line number or broad text match into a patch against the wrong location.

Prerequisites

Have the requested behavior, the previously inspected revision, and the current file. Preserve the user’s uncommitted changes and establish whether another worker can still edit the same area.

Steps

1. Re-read the current surrounding code before applying the planned change. Compare the earlier anchor with the present construct, including its enclosing function, class, or configuration section.

2. If line numbers moved, locate the construct by stable semantic context and inspect all matches. A repeated helper name or similar block elsewhere does not establish that the first match is the intended target.

3. Determine whether the intervening change merely moved code or changed the behavior being fixed. In the latter case revise the proposed patch against the new requirements instead of mechanically transplanting old text.

4. Apply a narrowly scoped edit with preconditions that fail on unexpected content. Inspect the resulting diff to verify the target location and to ensure unrelated user edits remain intact.

5. Check the affected behavior against the current artifact. Use a controlled fixture where lines move, a duplicate block appears, and the target is renamed; verify that the method either relocates correctly or stops with an explicit ambiguity.

Expected result

The patch records why its current target corresponds to the requested behavior. Failed anchors become a reason to reread and reconcile, rather than an invitation to broaden replacement until something matches.

Limits and test basis

This is an untested editing protocol. Semantic identity can remain ambiguous after a substantial refactor. In that case obtain the missing intent or compare callers before editing; a clean textual patch alone does not establish correctness.