DEV y PROD corren cuerpos distintos bajo el mismo nombre de vista y el unico control que lo detecto fue Postgres negandose a dropear columnas

MECANISMO: una vista se puede crear o reemplazar directo en una base sin dejar archivo, y nada compara los cuerpos entre DEV y PROD. El nombre coincide, los consumidores compilan, y la diferencia solo aparece cuando alguien la pisa. Medido 2026-09-17 (db02) sobre v_vehiculos_export, al ensayar el apply PROD de MOVILBA-453 (6c789c4e): - fecha_alta: PROD usa COALESCE de un max(fecha_alta) de v_vehiculo_historial filtrado por tramite_id=ALTA con fallback a vdc.fecha_vigencia_desde. DEV usa el CTE de match por chasis contra rutap.v_rutap_latest_norm. Son dos mecanismos distintos, no dos redacciones. - PROD no tiene el join a periodo_veh: op_piso/op_aire salen directo de ca. DEV los toma con COALESCE del periodo vigente. - PROD tiene 4 columnas que DEV no: vdc.sube_mounting_kit, vdc.sube_id_validadora, vdc.openpass_mounting_kit, vdc.openpass_id_validadora. - Ningun archivo de docs/migrations/ referencia la logica especifica de ninguna de las dos formas. LO QUE HAY QUE LEER DE ESTO no es que el chequeo previo fue corto. El chequeo previo fue un LIKE sobre un substring ('vdc.fecha_vigencia_hasta AS fecha_baja'), que matcheaba en las dos bases y por eso dijo 'identicas'. Lo que paro el apply fue CREATE OR REPLACE VIEW abortando con 'cannot drop columns from view'. Es decir: el unico control efectivo fue el motor. Si las listas de columnas hubieran coincidido por casualidad, el REPLACE entraba, cambiaba en silencio como PROD calcula fecha_alta, y no quedaba ninguna fila que lo dijera. Un control que solo actua cuando el cambio ademas borra columnas no es un control sobre el cuerpo. Precedente identico de la misma semana: v_vehiculos_ciclo_actual, la unica de las 18 vistas que leen la ficha y los reportes sin ningun archivo en docs/migrations/ (ahi DEV y PROD SI coinciden, md5 77b388c7605c924781cef919afcdf040; acta en docs/migrations/2026-09-17-v-vehiculos-ciclo-actual-cuerpo-instalado-RECORD.md, commit 1f96cecd). Un barrido por NOMBRE da verde en los dos casos. El nombre no es el objeto. DENOMINADOR PEDIDO (db02, solo lectura): md5 de pg_get_viewdef(v, true) en DEV y en PROD, lado a lado, para cada vista que consumen la ficha (page.tsx, src/actions/vehiculos.ts) y los reportes/repositorios (liquidacion.ts, vehiculos.ts, parque-movil.ts, rutap-historial.ts). Hoy sabemos de 1 que difiere y 1 que coincide sobre 18. Sin el resto, cualquier afirmacion sobre 'la deriva' es sobre dos casos. NO ES PARTE DE ESTE ITEM decidir que forma gana. Que PROD adopte el fecha_alta de DEV, o al reves, es una decision de negocio de Elazar con su propio GO: las dos formas dan fechas distintas para el mismo vehiculo y eso llega al export que mira Eugenia. Este item mide y documenta; no unifica. DEPENDIENTE: el apply PROD de MOVILBA-453 queda frenado hasta que exista un archivo escrito desde el pg_get_viewdef vivo de PROD, tocando unicamente fecha_baja. El GO relayado el 2026-09-17 14:52 fue retirado a las 14:56.