feedback_reflog_cherry_pick_recovery_pattern

When a hard-reset drops local-only commits during concurrent-storm resolution, recover via:

1. git reflog HEAD@{N} — surfaces dangling commit hashes (the local-only work that the --hard reset orphaned but git’s reflog still tracks for 90 days by default).
2. git cherry-pick <hash> — re-applies the dangling commit on top of current HEAD.
3. Resolve conflicts at familiar collision-points (arch-state §15 + ledger version + CHANGELOG). Renumber-on-collision per BATCH α″ Decision Matrix #10 — bump arch-state version + A-NNN + ledger task-NNN + version to next-available, no thrashing.

Why: During the 2026-05-20→21 5-way concurrent-batch burst, BATCH δ′ Paul-session prep pack hit this exact pattern. After authoring 6 deliverables + arch-state amendment + ledger row, a git reset --hard origin/main (intended to clear an unrelated rebase stall) dropped the local-only δ′ work. Recovery: git reflog surfaced dangling commit a89e9a8 containing the full δ′ work-content; git cherry-pick a89e9a8 re-applied cleanly on top of current HEAD; result landed at commit 3bb4a40. No work lost; the conflicts surfaced at the predictable arch-state §15 + ledger CHANGELOG collision-points and were resolved via clean renumber-on-collision per α″ precedent.

How to apply:

• ANY time you git reset --hard and realize afterward that you dropped local-only commits, IMMEDIATELY run git reflog (NOT git log). The reflog retains the orphaned commit hashes; git log only shows what’s reachable from current refs.
• For the dropped commits you want to recover, use git cherry-pick <hash> (not git reset --hard <hash>, which would itself drop other work). cherry-pick re-applies on top of current HEAD as a NEW commit (with new SHA).
• Conflicts will land at the same files that collided originally (arch-state §15 + ledger). Use the BATCH α″ + Decision Matrix #10 renumber-on-collision discipline: bump arch-state version + A-NNN + ledger task-NNN + version to next-available; do NOT thrash.
• The reflog has a 90-day default expiry. If you discover dropped work months later, it may already be gone. So: if you git reset --hard and you’re unsure whether anything important was lost, run git reflog BEFORE switching to other work.

Empirical evidence: δ′ recovery 2026-05-21T01:50 BST — 30 minutes of work recovered cleanly. Companion to feedback-launch-prompt-scope-framing-at-rule-statement-granularity (sibling discipline; both surfaced in the same burst). Part of the broader 5 race-condition recoveries in 24h pattern documented at feedback-concurrent-burst-race-condition-count-24h.

Anti-pattern to avoid: running git reset --hard origin/main reflexively to “clean up” a complex rebase state without first verifying via git stash list + git reflog HEAD@{1} what’s about to be lost. The reset is reversible via reflog within 90 days, but each operation that follows a destructive reset reduces visibility into what was dropped.

Routing: Always-load via ~/.claude/projects/-home-richardd-testatetech/memory/MEMORY.md index. Fires when the work in this project hits git-state-recovery scenarios.