Bake one SS migration against the live working DB. Pure of file I/O — caller writes pgSQL.
Leaves the working DB current for the next migration in the sequence.
RE-BAKE mode (committedPgSql provided): advance the working DB by applying the known-good
committed .pg.sql (balanced DROP+CREATE keeps dependent views consistent and registers new
entities), then capture native CodeGen READ-ONLY. A transpile gap (unhandled statement or
hand-procedural routine) makes an auto-bake incomplete, so the committed file is preserved
(mode: 'preserved'). This is the robust path for re-baking the committed post-baseline set.
FORWARD mode (no committedPgSql): apply the transpiled hand body and execute the capture.
Known limitation — a new-entity migration's ALTER COLUMN preamble CASCADE-drops dependent
metadata views (e.g. vwApplicationSettings) that per-entity capture doesn't restore, which
corrupts the metadata load mid-sequence; prefer the re-bake path for a full set.
BASELINE mode (fileName is a B… baseline): a baseline is a full from-scratch snapshot with
NO CodeGen banners, so the banner-derived affectedEntities is empty and the "apply the hand
body then capture" flow can't bootstrap (the metadata views the provider reads don't exist on
an empty DB). Instead the working DB is PRE-SEEDED to the baseline end-state by the caller
(v5.x baseline + AST-transpiled deltas → all metadata views present), so we DON'T re-apply the
hand body (its tables already exist) — we capture native CodeGen for the FULL entity set and
pair it with the file's transpiled hand body. The 5 hand utility functions still surface as
gaps (needs-hand-authoring); they aren't referenced by base views/sprocs, so the capture is
complete regardless and the caller authors them into the final .pg.sql.
Bake one SS migration against the live working DB. Pure of file I/O — caller writes
pgSQL. Leaves the working DB current for the next migration in the sequence.RE-BAKE mode (
committedPgSqlprovided): advance the working DB by applying the known-good committed.pg.sql(balanced DROP+CREATE keeps dependent views consistent and registers new entities), then capture native CodeGen READ-ONLY. A transpile gap (unhandled statement or hand-procedural routine) makes an auto-bake incomplete, so the committed file is preserved (mode: 'preserved'). This is the robust path for re-baking the committed post-baseline set.FORWARD mode (no
committedPgSql): apply the transpiled hand body and execute the capture. Known limitation — a new-entity migration'sALTER COLUMNpreamble CASCADE-drops dependent metadata views (e.g.vwApplicationSettings) that per-entity capture doesn't restore, which corrupts the metadata load mid-sequence; prefer the re-bake path for a full set.BASELINE mode (
fileNameis aB…baseline): a baseline is a full from-scratch snapshot with NO CodeGen banners, so the banner-derivedaffectedEntitiesis empty and the "apply the hand body then capture" flow can't bootstrap (the metadata views the provider reads don't exist on an empty DB). Instead the working DB is PRE-SEEDED to the baseline end-state by the caller (v5.x baseline + AST-transpiled deltas → all metadata views present), so we DON'T re-apply the hand body (its tables already exist) — we capture native CodeGen for the FULL entity set and pair it with the file's transpiled hand body. The 5 hand utility functions still surface as gaps (needs-hand-authoring); they aren't referenced by base views/sprocs, so the capture is complete regardless and the caller authors them into the final.pg.sql.