Files
HealthLog/prisma
Marc-André BombeckandClaude Opus 4.8 f1329b24e1 chore(release): v1.13.0 — per-user custom mood tags + catalogue hide
Let a user shape their own mood-tag set on top of the global catalogue:
create custom tags (label encrypted at rest, icon from a fixed allow-list),
and hide built-in tags per user. Custom tags live in `mood_tags` with a
non-null `user_id` and a `custom:<uuid>` key; `GET /api/mood/tags` returns
the effective per-user set (catalogue − hidden + own customs) with new
`custom` + `label` fields, and `?include=hidden` surfaces hidden catalogue
tags for the management screen. The write path resolves a `custom:` key only
against the caller's own rows — a foreign custom key is dropped, never linked.
Delete soft-deactivates by default (history intact); `?purge=true` removes
the row and its links. BINARY-only for v1.

New: POST/PATCH/DELETE /api/mood/tags/custom[/:key], PUT /api/mood/tags/:key/hidden,
migration 0127 (user_id + label_encrypted columns, mood_tag_hidden table,
`custom` category). Integration setup snapshots + restores the seeded catalogue
because the new mood_tags→users FK makes TRUNCATE users CASCADE wipe it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-05 20:50:05 +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).