← Registry
Loop Official

Store-Content Parity

When your sync pipeline only upserts, removals never propagate — loop until the live store's rows exactly match the curated source files, pruning orphans deliberately.

Install

via Positronick CLI

$positronick loop install store-content-parity

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.