Kristian WindandClaude Opus 5
726a489a67
Release / Build and publish image (push) Failing after 10m0s
The note on 0009 and 0012 said the drop would cascade and take every row with it. It would not: nothing references `activity` or `attachments`, so dropping either takes nothing along. That claim was carried over from 0008, where seven tables do reference `tasks` and it is exactly right. The real reason is the check that comes with the marker. With foreign keys on, the copy is validated a row at a time against a half-rebuilt schema, and the first bad row aborts with no idea how many others are like it. With them off, `PRAGMA foreign_key_check` runs once before the commit and names what is actually wrong — which matters, because these run against a live database on somebody's next restart and a failed migration is a server that does not start. The upgrade test now carries activity rows, an attachment and a group across all five migrations rather than stopping at 0008, and checks that the columns added by ALTER arrived with their defaults rather than as NULL. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>