docs(person): note YEAR seeding of legacy precisions in ADR-039
Some checks failed
CI / Unit & Component Tests (push) Failing after 4m25s
CI / OCR Service Tests (push) Successful in 24s
CI / Backend Unit Tests (push) Successful in 5m30s
CI / fail2ban Regex (push) Successful in 45s
CI / Semgrep Security Scan (push) Successful in 27s
CI / Compose Bucket Idempotency (push) Successful in 1m9s

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit was merged in pull request #812.
This commit is contained in:
Marcel
2026-06-12 19:37:11 +02:00
committed by marcel
parent ad344db2bf
commit 75e48f2922

View File

@@ -45,6 +45,13 @@ are semantically nonsensical for a birth or death, and `APPROX` is excluded from
form to reduce cognitive load for the senior author audience. Legacy `APPROX` rows
still render correctly (display delegates to `formatDocumentDate`).
The edit form seeds a stored non-offered precision (`APPROX`/`SEASON`/`RANGE`) into
the select as `YEAR`, so an untouched save coerces it to `YEAR` ("ca. 1944" becomes
"1944"). Accepted: nothing currently writes those precisions to persons (the form
offers DAY/MONTH/YEAR, the importer writes YEAR/UNKNOWN, V76 backfills YEAR), so the
case is only reachable via direct API writes — and seeding `YEAR` is strictly safer
than the alternative of silently claiming `DAY` precision.
### 3. Derived-year pattern for backward-compatible DTOs
`PersonNodeDTO` (Stammbaum) and `RelationshipDTO` keep `Integer birthYear/deathYear`,