El proximo import RUTAP revierte MOVILBA-248 en silencio: el loader reescribe las tipadas desde las raw y ningun gate lo mira
db02, 2026-09-05, DEV. MOVILBA-248 se APLICO en DEV (commit 02ffe61c, md5 2925037981fee9e042bbf57d04ef93c8, EXIT=0). Post-estado verificado por db02 de forma independiente: 0 celdas tipadas con la frase, 472 filas del espejo raw que SI la conservan (a proposito, es lo que sostiene el DOWN), respaldo.m248_wide 472 / m248_legacy 416, 28 observaciones con salto de linea (18 ancha + 10 legacy) donde antes habia CERO. EL RIESGO: EL PROXIMO IMPORT REVIERTE LA CORRECCION EN SILENCIO. El loader escribe las columnas tipadas desde las raw; las raw siguen trayendo la frase en las 472 filas por diseno. Corrido un import, la frase vuelve a 474 celdas de expediente, las 28 observaciones de dos lineas quedan como huerfanas (el texto appendeado no se borra) y el estado resultante NO es ni el de antes ni el de despues. Nadie se entera hasta que alguien abre una ficha. NADA LO VIGILA. Los dos gates del libro (rutap-fidelidad.py, rutap-membresia.py) leen v_vehiculos_export, que resuelve esas tres columnas contra vehiculos_datos_colectivos - db02 lo midio: 2411 filas, 0/0/0 de cambio por esta migracion, con control positivo que da 1/1/1. O sea son ciegos a esto por construccion, no por omision. Y el archivo de migracion no se vuelve a correr. DOS SALIDAS, hay que elegir una y ESCRIBIRLA, no asumirla: (a) el transform del loader aterriza ANTES del proximo import - spec en docs/reference/movilba-248-loader-transform.md, escrita y NO implementada; o (b) algo frena el import hasta entonces. Es decision de coder02 y de Elazar. NO BORRAR respaldo.m248_wide NI respaldo.m248_legacy: son el DOWN, y para las filas legacy 7912, 8372, 8373, 9656 y 9662 son la UNICA copia que va a existir - el libro no puede reconstruirlas. NO CUBIERTO: PROD (la migracion es DEV-only por su propio guard). El renderer del PDF. Y las 28 filas en pantalla, que son una PREDICCION desde white-space: pre-line (globals.scss:2529-2530) y no una observacion: hasta hoy no existia ninguna observaciones de dos lineas en esta base.
Activity
-
Riesgo eliminado en el camino de import, no documentado. Commit a2649f19, v5.4.193, aplicado en DEV. Migracion 248c crea tres funciones IMMUTABLE en rutap: frase_modificacion_empresa(), expediente_desde_libro(text) y observaciones_desde_libro(obs,ea,eb), con NUEVE controles ejercitados en la misma transaccion antes del COMMIT - un CREATE FUNCTION siempre pasa y no prueba nada. Los dos writers SQL del camino de import ahora las llaman: el writer del snapshot ancho deriva las tres columnas por funcion, y tools/rutap-sync-prod.sql deriva ea/eb en la linea 141, que es el unico punto donde el libro aporta esas columnas a todo ese script. Las columnas raw_* no pasan por el transform y siguen siendo el espejo verbatim. Funcion y no un CASE pegado: el writer del snapshot es un archivo FECHADO que se COPIA para cada snapshot, y un CASE pegado muere en la primera copia que alguien tome de una version vieja, en silencio, porque no falla - simplemente vuelve la frase. PRUEBA: se corrio el writer recableado contra DEV con COMMIT reemplazado por ROLLBACK, midiendo DENTRO de la transaccion. 5370 filas insertadas, 0 expedientes tipados con la frase, espejo raw 472, 0 cadenas vacias, 18 observaciones multilinea. Un re-import ahora es IDEMPOTENTE respecto de 248 en vez de revertirlo. Falso positivo que casi reporto: esperaba 472 observaciones con la frase y dieron 3256. El writer estaba bien y mi expectativa mal - el LIBRO ya trae la frase en Observaciones en 3084 filas por su cuenta, mas las 172 que 248a movio y no la tenian, da exactamente las 3256 que hay hoy. PROD queda pendiente y anotado en docs/migrations/pending-prod-changes.md: las funciones no existen ahi, asi que rutap-sync-prod.sql fallaria con 'function does not exist' sin escribir nada, que es el modo correcto. Orden: funciones, despues las filas (248a y 248b con cifras de PROD, no las de DEV), despues cualquier import. GO propio nombrando PROD.