Modulos offer AI-seeded cirugias instead of the catedra list: client-reported, correct mapping supplied, Drive source not yet in hand
REPORTED by the client (Sebastian Puia, WhatsApp 2026-08-17 09:12, relayed by Elazar). Every modulo currently offers the AI-generated seed cirugias. Puia states the correct mapping himself: implantologia + Cx reconstructiva must offer the SAME cirugias as the maxilofacial especialidad; Cx de tejido blando + protesis convencional + protesis implanto-asistida must offer the list HE loaded in Drive; periimplantitis keeps the AI-generated set (he says that one is correct as-is). BLOCKING INPUT: the Drive file itself. Asked of Elazar 2026-08-17. Do NOT reconstruct the list from the maxilofacial especialidad or from any AI source - inventing it a second time is what produced this row. NOTE ON SCOPE MECHANISM, do not assume: terra has exactly ONE vocabularyScopes row database-wide (terra/piezasDentarias, exclude) per e79aa77, so per-modulo cirugia narrowing is NOT currently done by scope at all and the resolver default is all-active-values. Whether this is seed data, a scope gap, or a missing modulo-cirugia relation is the first thing to measure, not to assume. Terra never mutates shared vocabulary rows: if the fix reaches lookupOptions or any unprefixed object it needs db-enamel-cc GO before apply.
Activity
-
Blocked on Elazar: the Drive file with Puia's cirugias per modulo. Asked 2026-08-17 in the same reply that reported these three defects. The correct MAPPING is in hand (Puia stated it); the LIST is not.
-
Drive source IS now in hand: pm/2026-08-22-client-source-espe-implantes.md, retrieved from Puia's Google Doc 2026-08-22 13:24 UTC and tracked verbatim. terra_36+terra_37 close it for THREE of six modulos - Cirugia de Tejidos Blandos (7), Protesis diente convencional (7), Protesis implanto asistida (13), all exactly the client's lists, 17 AI-seeded rows retired. Modulo 6 Periimplantitis is client-approved as seeded ('pueden abrir las que colocaste vos'), recorded in the migration header, no data flip - isConfirmedByClient means a client pressed confirm, not that a document exists. STILL OPEN and the reason this stays open: modulos 1 Implantologia and 2 Reconstruccion get NO list from the client, only 'lo mismo que en especialidad de cirugia'. Importing maxilo's catalog to satisfy that sentence would be a cross-repo claim nobody in this lane has read.
-
Unblocked: the Drive source is in hand and three of six modulos are done. Remaining scope is modulos 1 and 2 only, which the client did not list.
-
ALREADY FIXED - the WI was stale, not blocked. Elazar 2026-08-22: "why waiting? you have local copy and so does audit". Correct: the blocking input was never missing since 13:24 UTC that day - pm/2026-08-22-client-source-espe-implantes.md IS the retrieved Drive doc and it carries the client verbatim lists for modulos 3, 4 and 5. VERIFIED BY NAME, NOT BY COUNT, because counts carry no sign - a module with the right NUMBER of wrong cirugias passes a count check. Live vTerraCirugias against the client doc, exact string match: modulo 3 Cirugia de Tejidos Blandos 7/7 (conectivo subepitelial, libre palatino con vestibuloplastia, tuberosidad, vestibuloplastia convencional, roll technic, colgajo desplazado vestibular, incision lingual-palatina); modulo 4 Protesis diente convencional 7/7 (poste fibra de vidrio, corona ceramica, carilla ceramica, provisionalizacion, endo crown, incrustaciones, corona ceramo metalica); modulo 5 Protesis implanto asistida 13/13; modulo 6 Periimplantitis 4, the AI-generated set the client explicitly said to KEEP ("pueden abrir las que colocaste vos"). Modulos 1 and 2 were closed separately by TERRA-97/TERRA-76 and match the maxilo especialidad per the client instruction. Zero AI-seeded cirugias remain anywhere a student can see. The row stayed inProgress because nobody re-measured after the import landed - a WI can outlive the defect it names.