Canonical chassis resolver required to materialize SSOT missing buses

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
  parent=#3268
• wi-cli-venus note · 5w ago
  Dependency recorded by db02-mba-l-cc 2026-09-08 00:56 ART at db03's request (MOVILBA-269 crear_fichas_faltantes). State of the resolver as it stands on DEV, measured tonight: rutap.chasis_resolver(fabricante_normalizado, modelo_normalizado, unidad_propulsora_id, estado, chasis_id, evidencia, dominios_evidencia, snapshot_id, creado_en) and rutap.unidad_propulsora_resolver(valor_fuente_normalizado, estado, unidad_propulsora_id) already exist and ARE snapshot-independent: the triple is keyed by rutap.normalizar_clave_chasis(), and chasis_resolver.snapshot_id is provenance of the approval, not a filter. What is latest-only is the VIEW rutap.v_rutap_chasis_resuelto, because its source is rutap.v_rutap_latest; rutap.v_rutap_chasis_resuelto_aprobado adds estado_resolucion='aprobado' AND chasis_id IS NOT NULL. Consumers that must work on an explicit snapshot (the MOVILBA-269 projector today, crear_fichas_faltantes next) reproduce the view's two joins over rutap.rutap_rows for that snapshot instead of using the view. Coverage measured on the 2026-09-08 projection of snapshot 12: 52 rows of 5388 got a chasis_id; 5336 rows carry 'chasis_no_resuelto' with normalizacion_estado='pendiente'. That 52/5388 is the gap this item closes. NOT exercised: how many DISTINCT normalised triples those 5336 rows represent (counted rows, not triples).
• wi-cli-venus blocked · 5w ago
  2026-09-08 00:56 - DEPENDENCIA de MOVILBA-269/crear_fichas_faltantes (db03-mba-l-ca): no existe resolver canonico de chasis independiente del snapshot; el proyector resuelve chasis latest-only pese al argumento bigint (MOVILBA-340). crear_fichas_faltantes reproduce los joins sobre rutap.rutap_rows del p_snapshot_id en vez de la vista latest-only, y no inventa mapeo: fuente no vacia sin resolver se REPORTA, NULL de entrada queda NULL. Misma dependencia en MOVILBA-245 (carroceria).
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  EL RESOLVER YA EXISTE Y CUBRE EL 99,85% - db02-mba-l-cc, 2026-09-12, DEV, SOLO LECTURA. Este item pide 'persistir un resolver de chasis con procedencia y estado de conflicto explicito'. Ya esta construido. Lo que falta es otra cosa, y la nombro. LO QUE HAY EN DEV: rutap.chasis_resolver y rutap.unidad_propulsora_resolver, mas la funcion rutap.normalizar_clave_chasis. chasis_resolver tiene 96 filas: 91 aprobado (todas con chasis_id), 4 pendiente y 1 conflicto - o sea el estado explicito que el item pide ya esta modelado y ya se esta usando para retener casos. unidad_propulsora_resolver tiene 4 filas, las 4 aprobadas. La clave es la TERNA (fabricante, modelo, unidad_propulsora), como ya estaba registrado. COBERTURA CONTRA EL LIBRO IMPORTADO (snapshot 12, 2026-09-07-2350): de 5388 filas, 5380 resolverian HOY a un chasis aprobado. No resuelven 8 filas, que son SIETE ternas: AGRALE / MT 17.0 GNV CA 6200 / GO (1 fila) MERCEDES BENZ / CN-BMO 368 VERSION 1 / GO (1) MERCEDES BENZ / FU-BMO 368 VERSION 1 / GO (2) MERCEDES BENZ / MT 15.0 LE V 5500 / GO (1) MERCEDES BENZ / MT 15.0 LE V 5500 6.7 5 226 AUTR / GO (1) MERCEDES BENZ / MT 17.0 LE V 6000 / GO (1) MERCEDES BENZ / MT 17.0 LE V 6000 6.7 5 226 AUTR / GO (1) Notar que cuatro de las siete son el MISMO modelo con y sin el sufijo tecnico '6.7 5 226 AUTR'. Eso no se resuelve inventando un alias: o el libro tiene dos grafias del mismo modelo y lo corrige Eugenia, o son modelos distintos y van al catalogo como entradas nuevas. Es exactamente la decision que el item dice que hay que tomar CON evidencia, y no la tomo yo. EL HALLAZGO QUE CAMBIA LA PRIORIDAD: el espejo ancho NO tiene escrito lo que el resolver ya sabe. De las 5388 filas proyectadas del snapshot 12, solo 52 tienen chasis_id. Las otras 5336 estan en NULL aunque el resolver de hoy las resolveria. La lectura es que la proyeccion del snapshot 12 corrio ANTES de que el resolver estuviera poblado/aprobado, y nadie volvio a pasar. O sea que el trabajo pendiente no es construir el resolver: es re-proyectar o backfillear el chasis_id, y decidir las siete ternas de arriba. Cuidado que eso NO es trivial: la funcion proyectar_snapshot se niega explicitamente a re-proyectar un snapshot que ya tiene filas y nunca borra. Asi que 'volver a pasar' es un UPDATE de backfill con su propia decision y su propio GO, o una re-importacion, no una re-corrida de la proyeccion. Y PROD NO TIENE NADA DE ESTO: en PROD no existe ninguna tabla *resolver* en el schema rutap ni la funcion normalizar_clave_chasis. Cualquier plan que diga 'el resolver decide' vale hoy solo en DEV. NO EJERCITADO: no escribi nada, no proyecte, y no verifique la procedencia de las 91 filas aprobadas -si cada una tiene la evidencia que el item exige, no lo medi-. Nada ejecutado.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:03 -03 — SELECT-only current-state check: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The canonical chassis resolver and missing-bus materialization gate were not exercised. Status unchanged; no DB write.
• db04-mba-l-ca verified · 1w ago
  2026-10-05 SELECT-only remeasurement of current approved book 2026-09-30-1305-parque-rutap.xlsx (md5 8512833be84d1568743d61b601179c6b): PROD snapshot 8 and DEV snapshot 20 each have 5,548 source rows, 5,548 approved chassis resolutions, 0 unresolved, and 5,548 normalized-history rows with non-NULL chasis_id. Both bases have 100 chasis_resolver rows, all approved, all with chasis_id and nonblank evidencia; 98 have snapshot_id NULL, so their provenance is textual, not a snapshot FK. Both installed materializar_snapshot_raices bodies (PROD prosrc md5 d11f9ae5f85e7a25b86f5d4fdf958a0e) require exactly one approved resolver row for every nonblank source chassis at lines 92-96 and RAISE on any failure at line 109, before root INSERT at line 171. The old 2026-09-12 findings (PROD resolver absent, 5,336 NULL projected ids) no longer describe the current bases. Negative mutant was NOT executed; fail-closed conclusion is from installed-body read, while 5,548/5,548 is a positive data control. No DB write.
• db04-mba-l-ca completed · 1w ago
  Current PROD and DEV resolver coverage is complete (5,548/5,548) and the installed materializer fails closed on missing/non-unique approved mappings; verified event records evidence and the unexercised negative mutant. Any future book-specific unresolved terna is a new catalog-resolution item, not missing resolver infrastructure.