Skip to content

fix(contract): let the reviewed item catalog resync - #113

Merged
diese-tech merged 1 commit into
mainfrom
claude/item-catalog-sync-compatible
Sep 1, 2026
Merged

fix(contract): let the reviewed item catalog resync#113
diese-tech merged 1 commit into
mainfrom
claude/item-catalog-sync-compatible

Conversation

@diese-tech

Copy link
Copy Markdown
Owner

Problem

Second hard-coded blocker in the same pipeline as #112, on the items side.

005_item_catalog.test.sql test 5 asserted an exact row count and a frozen provenance timestamp on every row:

SELECT count(*) = 265
  AND count(*) FILTER (WHERE active) = 265
  AND count(*) FILTER (WHERE source_url ~ '^https://www[.]smitefire[.]com/smite/item/') = 265
  AND count(*) FILTER (WHERE source_updated_at = '2026-07-29T15:19:05.553Z'::timestamptz) = 265

A reviewed sync restamps source_updated_at by design, so this fails on every content PR. #83 carries 265 items — the catalog did not change size — with provenance at 2026-08-07T21:32:25.077Z and 2026-08-17T13:52:50.004Z, and fails purely on the frozen timestamp.

This was invisible until now. database-contract is gated on repository-state, which had been failing first on the hard-coded god count, so this suite had never actually run against a synced catalog. Fixing #112 surfaced it.

The description had also drifted — it said "260-item" while asserting 265.

Change

The assertion keeps every invariant that matters and drops the two the sync necessarily breaks:

SELECT count(*) >= 265
  AND count(*) FILTER (WHERE active) = count(*)
  AND count(*) FILTER (WHERE source_url ~ '^https://www[.]smitefire[.]com/smite/item/') = count(*)
  AND count(*) FILTER (WHERE source_updated_at IS NOT NULL) = count(*)

Whole, active, source-attributed, and carrying provenance on every row. Shrinkage is caught by the verify-seed-growth step added in #112, which already runs over the items seed too.

Verification

Run on PostgreSQL against a table shaped like #83's seed:

Case New assertion Old assertion
265 rows, two distinct provenance timestamps (#83's shape) ✅ passes ❌ fails
Catalog grows to 266 ✅ passes ❌ fails
A row with source_updated_at IS NULL ❌ fails
An inactive row ❌ fails

npm run build and npm test (22 passing) green.

Once this lands, #83 — the Ix Chel sync PR stuck since August 4th — should finally go green end to end.


Generated by Claude Code

Second blocker in the same pipeline as #112. 005_item_catalog test 5
asserted an exact 265 rows and a frozen
source_updated_at = '2026-07-29T15:19:05.553Z' across every row. A
reviewed sync restamps that provenance by design, so the assertion fails
on every content PR — sal-database#83 carries 265 items with provenance
at 2026-08-07 and 2026-08-17 and fails here even though the catalog did
not change size.

That failure was invisible until now: database-contract is gated on
repository-state, which had been failing first on the hard-coded god
count, so this suite had not actually run against a synced catalog.

The assertion now requires the catalog to be whole, active,
source-attributed, and carrying provenance on every row, with a floor
rather than an exact count. CI's verify-seed-growth step is what stops
the catalog shrinking. The description also claimed 260 while asserting
265, so it had already drifted.

Verified on PostgreSQL against PR #83's shape: 265 rows with two distinct
provenance timestamps pass where the frozen assertion fails, growth to
266 passes, and a null source_updated_at or an inactive row still fails.
@diese-tech
diese-tech merged commit 8e9d12b into main Sep 1, 2026
3 checks passed
diese-tech added a commit that referenced this pull request Sep 1, 2026
Adds Ix Chel to the reviewed god seed (88 to 89) and restamps item
provenance. The item catalog is unchanged in size at 265.

This PR had failed CI every day since 2026-07-20, blocked by two
hard-coded assertions that a reviewed sync necessarily invalidates: an
exact 88-row god count (#112) and a frozen item source_updated_at
(#113). The second was invisible until the first was fixed, because
database-contract is gated on repository-state.

Ix Chel was discovered with no class or damage type, so it carries
placeholder Mage/Magical metadata and is flagged for manual review in the
generated seed, alongside Chronos which was already in that state.

The sync run reported REVIEW_REQUIRED for two items not found on that
scrape, Ruinous Ankh and Spectral Visage. Both are preserved by the
pipeline's fail-safe and are not removed by this change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant