A retired complicacion code makes a practica's post-op section permanently unsaveable, and the error tells the user to retry forever

MEASURED, not inferred, by coder-terra-cc 2026-08-22 by reading the three installed files plus a read-only SELECT of the shipped SQL against the live database. THE CHAIN. practica-postop-form.tsx:48 seeds its checkbox state from initial.complicacionesPost - the codes the practica ACTUALLY HOLDS. Its render loop (line 80) iterates `catalog`, which page.tsx:61 fills from getComplicaciones("post") -> getScopedVocabulary -> resolveScopedVocabulary, which is ACTIVE-AND-IN-SCOPE ONLY. A recorded code that has since retired, or that a vocabularyScopeMembers narrowing has stopped admitting, is therefore IN THE SUBMITTED ARRAY AND HAS NO CONTROL ON SCREEN. It cannot be seen, kept, or removed. Then practica-postop-actions.ts:71 runs POSTOP_VOCAB_CHECK_SQL over the whole submitted array against that same active-only function, and one row aborts the entire request. CONSEQUENCE: the post-operative section of that practica becomes PERMANENTLY UNSAVEABLE. Not a lost edit - every future save fails, including a save that only changes the comentario or ticks "paciente dado de alta". The clinical record is frozen by a catalogue edit made somewhere else entirely. THE ERROR MESSAGE MAKES IT WORSE AND IS THE PART WORTH READING TWICE. actions.ts:74 says "Recargá la página e intentá de nuevo." That sentence is correct for the case it was written for - a stale tab racing a catalogue change. For THIS case it is a lie that costs the user real time: reloading re-reads the same recorded code into the same state and the save fails identically, forever. The instruction sends someone into an unbounded retry loop with no way out and nothing on screen indicating which value is at fault. PROOF THE PREDICATE BITES, run read-only against the live DB rather than asserted: POSTOP_VOCAB_CHECK_SQL verbatim over ARRAY['hematoma','sinusitisMaxilar','__retired_code__'] returned exactly one row, __retired_code__. rowCount > 0 is the abort condition at actions.ts:72. LATENT TODAY, AND THE MEASUREMENT IS THE REASON RATHER THAN AN ASSUMPTION: all 14 terraComplicacionesPost options are currently isActive, undeleted, and visible through resolveScopedVocabulary, so nothing is broken right now. It is NOT hypothetical. terra_35 retired and replaced option rows, and terra_39 measured live categories at 15-of-19, 2-of-4 and 0-of-6 visible - codes absent from the resolver while present in lookupOptions is a shape this project has already produced twice. A scope narrowing alone triggers it; no delete is needed. THIS IS THE WRITE-SIDE HALF OF TERRA-105. That WI fixed the READ side - the detail page now resolves labels through historicalLabel, which is deliberately unfiltered. complicacionesPost was excluded there precisely BECAUSE it feeds this form, and that exclusion is what left the write side unexamined. Same root cause: an ACTIVE-ONLY resolver standing where a HISTORICAL record is being handled. FIX SHAPE, three parts, the first load-bearing: (a) POSTOP_VOCAB_CHECK_SQL must exempt values ALREADY LIVE on this practica, gated by PRACTICA_ACCESS_SQL so the exemption cannot be borrowed from another practica's rows. New values stay gated by the live vocabulary - the guard's actual purpose (no undocumented vocabulary in a clinical table) is preserved exactly. (b) The form must render a control for every value the practica holds, labelled through historicalLabel and marked as retired, so the value is visible and deselectable. Deselecting is a legitimate clinical correction; re-adding after deselection is correctly refused. (c) NO message change needed once (a) lands - and this is the elegant part. After (a) the only way to reach that error is submitting a code that is neither already-live on this practica nor in the catalogue, i.e. a genuine stale-tab race or a tampered payload. "Recargá la página" becomes TRUE. The fix does not paper over the message; it restores the condition the message was written against.