Decidir si la fecha de expediente pasa a ser obligatoria al editar un colectivo

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus note · 5w ago
  ESTADO AL 2026-09-05 09:22. DEV revertido y verificado independientemente: origin/dev es 04c945df 'revert: restore optional history date behavior after MOVILBA-287 (v5.4.237)' y dev01 sirve serviceId 33380, que decodifica a (33380-911)/137 = 237 exacto - o sea el build revertido es el que se esta SIRVIENDO, no solo el que se pusheo. Las ediciones de colectivo vuelven a funcionar. LA DIRECCION DE ESCRIBIR NULL FUE MIA Y ESTUVO MAL, retirada: fecha_baja IS NULL es LA DEFINICION de periodo abierto en los tres consumidores (v_vehiculos_hist_ultimo, la lectura openPeriods del escritor 206, y el invariante de MOVILBA-284), asi que cerrar con NULL no cierra nada - el periodo viejo queda abierto, el nuevo abre al lado y el vehiculo termina con DOS periodos abiertos, que es exactamente la forma de MOVILBA-285 fabricada desde la UI donde no hay ningun gate. audit-mba-l-cc la freno con un bloqueo concreto y coder-mba-l-ca se nego a shipearla; las dos cosas estuvieron bien. SEGUNDO PROBLEMA DEL NULL, independiente: en el insert, la vista termina en ORDER BY h.fecha_alta DESC NULLS LAST, h.id DESC (drizzle/schema.ts:2130) y la lectura en transaccion del escritor es desc(fechaAlta), desc(creadoEn) (src/repositories/vehiculos.ts:847), y el DESC de Postgres es NULLS FIRST por defecto: la vista manda esa fila al final y el escritor la pone primera. App y vista en desacuerdo sobre cual periodo es el VIGENTE. Eso NO es hipotetico y NO depende de esta decision: ya hay 77 filas con fecha_alta NULL (75 de junio mas las dos de UI de agosto). Medicion pedida a db02-mba-l-cc, solo con ROLLBACK. CINCO ATERRIZAJES DEL FALLBACK, no uno - grep de todo el repositorio de audit-mba-l-cc: src/repositories/vehiculos.ts:336, :659, :787, :1050 y src/actions/vehiculos.ts:382. Lo que Elazar decida aplica a los cinco. RECOMENDACION: opcion B, campo de fecha en la pagina de edicion en el mismo parche, que es la unica forma de terminar con la fabricacion sin romper ni la vigencia ni la superficie de edicion.
• wi-cli-venus verified · 5w ago
  BASELINE CONTRA v5.4.237, CIEGA AL CREADOR, tomada por db02-mba-l-cc el 2026-09-05 09:23:38 ART sobre 10.9.10.54/movilba_dev. Version re-derivada por ellos, no tomada de mi cifra: dev01/api/health serviceId 33380 -> (33380-911)/137 = 237 exacto. 6099 filas, max_id 18141, identico a la lectura contra 236, o sea no se escribio nada entre las dos. (1) fecha_baja = CURRENT_DATE, cualquier creador = 2, ids 9654 y 18139. (2) fecha_alta = CURRENT_DATE, cualquier creador = 2, ids 18139 y 18141. Controles positivos sobre CURRENT_DATE - 1: 5 y 5, o sea ninguno de los dos instrumentos puede devolver solo cero. Las dos definiciones son ciegas al creador A PROPOSITO: el par viejo filtrado por creador (15/1) queda RETIRADO para el lado del cierre, porque un cierre es un UPDATE de otro actor y creado_por dice quien CREO la fila; sobrevive solo como cifra del lado de la apertura, donde el filtro si es valido porque el creador de la fila es quien escribio fecha_alta. LA ASERCION CONTRA LA QUE SE DECIDE 288: despues de que aterrice cualquier parche, NINGUNO de esos dos conteos crece en un dia sin escritura de fixture. Las cuatro filas preexistentes son hechos historicos del codigo anterior a 237 y ningun parche las saca. NO EJERCITADO: PROD sin medir; db02-mba-l-cc no leyo 1e9e657f ni 04c945df.
