scoped vocabularies: inserting a lookupOption does NOT make it visible, and both terra_35 and terra_38 shipped green while invisible
The form reads resolveScopedVocabulary, which filters lookupOptions through vocabularyScopes/vocabularyScopeMembers. Retiring a row and inserting its replacement leaves the include-set pointing at dead codes. MEASURED 2026-08-22: terraMarcaImplante 15 visible of 19 (terra_35's four client-named brands absent), terraTipoInjerto 2 of 4, terraZonaDadora 0 of 6 (field empty), the two new barrera categories fine ONLY because a missing scope row means default-open. Both migrations were verified by counting lookupOptions - by db-terra-cc AND by coder-terra-cc independently - which is not the relation the consumer reads. Needs terra_39 to resync members, an explicit decision on the two unscoped new categories, and a drift query so this is detectable in one statement instead of by noticing an empty dropdown.
Activity
-
terra_39 applied 2026-08-22, version 20260822151825, md5 ae70dd9a173c62fcb9d409b0aa0ff886. Repairs vocabularyScopeMembers drift for terraMarcaImplante(+4)/terraTipoInjerto(replaced)/terraZonaDadora(replaced), decommissions terraTipoBarrera scope row (0 live options), adds explicit include-mode scope for terraTipoBarreraImplante/terraTipoBarreraReconstruccion. Live-verified via resolveScopedVocabulary('terra',cat): 19/4/6/4/7, matches header exactly across all 5 categories. audit-terra-ca PASS audit-terra-ca-mt4iv2ssmarl, sha256 9e9a61...4720. Citation gate rc=0. Moved to db/migrations/applied/.
-
POST-REPAIR RUN, live, 2026-08-22 15:5x: ZERO drift across all 10 scoped categories. The three the P0 was about are now whole - terraMarcaImplante 19/19 (was 15 visible of 19), terraTipoInjerto 4/4 (was 2 of 4), terraZonaDadora 6/6 (was 0 OF 6, the field was live and could return nothing). hiddenValues and staleMembers empty everywhere. Two readings that are NOT drift and the query correctly stays silent on: documentoType is 5 live / 2 visible because terra's include scope narrows away three enamel-owned rows on purpose - that was the instrument's own second false positive and the owner predicate on hiddenValues is what fixed it; and the decommissioned terraTipoBarrera does not appear at all, having been replaced by the two per-modulo categories. Run through the shipped VOCABULARY_DRIFT_SQL verbatim, extracted from source rather than retyped, so this is the same statement the administrar surface executes. What is still open here is the GUARD surface, not the check: a green run today says nothing about the next insert, and the must-fail control (both directions, txn+ROLLBACK) is what makes a future green readable.
-
DONE - all three requirements met and drift is zero live. (1) terra_39 resynced the scope members; (2) the two new barrera categories got an EXPLICIT include-mode scope rather than being left default-open, which was the decision the WI asked for - default-open was working and silent, and silent is the danger; (3) the drift query shipped as src/lib/vocabulary-drift.ts and renders on /administrar. RUN LIVE JUST NOW through resolveScopedVocabulary - the relation the FORM reads, not lookupOptions, which is the whole lesson of this row: 10 categories, zero hiddenValues, zero staleMembers. terraMarcaImplante 19/19 (was 15 of 19, the four client-named brands invisible), terraTipoInjerto 4/4 (was 2), terraZonaDadora 6/6 (was 0 - an empty field on screen). documentoType correctly reports 2 visible of 5 with NO complaint: those are enamel-owned rows that terra narrows on purpose, and the instrument distinguishes a hidden option terra OWNS (a defect) from one a co-tenant owns (the scope working). The surface is silent when healthy and says "no pude verificar" when the query fails - never a permanent green panel, because a panel that always says OK is read once.