test(migrations): prove 0002 purges tombstones and keeps live rows

[hsinatfootprintai]

Nothing asserted that 0002 does anything

migrations/embed_test.go says so in its own header:

The tests below are therefore about COVERAGE, not about the SQL: every file in this directory has to be reachable through the embed

So 0002_purge_soft_deleted_documents shipped, was pinned by grandturks (#1004/#1014), and was applied to a deployed cluster — without a single assertion that it removes a tombstone.

How the gap surfaced

Running FootprintAI/grandturks#977's criterion 4 against ubm01 — "after #970's migration, count(*) WHERE deleted_at IS NOT NULL returns 0".

It returned 0. It had also returned 0 before the migration ran, because that database had never held a tombstone; the apply reported DELETE 0. The criterion passed while demonstrating nothing — sprint #827's failure one level down.

What this adds

A test that cannot be satisfied vacuously: it creates a tombstone, asserts it exists, then asserts the migration removed it. A require.NotZero on the fixture makes the vacuous case a hard failure rather than a silent pass — that specific failure mode is what prompted this.

The fixture is built the way the old code built it. DocumentCURD.Delete is Unscoped now (#136/#137), so it hard-deletes and cannot produce the rows this migration exists to purge. A scoped gorm delete is what the pre-#137 code did, and what wrote every tombstone in every deployed database. Reproducing that rather than INSERTing a hand-made row keeps the fixture honest: gorm sets deleted_at exactly as production did, and if that behaviour ever changes the test changes with it.

Two assertions, not one. "Tombstones are gone" is half the contract; "live rows are untouched" is the half that makes the migration safe to run — a DELETE with a broken predicate would still satisfy the first. The keeper is read back through the normal path rather than counted, so a row that survived as a tombstone would not pass.

It also asserts the tombstoned row still holds its data payload before the purge — the state #936 objected to, and the reason this is a retention question rather than a tidiness one.

A second test covers idempotence, because #970's runbook tells operators "re-running is harmless" and the deployed sites are applied by hand, so a second run is likely rather than hypothetical.

Applied from the embedded copy, not from disk — that is what a consumer pinning this module actually runs.

Verification, stated honestly

go vet passes and the tests skip cleanly under -short. They have not been executed against a real Postgres — I have no Docker locally, so CI's postgres:16-alpine service is the first thing that will actually run them.

If CI is green, that is the first time anyone has seen 0002 remove a row. Worth watching that run rather than assuming it.

Gated on testing.Short() like every other postgres-backed test here.

🤖 Generated with Claude Code