v1.2.0 to v1.3.0

---

name: pr-from-stale-branch-silently-reverts-newer-main-files

description: |

author: Claude Code

date: 2026-06-17

disable-model-invocation: true

---

# A PR from a stale branch can silently revert newer main files (no conflict)

## Problem

## Context / Trigger Conditions

no memory of touching (e.g. someone else's analysis/handoff/docs from a sibling

session that merged while you worked).

- The PR's deletion count is suspiciously high for the work you did.

## Solution

```sh

git fetch origin main

```

```sh

```

`merge-conflict-generated-files` (generated-file union playbooks).

## If one of these has already merged: splice, never revert

`git revert` on the offending squash commit re-deletes everything that has

merged *since* — the same failure, aimed the other way. Recover each lost object

individually from the last commit where it was intact and re-insert it into

*current* main:

```sh

git checkout <last-good-sha> -- <path> # files

git show <last-good-sha>:<ledger> | ... # hand-edited ledgers: splice ONE object

```

**Check the hand-maintained ledger separately from the files.** A tracker entry

can be gone while its files are fine, and vice versa — and a text field can be

rolled back to its earlier wording while the record still exists, which no

id-presence check catches. Diff the field, not just the key.

### Checking as a victim: scope the check to what you TOUCHED, not what you MADE

The natural check — and the one a broadcast asks for — enumerates *the things I

created*. **The revert's scope is *the things I touched*, which is larger**, and

the gap between them is where a clean-looking check goes wrong. Three ways it

did, all in one session, each after an earlier check had reported clean:

- **In-place edits to records you did not create.** Amending someone else's

standing ruling, appending a "DONE" paragraph to a pre-existing task, editing

a caveat block — none of those produce a new id, so an id/status/PR-number

sweep passes while the prose underneath has reverted. One standing ruling was

left publishing a superseded range with no marker on it, and the sweep that

was supposed to have verified it had looked only at `status` and `prs`.

- **A PARTIAL rollback inside one record.** Half of an appended edit survived

and half reverted, so a single entry said the question was *settled* and, two

sentences later, quoted the range the settlement replaced. **A half-reverted

record reads self-consistent** — worse than a clean revert, which at least

looks obviously old.

- **A moved number is indistinguishable from a reverted one by grep.** A README

count read 560 where the session had written 546; both a file-existence check

and a content-needle check flagged it lost, and it was not — sibling sessions

had added tests. **Re-derive the value; do not compare the string.** The

needle check is right for prose and wrong for anything computed.

The executable form is a needle per *claim*, not per file — one distinctive

phrase for every paragraph you amended, every ledger field you edited, and every

computed figure re-derived rather than matched. **Save it as a file** (called

`needle-audit.sh` throughout this section), because you will run it more than

once with different values of `REF`:

```sh

REF=${REF:-origin/main} # override to check a BRANCH pre-merge

f() { git show "$REF:$2" | grep -qF -- "$3" && echo "OK $1" || echo "LOST $1"; }

f "ruling: the amendment" path/to/ledger.js "AMENDED 2026-08-07 BY"

f "caveat: pinned, not open" path/to/ledger.js "PINNED 2026-08-07 at"

# ...and for anything computed, re-measure instead of grepping:

test "$(pytest docs -q --co 2>&1 | tail -1 | awk '{print $1}')" = "$(grep -oE '[0-9]+ collected' README.md | head -1 | cut -d' ' -f1)"

```

Keep the `REF` override: the same script is the pre-merge gate for *your* PR and

the post-merge audit for someone else's, and only the second one is usually

written.

#### Where the needle comes from — and what it costs to guess one

**Take every needle out of the merged artifact, never out of recall.** Paste the

line you took it from next to the check:

```sh

git show <squash-sha> -- path/to/file.py | grep '^+' | grep -i finalist

# → + finalist_km = ... ← THIS line is the needle

```

The audit of PR #853 (DoodleRun, 2026-08-07, tracked under #863) grepped for

`route_km_finalist` — a

symbol name recalled from the session that had written it. The real symbol was

**`finalist_km`**. The grep found nothing, and for a minute the session believed

an entire merged PR had been deleted.

**The failure is two-sided, and only one side is intuitive:**

| A guessed needle that… | …manufactures |

|---|---|

| MISSES | a phantom deletion — alarming, but self-correcting: somebody goes and looks |

| happens to MATCH | a **false all-clear** — and nobody re-checks a clean audit |

The matching case is the worse one and produces no symptom whatsoever. That is

why the provenance rule is absolute rather than a nicety: a needle you cannot

point at a line for is not evidence in *either* direction.

#### Check the state AT the suspect commit, not at `origin/main`

Current state cannot distinguish **"never hit"** from **"hit, and restored by

someone else"**. If a sibling session already noticed the revert and pushed a

recovery PR, `origin/main` holds your content again — and an audit run against

main reads that as proof you were never affected, which is exactly backwards when

the question is what a particular merge did.

```sh

REF=<suspect-squash-sha> sh needle-audit.sh # "did THAT merge drop it?" ← the real question

REF=origin/main sh needle-audit.sh # "is it there right now?" ← a different one

```

This is what the `REF` override above is for, and it is worth running both ways:

the first says whether you were a victim, the second says whether anything is

still outstanding.

**Then tell the other sessions.** Losses are per-session and nobody else can see

yours; a broadcast with a copy-pasteable `git cat-file -e origin/main:<path>`

loop is the only thing that finds the ones whose owners have already wrapped.

## Verification

PR #853 (`claude/floor500-rulings`, squash `6c79ff26`) shipped three ticked

owner rulings **and deleted 11 files plus 15 hand-maintained ledger entries**

belonging to four other sessions — 59 files, 5,081 deletions.

**Its parent was the newest commit on main.** `git log` showed it directly on

top; nothing was behind. The tree, however, was ~8 hours old: the branch tip

differed from its own parent by **59** files but from an 8-hour-old commit by

only **39**. Everything merged in that window was recorded as a deletion.

**Nothing gated it.** The PR was **created at 09:30:12Z and merged at

09:30:23Z — eleven seconds** — so no reviewer and no CI run ever saw the diff.

**It was found 3½ hours later, by accident**, during an unrelated wrap-up check

that happened to re-read the ledger. Two follow-up PRs restored some casualties;

one session's four files and six ledger entries were still missing hours after

that, because that session had already finished and nobody was coming back.

**The two habits that would have caught it**, in order of cost: run

`git diff --diff-filter=D` before merging, and — in a solo repo where no human

reviews — re-verify your own merged work still exists on main *after* the last

sibling merge, not at the moment you write the ledger entry.

## Notes

- Same root cause as `large-redesign-parallel-branch-collision-audit` (branches

drift from main), but that skill is a *pre-plan* collision audit across many

- `gh pr merge --delete-branch` may then fail with "main is already used by

worktree at ..." when you run from a worktree — the merge still succeeded;

delete the remote ref with `gh api -X DELETE repos/<owner>/<repo>/git/refs/heads/<branch>`.