Personal product domain
When to update: Personal app scaffolding, auth changes, or new personal-only data stores.
Purpose
Section titled “Purpose”The personal product line covers individual life management: vehicles, finance, fitness, and journaling. It runs on the personal isolation plane — separate Worker, D1, R2, KV, and auth from business.
Does not own
Section titled “Does not own”- Business organizations, invoicing, payroll, or scheduling
- Shared auth with business or marketing
- TigerBeetle or ledger transfers
- Enterprise tenant provisioning (Workers for Platforms)
Key paths
Section titled “Key paths”| Area | Path | Status |
|---|---|---|
| Web SPA | apps/personal-web/ | Auth UI, protected routes |
| API Worker | apps/personal-api/ | Magic-link auth, sessions, GET /me |
| Auth modules | apps/personal-api/src/auth/ | Sessions, magic links, middleware |
| Crypto package | packages/crypto/ | Versioned algorithms; PQC via mlkem-wasm |
| Migrations | apps/personal-api/db/migrations/ | users, sessions, magic_link_tokens |
packages/crypto/ | Plane-agnostic crypto agility (hash, AEAD, ML-KEM, session HMAC) | |
packages/ui/ | App shell, nav, core components |
Data model (planned)
Section titled “Data model (planned)”Personal D1 (personal-db): users (plaintext + encrypted email columns during migration), sessions, magic_link_tokens, vehicles, finance accounts/transactions, fitness workouts, journal entries. Attachments in R2 (personal-assets).
Session cache, magic-link rate limits, and ML-KEM keypair cache use KV (personal-sessions).
Every query is scoped by user_id (single-user tenancy).
Invariants
Section titled “Invariants”- Never read or write business D1, R2, KV, or auth secrets
- Session cookies use personal-specific names on
personal.*subdomains - No
org_id— personal data is user-scoped only
Related ADRs
Section titled “Related ADRs”References
Section titled “References”- Personal app help — end-user documentation
- ARCHITECTURE.md — Personal data model