Paso 5 de MOVILBA-299 bloqueado: 27 vistas dependen de vehiculo_historial y el export sigue leyendo cambios - falta la migracion que las recree sobre la tabla ancha
MEDIDO por db03-mba-l-ca el 2026-09-07 en movilba_dev, sin escribir nada: pg_depend recursivo da 27 vistas dependientes (28 relaciones contando la tabla) sobre public.vehiculo_historial. Lectores directos: v_vehiculo_historial, v_vehiculo_cadena, v_vehiculos_hist_ultimo, v_vehiculos_detalle, el camino de export/API y la vista nueva de conteo. La columna cambios (jsonb) la referencian directamente v_vehiculo_historial y v_vehiculos_detalle. Un DROP pelado falla y CASCADE romperia la ficha - db03 se nego a usar CASCADE, que es la decision correcta: CASCADE habria dropeado las 27 sin nombrarlas y la rotura habria aparecido como un 500 en la ficha horas despues, no como un error en la corrida. Objetos protegidos verificados intactos: rutap.rutap_rows=16126, respaldo.m248_wide=472, m248_legacy=416, m255_pares=108. Ademas NO existe script de DROP con SHA: el unico archivo del paso es docs/migrations/2026-09-06-movilba-299-historia-ancha-app-writes-DEV.sql y no contiene el drop, o sea el GO que relaye era sobre un artefacto inexistente. MI PREMISA ERA FALSA, y es el hallazgo que importa: le dije a db03 que nada vivo deberia estar leyendo lo que se iba a dropear. El corte del paso 2 movio LA FICHA a getRutapHistorialByChain sobre la tabla ancha, y yo lo lei como "el paso 2 esta cerrado". Esta cerrado para la PANTALLA y NO para el EXPORT: getVehiculoHistorial y vVehiculoHistorial siguen vivos en el codigo - los usa el PDF en src/app/vehiculos/[dominio]/page.tsx - y leen v_vehiculo_historial, que lee la columna cambios. Un corte medido sobre una sola superficie no es un corte. Lo que falta antes de volver a pedir un GO de paso 5, las tres cosas juntas: (1) reapuntar a la tabla ancha los lectores de codigo que quedan, empezando por el camino del PDF; (2) una migracion que RECREE las 27 vistas sobre rutap.vehiculo_historial_normalizado ANTES del drop, verificada con el diff destino-contra-archivo por pg_get_viewdef en una transaccion con rollback, nunca diff de texto; (3) el contrato de app que cada vista tiene que seguir cumpliendo, para que la recreacion se pueda verificar contra algo y no contra una impresion. El paso 5 sigue siendo el unico paso irreversible del plan y no se corre hasta que esto exista.
Activity
-
was: MEDIDO por db03-mba-l-ca el 2026-09-07 en movilba_dev, sin escribir nada: pg_depend recursivo da 27 vistas dependientes (28 relaciones contando la tabla) sobre public.vehiculo_historial. Lectores directos: v_vehiculo_historial, v_vehiculo_cadena, v_vehiculos_hist_ultimo, v_vehiculos_detalle, el camino de export/API y la vista nueva de conteo. La columna la referencian directamente v_vehiculo_historial y v_vehiculos_detalle. Un DROP pelado falla y CASCADE romperia la ficha - db03 se nego a usar CASCADE, que es la decision correcta. Ademas no existe script de DROP con SHA: el unico archivo del paso es 2026-09-06-movilba-299-historia-ancha-app-writes-DEV.sql y no contiene el drop. MI PREMISA ERA FALSA: le dije a db03 que nada vivo deberia estar leyendo lo que se iba a dropear. El corte del paso 2 movio la ficha a getRutapHistorialByChain sobre la tabla ancha, pero getVehiculoHistorial/vVehiculoHistorial siguen vivos en el codigo - los usa el PDF en [dominio]/page.tsx - y esos leen v_vehiculo_historial, que lee . O sea el paso 2 esta cerrado para la PANTALLA y NO para el export. Lo que falta antes de pedir un GO nuevo de paso 5: (1) reapuntar los lectores de codigo que quedan a la tabla ancha; (2) una migracion que RECREE las 27 vistas sobre rutap.vehiculo_historial_normalizado antes del drop, con el diff destino-contra-archivo por pg_get_viewdef y no por texto; (3) el contrato de app que cada vista tiene que seguir cumpliendo. El paso 5 sigue siendo el unico irreversible del plan y NO se corre hasta que esto exista.
-
coder03-mba-l-cc / coder
-
coder02-mba-l-cc
-
RE-MEDIDO 2026-09-18 antes de tocar nada: la premisa del ticket esta STALE. MOVILBA-441 (cutover distinto, aplicado en DEV 09-16 y PROD 09-17, gate 3 cerrado end-to-end via saga 441->453->459->445->461) ya hizo el DROP de public.vehiculo_historial como tabla base y reapunto los 11 lectores directos + v_vehiculos_hist_ultimo a una cadena de vistas de compatibilidad sobre rutap.vehiculo_historial_normalizado. Medido HOY, SELECT-only, DEV: - to_regclass('public.vehiculo_historial') IS NULL - tabla base ya no existe. - pg_depend/pg_rewrite recursivo sobre rutap.vehiculo_historial_normalizado (fuente unica real hoy): 10 vistas, no 27 - el numero de 27 media contra un objeto que ya no existe. - Ningun archivo en src/ (origin/dev) lee v_vehiculo_historial ni getVehiculoHistorial/vVehiculoHistorial como QUERY (solo la definicion auto-generada en drizzle/schema.ts, que introspect.sh regenera). El path de PDF/ficha ya usa getRutapHistorialByChain. - El bug real que quedo del cutover de 441 (regexp de rewrite mato un literal 'vehiculo_historial' dentro de un lookup de catalogo, MOVILBA-459) esta corregido y verificado en vivo: v_vehiculos_export ya no tiene ese literal. - La columna cambios sigue existiendo SOLO como campo de compatibilidad en public.v_vehiculo_historial (vista, no tabla) para lectores viejos; ningun writer de app la escribe. La quimera de fila de MOVILBA-315 (COALESCE por columna) tambien quedo obsoleta: public.v_vehiculo_historial_normalizado_actual resuelve el periodo vigente sobre UNA sola fuente (rutap.vehiculo_historial_normalizado_fuente_actual), no dos capas. CONCLUSION: el objetivo de este ticket - una sola capa de historial - esta CUMPLIDO por 441, ejecutado por otro carril mientras este ticket seguia en backlog. Lo unico que sigue abierto y NO es parte de este ticket: MOVILBA-461 (clasificacion Alta vs Modificacion en pase de dominio) y MOVILBA-453 (reporte de compensaciones), que son consecuencias de negocio expuestas por el modelo correcto, no huecos de la capa de historial. Cierro este ticket como DONE, superseded by MOVILBA-441.
-
unassigned
-
coder02-mba-l-cc
-
Superseded by MOVILBA-441 (already applied DEV+PROD, gate 3 closed end-to-end via saga 441->453->459->445->461). Single history layer objective is met; see note above for full measurement.