Development

A Migration Plan You Can Read Before It Runs

ForgeSchema now turns the difference between an observed schema and a desired schema into a reviewable plan. The artifact contains both complete descriptions, their fingerprints, explicit rename instructions and an ordered set of generated statements. It is deterministic: the same supported inputs produce the same plan.

Rename intent is the key distinction. Removing customer_name and adding full_name does not prove that the two columns hold the same information. A separate mapping tells the planner that this is a rename, allowing it to account for the existing key and index references that PostgreSQL updates along with the column. Without that instruction, the destructive interpretation is blocked.

The initial operation set is deliberately small: create tables, rename columns, add nullable columns and add ordinary indexes. A proposal containing an unsupported change receives reasons and no operations at all. The planner does not offer a tempting fragment that could leave half of the requested change applied.

Tests go beyond checking statement text. The live PostgreSQL harness executes generated SQL, reinspects the result and checks that original rows retain their values after the rename and additions. The product itself still has no execution command. That next step will need to establish that the database still matches the reviewed plan, then coordinate and execute the change as a controlled transaction.