docs(person): note YEAR seeding of legacy precisions in ADR-039
All checks were successful
CI / Unit & Component Tests (pull_request) Successful in 4m47s
CI / OCR Service Tests (pull_request) Successful in 24s
CI / Backend Unit Tests (pull_request) Successful in 5m12s
CI / fail2ban Regex (pull_request) Successful in 52s
CI / Semgrep Security Scan (pull_request) Successful in 28s
CI / Compose Bucket Idempotency (pull_request) Successful in 1m10s

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Marcel
2026-06-12 19:37:11 +02:00
parent 11efb44e7f
commit 2fac687318

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 form to reduce cognitive load for the senior author audience. Legacy `APPROX` rows
still render correctly (display delegates to `formatDocumentDate`). 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 ### 3. Derived-year pattern for backward-compatible DTOs
`PersonNodeDTO` (Stammbaum) and `RelationshipDTO` keep `Integer birthYear/deathYear`, `PersonNodeDTO` (Stammbaum) and `RelationshipDTO` keep `Integer birthYear/deathYear`,