Una modificación debe cerrar el período anterior y abrir el nuevo con el mismo expediente y fecha
Eugenia confirmó el 2026-09-10 en la pregunta 5 del tracker que una modificación es un único expediente con dos operaciones y la misma fecha: cerrar el período anterior y abrir el nuevo. origin/dev applyColectivoEditWithHistory ya hace ambas operaciones cuando el período vigente es origen=app, pero si el vigente es origen=import conserva la fila importada abierta y solo agrega el período app. Eso deja dos intervalos abiertos aunque el selector oculte uno por prioridad. Corregir el modelo sin alterar rutap.rutap_rows: registrar el cierre efectivo del período importado mediante la representación normalizada/overlay aprobada, y agregar gate que pruebe exactamente un período vigente después de una edición sobre un vehículo cuyo período actual viene del import. Fuente: /data-lezama/movilba/import-reports/2026-09-10-1441-todo-rutap-importacion-prestaciones.xlsx, hoja Para Eugenia, pregunta 5.
Activity
-
parent=#3027
-
Implementation: the edit transaction now closes every older open app overlay for the locked vehicle/domain before inserting the replacement, while imported evidence remains untouched. The rollback rehearsal has a stale-app positive control and asserts one view winner, 1/0 open app periods for MODIF/BAJA, and unchanged import rows. Awaiting one DB rehearsal and one focused diff review before deploy.
-
Shipeado en DEV como 9ea5ab03 (v5.5.136, "MOVILBA-431: close superseded app history periods"). Cerrado por coder02-mba-l-cc a pedido de coder-mba-l-ca, cuyo shim no tiene herramienta de mutacion de bwi; la autoria del trabajo es de coder-mba-l-ca, no mia. Verificado por mi antes de cerrar, no tomado de palabra: el commit existe y es ANCESTRO de origin/dev (de hecho era su punta al momento de cerrar). Reportado por coder-mba-l-ca y NO verificado por mi, queda asi declarado: audit PASS; ensayo real de rollback en DEV PASS (import de origen inmutable, predecesor APP obsoleto cerrado con la misma fecha y expediente, un unico vigente efectivo); dev01 freshness PASS. ALCANCE: esto cierra el trabajo en DEV. El push al pod de GCABA que se pidio para esta misma version quedo BLOQUEADO y no forma parte de este cierre - push-to-gcaba.sh no existe en lezama y un push al pod es outward-facing y dificil de revertir, asi que necesita GO explicito de Elazar nombrando este push y lo ejecuta bin-whey-ca en whey. Un freshness PASS de dev01 es evidencia sobre dev01 y no dice nada de lo que va a servir el pod. MOVILBA-432 lo cierra coder04.