DB: adopt a capture-verified v1 baseline and release db-v1.0.0

[diese-tech]

Objective

Turn the recovery-gated repository scaffold into the canonical, reproducible database contract and release db-v1.0.0.

Hard prerequisite

Do not create, apply, repair, or tag the baseline until diese-tech/sal-site#156 proves backup/PITR recovery in a scratch Supabase project and captures the production schema plus migration ledger.

Scope

• confirm production migration 025 and the deployed behavior from site PR #170
• capture and preserve the production schema and migration ledger
• reconcile the restored schema with both consumer expectations
• create one 14-digit canonical schema-only baseline and deterministic non-production seed fixtures
• prove blank supabase db reset, database lint, RLS assertions, Realtime assertions, and a normalized empty local-versus-restored-production diff
• use the protected production-plan workflow to repair only captured historical ledger entries after drift is empty
• require exact ledger parity and an empty push dry-run
• generate generated/database.types.ts and contract.json
• release and tag db-v1.0.0 only after protected production verification

Acceptance

• recovery evidence is linked privately and the measured RPO/RTO are recorded
• a blank database rebuilds from the single active migration sequence
• contract hashes and generated types verify in CI
• production migration history equals the released contract with no pending push
• old ledger export is preserved for rollback evidence
• no production identities, submissions, or audit data enter Git

Corrections must be forward migrations; never execute equivalent baseline DDL against the existing production schema.

[diese-tech]

Dependency clarification from the 2026-07-17 owner update: sal-site#156 is no longer a historical PITR restore gate because no existing Supabase backups are available. This baseline must be built only after the current production state is captured and restored into scratch through a logical export.

Required interpretation for db-v1.0.0:

• Preserve today's production information; do not remap league data by hand.
• Use the verified production schema as the canonical baseline source.
• Keep production data dumps out of Git; commit only schema, deterministic seed fixtures, generated types, contract metadata, and non-sensitive verification evidence.
• Reconcile drift with forward migrations only.

[diese-tech]

The recovery prerequisite now has technical acceptance evidence:

• production was captured read-only and restored with 55-table / 440-row parity;
• both SAL Site and SALbot passed isolated scratch reads through their real data layers;
• PR #170 deployment is verified;
• migration 025 is absent and under-specifies live constraints/policies, so it must not be applied or ledger-repaired;
• weekly encrypted backups and a scheduled checksum/age/restore-state verifier are active.

Evidence is recorded in diese-tech/lab-grid-lab#9 (head 6582483) and sal-site#156. The v1 baseline should preserve the complete captured live DDL, including constraints and policies. forfeit and the stale gaia report constraint should be separate forward migrations after baseline equivalence is proven.

This issue is ready to start once the owner records a schema-freeze window. No production ledger or schema mutation is authorized by this update.

[diese-tech]

Schema freeze approved by the owner and begins now: 2026-07-17T14:37:33Z (2026-07-17 10:37 -04:00 America/New_York).

Freeze scope:

• pause all Supabase DDL, SQL Editor schema changes, migration pushes, and ledger repairs outside this issue/sal-database;
• normal league operations and row-level data entry continue;
• emergency schema work must be a reviewed forward migration in sal-database and will restart the baseline parity proof;
• migration

[diese-tech]

Schema-freeze baseline update:

• Freeze began at 2026-07-17T14:37:33Z and remains active for DDL outside sal-database.
• Draft PR DB: add capture-verified v1 production baseline #7 contains the schema-only db-v1.0.0 candidate at commit a0f52f391a43c2ca273427b94f6515737b856d1b.
• The candidate preserves observed production state exactly. Archived site migrations 019-025 remain absent and are not applied or repaired into history.
• No production rows are committed. The only fixtures are deterministic division and reviewed god reference data.
• Production and rebuilt public schema dumps are byte-identical (sha256:b3580ab348103fc0842dc1555711dfded49113515e5f6f5e359c3dc5d2a89e6b).
• Baseline migration SHA-256: 80a516c31533b7dfa0f2948eb657eb0f38bf3305b51826a139b610a1891800cc.
• Generated types SHA-256: c4197d5c9368c80b867d9e310664360915053320c7f67ab941ddecdca171cff5, matching contract.json.
• Local proof passed: clean reset, database lint, 4 pgTAP files / 30 tests, generated-type stability, Node 24 lint/typecheck/tests/build, npm audit, and whitespace checks.
• Hosted CI run 29590267398 is green for repository-state, secret-scan, and the full database-contract job.

Production remains unchanged: no baseline DDL execution, no migration-ledger repair, no release/tag, and no deployment run. recovery-attestation.json is intentionally absent, so deployment remains fail-closed.

Remaining protected sequence: review/merge PR #7, bind a recovery attestation to the exact contract commit, review the bookkeeping-only ledger plan, require exact ledger parity and an empty push plan, then create immutable db-v1.0.0.

[diese-tech]

Follow-up: the candidate now separates database-owned division fixtures from the generated SMITE reference fixture at supabase/seeds/smite2-gods.sql.

• Updated baseline commit: 974e5d241eb1317a06561068026d67d7cddf71da.
• Hosted database CI 29591282259 is green after the split, including clean reset, lint, 30 pgTAP tests, generated-type drift, repository checks, audit, and secret scan.
• diese-tech/smite-content-sync issue DB: add capture-verified v1 production baseline #7 and draft PR DB: add SMITE item catalog as db-v1.1.0 #8 reroute future SAL content PRs from sal-site to sal-database and emit production-compatible god_class values.
• Content-sync CI 29591494991 is green.
• The content sync remains review-only and has no Supabase credential; production promotion still requires a forward database migration and protected release.

Safe merge order: baseline PR #7 first so the target fixture path exists on main, then smite-content-sync PR #8. Production remains unchanged.

[diese-tech]

Baseline repository merge completed without production execution:

• PR DB: add capture-verified v1 production baseline #7 merged as 2a2d4017c7fdf789222b5e7ea449f0045a8dcd42.
• Final main CI 29623608243 passed repository state, secret scan, blank PostgreSQL 17 reset, database lint, 30 pgTAP assertions, contract verification, and generated-type drift.
• No deploy workflow, production push, migration repair, tag, or release was run.
• The current production deploy workflow must remain undispatched until a protected bookkeeping-only baseline-adoption workflow and recovery attestation are bound to this exact v1 commit.

The first additive post-v1 work is isolated and intentionally gated:

• Item database issue DB: add SMITE item catalog as db-v1.1.0 #8 / draft PR DB: add SMITE item catalog as db-v1.1.0 #9.
• Content producer issue diese-tech/smite-content-sync#9 / draft PR diese-tech/smite-content-sync#10.
• Blank reset, lint, all 35 pgTAP assertions, generated types, exporter tests, dependency audits, and hosted secret scans pass.
• These drafts must remain unmerged until v1 production adoption and release are complete.