Rehearsal: test the whole rollout

A database migration can succeed while a rolling deployment breaks. New application instances read the renamed column; older instances still use its previous name. A smoke test that exercises only the new version misses that failure. Application rollback becomes harder once the new version has written data. Rehearsal gives developers a repeatable way to inspect this gap before merging a migration. Choose an original synthetic orders scenario, edit the SQL, and run it in a fresh PostgreSQL/PGlite database. Five stages check the original contract, migration execution, the new-version smoke test, mixed old/new writes, and application rollback with the migrated schema retained. Expand any assertion to see the exact SQL, expected rows, actual rows, or database error. Export the report as JSON. The same engine runs behind a local MCP server in IBM Bob IDE. Bob can inspect the contracts, execute a candidate, diagnose failures, write a repair, and rerun unchanged assertions. In the demonstrated rename scenario, the original passes its new-version smoke test but fails seven of thirteen checks. Bob's independent repair passes all thirteen. The public demo includes that actual candidate separately from the supplied reference example. The workflow replaces manual switching between query snippets, migration reasoning, and test output with one executable feedback loop. Developers remain responsible for defining adequate contracts. Three scenarios cover a column rename, a required field, and a money-column conversion. This prototype uses sequential SQL contracts and synthetic records. It does not test concurrent clients, locks, replicas, or real application binaries, and it does not certify production safety. We report executed check counts rather than unmeasured time savings. Next validation is project-defined contracts and native PostgreSQL concurrency tests.