121 filas de vehiculo_historial sin periodo en el libro quedan fuera de todo gate (+2 periodos duplicados en el libro)

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus note · 6w ago
  db02 enumero todas las keyings sobre las 6078 filas: max 222 (todas sin periodo en libro) = 121 vivas + 101 borradas. NINGUNA da 708. La pregunta 'subconjunto o disjunto' no se puede contestar como esta planteada: 708 no es un conteo de filas de historial ausentes del libro bajo ninguna clave construible. Pedido a db03: predicado exacto, timestamp (pre/post correccion) y DIRECCION (filas de historial sin periodo en libro, vs filas de libro sin historial). Hasta que se defina, 708 no se cita en ningun resumen. Duplicado del libro RESUELTO: exactamente 1, AD956UK 2025-12-10->2025-12-11, dos filas, mismo observaciones, expedientes distintos, el que ABRE la primera CIERRA la segunda (53390264).
• wi-cli-venus note · 6w ago
  Hipotesis 'direccion' DESCARTADA por medicion: filas del libro sin fila de historial = 0; sin fila de historial VIVA = 0; dominios del libro ausentes de vehiculos = 0; denominador 5370. 708 tampoco es la direccion inversa. Quedan dos explicaciones para db03: medido ANTES del commit de correccion, o clave distinta de (dominio, fecha_alta, fecha_baja). RESULTADO DE FIDELIDAD publicable por si solo: las 5370 filas del libro (snapshot 10) tienen fila viva de vehiculo_historial en la clave de periodo exacta - el libro esta integramente representado en DEV al grano de periodo. NO es simetrico: la direccion inversa deja 121 filas vivas sin periodo en el libro (este item). El cero es confiable y no estructural porque el mismo join al reves devuelve 121.
• wi-cli-venus note · 6w ago
  708 RESUELTO como problema de NOMBRE, no de datos. db03: es el conteo de filas de vehiculo_historial (incl. soft-deleted) cuyo id NO selecciona _m227_history_match, que clavea por vehiculo_id resuelto + fecha_alta + fecha_baja + expte_alta + expte_baja + ordinal. Es un conteo de IDENTIDAD DEL LOADER sobre una clave mas ancha, no de fidelidad; por eso puede superar a 222 (la clave de periodo es un prefijo suyo). Los tres numeros son consistentes una vez nombrados: 5370 filas del libro todas representadas (clave de periodo, libro->DEV), 121 filas vivas de DEV sin periodo en el libro (clave de periodo, DEV->libro), 708 sin match de identidad del loader (clave del loader). db03 renombra el diagnostico. NADIE cita 708 como cifra de fidelidad. PREGUNTA ABIERTA a db03: si el match set ES el update set, esas 708 filas son inalcanzables para el loader y cualquier defecto que viva ahi sobrevive cada corrida en silencio.
• 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:05 ART — SELECT-only installed-object check in DEV movilba_dev and PROD movilba: to_regclass('public.vehiculo_historial') is NULL in both; the ticket's historical population/column premise cannot be reverified in that retired table. Current replacement rutap.vehiculo_historial_normalizado has 5528 nondeleted imported rows in each base, but this sweep did not exercise the ticket-specific invariant against it. Status unchanged; do not apply an old-table repair.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc note · 1w ago
  RE-DERIVADO CONTRA EL ESQUEMA ACTUAL - db03-mba-l-cc 2026-10-08, PROD, solo lectura. El ticket se escribio (2026-09-04) contra public.vehiculo_historial, que ya no existe (confirmado por db04 2026-09-24: to_regclass devuelve NULL en DEV y PROD). Existe bkp.vehiculo_historial_20260814_prebackfill_prod - esa tabla fue reemplazada por un backfill el 2026-08-14, ANTES de que se creara este ticket, por rutap.vehiculo_historial_normalizado (la funcion rutap.proyectar_snapshot). La premisa de "121 filas sin periodo en el libro" y "708 filas source-absent del importador" es de una arquitectura que ya no esta instalada. ARQUITECTURA HOY: rutap.vehiculo_historial_normalizado tiene 5558 filas vivas (borrado_en IS NULL) en PROD, TODAS origen='import' - no hay ninguna fila origen='app' viva hoy. TODAS pertenecen al snapshot vigente (rutap_snapshot_id=11, el mas reciente); cero filas vivas de un snapshot anterior. Por construccion, cada fila viva ES una proyeccion directa de una fila del libro (via rutap_snapshot_id+rutap_fila_excel, FK MATCH FULL contra rutap.rutap_rows) - no existe la categoria "fila viva sin periodo del libro" en el diseño actual: una fila solo puede estar sin period que si fuera origen='app' (no hay ninguna) o si sobreviviera de un snapshot viejo no reimportado (no hay ninguna). CONCLUSION: el hallazgo principal del ticket (121 filas) no reproduce porque la condicion que lo producia ya no puede ocurrir. PERIODOS DUPLICADOS (la segunda parte SI reproduce hoy): 1 grupo de 2 filas con mismo (dominio, fecha_alta, fecha_baja) en el snapshot vigente: dominio=AD956UK, fecha_alta=2025-12-10, fecha_baja=2025-12-11, filas rutap_fila_excel=789 (id 205648, expte_alta=Ex-2025-53390264) y 790 (id 205647, expte_alta=Ex-2025-53084543, expte_baja=EX-2025-53390264). Son 2 lineas DISTINTAS del libro (expedientes distintos, el expte_baja de la 790 es el expte_alta de la 789 - dos tramites encadenados que calculan la misma fecha_alta/fecha_baja), no un artefacto de resolucion ni una fila duplicada por error del proyector. Por la regla del 2026-09-24 ("el libro trae dos filas con el mismo dominio/fecha_alta/fecha_baja, se importa verbatim y se reporta, no es pregunta para Eugenia"): se importa como esta, se reporta, NO se borra ni se actualiza ninguna de las dos. PROPUESTA: cero escritura. Sin filas para DELETE/UPDATE bajo la regla #4 (2026-09-24) porque no hay filas candidatas - no hay origen='app' viva, no hay fila sin periodo del libro bajo el esquema actual, y el unico duplicado medido es un duplicado LEGITIMO del libro (import verbatim). Cierra el ticket por premisa superada + segunda parte confirmada-y-reportada sin accion de escritura requerida.
• db03-mba-l-cc completed · 1w ago
  public.vehiculo_historial no existe (backfill 2026-08-14 a rutap.vehiculo_historial_normalizado, previo a este ticket) - premisa de 121 filas sin periodo no reproduce bajo el esquema actual (toda fila viva es origen=import del snapshot vigente, sin categoria posible de 'sin periodo'). El duplicado de periodos SI reproduce (1 grupo, 2 filas, AD956UK, 2 tramites encadenados) y es libro-verbatim legitimo por la regla 2026-09-24 - reportado, 0 escritura.
• audit-mba-l-cc audited · 1w ago
  audit pass: 3 SELECTs PROD
  payload

  {"scope":"3 SELECTs PROD","outcome":"pass","evidence":"to_regclass('public.vehiculo_historial') NULL; 5558/5558 live rows origen=import; exactly 1 dup group AD956UK 2 rows - matches claim exactly","reportRef":null}