#260 fix(migrations): revert #250 header edits that broke sqlx checksums

[Anonymous]

Originally created by: Akarsh-Hegde

The bug

Every existing user's daemon crash-loops on upgrade to any build containing [#250], with:

Caused by:
    migration 1 was previously applied but has been modified
Error: failed to run migrations

(Reported live by a user upgrading 1.43.0 → 1.46.0 — the daemon showed "loaded but not running" and the log repeated meridian daemon starting every ~30s as launchd restarted it.)

Root cause

sqlx records a SHA-384 checksum of each migration's bytes in _sqlx_migrations when it's applied, and re-validates every checksum on startup — this is its tamper-detection for already-applied migrations.

PR #250 ("chore: update file headers… tagline", 64a9aa3) rewrote line 1 of all 34 shipped migrations (001–034):

--- meridian — normalises screenpipe activity into structured app sessions
+-- ambient dev tool that watches what you do and updates your PM tickets… productivity

Only a comment changed — no schema — but sqlx hashes the whole file, so the checksum of every migration changed. Existing DBs recorded the old checksums; the new binary ships the new files → mismatch → migrations abort → daemon panics before the poll loop → crash-loop. This hits everyone, not one machine.

Fix

Restore migrations 001–034 to their exact pre-#250 bytes (verified header-line-only: each file is 1+/1-, zero schema bytes touched) so they match what every existing database recorded. Keep [#250]'s .rs/.ts/.sh header changes — those aren't checksum-validated, so they're harmless.

Also add a CLAUDE.md carve-out so the file-header rule and sqlx immutability stop colliding: the header applies to a migration only at creation; shipped migrations are frozen and must never be re-headered.

Why reverting is safe (not the same mistake in reverse)

The restored bytes are the ones stable across all releases 1.0–1.45 — i.e. what virtually every existing DB checksummed. [#250] landed only hours before this, so the cohort that recorded the new checksums (a fresh install of a post-#250 build) is essentially empty; for any such case the same checksum-repair applies.

Verification

• git diff --numstat on all 34 files: every change is exactly 1+/1- (header line only).
• Restored line 1 confirmed back to -- meridian — normalises screenpipe activity into structured app sessions.
• No schema, no SQL statements altered.

Immediate user remediation (until this ships)

For a user already stuck, the schema is intact, so realign the stored checksums (back up meridian.db first), then restart the daemon — or, as a last resort, move meridian.db aside and let it rebuild from screenpipe.

https://claude.ai/code/session_013mv3epyceLahz9Cue1mtPj

---

Generated by Claude Code

[Anonymous]

Ticket changed by: Akarsh-Hegde

• status: open --> closed

[Anonymous]

Originally posted by: adityaharishch

🎉 This PR is included in version 1.48.1 🎉

The release is available on:

• GitHub release
• v1.48.1
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