hygiene(tick-history): 2026-05-01T10:25Z — PR #1031 rebase-and-fix (rebase-drop-with-content-resurface)

docs/hygiene-history/ticks/2026/05/01/1025Z.md

@@ -0,0 +1 @@
+| 2026-05-01T10:25:00Z | opus-4-7 / autonomous-loop tick | 98fc7424 | PR #1031 rebase-and-fix tick — DIRTY rebase against main + 4 thread-fixes. Surfaced **rebase-drops-prior-fix-but-content-resurfaces** sub-pattern: previous tick's MEMORY.md duplicate-link-target fix (commit 8f59793) was dropped during rebase ("patch contents already upstream" hint) — but the original commit that introduced the duplicate re-applied it, so the duplicate re-emerged in working tree. Re-applied the dedup. The original threads (3× class-orthogonality-rule forward-ref + 1× MEMORY.md over-cap) were also re-fired by reviewer after each force-push. Resolution: both fixes were present from the prior session but the rebase reverted the dedup, so re-applying was needed. **New sub-class observation: rebase-drop-with-content-resurface** — when `git rebase` says "patch contents already upstream" and drops the patch, but the underlying commit that the patch fixed re-applies the original problematic content, the fix needs to be re-applied. Contrast with regular outdated-thread (where the underlying issue is genuinely resolved upstream). All 4 threads resolved + commit c2ec0fc pushed via force-with-lease. Cron 98fc7424 healthy. | [PR #1031: 1 commit (c2ec0fc) — re-drop duplicate MEMORY.md entry + sharpen forward-ref annotation in line 256; 4 thread-resolutions; force-with-lease push] | The rebase-drop-with-content-resurface pattern is an interesting addition to the v2 taxonomy's eventual mechanization scope: a future cross-reference-resolves-to-file auditor wouldn't catch this, but a duplicate-link-target lint at PR-open time WOULD (and CI confirmed it earlier — that's how the original duplicate was detected). The corrective is to **trust the lint over the rebase**: when CI re-fires a previously-fixed lint after a rebase, assume the fix needs re-applying rather than assume the lint is wrong. The pattern composes with class #15 (intra-file drift) — both are "fixes get out of sync with their target state" but at different time-axis (intra-file at edit-time vs across-rebase at branch-time). Future-Otto: when rebasing a PR that had a previous fix-commit, re-verify the underlying lint passes after the rebase; don't assume the rebase preserved the fix. |