git rerere is per-clone, so every session re-resolves the same f5 conflict independently nf-g2um ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/535 by tools/beads/import_github.py's reconcile pass.

Filed unclaimed. Noticed while trying to rebuild f5/integration three times in a row today and being stopped each time.

The claim in CLAUDE.md, and what is actually true

> *"The same merge conflict ... comes back on EVERY rebuild. git rerere records each hand-resolution and replays it automatically the next time, so a recurring conflict is resolved once, ever."*

Resolved once per clone, ever. rerere state lives in .git/rr-cache/, which is local and never pushed. Every dev session runs rebuild_f5.sh in its own long-lived clone (ninefold-dev/ninefold-a, -b, -c, plus release and art), so N sessions means the same conflict is hand-resolved N times — and each resolution is invisible to the others.

Observed directly: origin/f5/integration was rebuilt successfully by another session at 16:41 and again at 16:55, including both sides of a conflict my clone could not get past — because their rr-cache had the resolution and mine did not. From my side it presents as ✗ UNRECORDED CONFLICT, which reads as "nobody has ever resolved this" when in fact somebody just did, minutes ago.

Why it is worth more than a doc correction

• The cost scales with sessions, not with conflicts. Five clones, one recurring conflict = five hand-resolutions of the same thing, each an opportunity to resolve it *differently*. Nothing detects divergence: f5 is throwaway, so two sessions can hold contradictory resolutions indefinitely and each sees a green rebuild.
• The rebuild is a shared service with per-clone competence. Any session may be the one Aedan asks for a fresh f5, and whether that works depends on which conflicts that particular clone happens to have seen.
• It makes "resolve it, rerere records it" misleading advice at exactly the wrong moment — a session hitting the wall reads the doc, resolves someone else's semantic conflict between two other sessions' branches, and records a guess that then replays silently in its clone forever. I declined to do that today for #519 vs #530 for this reason, which left my clone stuck while others were fine.

Worth considering

• Share the rr-cache. rerere.enabled plus a shared directory, or committing resolutions to a branch and syncing them, would make the doc's claim true. git rerere has no native sync, but rr-cache is just files.
• Or stop pretending the rebuild is per-clone at all. If one session (or a cron) owned f5/integration and everyone else only consumed it, the conflict would be resolved once by construction and the "which clone are you in" variable disappears. This is the bigger change and probably the right one — see #518, which is already moving the rebuild into a dedicated worktree for unrelated reasons.
• At minimum, correct the claim in CLAUDE.md and say what to do when you hit a conflict between two branches you do not own — today the doc only says "resolve it".
• Make the message honest. ✗ UNRECORDED CONFLICT could say "unrecorded *in this clone*", which is a one-word fix that would have saved me from assuming nobody had resolved it.

Related: #518 (worktree), #465 (same script, delete/modify conflicts), #400.