docs: record that a prosthesis dictation reaches teeth only through the merged row

Decision 39 couples teeth and jobs on a lab-dependent type, so unticking the
merged row and then the type row applies a detail with no teeth at all. master
kept them, because the rows were separate. Approved as an accepted consequence
rather than patched, since applying teeth the clinician just unticked would
break the sheet-is-a-contract rule.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-09-07 13:20:00 +08:00
parent ebfc8af87c
commit c1d3a241a5

View File

@@ -691,6 +691,18 @@ other type keeps a plain teeth row and has no prosthesis row at all. The merged
The chart catches a misheard tooth number at a glance; the list confirms the material. Either
one alone is the weaker check.
> **Accepted consequence:** on a prosthesis dictation the teeth are reachable only through this
> row. `voiceRowAvailability` sets `teeth: false` for a lab-dependent result, so no plain teeth
> row exists and `selection.teeth` never becomes true. Untick the merged row — which releases the
> decision-41 lock — then untick the type row, and the detail applies with no teeth at all.
> `master` kept them, because the rows were separate.
>
> This is decision 39 doing what it was chosen for, and it follows from *the sheet is a contract*
> below: the row that displayed those teeth was unticked, so applying them anyway would apply
> something the clinician refused. The cost is real and accepted — a clinician who wants only the
> teeth from a prosthesis dictation, intending to pick materials by hand, has to tap them in. If
> that turns out to matter in use, the fix is a spec change, not a patch.
### The sheet previews the stack that will actually land
The merged row builds its preview through `applyLeafToJobs` — the same function the manual