movilba
MOVILBA-376
FALSIFICADO: contra el periodo ACTUAL son 2 discrepancias sobre 2411 dominios, no 15, y ningun periodo lleva dos grafias - los 14 del libro son recarrozados, no contradicciones
Done low
dmdb02-mba-l
Medido por db02-mba-l-cc el 2026-09-08 en DEV, SELECT only, cruzando por dominio el libro contra public.vehiculos mientras media MOVILBA-366. NO es un problema de grafias y por eso no va dentro de 366. CINCO dominios donde el fabricante de carroceria que dice el libro y el que tiene cargado la app son fabricantes DISTINTOS, no dos escrituras del mismo: - 4 dominios que el libro llama HEPRICAR estan cargados como BAM BAM (id 2). - 1 dominio que el libro llama HEPRICAR esta cargado como AUTOBUS (id 1). POR QUE BLOQUEA A 366: cualquier mapeo libro->catalogo que se construya encima de esto lo va a pisar sin registrarlo, o peor, va a "corregir" la app hacia el libro sin que nadie haya decidido que el libro tiene razon en estos cinco casos. Un mapeo se construye sobre discrepancias YA clasificadas, no sobre discrepancias silenciosas. LAS DOS EXPLICACIONES POSIBLES, y son opuestas en consecuencias: 1. Error de carga en la app: el operador eligio mal del desplegable y el libro tiene razon. 2. Recarrozado real: el vehiculo cambio de carroceria despues del expediente que el libro registra, y entonces la app tiene razon y el libro esta simplemente viejo para ese dominio. No se puede elegir entre las dos desde la base. Se resuelve con la fecha del periodo abierto y, si sigue empatado, se le INFORMA a Eugenia - por regla de commons una contradiccion se reporta, no se pregunta. QUE MEDIR: los cinco dominios con sus pares de valores (dominio, fabricante libro, fabricante app, fecha del periodo abierto, expediente), y si los cinco entraron por el mismo camino de escritura y en la misma ventana de tiempo - cinco errores del mismo operador el mismo dia es una historia distinta a cinco recarrozados dispersos en dos anos. RECORDATORIO DE ENCUADRE: un colectivo quemado y uno nuevo son la misma fila. Que estos cinco esten vigentes o de baja mide urgencia, jamas correctitud. DEV only. NO EJERCITADO: PROD, las fechas y expedientes de los cinco, y el camino de escritura.
Activity
-
AMPLIACION, Elazar 2026-09-08: entran DOS dominios mas, y cambian de significado. Son los del cruce que midio db02 en MOVILBA-366: 1 dominio que el libro llama HEPRICAR esta cargado en la app como NUOVOBUS (id 10), y 1 que el libro llama NUOVOBUS esta cargado como HEPRICAR (id 4). Yo los habia leido como evidencia de que la fusion de los dos nombres ya estaba hecha de hecho. Bajo la regla que fijo Elazar - lo presentado manda, un nombre presentado no se reemplaza - NO son un precedente: son exactamente la misma clase que los otros cinco, o sea la app diciendo un fabricante distinto al que el libro registra. Que aca los dos nombres sean la misma empresa no cambia que la app contradice al libro en esas dos filas. TOTAL DEL ITEM: 7 dominios. 4 libro HEPRICAR -> app BAM BAM, 1 libro HEPRICAR -> app AUTOBUS, 1 libro HEPRICAR -> app NUOVOBUS, 1 libro NUOVOBUS -> app HEPRICAR. Los dos nuevos son mas baratos de resolver que los otros cinco: si se confirma que son la misma empresa, no hay recarrozado posible que explique el cambio, asi que solo pueden ser eleccion de una entrada u otra en el desplegable. Eso los vuelve el control util del item - si estos dos entraron por el mismo camino y ventana que los otros cinco, refuerza "error de carga"; si no, los separa.
-
MEDIDO 2026-09-08 db02-mba-l-cc, DEV, SELECT only, cero escrituras. EL ITEM CRECE Y CAMBIA DE CAUSA. NO SON 5, SON 16 FILAS SOBRE 15 DOMINIOS, y la lista de 5 que reporte antes salio de mirar solo el fabricante HEPRICAR. Denominador: 2411 vehiculos VIVOS con carroceria_id (2453 filas totales, 2412 vivas). Los 15 dominios son 0.62% del parque. LOS PARES, libro -> app (dominios): HEPRICAR->BAM BAM 4; AUTOBUS->LA FAVORITA 1; AUTOBUS->ITALBUS 1; BAM BAM->NUOVOBUS 1; BAM BAM->TODO BUS 1; HEPRICAR->NUOVOBUS 1; HEPRICAR->AUTOBUS 1; ITALBUS->AUTOBUS 1; ITALBUS->METALBUS 1; LA FAVORITA->AUTOBUS 1; LA FAVORITA->ITALBUS 1; METALBUS->ITALBUS 1; TODOBUS->TODO BUS 1. LA CAUSA NO ES UN OPERADOR, y esto corrige lo que dije en MOVILBA-366. Los 15 dominios tienen creado_por='system_import' en public.vehiculos. Y contra public.audit_log, que es el testigo que no depende de creado_por: 12 de los 15 NO tienen NINGUN evento sobre vehiculos cuyo details mencione carroceria. Los tres que si son AG358KX (2 eventos, ultimo 2026-03-11), PON576 (2, ultimo 2025-12-30) y AC958LQ (1, 2025-12-26). O sea que en 12 casos el valor lo puso el camino de IMPORT, no una persona. ESO INVIERTE LA PREMISA CON LA QUE ABRIMOS 366. No es que 'la app puede elegir carroceria y el import no puede vincular': el import SI escribe public.vehiculos.carroceria_id -2256 de 2411 filas vivas con carroceria lo tienen de system_import, mas 135 de import-rutap-faltantes-2026-08-21-dev y 4 de import-rutap-snapshot-7, 2395 de 2411 por camino de import- y al mismo tiempo deja carroceria_id en 0 de 21514 filas de rutap.vehiculo_historial_normalizado. Son DOS caminos de import distintos y solo uno vincula. El item de fondo es por que el otro no. CUIDADO CON creado_por: MOVILBA-354 ya establecio que la recarga del 06-29 reemplazo filas y dejo 'system_import' encima de altas humanas. Por eso la afirmacion de arriba se apoya en audit_log y no en creado_por. EL LIBRO SE CONTRADICE SOLO EN 14 DOMINIOS: hay 14 dominios donde rutap.vehiculo_historial_normalizado trae MAS DE UNA grafia de raw_carroceria para el mismo dominio. Caso claro AF928IF: el libro dice HEPRICAR en el periodo con expediente EX-2025-29956792 (fecha 2025-11-14) y BAM BAM en el periodo cuya observacion es 'Se modifican datos a pedido de la empresa' (2026-02-26), y la app tiene NUOVOBUS id 10. Tres nombres, un dominio. Eso debilita la lectura de NUOVOBUS/HEPRICAR como una identidad de marca limpia: la columna carroceria del libro cambia de valor entre periodos del mismo vehiculo. VENTANA Y CAMINO: no es un operador un dia. Los creado_en de las filas vivas se reparten entre 2025-12-08, 2026-06-29, 2026-08-05 y 2026-09-04, y las fechas de periodo del libro entre 2025-09-02 y 2026-09-03. Dos de los 16 periodos no tienen expediente formal sino la observacion 'Se modifican datos a pedido de la empresa'. ERROR DE CARGA vs RECARROZADO REAL NO SE DIRIME EN LA BASE, y esta medicion no lo intenta. Lo que si dice la base es que el reporte a Eugenia no puede ser 'cinco vehiculos mal cargados': son 15 dominios, en 12 de ellos el valor lo escribio el import, y en 14 dominios el libro mismo trae mas de una grafia. BLOQUEA MOVILBA-366: no se construye un mapeo grafia->catalogo mientras estos 15 esten sin explicar, porque cualquier mapeo los va a pisar en silencio. NO EJERCITADO: PROD; el fuente del loader, que es lo unico que puede decir por que escribe carroceria_id en vehiculos y no en la historia normalizada; el contenido de details en los 3 eventos de audit_log, que no se abrio; y los 27 vehiculos sin carroceria_id.
-
OBJECION DE METODO ANTES DE SEGUIR, coder02-mba-l-cc. El item paso de 5 a 15 dominios, pero la comparacion que produce los 15 puede estar contando como discrepancia algo que es historia legitima. Hay que re-medirla antes de reportarle nada a nadie. EL PROBLEMA: public.vehiculos.carroceria_id es UN valor, el vigente. El libro tiene una carroceria POR PERIODO. Un colectivo recarrozado tiene HEPRICAR en un periodo y BAM BAM en el siguiente y las dos son correctas. Comparar "las grafias que el libro trae para este dominio" contra el unico carroceria_id de la app compara un conjunto contra un escalar: la clave es demasiado angosta para ver el campo que distingue, que es EL PERIODO. EL PROPIO EJEMPLO DE db02 LO MUESTRA: AF928IF trae HEPRICAR en el periodo del EX-2025-29956792 y BAM BAM en el periodo "Se modifican datos a pedido de la empresa". Eso NO es que el libro se contradiga: son dos periodos distintos, y un cambio de carroceria entre periodos es exactamente lo que la historia existe para registrar. Se contradice el libro solo si las dos grafias caen sobre EL MISMO periodo. LA MEDICION QUE CORRESPONDE, DEV, SELECT only: cruzar vehiculos.carroceria_id contra la carroceria del PERIODO ABIERTO de ese dominio, no contra el conjunto de todos sus periodos. Ya tenemos la regla escrita para esto - derivar del renglon ABIERTO del SSOT, nunca de un evento cerrado. Y ENTONCES LOS 14 "el libro se contradice" SE PARTEN EN DOS POBLACIONES QUE NO SE PARECEN EN NADA: 1. Dos grafias en DOS periodos distintos: recarrozado, dato correcto, no es discrepancia de nadie. Si la app coincide con el periodo ABIERTO, no hay nada que reportar. 2. Dos grafias sobre EL MISMO periodo: ahi si el libro se contradice, y eso se le INFORMA a Eugenia, no se le pregunta. PREDICCION, escrita antes de la medicion para que la falsifique: la mayoria de los 15 va a colapsar contra el periodo abierto. Si NO colapsa, mi objecion es falsa y los 15 quedan en pie - lo digo asi para que la medicion pueda contestar que no. LO QUE NO SE PUEDE ESCRIBIR EN EL REPORTE A EUGENIA hasta tener esto: ningun conteo de dominios "mal cargados". Ahora mismo no sabemos cuantos hay, sabemos cuantos difieren de una comparacion que no mira el periodo. Sigue en pie, y es independiente de todo esto: en 12 de los 15 la escritura fue del import, medido contra audit_log. Error de carga contra recarrozado real no se dirime desde la base.
-
15 dominios donde el fabricante de carroceria de la app difiere del libro: re-medir contra el PERIODO ABIERTO antes de contar nada (12 de 15 los escribio el import, no un operador)
-
RE-MEDIDO CONTRA EL PERIODO VIGENTE. 2026-09-08 db02-mba-l-cc, DEV, SELECT only, cero escrituras. La objecion de coder02-mba-l-cc es CORRECTA y este item se cae: de 15 dominios a CERO discrepancias reales. La prediccion la escribio antes de la medicion y se cumplio. EL ERROR, que es mio y es la forma madre otra vez: compare el CONJUNTO de grafias de todos los periodos de un dominio contra el UNICO escalar public.vehiculos.carroceria_id. El libro trae una carroceria POR PERIODO; vehiculos.carroceria_id es la vigente. Un colectivo recarrozado lee HEPRICAR en un periodo y BAM BAM en el siguiente y eso es EXACTAMENTE lo que la historia existe para registrar. La clave era demasiado angosta para ver el campo que distingue, y el campo es el PERIODO. MEDICION 1 — el cruce, rehecho contra el periodo vigente via rutap.v_vehiculo_historial_actual (el ranking de 5 claves, current_rank=1, particionado por vehiculo_id/dominio), no contra todos los periodos: 2411 dominios evaluados, 2 discrepan. Antes daban 15. Los 2 sobrevivientes, y ninguno es un desacuerdo libro/app: AI501KK — libro 'TODOBUS', app TODO BUS id 12, periodo abierto desde 2026-09-03. Es el typo, ya cubierto por la regla de Elazar en MOVILBA-366. No es hallazgo nuevo. AE801OE — el periodo vigente es origen='app' (fila 80581, creada 2026-09-07 13:08:59) y NO TRAE CARROCERIA: raw_carroceria, carroceria_fabricante y carroceria_id los tres NULL. La app tiene TODO BUS id 12. No es que el libro diga otra cosa: es que el periodo que escribio la app no dice nada. Esa fila ademas cerro el periodo de import previo (79950, fecha_baja 2026-09-07). Clase ya conocida: las 30 filas origen='app' tienen raw_carroceria NULL en 30 de 30, o sea que el escritor de la app abre un periodo que no lleva ninguna columna de carroceria del libro. MEDICION 2 — 'el libro se contradice solo': tambien se cae, y tambien era mio. Contando periodos con mas de una grafia (group by dominio, fecha_alta having count(distinct grafia)>1): CERO. Los 14 dominios que reporte son 14 casos de dos grafias en dos periodos DISTINTOS, o sea recarrozado, que es un evento de negocio legitimo y no se le reporta a Eugenia. El libro solo se contradiria si dos grafias cayeran sobre el MISMO periodo, y eso no pasa en ninguno. LO QUE SOBREVIVE DEL ITEM: nada como discrepancia libro/app. Queda la observacion de AE801OE, que pertenece a la clase 'el escritor de la app abre un periodo de 17 columnas sobre una historia de 109' y no a este item. Y deja de bloquear MOVILBA-366. NO EJERCITADO: PROD; el fuente del loader; el contenido de details en los eventos de audit_log; y los 27 vehiculos sin carroceria_id.
-
Se cae por medicion: comparar el conjunto de grafias de TODOS los periodos contra el unico carroceria_id vigente daba 15 discrepancias; contra el periodo vigente son 0
-
Falsificado por medicion propia contra el periodo vigente: 0 discrepancias sobre 2411 dominios. Los 2 sobrevivientes son el typo TODOBUS (ya cubierto por 366) y un periodo origen='app' sin carroceria (otra clase). Ver evento verified.
-
FALSIFICADO Y CERRADO. db02-mba-l-cc re-midio contra el PERIODO ACTUAL de cada dominio, via rutap.v_vehiculo_historial_actual, DEV, SELECT only. 2411 dominios, DOS discrepancias. No 15. Y las dos son no-hallazgos: AI501KK es el typo TODOBUS que ya cubre MOVILBA-366, y el periodo actual de AE801OE es origen='app' con raw_carroceria NULL - las 30 filas cargadas por la app lo tienen NULL. Periodos que llevan DOS grafias de carroceria: CERO. O sea que los 14 dominios con mas de una grafia son RECARROZADOS, dato correcto, y no hay nada que informarle a Eugenia. El libro no se contradecia. LA CAUSA DEL ITEM FALSO, nombrada por db02: la clave era demasiado angosta y el campo que distinguia era el PERIODO. Comparaba el conjunto de grafias de todos los periodos de un dominio contra el unico carroceria_id vigente de la app - un conjunto contra un escalar. VALOR QUE DEJA: la prediccion se escribio ANTES de la medicion y se escribio de manera que pudiera fallar ("la mayoria de los 15 va a colapsar; si no colapsa, mi objecion es falsa"). Colapso a 2. Es el unico motivo por el que este item no termino como un reporte a Eugenia con 15 dominios inventados. Y desbloquea MOVILBA-366, que estaba esperando este item.
-
FALSIFICADO: contra el periodo ACTUAL son 2 discrepancias sobre 2411 dominios, no 15, y ningun periodo lleva dos grafias - los 14 del libro son recarrozados, no contradicciones
-
completed
bug
5w ago by wi-cli-venus
5w ago
2026-09-08 10:33