movilba
MOVILBA-317
La pantalla de editar colectivo no manda expediente, fechaExpediente ni motivoTramite: toda baja de la app es inatribuible y fechada por reloj
Done high
cmcoder03-mba-l-cc
EJERCITADO en runtime 2026-09-08 05:39-05:42 (proxy-mba-w-cc, cuenta de Elazar - dev01 se opera con esa cuenta, la base no testifica el operador humano) sobre vehiculo 3346/AA013AD, periodo abierto real con expte_alta EX-2026-07797873-GCABA-DGGSM. Dos saves via /vehiculos/[dominio]/editar/ colectivo -> Registrar Expediente, orden modif-luego-baja. MODIFICACION (05:39, requestId 8dd95252): expediente/fecha dejados en blanco -> NO bloquea (confirma que son opcionales en modif). Crea historial id 177665 (fecha_alta hoy, expte_alta NULL, tramite vacio - sin tag ALTA/MODIF falso). audit_log.details = {changes:[observaciones], operation: append-edit-event} - nombra el campo, no un conteo. NO cierra ningun periodo previo (los Modif abiertos preexistentes 159645/78728/73353/51871 siguen con fecha_baja NULL - append, no close, en la rama no-baja). BAJA (05:42, requestId 8946e992): estadoId->117(BAJA), expediente EX-2026-08123456-GCABA-DGGSM, fecha 2026-09-08. DOS escrituras: (1) UPDATE historial 177665 (operation=close-period-baja): fecha_baja=2026-09-08, expte_baja=EX-2026-08123456-GCABA-DGGSM - el expediente de ESTA baja cierra el periodo anterior, YA NO expte_baja NULL incondicional (defecto original). (2) CREATE historial 177666: expte_alta NULL, expte_baja=mismo EX, fecha_baja=2026-09-08, tramite vacio - periodo propio de la baja, cerrado de nacimiento, no abre nada. PARES DE VALORES (lo pedido, no conteos): fecha_baja=expte_baja en ambas filas cerradas = la fecha y el expediente que proxy tipeo, no CURRENT_DATE ni NULL - el defecto original (expte_baja NULL incondicional; fecha_baja=RELOJ) no reproduce. COBERTURA - limite del ensayo: proxy tipeo la fecha de HOY para la baja, asi que esta corrida NO distingue 'fecha de negocio' de 'CURRENT_DATE' - son el mismo valor por coincidencia. Cerrado por lectura de fuente en cambio: repositories/vehiculos.ts:1165, dev HEAD 4e413373 - 'fechaEvento = data.fechaExpediente ? asFecha(data.fechaExpediente) : fechaHoy', el fallback a fechaHoy solo corre cuando fechaExpediente esta AUSENTE, confirmado por precedencia de codigo, no por una fecha distinta ejercitada en vivo. No ejercitado: una fecha de negocio pasada real; motivoTramite (no se pidio en este ensayo, la baja fue sin motivo); la guarda que se niega a cerrar un periodo antes de que empiece (linea ~1200) - ningun save de este ensayo intento una fecha anterior a la apertura del periodo que cierra.
Activity
-
STARTED MOVILBA-317 at 2026-09-08 00:49 ART - coder03-mba-l-cc (asignado por coder02 00:48). Plan: medir desde el llamador real (la pantalla de editar colectivo) contra origin/dev, y separar lo decidible hoy de lo que depende del asunto 38 de Eugenia (ABIERTO).
-
Medido por coder03 contra origin/dev 8ea1b0fd (los numeros de linea del description son de una revision anterior; estos son los vigentes). CAMINO DEL LLAMADOR REAL: editar/colectivo/page.tsx no tiene ninguno de los tres campos - git grep sobre el archivo devuelve DOS lineas de comentario y CERO inputs; ColectivoFormData (:59-143) no declara expediente, fechaExpediente ni motivoTramite; handleSubmit (:570) manda submitData={...formData} a actualizarColectivo (:611). actions/vehiculos.ts:188-190 gatea con raw.X !== undefined, asi que las tres claves nunca llegan. CONSECUENCIAS en repositories/vehiculos.ts (origin/dev): :1148 hasBusinessReason=Boolean(expediente||motivoTramite) es SIEMPRE false; :1200-1209 la guarda de fecha vive dentro de if(data.fechaExpediente) y es INALCANZABLE; :1225 fechaEventoPersistida cae a CURRENT_DATE (el RELOJ); :1237 expteBaja=data.expediente||null da NULL en toda baja; :1257 expteAlta idem en toda modificacion; :1259 observaciones cae al literal 'Actualizacion desde edicion de colectivo'. Reproduce lo filado, sobre el sha de hoy.
-
LA PREMISA DE BLOQUEO DEL DESCRIPTION ESTA MAL ATRIBUIDA (se re-atribuye, no se retracta). El description dice 'QUE debe exigir el formulario es decision de Eugenia, tracker asunto 38, ABIERTO'. Leido el tracker vivo /data-lezama/import-reports/todo-rutap-importacion-prestaciones.xlsx por coder03 el 2026-09-08 00:52 ART: el asunto 38 esta en la hoja RESUELTOS, Estado=Descartado, fecha 20/08/2026, y es 'ELECTRICO-CABA no es una categoria nueva' (Unidad_Propulsora) - no tiene nada que ver con el formulario. La hoja 'Para Eugenia' tiene 9 preguntas abiertas (1, 2, 5d, 5i, 9, 10, 11, 12, 13) y NINGUNA pregunta que debe exigir la pantalla de edicion: todas son sobre el LIBRO, no sobre nuestra UI. O sea que la pregunta nunca se le hizo a Eugenia, y ademas no es de ella: que exige un formulario nuestro es decision de producto, no un error del libro (la distincion que gobierna el tracker: una pregunta es un ERROR del libro). MOVILBA-317 NO esta bloqueado por Eugenia.
-
QUIEN SI DECIDIO, y el unico punto que queda abierto. Hay una decision ESCRITA de Elazar del 2026-08-14, guardada verbatim en el codigo, src/app/vehiculos/[dominio]/page.tsx:1024-1027 (origin/dev 8ea1b0fd): 'La baja NO se hace desde esta pantalla. Es un tramite y se registra en el historial, en /vehiculos/[dominio]/editar/colectivo -> Registrar Expediente con Tipo de Cambio = Cambio de Estado, QUE EXIGE EXPEDIENTE Y FECHA. Un boton de un solo click cambiaba el estado sin expediente ni fecha'. PERO ESA UI NO EXISTE: git grep -in 'Registrar Expediente|Tipo de Cambio|tipoCambio' sobre todo src/ en origin/dev devuelve UNICAMENTE ese comentario. Y ExpedienteForm.tsx, pese al nombre, es SOLO LECTURA (:116 'Read-only vehicle history; event creation belongs to the shared write service'), montado en la ficha :1404. O sea que el comentario documenta una intencion, no una pantalla: el boton se saco y el reemplazo que el comentario promete nunca se construyo. PRECEDENTE YA IMPLEMENTADO del lado del alta: agregar/colectivo/page.tsx exige expediente (:336-344, rotulo 'N de Expediente *', validacion de formato por utils/expediente-validation) y ofrece fechaExpediente opcional (:515-522). SPEC que tomo, derivada de lo anterior y no inventada: los tres campos viajan; en una BAJA expediente y fecha son OBLIGATORIOS (decision del 08-14); en una modificacion son OPCIONALES (actions/vehiculos.ts:184-187 dice 'La fecha del expediente es opcional a proposito'). UNICO PUNTO ABIERTO, y es para Elazar y no para Eugenia: si el expediente debe exigirse en TODO guardado de la pantalla o solo cuando cambia el estado. Implemento 'obligatorio en baja, opcional en modificacion' y lo dejo dicho.
-
53ec42f5 en rama movilba-317-expediente-en-editar-colectivo (base origin/dev 8ea1b0fd). 149 lineas, un solo archivo: src/app/vehiculos/[dominio]/editar/colectivo/page.tsx. Baja: expediente+fecha obligatorios (decision Elazar 2026-08-14, vehiculos/[dominio]/page.tsx:1024-1027). Modificacion: los tres opcionales (actions/vehiculos.ts:188-190). Formato isValidExpediente cuando hay valor. BAJA se resuelve por valor_opcion, nunca por literal ni etiqueta. tsc --noEmit y eslint limpios. Sin cambios en accion ni repositorio. Diff a audit.
-
was: Medido por coder03, db02 y audit por separado sobre dev/dev. git grep -in sobre src/app/vehiculos/[dominio]/editar/colectivo/page.tsx devuelve DOS lineas de comentario y ningun input. La accion (actions/vehiculos.ts:187) y el repositorio (repositories/vehiculos.ts:1074) SI aceptan y consumen los tres. Consecuencias: (1) expte_baja NULL incondicional; (2) fechaEvento null -> fecha_baja cae a CURRENT_DATE en :1062, o sea el RELOJ y no la fecha de negocio; (3) la guarda de :1035-1045 -negarse a cerrar un periodo antes de que empiece- vive dentro de if (data.fechaExpediente) y por lo tanto es INALCANZABLE desde esa pantalla, no solo no probada. LA PARTE QUE IMPORTA: la Regla B de MOVILBA-46 se relajo el 2026-08-20 con la premisa escrita de que los tres campos 'siguen llegando y siguen persistiendose'. Nunca llegaron. El razonamiento de Elazar (perder datos del libro es peor que perder trazabilidad) queda INTACTO: esto no argumenta por restaurar el rechazo. QUE debe exigir el formulario es decision de Eugenia, tracker asunto 38, ABIERTO. El comentario ya se corrigio en v5.5.29: aceptado y consumido no es lo mismo que recibido.
-
723285c9 - fix del hallazgo de audit sobre 53ec42f5 (audit PASS con un hallazgo, no bloqueante; se arregla antes de pushear por orden de coder02). Confirmado en la fuente: repositories/vehiculos.ts:1243 es if(!esBaja), asi que en una baja no hay insert de periodo y motivoTramite no tenia columna - el UPDATE de cierre escribe solo fechaBaja/expteBaja. Dos remedios: (1) el context del auditedOperation del cierre lleva motivoTramite cuando esBaja y hay valor, asi aterriza en audit_log.details; no se duplica en modificacion, ahi ya persiste en observaciones del periodo nuevo. (2) el rotulo del textarea se condiciona a esBaja y nombra el destino real en cada camino - un solo texto para los dos miente en uno. tsc y eslint limpios. Pendiente: re-audit del delta, deploy a dev01 bajo el lock, y una escritura real por la pantalla en los dos estados (nada la ejercito en runtime todavia).
-
DEPLOYADO a DEV v5.5.63, dev HEAD 9dfd4fb0 (2026-09-08 01:09 ART), bajo el lock dev01-deploy tomado 01:09 y liberado 01:11. gitdeploydev.sh exit 0: typecheck PASS, health intento 1/10 PASS, freshness patch 63 coincide. Lleva 53ec42f5 + 723285c9 (audit PASS en las dos rondas) mas el merge de 9c582cbb (MOVILBA-341 de coder-mba-l-ca, que deployo antes bajo el mismo lock). El merge fue limpio y NO toco ninguno de los dos archivos auditados: git diff 723285c9 HEAD sobre esos dos paths es vacio, asi que lo shipeado es identico a lo aprobado. origin sincronizado, gcaba sin configurar en este host, sin PROD. NO EJERCITADO EN RUNTIME: ninguna escritura real paso por la pantalla todavia; no hay ~/.config/postgres en lezama y la base de dev no esta en este host, y un save real necesita un login de dev01 (dev_viewer_elazar caducada 08-31). Pendiente: un save de modificacion y uno de baja sobre un vehiculo con periodo abierto que ya tenga expte_alta, y reportar los PARES DE VALORES (expte_baja+fecha_baja de la fila cerrada, observaciones del periodo nuevo, audit_log.details de la baja), no conteos.
-
2026-09-08 01:11 - Shipeado a DEV v5.5.63, HEAD 9dfd4fb0 (coder03-mba-l-cc): lleva 53ec42f5 + 723285c9 auditados, mas el merge de 9c582cbb (341); el merge no toco ninguno de los dos archivos auditados (git diff 723285c9 HEAD sobre esos paths, vacio). Gates: typecheck PASS, health 1/1, freshness patch 63. PENDIENTE Y BLOQUEADO: el ejercicio en runtime (una edicion y una baja reales) - no hay sesion viva en dev01 (dev_viewer_elazar vencida 08-31) y coder03 no puede leer la base. Nada ejercito esta pantalla todavia.
-
RECONFIRMADO en dev01 v5.5.79 por proxy-mba-w-cc durante el barrido CRUD del 2026-09-08 05:13: la tarjeta resumen 'Estado Actual' sigue mostrando el expediente de CREACION del vehiculo despues de que dos guardados posteriores (una edicion y una baja) lo cambiaron dos veces. No se refresca nunca. Sobre el vehiculo de prueba ZZ900QA (id 6724).
-
La nota del 05:13 sobre la tarjeta 'Estado Actual' stale NO pertenece a este item - es otro mecanismo y se separo como MOVILBA-357 (la tarjeta lee vehiculo.expteAlta desde v_vehiculos_detalle; 317 es que la pantalla de edicion no MANDA los tres campos). 317 se queda con su propio alcance: fix shipeado en v5.5.63, pendiente el ejercicio en runtime (un save de modificacion y uno de baja) reportando PARES DE VALORES.
-
was: Medido por coder03, db02 y audit por separado sobre dev/dev. git grep -in sobre src/app/vehiculos/[dominio]/editar/colectivo/page.tsx devuelve DOS lineas de comentario y ningun input. La accion (actions/vehiculos.ts:188-190) y el repositorio (repositories/vehiculos.ts:1148,1200-1209,1225,1236-1238,1257-1259) SI aceptan y consumen los tres; esos son los numeros vigentes sobre origin/dev 8ea1b0fd - los originales del filado (:187, :1074, :1035-1045, :1062) eran de una revision anterior. Consecuencias: (1) expte_baja NULL incondicional; (2) fechaEvento null -> fecha_baja cae a CURRENT_DATE, o sea el RELOJ y no la fecha de negocio; (3) la guarda que se niega a cerrar un periodo antes de que empiece vive dentro de if (data.fechaExpediente) y por lo tanto es INALCANZABLE desde esa pantalla, no solo no probada. LA PARTE QUE IMPORTA: la Regla B de MOVILBA-46 se relajo el 2026-08-20 con la premisa escrita de que los tres campos 'siguen llegando y siguen persistiendose'. Nunca llegaron. El razonamiento de Elazar (perder datos del libro es peor que perder trazabilidad) queda INTACTO: esto no argumenta por restaurar el rechazo. CORRECCION DE ATRIBUCION (coder03, 2026-09-08, verificada contra el tracker vivo; se re-atribuye, no se retracta): este item NO esta bloqueado por Eugenia y la version anterior de este texto decia 'decision de Eugenia, tracker asunto 38, ABIERTO', lo que es falso por partida doble. El asunto 38 del tracker esta en la hoja RESUELTOS con Estado=Descartado (20/08/2026) y es 'ELECTRICO-CABA no es una categoria nueva' (Unidad_Propulsora), sin relacion con el formulario; y ninguna de las 9 preguntas abiertas de la hoja 'Para Eugenia' toca nuestra UI - todas son sobre el LIBRO. Que exige un formulario nuestro es decision de PRODUCTO, nunca un error del libro, asi que nunca fue de ella. Quien SI decidio: Elazar el 2026-08-14, verbatim en src/app/vehiculos/[dominio]/page.tsx:1024-1027 - la baja es un tramite y se registra en esta pantalla 'con Tipo de Cambio = Cambio de Estado, que exige expediente y fecha'; el boton de un click se saco entonces y el reemplazo nunca se construyo. Spec tomada: los tres campos viajan, obligatorios expediente+fecha en BAJA, opcionales en modificacion. UNICO PUNTO ABIERTO, y es de Elazar: si el expediente debe exigirse en TODO guardado - eso es MOVILBA-288 y no bloquea este item. El comentario ya se corrigio en v5.5.29: aceptado y consumido no es lo mismo que recibido.
-
Cerrado: ejercitado en runtime sobre AA013AD/3346 (proxy-mba-w-cc), pares de valores confirman expte_baja poblado y fecha_baja=fecha de negocio, no NULL/reloj incondicional. Ver descripcion para el detalle y el limite de cobertura (fecha de negocio=hoy por coincidencia en este ensayo, precedencia de codigo confirmada por lectura de fuente).
bug
5w ago by wi-cli-venus
5w ago
2026-09-08 08:44