cf-email

Multi-brand email system for Cloudflare Workers + D1 + Resend.

Extracted from the LBA Platform monorepo so it can be reused for new brands on separate Cloudflare accounts while keeping a single source of truth for updates.

Status: Phase 0 — safety-first scaffold. Code is mirrored from platform/main/email/; the existing Platform install is unchanged. See docs/plans/cf-email-extraction-plan.md in the Platform monorepo for the full roadmap.

Layout (Phase 0)

cf-email/main/
├── lib/          # Email service primitives (brand, db, resend, templates, tokens, validation, ...)
├── migrations/   # 14 D1 migrations (001 → 014)
├── tests/        # 24 vitest files (Miniflare + better-sqlite3)
├── package.json
├── tsconfig.json
└── vitest.config.ts

Quick Commands

npm install
npm run typecheck                    # all lib/ files type-clean
npm test                             # standalone tests (excludes worker-dependent suites)
npm run test:integration             # will fail in Phase 0 — needs workers/ (Phase 2)

Roadmap

• Phase 0 (now): standalone scaffold; lib + migrations + tests copied, standalone tests green.
• Phase 1: publish @littlebearapps/cf-email privately; LBA Platform switches email/lib/ imports to package imports; behaviour identical.
• Phase 2: thin Platform's email/workers/*.ts into ~10-line factory calls around package-owned createEmailApiWorker() etc.
• Phase 3: extract healthcheck primitives (account-agnostic, no cf-monitor coupling).
• Phase 4: create cf-email-template and deploy on a second CF account for a new brand.
• Phase 5: documented npm update flow for ongoing updates.

Source of truth

While the package is published, all behavioural changes must be made here and pulled into Platform via npm update @littlebearapps/cf-email. Direct edits to platform/main/email/lib/ after Phase 1 will be lost (the directory will be deleted).