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
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:
@@ -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`,
|
||||
|
||||
Reference in New Issue
Block a user