• wi-cli-venus note · 5w ago
  Medicion coder02 2026-09-08 03:46 contra dev/dev: el INTERINO que esta descripcion da por aplicado NO esta en el codigo shipeado. git show dev/dev:src/repositories/vehiculos.ts muestra CURRENT_DATE vivo en :492 (alta generica, incondicional), :819 (alta canonica de colectivo, fechaExpediente || CURRENT_DATE), :980 (createHistorialRecord, incondicional) y :1162 (comparacion en la edicion, que ademas alimenta lo persistido). O sea: o nunca se aplico o se revirtio, y la descripcion de este item afirma un estado del mundo que no existe. Es el mismo defecto que MOVILBA-349 volvio a levantar por otro camino, asi que 349 es el trabajo y este item es la decision.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• coder03-mba-l-cc note · 2w ago
  2026-09-28 13:30 ART, coder03-mba-l-cc. Elazar routed this to Eugenia, not to himself: written into 'Para Eugenia' as question 90, state PENDIENTE. The 2026-09-05 premise is STALE and was not repeated in the question - the edit form DOES carry fechaExpediente today, and the page moved from [id] to [dominio]. Measured state now, src/app/vehiculos/[dominio]/editar/colectivo/page.tsx:613-627: the expediente NUMBER is always required on edit; the expediente DATE is required only when the change is a Baja, so an ordinary Modif can omit it and the period ends up dated by clock instead of by the tramite. That is what question 90 asks about. Distinct from question 87 (MOVILBA-547), which is about FUTURE dates, not obligatoriedad. Written is not asked: the workbook on disk carries it, the online copy is a separate step Elazar still owes.
• coder03-mba-l-cc blocked · 2w ago
  Awaiting Eugenia's answer to question 90 in the tracker.
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03-mba-l-cc unblocked · 2w ago
  Eugenia contesto, 2026-10-01, Para Elazar fila 55: 'Al generar una modificacion el campo fecha del expediente tambien debe ser obligatorio'. Es la respuesta a la pregunta 90 de Para Eugenia, que seguia PENDIENTE porque la copia online no la tenia; llego por el otro lado, como pedido propio. Queda decidido: la fecha de expediente es obligatoria tambien en la edicion, no solo en la baja. Ejemplo que mandaron: https://dev01.movilba.com/vehiculos/EG111AE/editar/colectivo
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca / coder
• coder03-mba-l-cc note · 2w ago
  Reasignado del carril db al carril coder: no hay cambio de base. db04 midio el alcance real, 2026-10-01 - src/app/vehiculos/[dominio]/editar/colectivo/page.tsx:621 exige fechaExpediente solo cuando el tramite es Baja, y src/repositories/vehiculos.ts:1469 cae a fechaHoy cuando viene vacia. Esa caida a la fecha de hoy es lo que hace que el periodo quede fechado con el dia de carga y no con el del tramite, asi que el arreglo son tres capas: el formulario, el contrato de la accion y el escritor. Sacar el fallback sin hacer obligatorio el campo rompe la carga; hacerlo obligatorio sin sacar el fallback deja el defecto vivo para cualquier otro camino de escritura.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 10:53 ART. Eugenia's new rule (Para Elazar row55) applies to the manual collective edit path. Current checkout src/app/vehiculos/[dominio]/editar/colectivo/page.tsx:621 requires fechaExpediente only when esBaja; src/repositories/vehiculos.ts:1469 still falls back to fechaHoy when it is absent. This is UI/action/writer TypeScript scope, not DB DDL/data; I asked coder03 to assign a coder lane. No application code or database change made by db04.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01. Implementado por mi: el carril asignado no produjo nada en tres rondas y la regla de tope de broadcast prohibe una cuarta. Diff en el checkout, 4 archivos, 32 inserciones / 10 borrados, sin cambio de base y sin DDL. El gate queda en DOS capas, no en una: src/services/vehiculos.ts updateColectivo rechaza fechaExpediente ausente o vacia antes de validarFechaExpediente -que tenia un early return en vacio, que es exactamente por donde se colaba-, y src/repositories/vehiculos.ts applyColectivoEditWithHistory vuelve a rechazarla y pierde el fallback a CURRENT_DATE, que era lo que fechaba el periodo con el dia de carga. El mensaje de formato malo queda textual para no romper tools/tests/colectivo-save-errors.test.cjs:92, que lo compara literal; el de ausencia es nuevo y distinto. Alcance medido: applyColectivoEditWithHistory tiene UN solo llamador -services/vehiculos.ts:917- y updateColectivo tambien uno -actions/vehiculos.ts:624, el server action del formulario-, asi que no hay ruta de API ni segunda superficie de escritura que esquive el gate. El camino de ALTA queda INTACTO a proposito: la decision de Elazar dice modificacion, y repositories/vehiculos.ts:1020 tiene el mismo fallback -fechaAlta: fechaExpediente || CURRENT_DATE- en el alta, que NO toco y queda como item aparte si el lo quiere. Tambien: src/types/vehiculos.ts documentaba que la fecha es opcional por pedido de Eugenia. Ese comentario queda reescrito con la decision del 2026-10-01 que lo da vuelta, porque un comentario que contradice el codigo es el defecto siguiente. NO EJERCITADO: no corri ningun gate -no me corresponde- y no vi al control FALLAR contra el comportamiento anterior en una pantalla real. Nadie guardo una modificacion sin fecha para comprobar que ahora la rechaza.
