terra
TERRA-76
Implantologia and reconstruccion alveolar need modulo-specific fields (injerto, zona dadora, barrera, marca de implantes): never built, shape undecided
Done high
ctcoder-terra-cc
REPORTED by the client (Sebastian Puia, WhatsApp 2026-08-17 09:12, relayed by Elazar), verbatim: "Recorda q los Modulos implantologia y reconstruccion alveolar abrian muchas cosas: tipo de injerto, zona dadora, tipo de barrera, marca de implantes etc". The "etc" is load-bearing and is NOT a licence to guess the rest - the enumerated four are what we have, and the tail is an open question for the client, not for us. TODAY: the practica form is uniform across modulos, so these fields do not exist on any surface. This is not a regression - it was never built and was never specified to terra. FIRST QUESTION IS SHAPE, NOT FIELDS: whether a modulo-conditional field set is a form-branching change or a data-model change (per-modulo field definitions + per-practica values) decides everything downstream, and getting it wrong is expensive to undo. Answer that before writing anything. Each field is also a vocabulary question in its own right (tipo de injerto, zona dadora, tipo de barrera, marca de implantes are all closed lists somebody has to supply) - a free-text fallback silently creates the same uncontrolled-vocabulary problem measured on categoryValue. Do not ship free text as a shortcut. Related client input on the same day: TERRA-75, TERRA-77.
Sub-tickets — 3/3 done
TERRA-86 Done high
dtdb-terra-cc
TERRA-90 Done high
dtdb-terra-cc
TERRA-91 Done high
dtdb-terra-cc
Activity
-
DESIGN (coder-terra-cc 2026-08-22, Elazar lean-loop directive): DATA-MODEL, not form branching. Form branching hardcodes four fields for two modulos and the client's 'etc' guarantees a fifth; a per-modulo definition table makes the next field a seed row. Shape: terraModuloCampos (id, moduloId FK, key text, label text, inputType CHECK ('lookup','text','boolean'), lookupCategory text NULL (lookupOptions category, terra-scoped), orden, isRequired bool, isActive bool, createdAt) UNIQUE(moduloId,key); terraPracticasCampos (id uuid, practicaId FK, campoKey text, value text NOT NULL, createdAt, deletedAt, archiveReason) UNIQUE live (practicaId,campoKey), soft-delete + archive armed like the other detail tables (terra_14/15/20/21 pattern). Seed the four named fields for implantologia + reconstruccion alveolar as inputType=lookup with NEW terra categories terraTipoInjerto, terraZonaDadora, terraTipoBarrera, terraMarcaImplante - EMPTY until the catedra supplies the lists (no free text: TERRA-76 desc). Form renders a modulo's active campos after modulo selection; a lookup field with zero options renders disabled with 'lista pendiente de la catedra'. createPractica writes terraPracticasCampos in the same txn; detail page (TERRA-82) shows them. OPEN to client: the four vocabularies + the 'etc' tail - asked via Elazar. DB half delegated as child WI.
-
APP LEG SHIPPED c6c84cc, live 0.24.14. Form renders the selected modulo's campos (lookup/text/boolean), createPractica writes terraPracticasCampos with moduloId + campoId in the same txn as the practica, detail renders them. Keyed by campoId not key; writes hit the BASE table because terra_31's views are the first terra views whose ACL excludes service_role writes. No Node-side value validation - fn_terraPracticasCamposValueGuard owns it inside the txn. isRequired is form-only and stated as such. Modulo change cascade-resets campo values. WHAT IS STILL OPEN AND IS THE WHOLE POINT OF THE WI: all four vocabularies are EMPTY, so every field renders DISABLED with 'La catedra todavia no cargo las opciones de este campo' and NO practica can carry a value yet. The four lists (tipo de injerto, zona dadora, tipo de barrera, marca de implantes) and the 'etc' tail are with Puia via Elazar. UNEXERCISED: no authenticated save has run - the write path, the value guard and the composite FKs are wired and proven only by terra_31's apply-time arms, not by a real practica.
-
App leg shipped (c6c84cc). Blocked on the client for the four vocabulary lists + the 'etc' tail: the fields are live but every picker is empty and disabled until the catedra supplies them. Nothing further is buildable without those lists - a free-text fallback is explicitly ruled out by this WI.
-
UNBLOCKED 802b0b8 / terra_33: all four campo pickers are live with provisional lists (5/9/7/15) and say so at the field. What remains is client review - Puia's corrections to the four lists via TERRA-90, and the 'etc' tail (any fifth field) which is a seed row once named. No authenticated save has exercised terraPracticasCampos yet.
-
Partly unblocked by the venus import: the injerto / zona dadora / barrera VOCABULARIES are no longer undecided - coder-venus-cc supplied them from the client's own spec (2026-06-02) and TERRA-96 replaces terra's literature guesses with them, including splitting barrera into two per-modulo categories because the client specifies different lists for implantologia (4) and reconstruccion (7). Modulo 1 also gains injerto+barrera campos it never had. What REMAINS open here is the shape, not the vocabulary: see TERRA-97.
-
STALE AS TITLED, corrected by measurement rather than closed: 'never built, shape undecided' is no longer true. vTerraModuloCampos holds all six fields live today - modulo 1 marcaImplante + tipoBarrera(terraTipoBarreraImplante) + tipoInjerto, modulo 2 tipoBarrera(terraTipoBarreraReconstruccion) + tipoInjerto + zonaDadora - and practica-form renders each one, with an empty list rendering disabled and a 'pendiente de la catedra' note instead of vanishing. The vocabularies were supplied by terra_35/36/38 and made VISIBLE by terra_39 (inserting a lookupOption does not make it visible; resolveScopedVocabulary is what the picker reads). What actually remains of this WI is the SHAPE half, and that is TERRA-97: presence is per-CIRUGIA in the client model and per-MODULO in terra, so injerto+barrera are over-offered on 3 of modulo 1's 10 and zonaDadora on 3 of modulo 2's 7. Not closing this until TERRA-97 lands, because closing it now would read as 'the fields are right' when they are merely present.
-
DELIVERED live v0.24.42. All four client-named fields exist and now render per-CIRUGIA, matching the venus client spec exactly - measured against live data, not against the migration file. Modulo 1 Implantologia (10 cirugias activas): marcaImplante 0 scope rows = every cirugia; tipoBarrera and tipoInjerto 7 rows each = 7 of 10, the three left out being the marca-only ones. Modulo 2 Reconstruccion del reborde alveolar (7 cirugias): tipoInjerto and tipoBarrera 0 rows = every cirugia; zonaDadora 4 rows = the four bloque cirugias only. That is 1:1 with the client asterisk shorthand in the spec (* = injerto+barrera, *** = +zonaDadora, none = neither). SHAPE QUESTION ANSWERED THE EXPENSIVE WAY AND CORRECTLY: it was a data-model change, not form branching - terraModuloCampos for definitions, terraPracticasCampos for values, terraCirugiaCampos (terra_41) for per-cirugia presence. All four are inputType=lookup against closed vocabularies (terraMarcaImplante, terraTipoBarreraImplante, terraTipoBarreraReconstruccion, terraTipoInjerto, terraZonaDadora); no free-text fallback was shipped, per the WI note. STILL OPEN AND NOT CLOSED BY THIS: the client etc. The four enumerated fields are done; whatever else the catedra wants is a question for Puia, not something to infer. File a new WI when he answers.
feature
2026-08-17 by wi-cli-venus
7w ago
2026-08-22 19:09