codeSplitters live deploys: Alchemy state is per-worktree, and D1 has two migration ledgers #294

Found while deploying the live site for #216 (2026-10-10).

1. Deploy state lives in one worktree and vanishes with it. targets.edge.adopt keeps Alchemy state in apps/codesplitters/.alchemy/state, which is gitignored and per checkout. The #170 deploy's worktree is gone, so this deploy started from nothing: plan said [Worker] create for the live Worker. It was safe, because AdoptPolicy.adopt(true) took the existing Worker over ("precreate: reusing existing codesplitters"), but the plan reads like a fresh install and any resource without adopt would really be duplicated. Options: keep state somewhere shared (Alchemy's Cloudflare state store, or a path outside the worktree), or have plan say "adopting" when adopt is on.

2. Two migration ledgers in the live D1. Wrangler applied 0001–0009 into d1_migrations; Alchemy has applied everything since into __alchemy_migrations (18 rows). So wrangler d1 migrations list codesplitters-db --remote lists 0010–0020 as pending although they're all applied, and running wrangler d1 migrations apply would try them again and fail. Either backfill d1_migrations, or document in the codeSplitters README that __alchemy_migrations is the one that counts and never to apply with wrangler.

🤖 Generated with Claude Code