El formulario acepta una fecha de expediente en el ano 3051: nada acota por arriba la fecha de un tramite ya presentado
Medido el 2026-10-01 en DEV mientras se verificaba MOVILBA-451. Dos de los 22 periodos de baja que escribio la aplicacion tienen fecha_alta y fecha_baja en 3051-09-22 y en 3055-05-20, del vehiculo_id 6777, con expediente de baja real (EX-2026-41551499 y EX-2026-00771410, los dos de 2026). Son filas de prueba de DEV y no se tocan, por la regla del 2026-09-24: en DEV no se toca lo que un usuario creo o edito. Lo que importa no es la fila sino lo que prueba del codigo: ninguna capa acota por arriba la fecha del expediente, asi que un dedo torpe en el campo de fecha escribe un tramite a mil anos y la aplicacion lo guarda, lo fecha el periodo con eso y lo imprime en la ficha y en el PDF. El SSOT es un libro de expedientes YA PRESENTADOS, asi que una fecha de tramite posterior a hoy no existe: el limite superior defendible es hoy, y no hay una segunda lectura razonable del limite. Donde mirar: validarFechaExpediente, que MOVILBA-288 acaba de volver obligatoria en toda modificacion pero que solo valida forma, y el camino de alta, que sigue con el fallback a CURRENT_DATE y es el objeto de la decision abierta de MOVILBA-638. Alcance pedido: rechazar en el servicio una fecha de expediente posterior a la fecha de hoy, con el mensaje en castellano, mas el control negativo visto FALLAR contra el comportamiento de hoy. No arreglar el dato de DEV. PROD no tiene filas de historial de origen app, asi que ahi no hay nada escrito con esta forma todavia.
Activity
-
coder03-mba-l-cc 2026-10-01 16:30: FALSE DEFECT, filed by me and retracted by me in the same round. The upper bound already exists and has existed since before I filed this. src/services/vehiculos.ts:107-109 rejects any fecha de expediente greater than fechaHoyEnBuenosAires() with 'La fecha del expediente no puede ser posterior a hoy', and it runs on both write paths, creation at :484 and edit at :818. It landed in 03155317 on 2026-09-24 as MOVILBA-547, with Elazar's criterion of today inclusive and no forward grace window, and the today is computed in America/Argentina/Buenos_Aires rather than from the server clock. The two DEV rows that made me file this were written on 2026-09-22 15:09 and 15:11, two days BEFORE that bound shipped, on vehiculo_id 6777, history ids 286437 and 286438. They are residue of the old behaviour, not evidence about the installed code. That is the whole lesson: a bad row in DEV dates the defect, it does not prove the defect is still there, and I skipped the one cheap step - git log -S on the error message - that would have told me before I opened an item. The rows themselves stay as they are: DEV data a user created is not touched. One real hole stays open and is NOT this item: src/services/validadoras-vehiculo.ts:169 accepts a fechaExpediente and never calls validarFechaExpediente, so that path has no bound at all. It is unreachable today because validadoras are hidden on every surface, and the standing rule is that validadoras are hidden and not otherwise modified, so nothing is to be changed there now. Whoever un-hides validadoras has to bring that path under the same validation; that belongs to the MOVILBA-580 epic, not here.
-
False defect, retracted with the measurement in the note: the bound shipped 2026-09-24 in MOVILBA-547 and the DEV rows that prompted it were written 2026-09-22.