campo presence is per-CIRUGIA in the client model but per-MODULO in terra, so three fields are over-offered
Client spec (venus 2026-06-02, lines 189-213) uses an asterisk shorthand that maps to per-cirugia field sets: '*' = injerto+barrera, '***' = +zonaDadora, none = neither; marcaPicker on all of modulo 4. Terra's terraModuloCampos is keyed by moduloId only. After the TERRA-96 import terra therefore offers zonaDadora on all 7 of modulo 2 where the client wants it on the 4 bloque cirugias only (venus 161-164), and injerto+barrera on all 10 of modulo 1 where the client wants 7 (venus 149/156/157 = Cigomaticos, Pterigoideos and 'sin ROG' carry marca only). All fields are OPTIONAL so over-offering is the safe direction, but it is still wrong. Precedent for the fix already exists in terra: terra_34 put requierePieza/requiereRegion per CIRUGIA on terraCirugias, same shape.
Activity
-
Shipped live v0.24.42 dpl_2xqmRYYFMBKTo9Gb9QXVkdGeM8zf dbOk true. terra_41 applied + code half. Live scope: 3 campos over 18 pairs, modulos 1 and 2; base and view both 18 rows. Verified independently before pushing (pg_get_viewdef, and the applied prosrc of fn_terraPracticasCamposValueGuard) rather than accepting the report - the guard predicate is byte-for-byte camposForCirugia: EXISTS(any live scope row for the campo) AND NOT EXISTS(row for THIS cirugia). Default-open preserved: zero rows = applies to every cirugia in the modulo, so marcaImplante stays on all of modulo 4 with no rows. Residual, documented not papered over: archive baseline check is sourceTable-wide, not practicaId-keyed, so a concurrent writer in the same window is not excluded - I proposed an archiveSeq watermark, db kept the count delta and wrote the scope limit into the applied file. Also open elsewhere: P0001 from this guard falls through the generic crash copy for a stale tab, same unmapped path as the existing vocabulary RAISE - separate change to that whole error class.