marcel/familienarchiv
1
0
Fork 0
Code Issues 118 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
1 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/adr/039-person-life-dates-localdate-precision.md
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`,