An operator holding a font licence could only use it by baking the file
into a custom image, which tied every change to a rebuild and left the
file out of the backup.
ADR 0016 said there is no runtime font management. It also listed this
exact case under "Alternatives considered" — *may become a Site-Admin-
level feature later*. The amendment takes that option and answers the two
objections it raised: licensing risk (Site Admins only, licence recorded
with the family) and file-format attack surface (magic-byte check and a
size cap, never a parse).
- `CUSTOM_FONTS_DIR` (default `./data/fonts`) — a sibling of uploads and
plugins, NOT inside the image-baked `FONTS_DIR`, where a deploy would
overwrite it and no backup would ever see it.
- One list of data directories (`apps/backup/src/data-dirs.ts`) now feeds
both the nightly archive and the restore, so they cannot drift. #306 and
#307 add one line each instead of a second mechanism.
- Both Dockerfiles bake the path. The backup image sets its volume paths
itself ("self-sufficient without compose env" — #71's lesson) and reads
no *_DIR from compose; without the ENV entry the archive would have
skipped the directory silently.
- The PDF path already read WOFF2 from disk at request time, so it only
had to pick the other base directory for a custom family.
- `fontStack`/`fontEntry` take the instance's uploaded families as an
argument — they are runtime data. The catalog is searched first, and a
colliding family name is rejected at upload, so a custom font can never
shadow a catalog one.
- Deletion is never blocked by usage: an unknown family already falls back
to the system stack, so affected ponds degrade instead of breaking. The
count of affected ponds travels into the audit entry.
- Audit catalogue v1.6 (`font.uploaded`, `font.deleted`).
Verified: api full suite against a fresh database, 102 files / 571 tests.
The upload suite writes into a real temp directory and reads the bytes
back off disk, so the storage layer is exercised rather than mocked.
Initial deliverable of the architecture phase: 16 ADRs (stack, CRDT
collaboration, plugin sandbox, import/export, backups, CI/CD), data
model, permission model, real-time collaboration and plugin concepts,
deployment/operations/security documentation, and the milestone roadmap
that the implementation issues are derived from.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
