'Vigencia hasta' no existe en el modelo de la stakeholder: es el cierre del registro, no el fin de la vigencia

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus statusChanged · 2026-08-20
• wi-cli-venus note · 2026-08-20
  Shipeado a dev01 v5.3.260 (d516f8d3) y v5.3.261 (c1d4fa4c): 'Vigencia hasta' fuera de pantalla y del PDF; 'Informacion Operativa' partida en atributos del vehiculo vs tarjeta 'Estado Actual' con el tramite vigente; la tarjeta 'Estado' de un solo renglon se elimino y 'Estado actual' encabeza 'Informacion General'. En review con db03 (mediciones) y audit (diff). Prod sin tocar.
• wi-cli-venus note · 2026-08-20
  db03 midio (2026-08-20 15:36, prod y dev): fecha_vigencia_hasta no NULL = 137 en prod, 0 en dev. Los 137 son EXACTAMENTE el mismo conjunto que los 137 con expte_baja: interseccion 137, solo-fecha 0, solo-expediente 0. Y los 137 valores coinciden uno a uno con COALESCE(fecha_baja, borrado_en::date) de la fila abierta del historial. O sea que fecha_vigencia_hasta es el cierre escrito por tercera vez y no aporta informacion. El ticket deja de ser de rotulo y pasa a ser de columna muerta: candidato a DROP, con GO y despues de confirmar que nada mas la lee. Caso de referencia en prod: /vehiculos/3793 (AE060XC), desde 2025-12-29, hasta 2026-08-07. Segundo hallazgo, separado: dev NO puede ejercitar la ficha de un vehiculo dado de baja. El libro RUTAP de dev SI tiene los datos (3487 fecha_baja, 3215 expte_baja) y vehiculo_historial de dev tiene 2120 expte_baja, pero el historial de dev tiene CERO fecha_baja (los cierres siguen en borrado_en, que es MOVILBA-83) y la tabla de colectivos de dev tiene cero fecha_vigencia_hasta y cero expte_baja. No es ausencia de fuente ni de dump: los campos de cierre nunca se copiaron a dev. Consecuencia practica: el renglon condicional 'Expediente de Baja' que se agrego hoy no se ve en dev01 en ninguna de las 1603 fichas, y una demo a la stakeholder sobre un vehiculo de baja no se puede hacer en dev01.
• wi-cli-venus note · 2026-08-20
  Se saca 'Ultima Actualizacion' de la ficha, del PDF y del formulario de edicion del colectivo (v5.3.265). Evidencia de db03: ningun trigger toca vehiculos.fecha_ultima_actualizacion en dev ni en prod, la app no la escribe en ningun lado (grep completo de repositories/services/actions), la columna tiene DEFAULT CURRENT_DATE. Distribucion: 16 fechas distintas para 1736 vehiculos de prod, 1094 de ellos en un solo dia (2025-12-08). Y 1015 vehiculos de prod (~59% de los activos, 1618 filas) tienen un tramite POSTERIOR a esa fecha. El rotulo era falso para la mayoria del parque. La fecha real de ultima actualizacion es la del tramite mas reciente y ya se ve en el historial. La columna NO se toca: sigue en la base y en el repositorio.
• wi-cli-venus note · 2026-08-20
  Direccion de la brecha dev/prod RESUELTA (Elazar, 2026-08-20): prod NO esta atrasado. Eugenia no veia ninguna baja, asi que se tomo el excel mas reciente y se importo EN PROD. Dev es la copia vieja y su dato es descartable. El refresh corre PROD -> DEV y no escribe una sola fila en prod. Verificacion de db03 antes de habilitarlo (SELECT only): - Catalogo alineado: 193 claves naturales (grupo_nombre, campo_nombre, valor_opcion) compartidas, CERO con id distinto, y el estado de soft-delete coincide en las 193. Las columnas *_id se pueden mover entre entornos sin remapear. Hay 2 opciones que existen solo en dev (vivas) y ninguna solo en prod: eso solo importaria en una copia dev->prod. - La clave de cruce es , NO chasis. El chasis no es unico: 130 duplicados activos en prod y 2 en dev; el join dev->prod por chasis da 1732 pares para 1600 valores distintos y 132 ids distintos en 131 claves ambiguas. 1600 de los 1603 dominios de dev existen en prod y todos ellos ya tienen el MISMO vehiculos.id. 3 dominios de dev no existen en prod. - Fuera de alcance: vehiculo_historial.tramite_id viaja al reves (dev 3859, columna ausente en prod) y sale por MOVILBA-94 con su propio GO.
• wi-cli-venus note · 2026-08-20
  Correccion de la nota anterior, que perdio una palabra por sustitucion del shell: la clave de cruce es DOMINIO, no chasis.
• wi-cli-venus note · 2026-08-21
  IMPORT RUTAP 16:01 APLICADO EN DEV - 21:56, md5 2c1e876fb7eef0cb9932b3f90ebdb072, GO de Elazar 21:20 + firma de db + GO de audit (tercera lectura; dos NO-GO previos con hallazgos reales corregidos). Cifras identicas ensayo=apply, contra-medidas por db con queries propias: historial 3963->3968 filas, fecha_baja 0->2272, expte_baja 2120->2190, tramite_id 3859->3871; vdc cierres 0->7. CIFRA DE ACEPTACION: fichas vigentes con cierre visible 0->7. Dev-only PAN219/ZZ001ZZ/ZZ002ZZ sin una sola escritura (verificado por manifiesto). Residual 15 filas listadas; 1217 filas/788 dominios sin vehiculo en dev a TSV; Hoja2 fuera de alcance declarado. Manifiestos bkp.rutap1601_* intactos (unica via de rollback). TSVs en /resource/movilba/import-reports/. Hallazgo colateral de db, no bloqueo: 11 filas de ZZ001ZZ/ZZ002ZZ traen tramite_id/expte_baja de AE801OE por el backfill de la tarde (clave por chasis compartido 8BBC67B1ALM001636 - la misma debilidad que audit cazo en A2); fecha_baja intacta, cierres no inventados; limpieza como item propio con owner db.
• wi-cli-venus completed · 2026-08-21
  Shipped to prod: main c7b4f22d, v5.4.12, 2026-08-21 07:58 ART. Estado Actual es la ultima tarjeta de la ficha, a 3 columnas, con Observaciones del tramite vigente adentro como renglon. El PDF gana el campo.