--- name: confirmation-without-postop-sha description: "a peer's 'CONFIRMED' that names no post-operation sha is a prediction, not a report — re-derive the state (git log origin/main -1) before building on it; the 2026-08-03 ff fault" metadata: node_type: memory type: feedback originSessionId: d71ff42e-f74a-4e32-a112-81c9494b985c modified: 2026-08-03T07:20:57.639Z --- **2026-08-03, IR-18 landing:** deployah sent "FF CONFIRMED for b48e35b. Push the register batch." He had verified ff-ABILITY (a property of two shas at an instant) — the ff push never happened. I read "confirmed" as "executed" and pushed the register batch onto 0f35bc2; main moved to 1e520b4 and broke the PR's ff-ability, costing a rebase + full thin-CI cycle. Same night, same agent, second instance of the class: his 98cd77b commit earlier was committed-but-never-pushed while he messaged "register @98cd77b on main". **Why:** a state-change report without the post-operation read-back is indistinguishable from an intent. The ONLY artifact that separates "I verified this would work" from "this happened" is the authoritative source read AFTER the operation — for git, `git log origin/main -1` naming the new tip. Both of tonight's instances were missing exactly that artifact. **How to apply:** before building on any peer-reported state change (ff done, pushed, closed, deployed), re-derive it from the authoritative source yourself — one fetch + log is cheaper than one broken ff. Symmetrically, when reporting my own operations: name the post-operation sha/state read back from origin, or use the honest words ("ff-able as of ", "committed, not yet pushed"). Deployah's adopted rule: never say "confirmed" about anything not read back from the authoritative source after the operation completed. See [[premature-closure-guards]], [[start-event-is-not-proof-nothing-ran]], [[restore-step-presumes-committed-baseline]].