Checking the Database Without Changing It

ForgeSchema now has an independent verify command. It compares a live PostgreSQL schema with a desired schema file or a reviewed plan’s target, then reports a match or structured drift. It reads catalog metadata in a read-only snapshot and makes no repairs.

That distinction matters after deployment. A database may have reached the expected structure and then changed again. Verification identifies missing or unexpected objects, type and nullability changes, and ordered key or index differences. It does not guess that two different column names represent a rename, and it does not turn a difference into executable SQL.

The new end-to-end test takes a populated customer database through inspect, plan, apply and verify using the actual CLI. Six supported operations create a table, rename columns, add a nullable field and create indexes. Original customer values survive. A later unexpected column produces a drift report while history and data remain untouched by verification.

The failure tests also reach an awkward but important case: application DDL succeeds and target verification passes, but writing migration history fails. The transaction rolls back the application change rather than leaving an unrecorded migration committed. Cancellation, statement timeout and metadata bootstrap failures receive similar checks against PostgreSQL 16.10 and 17.6.

The final checkpoint is a reproducible walkthrough and handoff. The implementation is still a limited prototype; a structural match does not certify application data or resolve every possible uncertain commit outcome.