Historical workflow: failing rename → one-file additive repair → unchanged CI → draft review gate. MRs merged 25 Oct.
Synthetic SQLite 7/12 → 12/12, with pinned GitLab pipeline IDs. Historical review state; no production validation claimed.
Real public browser run: bundled recovery fixture, 12/12 synthetic SQLite checks; separate from native Duo.
Real authenticated GitLab Duo session: recorded SQL edit command. Public one-file diff and CI links are in the story.
Live deployed demo: 12/12 synthetic SQLite checks after the bundled repair fixture. GitLab Duo repair is separate.

Inspiration

A green build for a new application does not answer the question I care about before a database release: will the previous application still work after the schema changes? Old and new instances can coexist during a rolling release. If the application is rolled back, old code meets a database the new code may already have written. Rehearsal makes that path back inspectable before a person accepts a migration. This is my design motivation, not a claim that I experienced a production outage.

Try it in one minute

Open the public browser demo. Keep Breaking rename selected and press Run rehearsal. Open Inspect the failed first attempt: the new adapter passes, but the previous adapter cannot read or write the renamed column, and the application rollback check fails. The dashboard then selects a known bundled repair fixture and verifies the compatible shape at 12/12. Download the JSON receipt to inspect each check. This fixed browser scenario is separate from the recorded GitLab Duo repair.

What it does

Rehearsal executes a proposed SQL migration against a fresh, disposable SQLite database with fictional customers. It tests two versioned SQL adapters before and after migration, including writes by one version that the other must read. It then reverts the application to the previous adapter on the migrated database; it does not run a down migration.

The original candidate renamed customers.name to display_name. Its new-version path passed, while five old-version, cross-version and rollback checks failed: 7 pass / 5 fail. The repaired candidate retained name, added and backfilled display_name, and used three synchronization triggers while both adapters coexist. The unchanged candidate contract then passed 12/12. A separate prohibited-change scenario demonstrates the policy block.

How I built and verified it

The evaluator and browser service use Python's standard library and SQLite. GitLab CI validates configuration, runs 21 unit and HTTP tests, executes the fixed scenarios, checks the candidate contract, and packages source only after the required jobs pass.

The original GitLab pipeline preserves the red candidate gate and blocked package job. GitLab Duo Agent Platform's foundational developer/v1 Developer Flow investigated that failure. Its public workload job records a successful run; the full native session and workload trace may require GitLab access. The trace shows it reading a prewritten safe expansion example, changing fixtures/candidate.sql, pushing the repair branch and opening MR !2. This was a reference-assisted repair, not a blind invention or an execution of my prepared custom YAML.

The pinned base-to-repair comparison changes one SQL file. The evaluator, tests and CI configuration were not weakened in that repair. The independent repair pipeline passed all five jobs and reported 12/12 contract checks. A person controlled integration; MRs !1–!3 later merged into the public MIT-licensed Showcase source. Passing CI alone was not human approval.

What I learned and what comes next

The key lesson is to test the old adapter after the new one writes, not just whether the new app reads migrated rows. The preserved red result, exact one-file diff and green CI make the repair reviewable. The 2:11 public video opens with a continuous real browser run, then shows the separate Duo and CI evidence. The refined Render demo is deployed from merged Showcase main.

This is Path B / Bring Your Own: Supervised. The original MIT repository preserves the pre-repair baseline; Showcase contains the later automation evidence and merged repair. The demo uses sequential adapters and synthetic SQLite rows. It does not establish concurrent-client behavior, PostgreSQL safety, production traffic, database restoration or a custom Duo flow. No production migration is claimed. Earlier source/import/repair commits lack recognized DCO sign-off trailers in GitLab; I do not claim project-wide DCO compliance while that record remains unresolved.