fix(contract): let the reviewed god seed grow - #112
Merged
Conversation
verify-contract.mjs asserted the SMITE god seed contained exactly 88 rows, with the number hard-coded in the script. The catalog grows as SMITE ships gods, and diese-tech/smite-content-sync proposes those additions as reviewed PRs into this repository — so the first real god addition failed check:contract and stayed blocked until someone edited a verification script. Confirmed by adding a row locally: Error: The reviewed local SMITE god seed must contain exactly 88 rows. What the guard is actually for is a seed that silently loses entries, not one that gains them; smite-content-sync already runs its own catalog-size regression guard before exporting. So the assertion becomes a declared floor in contract.json, where the release is declared, rather than a magic number in a script. An exact count caught duplicates only by accident, through the total, so a duplicate-name check now stands on its own — matching case-insensitively and unescaping doubled quotes, since the seed carries names like Chang''e. Verified all four cases against the real seed: unchanged (88) passes, growth to 89 passes, shrinkage to 87 fails naming both numbers, and a duplicate name at full count fails naming the god.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 62629fa996
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The declared floor does not rise when growth is accepted. Once a sync PR takes the catalog to 89, a later change could drop back to 88 and still pass, quietly losing a god that had already been reviewed — so the floor alone did not deliver the "never shrinks" invariant the runbook claimed. CI now also compares each reviewed seed against the same file on the pull request's base branch and fails if it lost rows. That holds the invariant continuously without a manual bump on every addition, and the floor stays as an absolute backstop. Verified against the real seed: growth 88 to 89 passes, the regression the review described (base 89, PR back to 88) fails naming both counts, an unchanged seed passes, and a seed with no base copy is skipped rather than erroring, so adding a brand-new seed file still works. Also corrects the runbook, which described the floor as if it ratcheted.
This change alters contract.json itself, so it needs its own release identity. Leaving it as db-v1.21.0 would let that tag resolve to two different manifests depending on which commit a consumer fetched, and sal-site's verifier compares the manifest at the release tag against the one at the pinned commit.
diese-tech
added a commit
that referenced
this pull request
Sep 1, 2026
Second hard-coded 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 failed on every content PR -- #83 carries 265 items, an unchanged catalog size, with provenance at 2026-08-07 and 2026-08-17, and failed purely on the timestamp. The 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 never 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. The verify-seed-growth step added in #112 is what stops the catalog shrinking, and it already covers the items seed. The description had also drifted, claiming 260 while asserting 265. Verified on PostgreSQL against #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
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
verify-contract.mjsasserted the SMITE god seed contained exactly 88 rows, with the number hard-coded in the script:The catalog grows as SMITE ships gods, and
diese-tech/smite-content-syncproposes those additions as reviewed PRs into this repository — itspublish-project-prs.ymlcopiesexports/sal-database/supabase/seeds/smite2-gods.sqlin and opens a PR. So the first real god addition failscheck:contractand stays blocked until someone edits a verification script.Confirmed by adding one row to the real seed locally:
Both sides currently sit at 88, so nothing is broken today — this blocks the next god.
Change
What the guard is actually for is a seed that silently loses entries, not one that gains them (and smite-content-sync already runs its own catalog-size regression guard before exporting). So the assertion becomes a declared floor, in
contract.jsonwhere the release is declared rather than a magic number in a script:An exact count also caught duplicates only by accident, through the total — a floor would not — so a duplicate-name check now stands on its own. It matches case-insensitively and unescapes doubled quotes, since the seed carries names like
Chang''e.Lowering the floor stays a deliberate edit to the manifest.
Verification
All four cases run against the real 88-row seed:
Verified db-v1.21.0 at migration 20260901120000must contain at least 88 rows, received 87The SMITE god seed repeats a name: zeusnpm test20 passed (3 new, covering duplicates, clean growth, and case/quote handling);npm run lint,npm run typecheck,npm run buildgreen.Generated by Claude Code