Release workflow · PostgreSQL · IBM Bob 2.0
Catch the migration that locks production — before you ship it.
A one-line CREATE INDEX can block every write to a 42-million-row table for minutes. Diffs don't show it. LockSmith measures it, explains it, and has IBM Bob rewrite it into a zero-downtime sequence you can verify.
How it works
Detect
12 deterministic rules read every statement in db/migrations — non-concurrent indexes, NOT NULL adds, type changes, validated constraints, renames still referenced by code.
Prove
Each statement is replayed inside a real embedded PostgreSQL (PGlite). LockSmith reads pg_locks and relfilenode to record the lock actually taken and whether the table is rewritten.
Rewrite with IBM Bob
A custom Bob mode, migration-surgeon, turns each flagged migration into a safe expand → backfill → contract sequence — one Bob subagent per migration, in parallel.
Re-verify & gate
Bob's rewrite goes back through the same engine and lock probe. The CLI exits non-zero while any critical finding remains, so CI blocks the unsafe deploy.
Why this workflow
Schema changes ship through the same pull-request review as application code, but their risk depends on Postgres lock semantics and table size — knowledge most reviewers don't carry in their head. The safe rewrite is tedious, error-prone senior-engineer work. LockSmith turns that review into a measured, repeatable gate and hands the rewrite to IBM Bob.