Files
HealthLog/prisma
Marc-André Bombeck 985e197db4 feat(cycle): user-defined custom symptoms
Mirror the v1.13 custom-mood-tag CRUD for cycle symptoms. A user can mint
their own symptoms beyond the 15 seeded ones, picked from a label + icon
popover via a dashed ghost-chip in the log-day sheet's symptom grid.

- POST/GET /api/cycle/symptoms/custom and PATCH/DELETE on /[key]: mint a
  custom:<uuid> key, encrypt the free-text label at rest (AES-256-GCM),
  per-user cap, owner-scoped, gated behind requireCycleEnabled. Soft-hide by
  default, hard-purge on ?purge=true.
- The day-log write already resolves a symptom key against the catalogue plus
  the caller's own rows, so a custom: key links by construction.
- The log-day sheet fetches the user's customs and merges them under a new
  custom category in the chip grid; the ghost-chip + popover reuse the chip
  styling and the Lucide icon set.
- Seed the global custom symptom category (migration 0134).
- The purge route (DELETE /api/cycle/all) now drops the user's custom symptom
  rows too, so no intent-revealing label survives a purge.
- The label is never logged: only the icon + counts reach annotate/auditLog.
- i18n: cycle.symptom.custom.* across all six locales.
2026-06-06 16:54:43 +02:00
..

prisma/

The database layer. HealthLog runs PostgreSQL 16 via Prisma 7. This directory holds the single schema file and the forward-only migration history; the generated client is emitted elsewhere.

Contents

  • schema.prisma — 61 models, one file. cuid() primary keys, snake_case columns via @map(...), encrypted columns mostly suffixed *Encrypted (search the file; there are 24 encrypted column references). The generator client block emits to ../src/generated/prisma (imported as @/generated/prisma).
  • migrations/ — numbered, forward-only SQL migrations (0001_… upward). migration_lock.toml pins the provider to postgresql.

Migration workflow

# author a migration from a schema edit
pnpm dlx prisma migrate dev --name <short_snake_case_name>

# regenerate the client after any schema change
pnpm dlx prisma generate

Number a new migration with the next free prefix. The production entrypoint runs prisma migrate deploy on boot, so every migration must apply cleanly forward — there is no down-migration path. Always include the migration file in the same change as the schema edit.

Conventions

  • Encryption is fail-closed: *Encrypted columns are written through @/lib/crypto (AES-256-GCM, versioned key ids); never store plaintext in an encrypted column. Key rotation is scripts/rotate-encryption-key.ts + docs/ops/encryption-key-rotation.md.
  • The generated client under src/generated/prisma is build output — do not edit it.
  • Schema-touching changes that affect the API surface must regenerate docs/api/openapi.yaml (see ../CLAUDE.md).

Related: ../src/lib/README.md (db.ts, rollups/), ../docs/ops/ (migrations + backup runbooks).