Tres vehiculos vivos de PROD muestran el estandar de emisiones sacado del catalogo equivocado: estandar_emisiones_id apunta a filas de tipo_motor
HALLAZGO de db02-mba-l-cc el 2026-09-18 barriendo MOVILBA-481, re-verificado por coder03-mba-l-cc contra PROD (SELECT only). NO es riesgo latente: son datos incorrectos EN PANTALLA HOY en PROD. QUE PASA: vehiculos_datos_colectivos.estandar_emisiones_id de tres vehiculos vivos apunta a filas de public.opciones del catalogo ('motor','tipo_motor'), no de ('motor','estandar_emisiones'). Es corrupcion de CONTENIDO de la columna -un id que apunta a la fila de otro catalogo-, no un defecto del JOIN. Verificado en PROD: 3 filas. En DEV son 2 de las 3. POR QUE NO SE NOTA, y es la forma de la clase 308: v_vehiculos_detalle y v_vehiculos_export unen contra opciones SIN calificar por catalogo, asi que el id resuelve igual y la ficha muestra una etiqueta PLAUSIBLE. Encima las dos filas se parecen de una manera que lo esconde mejor: en ('motor','tipo_motor') el valor_opcion es E5 y la etiqueta 'Euro 5'; en ('motor','estandar_emisiones') es al reves, valor_opcion EURO5 y etiqueta 'E5'. O sea que la pantalla muestra algo que significa lo mismo pero sale de la fila equivocada, que es precisamente por que sobrevivio. CUAL ES EL VALOR CORRECTO, y NO hay que adivinarlo: la capa normalizada derivada del libro ya lo trae bien y de forma consistente en TODOS los periodos de los tres dominios. rutap.vehiculo_historial_normalizado tiene raw_tipo_motor y estandar_emisiones_id apuntando al catalogo correcto para los tres. La correccion es alinear vehiculos_datos_colectivos a lo que el libro ya dice, no elegir un valor. CALIFICAR EL JOIN NO ALCANZA Y NO VA SOLO: con el par puesto, estas tres filas pasan de mostrar una etiqueta ajena a mostrar la celda VACIA. Eso las SACA A LA LUZ, que esta bien, pero no las corrige. El orden importa: primero se corrige el dato, despues se califica el join, o se calific a y se corrige en la misma ventana. Si se califica primero y solo, tres fichas de PROD quedan con el campo en blanco. ESCRITURA EN PROD: pide GO explicito y fresco de Elazar. No se toca hasta tenerlo. El join sin calificar de esas dos vistas es MOVILBA-481; este item es el DATO.
Activity
-
db02-mba-l-cc / db
-
parent=MOVILBA-481
-
RETRACTACION, verificada de forma independiente por coder03-mba-l-cc contra PROD (SELECT only), 2026-09-18. Las tres filas de vdc que este item llama 'vivas' estan SOFT-DELETED, las tres con el mismo borrado_en, y sus filas de vehiculos tambien. Nunca estuvieron en pantalla. Las filas VIVAS de los mismos tres dominios ya apuntan al catalogo correcto ('motor','estandar_emisiones') con el valor que este item proponia escribir: el arreglo ya era el estado del dato vivo antes de que se filara el ticket. La escritura en PROD NO se ejecuta. Yo co-firme el hallazgo ('re-verificado por coder03') sin medir borrado_en, asi que la re-verificacion repitio el error en vez de cazarlo. CAUSA, y es lo que sobrevive al ticket: el censo de MOVILBA-481 midio la poblacion sin filtrar por estado, o sea conto filas muertas como corrupcion viva. Es la MISMA clase de sesgo que MOVILBA-486 estuvo cazando toda la manana, corriendo al reves: 486 busca un predicado que EXCLUYE dato vivo, esto es la falta de predicado que INCLUYE dato muerto. La consulta sombra tal como se escribio solo caza la primera direccion. El item de checklist queda doble: correr la poblacion con y sin el predicado de estado, Y decir por que cada fila de la poblacion es una que el negocio considera real. Censo corregido y publicado: docs/reference/movilba-481-opciones-view-join-census.md en dev da1588ae. El JOIN de vdc.estandar_emisiones_id queda como profilactico, se califica con el resto. Cierre del item: es de db02, que ya dijo que lo saca de la cola.
-
AUDIT CONFIRM: retraction verified independently — memory file project_movilba486_go_2026_09_18.md updated same day with the retraction and the bidirectional-shadow checklist extension. No PROD write owed. Closing no-action.
-
False finding: MOVILBA-481's census counted 3 soft-deleted duplicate rows as live corruption (borrado_en not filtered). Live rows for the same 3 dominios already hold the correct estandar_emisiones_id values. Corrected census: docs/reference/movilba-481-opciones-view-join-census.md @ da1588ae.
-
HALLAZGO FALSO - RETIRADO 2026-09-18 por db02-mba-l-cc, verificado independientemente por coder03-mba-l-cc. NO SE EJECUTA NINGUNA ESCRITURA EN PROD. LAS TRES FILAS NO ESTAN VIVAS. vdc 5431/4923/4758 y sus filas de vehiculos estan soft-deleteadas con un unico borrado_en compartido, 2026-05-18 02:45:13. Ninguna pantalla las mostro jamas. La premisa del ticket -'datos incorrectos EN PANTALLA HOY en PROD'- es falsa. LAS FILAS VIVAS DE ESOS MISMOS DOMINIOS YA ESTAN BIEN: 6325/PMH988 = 17 (motor.estandar_emisiones=EURO3), 6022/AF928IF = 59 (EURO5), 6023/AH152NT = 59 (EURO5). Son exactamente los valores que este ticket proponia escribir. La correccion ya era el estado del dato vivo antes de que se abriera el item. CAUSA DEL FALSO HALLAZGO: el censo de MOVILBA-481 midio la poblacion de estandar_emisiones_id SIN filtrar borrado_en, asi que conto tres duplicados muertos como corrupcion viva. La segunda pasada (coder03) re-verifico los ids pero tampoco miro borrado_en, asi que repitio el error en vez de cazarlo - dos carriles, misma omision. LA LECCION, que vale mas que el item: es la MISMA clase de sesgo que estuvimos cazando toda la sesion, corriendo en la direccion CONTRARIA. El shadow-query caza 'un predicado EXCLUYE dato vivo'; esto fue 'la AUSENCIA de predicado INCLUYE dato muerto'. Misma columna, misma confusion, y el shadow tal como estaba escrito solo caza la primera mitad. Checklist ampliado a las dos direcciones: correr las DOS formas de la poblacion, Y decir por que cada fila de la poblacion es una que el negocio considera real. QUE QUEDA VIVO DE ESTO: - docs/reference/movilba-481-opciones-view-join-census.md: fila de estandar_emisiones_id re-veredictada como profilactica, ya amendada por coder03 (dev da1588ae). - Las 3 filas muertas son parte de la poblacion de 18 de MOVILBA-486 section 10 (duplicados superados, cada dominio con su fila viva, cero referencias en el historial). Cuando 486 section 10 las borre fisico, estas filas desaparecen y con ellas el sintoma. - Las entradas E3/E5 del catalogo paralelo que estas filas referencian quedan sin referencias una vez borradas -> las hereda MOVILBA-489, mismo patron que chasis id=8.