terraCirugias is deliberately unguarded as 'vocabulary, not clinical record' - TERRA-52 makes it carry a client decision and falsifies that premise

MEASURED LIVE by db-terra-cc 2026-08-16 (pg_trigger on public.terraCirugias, catalog read not repo grep): exactly ONE trigger exists - trg_terraCirugias_forbidTruncate (STATEMENT/BEFORE/TRUNCATE, tgenabled='A'). No archive trigger, no forbidHardDelete, no update guard. A plain DELETE on this table succeeds outright; a plain UPDATE overwrites content with zero trace. TERRA-28's remedy migrations terra_21 and terra_22 contain zero occurrences of terraCirugias - that row never reached this table, and its closure is not evidence it did. Compare terraPracticas: 4 triggers (archive + forbidHardDelete + forbidTruncate + practicaNumberImmutable). THIS IS NOT A MISSED GUARD. IT IS A DELIBERATE EXCLUSION WHOSE PREMISE IS EXPIRING. terra_13 COVERAGE LIMITS item 3 excludes terraCirugias and terraModulos on a stated rationale: vocabulary/lookup, not clinical record, soft-deletable via deletedAt, TRUNCATE-guarded only. That was CORRECT WHEN WRITTEN and was verified deliberately, by a rolled-back INSERT+DELETE probe recorded as expected-absence rather than defect. Nothing was overlooked. WHAT FALSIFIES IT: TERRA-52 makes terraCirugias the carrier of a CLIENT DECISION - isConfirmedByClient, written by the client, with an unconfirm reason code. TERRA-55 surfaces those reasons to staff; TERRA-56 is the correct-or-retire capability they imply. A row holding a client's decision is not vocabulary. Deleting it erases a decision and a plain UPDATE erases the fact that it was ever made, with the appEvents trail intact and the row's own state silently disagreeing with it. DELIVERABLE, IN ORDER: (1) re-decide the terra_13 item-3 classification for terraCirugias specifically - terraModulos may well still be vocabulary and this row does not assume otherwise; (2) if it is no longer vocabulary, the guard set it needs, which is a migration and therefore its own row per the standing framing; (3) whichever way it goes, terra_13's COVERAGE LIMITS text gets corrected where it is written, because the next reader inherits the old rationale and the rationale is the part that changed. CLOSE CONDITION AND TIMING: nothing is lost today - 35 cirugias, 0 confirmadas, and no client can confirm until TERRA-52 ships. The exposure begins at TERRA-52's first real confirmation. P2 not P1 for that reason; do not let it slide past TERRA-52 going live. THE TRANSFERABLE PART, worth more than the instance: a coverage exclusion carries a RATIONALE, and a rationale is a claim about the data that can be falsified by a feature shipped later in a different lane. Nothing re-checks it - the exclusion reads as settled, the probe that confirmed it stays green, and the scope change happens somewhere that never mentions the table's classification. The tell here was a feature adding a WRITER to a table someone had classified as read-mostly vocabulary.