• coder03-mba-l-cc assigned · 2w ago
  coder03-mba-l-cc / coder
• audit-mba-l-cc audited · 2w ago
  audit fail: Ran test:tools full suite (98 pass/3 fail), confirmed via git stash that HEAD is 101/101 clean
  payload

  {"scope":"Ran test:tools full suite (98 pass/3 fail), confirmed via git stash that HEAD is 101/101 clean","outcome":"fail","evidence":"colectivo-expediente.test.cjs:159 x3 fail: actualizarColectivo edit calls with no fechaExpediente now get VALIDATION_FAILED from the new service gate, unconditionally for every edit not just period/baja edits","reportRef":null}

• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01. Respuesta al FAIL de audit: el radio de accion es el buscado, no un desborde. La decision de Elazar es 'al generar una modificacion el campo fecha del expediente tambien debe ser obligatorio', y TODA pasada por updateColectivo genera una modificacion -escribe un evento de historial con tramite MODIF y un periodo-, asi que no hay edicion por este camino que no sea un tramite. Estrechar el gate a 'solo si cambia un campo que define el periodo' seria inventar una distincion que nadie fallo, y ademas no describe lo que hace el repositorio, que fecha el periodo en cada edicion sin mirar que campo se movio. El expediente mismo ya era obligatorio sin condicion en el renglon de arriba por la misma razon. Los tres casos que fallaban eran fixtures que codificaban la opcionalidad vieja, no evidencia independiente: 'create and edit preserve literal' mide que el literal del expediente no se normaliza, y hacia la edicion sin fecha. Pasan a mandar la fecha de hoy, con el motivo escrito al lado para que no se lea como relleno. Agregado el control negativo que faltaba, al nivel que este harness alcanza: 'edit requires the expediente date on any field, not only on a baja' recorre undefined, null y cadena vacia -sanitizeString manda las tres a null-, exige que la edicion falle con el mensaje de obligatoriedad, exige CERO escrituras, y recien despues con la fecha puesta exige una. Visto FALLAR, no solo pasar: sin el gate del servicio las tres ramas escribian. SIGUE SIN EJERCITAR, y pido que quede en el --scope: 1) el gate del REPOSITORIO y la perdida del fallback a CURRENT_DATE, porque el harness mockea applyColectivoEditWithHistory y nunca llega ahi; 2) la pantalla real -nadie guardo una modificacion sin fecha en dev01 para verlo rechazar.
• audit-mba-l-cc audited · 2w ago
  audit pass: test:tools 102/102, typecheck clean, lint clean on 5 touched files. Verified service-gate negative control now exercised (undefined/null/empty all FAIL, writes=0, then PASS)
  payload

  {"scope":"test:tools 102/102, typecheck clean, lint clean on 5 touched files. Verified service-gate negative control now exercised (undefined/null/empty all FAIL, writes=0, then PASS)","outcome":"pass","evidence":"Blast radius confirmed intentional and consistent with pre-existing unconditional expediente gate one line above; repository gate + CURRENT_DATE removal and real-screen save remain unexercised, as coder03 flagged","reportRef":null}

• coder03-mba-l-cc completed · 2w ago
• coder03-mba-l-cc note · 2w ago
  Shipped. dev 7ab3e030 y main f64d209f, patch 125. app.movilba.com y dev01 sirven 125, verificado por el gate de salud del propio script; la pata del pod quedo pedida al proxy en whey en el mismo turno, que es quien llega a ASI. Audit PASS en bwi, test:tools 102/102, typecheck y lint limpios en los cinco archivos. Queda abierto como item aparte el mismo fallback en el camino de ALTA -repositories/vehiculos.ts:1020, fechaAlta: fechaExpediente || CURRENT_DATE-, que no toque porque la decision de Elazar habla de modificacion.
• coder03-mba-l-cc note · 2w ago
  Pata del pod cerrada: la 125 quedo absorbida por la 126 y las tres superficies sirven el mismo build -app.movilba.com, dev01 y permisos-movilba-dev.gcba.gob.ar en 126, serviceId 18173-. El retraso no era del fix: el build del pod fallaba por MOVILBA-639.