1.13.0

State migrations

2026-10-02 · #81 · closes #74, #75, #76, #77, #78, #79, #80

State migrations. A Module can be paused, and a paused Module can run jobs that rewrite its state instead of planning and applying it:

• Move, import, remove and lookup addresses - the engine's own state commands, run one address at a time so you can see which worked if some do not.
• Split - a monolith becomes several Modules, each with its own state carved out of the original.
• Transfer - resources move between two existing Modules, each with its own repository, runner and backend. The receiving Module has to agree before anything is written.

Split and transfer are both proved first and pushed only after approval. Set the threshold per Module with state_migration_approval_threshold, or for a whole Namespace with default_state_migration_approval_threshold. It defaults to one rather than zero, because you cannot undo the write.

Fixes. The first message sent on the SQL Server transport could be dropped silently, leaving a job that was created but never started. "Kill current step" ended the job without stopping the command on the runner. A step reply arriving a moment early could be discarded, leaving the job waiting for it forever. The API's default cancellation type did nothing, and is removed - the two the dashboard offers remain.