Release v0.1.2 — migration safety

[JasonZQH]

Promotes dev to main for the v0.1.2 cut.

What ships

The ledger is backed up before a schema migration (#42). Opening .curator/ with a newer Curator applies pending migrations automatically — initialize_database has ~114 call sites, so effectively any command migrates. It now copies the ledger to .curator/archive/…-pre-migration.sqlite first, using SQLite's online backup API rather than a file copy: the ledger runs in WAL mode, and a copy of the main file alone can miss committed pages still in the -wal. Verified rather than assumed — a file copy of a freshly written ledger cannot even see the table. A ledger with nothing to migrate, the usual case, is not copied.

Migrations are all-or-nothing (#42). They used to commit one at a time, so a failure on the third left the first two applied and the ledger in a state no version of Curator is written to read — and because the version was never recorded, the next open would retry and fail on duplicate column name, permanently. They now share one transaction and roll back together, DDL included.

curator doctor shows what is pending, and how to get back (#42). It reports migrations without applying them — doctor only ever uses connect_database, never initialize_database, so it is a dry run by construction rather than by a flag. It also prints the newest backup with a ready-to-paste restore command, found by reading the directory rather than the ledger, so it still answers when the ledger will not open.

A half-written backup is never offered as a restore point (#43). Found reviewing #42. sqlite3.connect creates the destination before the copy runs, so a backup interrupted by a full disk or a killed process left a 0-byte file carrying the real name — which, being newest, became what doctor advertised. Copying that over a live ledger destroys it. Backups are now written to a .partial name the restore path ignores and renamed into place only once complete.

Version

pyproject.toml and curator.__version__ both move to 0.1.2; the drift test added in v0.1.1 fails if only one moves. README pins and the version table point at v0.1.2.

Verification

• 383 passing on CI across 3.11/3.12, plus macOS smoke and the state/mock-provider guard.
• Both the atomicity test and the two backup regression tests were confirmed to fail without their fixes, by reverting the source and re-running.
• A real v0.1.0 ledger, built by v0.1.0's own code at that tag, opens under this branch with no migrations and no backup (correct — v0.1.0 already carried migrations 1 and 2). Injecting a v0.1.4-shaped migration produces a backup that opens cleanly and still reads schema_version [1, 2].
• A five-dimension review of feat(state): back up the ledger before migrating it, and migrate atomically #42 surfaced the fix(state): never offer a half-written backup as a restore point #43 defect; the other four dimensions returned no findings.

After merge

1. git tag -a v0.1.2 -m "Curator v0.1.2" && git push origin v0.1.2 — fires release-smoke, which builds, clean-installs the wheel and sdist, and publishes them with SHA256SUMS.
2. gh release create v0.1.2 from the CHANGELOG entry.
3. The Dependabot grouping and target-branch: dev config from v0.1.1 finally takes effect, since Dependabot reads it from the default branch. chore(deps-dev): bump ruff from 0.15.19 to 0.16.0 #33 also unblocks once the Ruff pin reaches main.

🤖 Generated with Claude Code