Executing the Reviewed Plan as One Transaction

ForgeSchema can now execute a reviewed migration artifact. The new apply command does not recalculate the desired migration against whatever it happens to find. It validates the saved plan, freezes a private copy and checks that the live database still matches the source the reviewer saw.

The order of that check is important. Another transaction may hold a table lock while changing its structure. ForgeSchema waits for the locks first, then reads fresh catalog metadata before deciding whether the reviewed starting conditions still hold. The tests include exactly that case: an outside transaction commits a change during the wait, and the stale plan is rejected.

Supported statements, target verification and migration history are committed together. Tests against PostgreSQL 16.10 and 17.6 cover competing runs, timeouts, SQL failure rollback, target mismatch rollback and modified metadata rejection. The bookkeeping table lives in a separate reserved schema, so it does not quietly disappear from the application schema’s fingerprint.

There are limits. Existing-table locks do not prevent every new object another tool might create in the schema, so external DDL must be paused. A connection error during commit can also leave the outcome uncertain. ForgeSchema reports that distinction and returns identifiers for checking history; it does not promise a rollback it could not confirm.

The next checkpoint is an independent verification command. Apply already verifies its own target before commit, but operators also need a straightforward way to check the database later, without changing it.