An upsert-only seed or sync re-asserts what exists in source control but cannot know what was deleted: removing or re-identifying a content file leaves an orphan row that keeps rendering in production. Each iteration diffs the source-of-truth entries against the live store's rows, then resolves one mismatch — pruning an orphan row deliberately, or restoring a file that should never have been removed. Distinct from migration-until-applied and schema-migration-drift-zero (both target SCHEMA): this reconciles DATA rows against curated content.
Loop
- Goal
- the live store and the curated source files describe exactly the same set of entries — no orphan rows in the store, no source entries missing from it
- Exit when
- the diff between source entries and store rows is empty (the check prints PARITY)
Check between iterations
diff <(ls src/content/*.json | xargs -n1 basename | sort) <(psql "$DATABASE_URL" -tAc 'select slug from items order by slug') && echo PARITY
$
Kickoff prompt
Start the "Store-Content Parity" loop.
Goal: the live store and the curated source files describe exactly the same set of entries — no orphan rows in the store, no source entries missing from it
Max iterations: 5
Between iterations run: diff <(ls src/content/*.json | xargs -n1 basename | sort) <(psql "$DATABASE_URL" -tAc 'select slug from items order by slug') && echo PARITY
Exit when: the diff between source entries and store rows is empty (the check prints PARITY)
Step 1: Produce the two sorted lists — entries in source control and rows in the live store — diff them, and resolve the first mismatch by pruning the orphan row or restoring the missing entry.
›