Already-broken test

Safe
No supported incompatibility was detected under the conditions tested. This is not a universal safety guarantee.

One v1 test already failed before this migration. It must not be blamed on the migration.

Recorded example: genuine engine output generated Sat, 24 Oct 2026 18:30:01 GMT from the committed fixture. Run it again live below.

Baseline schema
Proposed schema
Previous versionshop-v1-with-broken-test
2/3 test files passSQLSTATE 42703
2/3 test files passSQLSTATE 42703, identical in all 2 runs
Current versionF-preexisting-failure
Not needed: ordinary CI covers this
Not configured

The outlined cell is the compatibility question. The verdict comes only from it, compared against the cell to its left.

Next step

Proceed with normal review. Keep the old application's tests meaningful; SAFE only covers what they exercise.

Starts a throwaway PostgreSQL and runs the full experiment, usually in under 15 seconds.

Evidence

Pre-existing failure test/reports.test.js

Observed
test/reports.test.js fails on the baseline schema and on the proposed schema.
Interpretation
Pre-existing failure; not attributed to the proposed migration and not used as evidence.

Schema changes

All 3 schema change(s) are additive and cannot affect statements the old application issues; no coverage is required.

ChangeRisk to old statementsExercised by previous version
Relation audit_log addedinertNot required
Column customers.loyalty_tier added (text)inertNot required
Index orders_created_at_idx added on ordersinertNot required

Runs

Proposed migration: 002_loyalty.sql · PostgreSQL 16.15 (Debian 16.15-1.pgdg12+2) · gate does not block (exit 0)

RunMigrationsTest filesDatabase errorsStatements logged
control (old app × baseline schema)1/12/3 pass1 (42703)8
candidate #1 (old app × proposed schema)2/22/3 pass1 (42703)8
candidate #2 (old app × proposed schema)2/22/3 pass1 (42703)8

Download this report: JSONMarkdownJUnit XML

What this result does not cover
  • Current application × proposed schema (no current app configured).
  • Performance / lock-time analysis (out of scope).
  • Skewcheck only observes code paths that the old application's tests execute; untested paths are reported as coverage gaps, not as safe.
  • Coverage is identifier-level: a statement "touches" a changed object when it names the table (and column, or uses *). It is not a SQL parser.
  • Correlation between an error and a schema change uses a fixed set of deterministic rules (R1–R6). Anything else is reported as ADVISORY, never UNSAFE.
  • Performance, locking and migration runtime on production-sized data are not evaluated.
  • Test files of one run share a database and run sequentially; ordering effects are identical across runs but are not isolated.
  • Data-only migration effects are detected only when a test asserts on the affected data.