Yes, turri will generate migrations with every change, so if you need to deploy a new version it will check against the current schema and generate it properly.

Honestly, I haven't used it on some reasonable scale to fell the real issues of migrations yet. I consider this to be one of the biggest problems with the approach, but I think it's addressable.

I went the other way: I do not generate code from scratch. In my workflow, the specification sis the source of truth. Every change goes in as a change request that becomes new tasks in the plan. Instead of recreating code, the agent modifies existing code. Migrations are strictly additive. Every schema change results in a new file, leaving previous files untouched. Each migration is backward-compatible. Destructive operations, such as DROP commands, are isolated into a separate, subsequent phase that I personally review.

The largest project I’ve managed this way has been in production for about six months and has already gone through 45 versions. So far I haven't had encountered no no data loss so far”.

Renaming is where I would be wary of generating code from scratch. Based solely on a schema diff, a rename appears as the deletion of one element followed by the addition of a new one. Does turri ask about what you meant in such cases, or is there a way to specify this directly within the specification?