CERRADO sin defecto (Elazar): no hay historia que preservar antes del go-live; el entregable es que el catalogo sea el SSOT normalizado, y lo que falte se re-crea

DEFECTO VIVO CREADO POR LA APLICACION DE MOVILBA-377 EN DEV, 2026-09-08 07:47. Medido por db02-mba-l-cc contestando el punto 4 que pidio Elazar ("make sure they are re-assigned to proper ids"). No reparado en linea, a proposito. QUE PASO: dos tablas guardan carroceria_id SIN foreign key, y despues del borrado de las 53 apuntan a filas que ya no existen. - public.vehiculos_archive: 9965 filas con 51 ids distintos huerfanos. - public.parque_rutap_temp: 1300 filas con 49 ids distintos huerfanos. ATRIBUCION, sin ambiguedad: los 51 ids huerfanos estan TODOS dentro de las 53 que se borraron, y CERO caen fuera de ese conjunto. Antes del apply existian todos los ids 1-74, asi que nada podia estar huerfano. Lo creo el apply de 377. LA CAUSA DE METODO, y es la que hay que aprender: el preflight midio referencias SOLO por las dos FK DECLARADAS, y el control POST "0 referencias huerfanas" consulto ESAS MISMAS DOS FK. Una guarda que reutiliza el censo que dejo pasar el caso no puede detectarlo. El DELETE nunca iba a ser frenado por una columna entera sin FK, y el post-control paso mientras 9965 filas quedaban colgando. **Un conteo de referencias por pg_constraint mide vinculos DECLARADOS, jamas el uso real de un id.** MI PARTE: yo revise el artefacto entera, verifique la identidad de los 53 ids, y aprobe ese control POST. Nombre la clase de las referencias no declaradas DESPUES del apply, no antes. La forma correcta era exigir el barrido por nombre de columna ANTES de cualquier borrado fisico, y ahora es requisito de MOVILBA-378 para todas las tablas del alcance. IMPACTO EN LA APP, medido por coder02-mba-l-cc en el codigo: MENOR DE LO QUE PARECE, y hay que decirlo con el mismo cuidado. El unico consumidor de vehiculos_archive en src/ es src/actions/audit.ts:31, el historial de auditoria del vehiculo, con RBAC. Ese camino NO joinea contra public.carrocerias: resolveFkLabels solo resuelve ids de tipo_persona y de opciones (FK_TIPO_PERSONA y FK_OPCIONES, linea 38), y carroceria_id no esta en ninguno de los dos conjuntos. O sea que carroceria_id se muestra como ENTERO CRUDO, sin etiqueta, y se mostraba igual ANTES del borrado. No hay pantalla rota, no hay filas que desaparecen, no hay excepcion. LA PERDIDA REAL, entonces, no es de UI sino de TRAZABILIDAD: el archivo guarda el numero de la carroceria que tenia cada vehiculo, y para 9965 filas ese numero ya no nombra nada dentro de la base. Es el registro historico de con que carroceria estuvo un vehiculo. Y ES RECUPERABLE, que es lo unico que salva esto: el pre-estado tiene las 74 filas con id, fabricante y modelo. /data-lezama/import-reports/2026-09-08-movilba-377-carrocerias-pre-estado-DEV.tsv, md5 692e22ef36103e7c78ff56cd93783f4a, modo 600. LA DECISION ES DE ELAZAR, no tecnica: si vehiculos_archive tiene que conservar una carroceria resoluble. Las opciones, sin recomendacion todavia porque falta cerrar la busqueda: A. Congelar el TEXTO en el archivo (fabricante + modelo al momento de archivar) y dejar de depender de un id vivo. Es lo que hace un archivo historico: guarda lo que se vio, no un puntero. B. Revivir en el catalogo solo los 51 ids que el archivo usa. Contradice la politica de MOVILBA-378 y reintroduce lo que se acaba de sacar. C. Aceptar la perdida en DEV y no repetirla en PROD. parque_rutap_temp es staging, sin consumidor en src/, y probablemente no necesita nada - pero eso se decide aparte. BUSQUEDA NO CERRADA, y no se declara exhaustiva hasta cerrarla: db02 barrio las 34 columnas cuyo nombre matchea 'carroceri' (2 con FK, 5 enteras sin FK - las dos de arriba mas bkp.rutap0624_veh_inserted 135 filas 0 huerfanos, bkp.rutap0624rec_veh_postimage 3/0, bkp.rutap0624rec_veh_preimage 3/0) y las 47 columnas jsonb/json fuera de pg_catalog. QUEDA ABIERTO: en public.audit_log.details (193 filas), public.vehiculo_historial.cambios (148) y public.app_logs.data (2451) el match es de la PALABRA 'carroceri', y todavia no se extrajeron los VALORES para ver si alguno es uno de los 53. Las 13 matviews de catalogo leen opciones, no carrocerias. BLOQUEA: MOVILBA-377b y 377c quedan SIN APLICAR hasta resolver esto, porque la misma clase de referencia no declarada aplica a los ids 13, 33, 70 y 72 y todavia no se midio para ellos. PROD NO TOCADO, y esto es exactamente el motivo por el que el borrado fisico se hace primero en DEV.