movilba
MOVILBA-168
· child of MOVILBA-167 EPIC: unificar modificaciones de vehículo y normalizar Entidad → Línea → Vehículo Backlog
Formulario unico de edicion de colectivo: linea/entidad/estado editables inline y el expediente que SE PERSISTA
Done urgent
cmcoder03assistant-mba-l-ca
== AUDIT 2026-09-18 (audit-mba-l-cc), contra dev/dev@ea0320c5 == TICKET DESACTUALIZADO: Parte 1 y Parte 2 estan HECHAS en dev, no bloqueadas. El texto de abajo (fechado 09-05) describe un estado que el codigo ya superó. PARTE 1 (linea/entidad/estado editable) — CONFIRMADO HECHO: - Ruta cambio de /vehiculos/[id]/editar/colectivo a /vehiculos/[dominio]/editar/colectivo. - UpdateColectivoInput (types/vehiculos.ts) YA TIENE lineaId (el hallazgo "NO tiene lineaId" del 09-05 esta resuelto). - page.tsx tiene los tres <select> (linea/entidad/estado) wireados, con la limpieza lineaId al cambiar entidadId (linea 588) que preserva la regla de pertenencia. PARTE 2 (expediente/fecha/motivo) — CONFIRMADO HECHO, via MOVILBA-317 (done): - UpdateColectivoInput tiene expediente/fechaExpediente/motivoTramite (types/vehiculos.ts:352-364), con la REGLA B de Elazar (expediente O motivo, nunca las dos, nunca ninguna) documentada y exigida en VehiculoService.updateColectivo. - page.tsx tiene los tres campos en el form (N° Expediente, Fecha del Expediente, motivoTramite), validados (isValidExpediente), expediente obligatorio en toda modificacion, fecha obligatoria en baja. - repositories/vehiculos.ts:createHistorialRecord escribe con origen:'app' — la marca de PROCEDENCIA que MOVILBA-224 pedia. BLOQUEO PARTE 2 (MOVILBA-224) — RESUELTO EN DEV, bwi de 224 esta atrasado (sigue inProgress, updatedAt 09-12): MOVILBA-299 (aplicado DEV 09-06) agrego la columna origen ('import'|'app', CHECK constraint) a rutap.vehiculo_historial_normalizado. rutap.proyectar_snapshot (269, aplicado DEV) tiene la regla de rebuild que preserva lo marcado: comentario explicito "Never DELETEs. Never touches origen='app'." Verificado contra el cuerpo instalado, no solo el comentario. Esto es exactamente el gate que 224 pedia (marca de procedencia + regla de rebuild que preserve lo marcado) — recomiendo que db02 (dueño de 224) confirme y cierre 224 si concuerda con esta lectura; no lo hago yo porque el veredicto final sobre "esto satisface el gate" es de quien abrio el gate. MOVILBA-211 (accion registrarExpediente sin llamadores) — confirmado status=done, consistente. NO VERIFICADO en esta pasada: guardado real ejercitado en runtime post-route-change (el ultimo ejercicio documentado, MOVILBA-317, es del 09-08 contra la ruta vieja [dominio] — mismo nombre de ruta, no debería importar, pero no lo re-ejercite yo). RECOMENDACION: coder03 (assignedAgent) confirma y mueve el status de blocked a done, o corrige si esta lectura de codigo se equivoca en algo.
Activity
-
parent=#3172
-
Elazar, 2026-09-03: 'table should track all'. Cierra la pregunta de diseno abierta de este item (opcion a vs b): ninguna de las dos. vehiculo_historial tiene que seguir TODAS las columnas del vehiculo. La parte 2 de este item (persistir la constancia) queda detras de la tabla ancha de MOVILBA-125, que ahora es requisito y no alternativa. La parte 1 - hacer editables inline Linea, Entidad y Estado - no depende de eso y arranca ya.
-
was: UX definida por Elazar 2026-08-31 mirando /vehiculos/6991/editar/colectivo: un formulario de edicion normal. El usuario cambia el campo que quiera - linea, entidad, estado, equipamiento, lo que sea - y abajo pone la Constancia (expediente y/o motivo). NO hay que declarar QUE se cambio: si cambiaste la entidad, cambiaste la entidad. Se elimina el panel 'Historial del Vehiculo / Registrar Expediente' con su radio 'Tipo de Cambio' (Cambio de Entidad / de Linea / de Estado / Otro) y su campo 'Nueva Entidad'. == HALLAZGO QUE CAMBIA EL ORDEN DEL TRABAJO == EL BLOQUE 'CONSTANCIA DE ESTE CAMBIO' HOY NO GUARDA NADA. Verificado en src/services/vehiculos.ts (updateColectivo): expediente, fechaExpediente y motivoTramite se reciben, se LOGUEAN y no se persisten. El comentario en el codigo lo dice explicito - 'MOVILBA-46 PARTE 2, PENDIENTE: el expediente y el motivo se RECIBEN aca pero todavia NO se persisten por este camino - no hay fila de historial por cambio de atributo'. Ademas la validacion de regla B esta LEVANTADA (Elazar, 2026-08-20 11:05), asi que tampoco se exige. Efecto para el usuario HOY: llena el expediente, guarda, ve exito, y la constancia no quedo en ningun lado salvo una linea de log. CONSECUENCIA DE SECUENCIA, NO NEGOCIABLE: hoy el UNICO camino que escribe una fila de historial de verdad es ExpedienteForm -> registrarExpediente. Si se borra ExpedienteForm ANTES de que updateColectivo persista la constancia, se destruye el unico camino que funciona y la app queda sin forma de registrar un expediente. Primero persistir, despues borrar. Nunca al reves. == LO QUE YA ESTA HECHO Y NO HAY QUE REHACER == - El bloque 'Constancia de este cambio' ya existe en la pantalla (page.tsx ~1082) con expediente, fecha del expediente y motivo del cambio, con los textos de ayuda que Elazar quiere. - La DERIVACION del tipo de cambio ya existe y ya funciona: src/lib/historial-vehiculo.ts, inferirEvento() deduce Alta / Transferencia de empresa / Reasignacion / Cambio de estado / Modificacion comparando la fila con la anterior (MOVILBA-99). O sea que el radio 'Tipo de Cambio' YA es redundante con como se LEE el historial: se pide al usuario un dato que el sistema despues ignora y recalcula. == LO QUE FALTA == 1. Hacer editables en el formulario principal los tres campos que hoy son de solo lectura con el link '(editar abajo en historial)': Linea (page.tsx:515), Entidad (page.tsx:650-658) y Estado (page.tsx:666-667). Selects contra los catalogos de siempre (opciones / v_ui_*), guardando ID entero. 2. Persistir la constancia: UNA fila de vehiculo_historial por guardado, con expediente, fecha y motivo, llevando los entidad_id / linea_id / estado_id nuevos. Es MOVILBA-46 parte 2. 3. Retirar ExpedienteForm de las dos pantallas donde esta montado (src/app/vehiculos/[id]/page.tsx:921 y src/app/vehiculos/[id]/editar/colectivo/page.tsx:1179) y retirar la action registrarExpediente. OJO: el layout de la entrada esta espejado en src/components/pdf/GenericReport.tsx:107, hay que tocarlo en la misma pasada. == PREGUNTA DE DISENO ABIERTA, LA DECIDE ELAZAR == vehiculo_historial SOLO tiene como columnas de negocio entidad, linea, estado y observaciones (limite declarado y medido en MOVILBA-99). Entonces: si el usuario cambia UNICAMENTE equipamiento (WiFi, MDVR, camaras, interno), que pasa? (a) se escribe fila igual, y como ningun campo que la tabla sabe seguir cambio, el historial la muestra como 'Tramite sin cambios de asignacion' - constancia guardada pero el renglon no dice que se cambio; o (b) no se escribe fila, y el expediente de ese cambio se pierde igual que hoy. Ninguna de las dos es buena, y la salida real es la tabla ancha de MOVILBA-125. Mientras tanto hay que elegir una. Mi recomendacion: (a) - la constancia y el expediente valen aunque el renglon no pueda detallar el cambio; perder el expediente es peor que un renglon poco especifico. == FUERA DE ALCANCE DECLARADO, MISMA FORMA == ChoferExpedienteForm tiene el mismo doble montaje en personas (src/app/personas/[id]/page.tsx:580 y [id]/editar/page.tsx:824). Si la unificacion es principio y no parche, choferes tiene el mismo defecto. == NO DEPENDE DE LA NORMALIZACION DE ESQUEMA == Esto se puede construir contra el esquema ACTUAL: vehiculo_historial ya lleva linea_id, entidad_id y estado_id. No hay que esperar a MOVILBA-166. Cuando 166 mueva el portador, esta pantalla se reapunta.
-
was: UX definida por Elazar 2026-08-31 mirando /vehiculos/6991/editar/colectivo: un formulario de edicion normal. El usuario cambia el campo que quiera - linea, entidad, estado, equipamiento, lo que sea - y abajo registra el numero de expediente y/o el motivo. NO hay que declarar QUE se cambio: si cambiaste la entidad, cambiaste la entidad. == CORRECCION DE ESTA DESCRIPCION, 2026-09-03 == La version anterior de este texto decia que el bloque 'Constancia de este cambio' YA existe en la pantalla en page.tsx ~1082 con sus textos de ayuda. ES FALSO contra dev de hoy, y ademas 'constancia' NO es un termino de MovilBA: aparece en 5 comentarios de codigo y en ninguna pantalla. Elazar no lo reconocio y tiene razon. ESTADO REAL DEL CODIGO EN dev (medido 2026-09-03 sobre un worktree en dev/dev, no sobre el checkout compartido que esta detached y 69 commits atras): - src/app/vehiculos/[id]/editar/colectivo/page.tsx (1220 lineas) NO tiene ningun campo de expediente ni de motivo. grep -i expediente sobre ese archivo da CERO. - ExpedienteForm.tsx quedo de SOLO LECTURA ('Historial del Vehiculo') y se monta unicamente en la ficha, src/app/vehiculos/[id]/page.tsx:1223. Ya no esta en la pantalla de edicion. Lo dejo asi MOVILBA-206. - La action registrarExpediente sigue existiendo en src/actions/vehiculos.ts:324 y no la llama nadie (MOVILBA-211). Conclusion: hoy NO hay ningun lugar en la UI donde registrar por que se hizo un cambio. No es que este a medias: no esta. == DECISION DE ELAZAR 2026-09-03 QUE CIERRA LA PREGUNTA ABIERTA == Se le pregunto que hacer cuando alguien edita solo equipamiento: escribir una fila que no puede describir el cambio, o no escribir nada. Contesto 'table should track all'. vehiculo_historial tiene que seguir TODAS las columnas del vehiculo. O sea la tabla ancha de MOVILBA-125 deja de ser una alternativa y pasa a ser el requisito. == LO QUE SIGUE EN PIE Y NO HAY QUE REHACER == La DERIVACION del tipo de cambio ya existe y funciona: src/lib/historial-vehiculo.ts, inferirEvento() deduce Alta / Transferencia de empresa / Reasignacion / Cambio de estado / Modificacion comparando la fila con la anterior (MOVILBA-99). El radio 'Tipo de Cambio' que se elimino ya era redundante con como se LEE el historial. == PARTE 1, DE ESTE CARRIL, ARRANCA YA, NO DEPENDE DE 125 == Hacer editables en el formulario principal los tres campos que hoy son de solo lectura con el link '(editar abajo en historial)': Linea (page.tsx:515), Entidad (page.tsx:650-658) y Estado (page.tsx:666-667). Selects contra los catalogos de siempre, leyendo por v_ui_* / v_opciones y guardando el ID entero. Ojo con la regla del 2026-09-03: los selectores SI filtran borrado_en, y el valor guardado que ya no este en el catalogo se agrega igual a la lista rotulado (conValorGuardado, ya shipeado en faa368f9 para chasis y carroceria). == PARTE 2, DETRAS DE MOVILBA-125 == Reponer en la pantalla los campos para registrar expediente / fecha / motivo, y persistirlos junto con el diff completo de columnas. No se puede construir contra la tabla angosta actual sin contradecir la decision de Elazar. Depende de 203 (writer) y 204 (lectores tipados), los dos de coder-mba-l-ca. == FUERA DE ALCANCE DECLARADO, MISMA FORMA == ChoferExpedienteForm tiene el mismo doble montaje en personas (src/app/personas/[id]/page.tsx:580 y [id]/editar/page.tsx:824).
-
Parte 1 arrancada: los tres desplegables ya existen y leen por v_ui_*; falta lineaId en UpdateColectivoInput.
-
Formulario unico de edicion de colectivo: linea/entidad/estado editables inline y el expediente que SE PERSISTA
-
coder03-mba-l-cc
-
Part 1 (linea/entidad/estado editable on editar/colectivo) is unblocked and NOT started; no code on this lane since assignment. Open design question sent to Elazar (nqla 2026-09-05): linea outside the selected entidad -> block on save vs filter the dropdown. Part 2 waits on 203/204 (coder-ca).
-
Part 1 started 2026-09-05 04:5x on PM instruction (roll call). Worktree /tmp/movilba-97 on dev/dev.
-
was: UX definida por Elazar 2026-08-31 mirando /vehiculos/6991/editar/colectivo: un formulario de edicion normal. El usuario cambia el campo que quiera - linea, entidad, estado, equipamiento, lo que sea - y abajo registra el numero de EXPEDIENTE y/o el motivo. NO hay que declarar QUE se cambio: si cambiaste la entidad, cambiaste la entidad. == VOCABULARIO, ORDEN DE ELAZAR 2026-09-03 == La palabra 'constancia' NO es un termino de MovilBA. Elazar no la reconocio y tiene razon: aparecia en 5 comentarios de codigo y en ninguna pantalla. El termino correcto es EXPEDIENTE (y 'motivo' cuando se habla del texto libre). Ningun agente debe usar 'constancia' en codigo, tickets ni mensajes. Ya se saco de los 5 comentarios. == CORRECCION DE ESTA DESCRIPCION, 2026-09-03 == La version anterior decia que el bloque de expediente YA existe en la pantalla en page.tsx ~1082 con sus textos de ayuda. ES FALSO contra dev de hoy. ESTADO REAL DEL CODIGO EN dev (medido 2026-09-03 sobre un worktree en dev/dev, no sobre el checkout compartido que esta detached y 69 commits atras): - src/app/vehiculos/[id]/editar/colectivo/page.tsx (1220 lineas) NO tiene ningun campo de expediente ni de motivo. grep -i expediente sobre ese archivo da CERO. - ExpedienteForm.tsx quedo de SOLO LECTURA ('Historial del Vehiculo') y se monta unicamente en la ficha, src/app/vehiculos/[id]/page.tsx:1223. Ya no esta en la pantalla de edicion. Lo dejo asi MOVILBA-206. - La action registrarExpediente sigue existiendo en src/actions/vehiculos.ts:324 y no la llama nadie (MOVILBA-211). Conclusion: hoy NO hay ningun lugar en la UI donde registrar por que se hizo un cambio. No esta a medias: no esta. == DECISION DE ELAZAR 2026-09-03 QUE CIERRA LA PREGUNTA ABIERTA == Se le pregunto que hacer cuando alguien edita solo equipamiento: escribir una fila que no puede describir el cambio, o no escribir nada. Contesto 'table should track all'. vehiculo_historial tiene que seguir TODAS las columnas del vehiculo. La tabla ancha de MOVILBA-125 deja de ser una alternativa y pasa a ser el requisito. == LO QUE SIGUE EN PIE Y NO HAY QUE REHACER == La derivacion del tipo de cambio ya existe y funciona: src/lib/historial-vehiculo.ts, inferirEvento() deduce Alta / Transferencia de empresa / Reasignacion / Cambio de estado / Modificacion comparando la fila con la anterior (MOVILBA-99). == PARTE 1, DE ESTE CARRIL, ARRANCA YA, NO DEPENDE DE 125 == Hacer editables los tres campos que hoy son de solo lectura: Linea (page.tsx:562-565), Entidad (card 2, page.tsx:631-650) y Estado (card 3, page.tsx:652-661). Los tres desplegables YA EXISTEN en src/actions/dropdowns.ts y ya leen por vista que filtra borrado_en: 'lineas' (v_ui_lineas, con orden numerico por CAST del label), 'allEntities'/'entityOptions' (v_ui_todas_entidades / v_ui_entidades) y 'estados'/'estadoColectivo' (v_estado_colectivo). OJO, HALLAZGO QUE AGREGA TRABAJO: UpdateColectivoInput (src/types/vehiculos.ts) tiene estadoId y entidadId pero NO tiene lineaId, asi que hoy la linea no se puede editar por este camino. El servicio si tiene assignToLinea (src/services/vehiculos.ts:648) y la action registrarExpediente ya sabe validar que la linea nueva pertenezca a la entidad nueva contra linea_entidad_asignaciones (src/actions/vehiculos.ts:398-415). Esa validacion hay que conservarla al mover la edicion de linea al formulario: no alcanza con agregar el campo al input. Aplica la regla del 2026-09-03: los selectores SI filtran borrado_en, y el valor guardado que ya no este en el catalogo se agrega igual a la lista rotulado (conValorGuardado, ya shipeado en faa368f9 para chasis y carroceria). == PARTE 2, DETRAS DE MOVILBA-125 == Reponer en la pantalla los campos de expediente / fecha / motivo y persistirlos junto con el diff completo de columnas. No se puede construir contra la tabla angosta actual sin contradecir la decision de Elazar. Depende de 203 (writer) y 204 (lectores tipados), los dos de coder-mba-l-ca. == FUERA DE ALCANCE DECLARADO, MISMA FORMA == ChoferExpedienteForm tiene el mismo doble montaje en personas (src/app/personas/[id]/page.tsx:580 y [id]/editar/page.tsx:824).
-
Parte 2: falta el writer de edicion de usuario sobre la tabla ancha (no es 203, que escribe el snapshot RUTAP). Sin item ni dueño; PM decide.
-
Parte 1 esta HECHA y en dev (b21a616a del 09-03, mas el fix 2e030841/v5.4.196 de coder03: el select de Estado arrancaba en 'Seleccionar estado...' para TODO vehiculo porque ColectivoDto/getColectivoByVehiculoId nunca traian vdc.estado_id). El texto del ticket estaba viejo. PARTE 2 BLOQUEADA POR MOVILBA-224, no por falta de item. coder03 la describio como 'hace falta un writer de edicion de usuario sobre la tabla ancha'. Eso NO se puede construir hoy y el motivo es estructural, no de esfuerzo: rutap.vehiculo_historial_normalizado es un ESPEJO DE UN SNAPSHOT, no un ledger, y el import REEMPLAZA. Un dato que escribe un usuario ahi lo borra el proximo import EN SILENCIO - sin error, sin log, sin diferencia visible. Escribir el writer antes de que exista la marca de procedencia de 224 es construir la perdida de datos, no la funcionalidad. O sea que la pregunta de la parte 2 no es 'quien escribe el writer' sino la de 224: donde vive lo que escribio una persona, con una marca por fila que el import no pueda escribir y una regla de rebuild que la preserve. Mientras 224 no tenga respuesta, la parte 2 no tiene destino donde escribir. DESBLOQUEO: 224 resuelto (marca de procedencia + regla de rebuild), o la prohibicion explicita y escrita de correr el import de reemplazo con usuarios adentro, que es la otra mitad del gate de arranque de 224.
-
was: == ESTADO REAL 2026-09-05 05:00 (coder03, medido en dev01 v5.4.196) == PARTE 1 HECHA. Linea, Entidad y Estado son <select> habilitados en /vehiculos/[id]/editar/colectivo (b21a616a 2026-09-03 + audit follow-up: validacion linea-pertenece-a-entidad en vehiculoService.updateColectivo, dispara en ambos cambios; lineas refiltradas por entidad via /api/dropdowns?type=lineasByEntidad, medido 2 -> 34 opciones al cambiar de entidad en 6701). Hallazgo cerrado hoy: el select de Estado arrancaba en 'Seleccionar estado...' para TODO vehiculo porque ColectivoDto/getColectivoByVehiculoId no traian vdc.estado_id - fix 2e030841, dev v5.4.196, 6701 muestra 'Alta'. NO se ejercito un guardado (nadie escribe en DEV mientras corre el sync de 255). Elazar aun no contesto si la linea fuera de la entidad se bloquea al guardar (hoy) o se filtra del desplegable (hoy tambien): el codigo ya hace las dos. PARTE 2 BLOQUEADA: no existe en la UI ningun campo de expediente/fecha/motivo (grep expediente sobre editar/colectivo/page.tsx = 0) y el servicio los recibe y solo los LOGUEA (services/vehiculos.ts ~965, comentario MOVILBA-46 parte 2). Persistirlos con el diff completo de columnas requiere un writer de EDICION DE USUARIO sobre la tabla ancha (rutap.vehiculo_historial_normalizado): MOVILBA-203 (done) es el writer del SNAPSHOT RUTAP, no de ediciones; 204 (inProgress, coder-ca) son los lectores tipados. Ese writer de edicion no tiene item ni dueño; decision de Elazar 09-03 'table should track all' lo exige. == DESCRIPCION ANTERIOR (2026-09-03, parcialmente superada por lo de arriba) == UX definida por Elazar 2026-08-31 mirando /vehiculos/6991/editar/colectivo: un formulario de edicion normal. El usuario cambia el campo que quiera - linea, entidad, estado, equipamiento, lo que sea - y abajo registra el numero de EXPEDIENTE y/o el motivo. NO hay que declarar QUE se cambio: si cambiaste la entidad, cambiaste la entidad. == VOCABULARIO, ORDEN DE ELAZAR 2026-09-03 == La palabra 'constancia' NO es un termino de MovilBA. Elazar no la reconocio y tiene razon: aparecia en 5 comentarios de codigo y en ninguna pantalla. El termino correcto es EXPEDIENTE (y 'motivo' cuando se habla del texto libre). Ningun agente debe usar 'constancia' en codigo, tickets ni mensajes. Ya se saco de los 5 comentarios. == CORRECCION DE ESTA DESCRIPCION, 2026-09-03 == La version anterior decia que el bloque de expediente YA existe en la pantalla en page.tsx ~1082 con sus textos de ayuda. ES FALSO contra dev de hoy. ESTADO REAL DEL CODIGO EN dev (medido 2026-09-03 sobre un worktree en dev/dev, no sobre el checkout compartido que esta detached y 69 commits atras): - src/app/vehiculos/[id]/editar/colectivo/page.tsx (1220 lineas) NO tiene ningun campo de expediente ni de motivo. grep -i expediente sobre ese archivo da CERO. - ExpedienteForm.tsx quedo de SOLO LECTURA ('Historial del Vehiculo') y se monta unicamente en la ficha, src/app/vehiculos/[id]/page.tsx:1223. Ya no esta en la pantalla de edicion. Lo dejo asi MOVILBA-206. - La action registrarExpediente sigue existiendo en src/actions/vehiculos.ts:324 y no la llama nadie (MOVILBA-211). Conclusion: hoy NO hay ningun lugar en la UI donde registrar por que se hizo un cambio. No esta a medias: no esta. == DECISION DE ELAZAR 2026-09-03 QUE CIERRA LA PREGUNTA ABIERTA == Se le pregunto que hacer cuando alguien edita solo equipamiento: escribir una fila que no puede describir el cambio, o no escribir nada. Contesto 'table should track all'. vehiculo_historial tiene que seguir TODAS las columnas del vehiculo. La tabla ancha de MOVILBA-125 deja de ser una alternativa y pasa a ser el requisito. == LO QUE SIGUE EN PIE Y NO HAY QUE REHACER == La derivacion del tipo de cambio ya existe y funciona: src/lib/historial-vehiculo.ts, inferirEvento() deduce Alta / Transferencia de empresa / Reasignacion / Cambio de estado / Modificacion comparando la fila con la anterior (MOVILBA-99). == PARTE 1, DE ESTE CARRIL, ARRANCA YA, NO DEPENDE DE 125 == Hacer editables los tres campos que hoy son de solo lectura: Linea (page.tsx:562-565), Entidad (card 2, page.tsx:631-650) y Estado (card 3, page.tsx:652-661). Los tres desplegables YA EXISTEN en src/actions/dropdowns.ts y ya leen por vista que filtra borrado_en: 'lineas' (v_ui_lineas, con orden numerico por CAST del label), 'allEntities'/'entityOptions' (v_ui_todas_entidades / v_ui_entidades) y 'estados'/'estadoColectivo' (v_estado_colectivo). OJO, HALLAZGO QUE AGREGA TRABAJO: UpdateColectivoInput (src/types/vehiculos.ts) tiene estadoId y entidadId pero NO tiene lineaId, asi que hoy la linea no se puede editar por este camino. El servicio si tiene assignToLinea (src/services/vehiculos.ts:648) y la action registrarExpediente ya sabe validar que la linea nueva pertenezca a la entidad nueva contra linea_entidad_asignaciones (src/actions/vehiculos.ts:398-415). Esa validacion hay que conservarla al mover la edicion de linea al formulario: no alcanza con agregar el campo al input. Aplica la regla del 2026-09-03: los selectores SI filtran borrado_en, y el valor guardado que ya no este en el catalogo se agrega igual a la lista rotulado (conValorGuardado, ya shipeado en faa368f9 para chasis y carroceria). == PARTE 2, DETRAS DE MOVILBA-125 == Reponer en la pantalla los campos de expediente / fecha / motivo y persistirlos junto con el diff completo de columnas. No se puede construir contra la tabla angosta actual sin contradecir la decision de Elazar. Depende de 203 (writer) y 204 (lectores tipados), los dos de coder-mba-l-ca. == FUERA DE ALCANCE DECLARADO, MISMA FORMA == ChoferExpedienteForm tiene el mismo doble montaje en personas (src/app/personas/[id]/page.tsx:580 y [id]/editar/page.tsx:824).
-
was: == ESTADO REAL 2026-09-05 05:00 (coder03, medido en dev01 v5.4.196) == PARTE 1 HECHA. Linea, Entidad y Estado son <select> habilitados en /vehiculos/[id]/editar/colectivo (b21a616a 2026-09-03 + audit follow-up: validacion linea-pertenece-a-entidad en vehiculoService.updateColectivo, dispara en ambos cambios; lineas refiltradas por entidad via /api/dropdowns?type=lineasByEntidad, medido 2 -> 34 opciones al cambiar de entidad en 6701). Hallazgo cerrado hoy: el select de Estado arrancaba en 'Seleccionar estado...' para TODO vehiculo porque ColectivoDto/getColectivoByVehiculoId no traian vdc.estado_id - fix 2e030841, dev v5.4.196, 6701 muestra 'Alta'. Guardado EJERCITADO 2026-09-05 05:06 (proxy, dev v5.4.196, sin cambios sobre 6701): audit_log id 604 UPDATE vehiculos_datos_colectivos con estadoId en valuesSet, fila igual, historial 1 -> 1, sin errores en app_logs. NO ejercitado: un guardado que MUEVE el estado (117/119). Tipo del DTO corregido a number (46b58db5, v5.4.197), auditado OK. Elazar aun no contesto si la linea fuera de la entidad se bloquea al guardar (hoy) o se filtra del desplegable (hoy tambien): el codigo ya hace las dos. PARTE 2 BLOQUEADA: no existe en la UI ningun campo de expediente/fecha/motivo (grep expediente sobre editar/colectivo/page.tsx = 0) y el servicio los recibe y solo los LOGUEA (services/vehiculos.ts ~965, comentario MOVILBA-46 parte 2). Persistirlos con el diff completo de columnas requiere un writer de EDICION DE USUARIO sobre la tabla ancha (rutap.vehiculo_historial_normalizado): MOVILBA-203 (done) es el writer del SNAPSHOT RUTAP, no de ediciones; 204 (inProgress, coder-ca) son los lectores tipados. Decision PM 09-05 05:04: ese writer NO se construye todavia - la tabla ancha es espejo de snapshot y el import la reemplaza; parte 2 es DOWNSTREAM de MOVILBA-224 (marca de procedencia por fila + regla de rebuild) y es su control positivo. Mismo modo de falla sobre vdc.estado_id: MOVILBA-259. == DESCRIPCION ANTERIOR (2026-09-03, parcialmente superada por lo de arriba) == UX definida por Elazar 2026-08-31 mirando /vehiculos/6991/editar/colectivo: un formulario de edicion normal. El usuario cambia el campo que quiera - linea, entidad, estado, equipamiento, lo que sea - y abajo registra el numero de EXPEDIENTE y/o el motivo. NO hay que declarar QUE se cambio: si cambiaste la entidad, cambiaste la entidad. == VOCABULARIO, ORDEN DE ELAZAR 2026-09-03 == La palabra 'constancia' NO es un termino de MovilBA. Elazar no la reconocio y tiene razon: aparecia en 5 comentarios de codigo y en ninguna pantalla. El termino correcto es EXPEDIENTE (y 'motivo' cuando se habla del texto libre). Ningun agente debe usar 'constancia' en codigo, tickets ni mensajes. Ya se saco de los 5 comentarios. == CORRECCION DE ESTA DESCRIPCION, 2026-09-03 == La version anterior decia que el bloque de expediente YA existe en la pantalla en page.tsx ~1082 con sus textos de ayuda. ES FALSO contra dev de hoy. ESTADO REAL DEL CODIGO EN dev (medido 2026-09-03 sobre un worktree en dev/dev, no sobre el checkout compartido que esta detached y 69 commits atras): - src/app/vehiculos/[id]/editar/colectivo/page.tsx (1220 lineas) NO tiene ningun campo de expediente ni de motivo. grep -i expediente sobre ese archivo da CERO. - ExpedienteForm.tsx quedo de SOLO LECTURA ('Historial del Vehiculo') y se monta unicamente en la ficha, src/app/vehiculos/[id]/page.tsx:1223. Ya no esta en la pantalla de edicion. Lo dejo asi MOVILBA-206. - La action registrarExpediente sigue existiendo en src/actions/vehiculos.ts:324 y no la llama nadie (MOVILBA-211). Conclusion: hoy NO hay ningun lugar en la UI donde registrar por que se hizo un cambio. No esta a medias: no esta. == DECISION DE ELAZAR 2026-09-03 QUE CIERRA LA PREGUNTA ABIERTA == Se le pregunto que hacer cuando alguien edita solo equipamiento: escribir una fila que no puede describir el cambio, o no escribir nada. Contesto 'table should track all'. vehiculo_historial tiene que seguir TODAS las columnas del vehiculo. La tabla ancha de MOVILBA-125 deja de ser una alternativa y pasa a ser el requisito. == LO QUE SIGUE EN PIE Y NO HAY QUE REHACER == La derivacion del tipo de cambio ya existe y funciona: src/lib/historial-vehiculo.ts, inferirEvento() deduce Alta / Transferencia de empresa / Reasignacion / Cambio de estado / Modificacion comparando la fila con la anterior (MOVILBA-99). == PARTE 1, DE ESTE CARRIL, ARRANCA YA, NO DEPENDE DE 125 == Hacer editables los tres campos que hoy son de solo lectura: Linea (page.tsx:562-565), Entidad (card 2, page.tsx:631-650) y Estado (card 3, page.tsx:652-661). Los tres desplegables YA EXISTEN en src/actions/dropdowns.ts y ya leen por vista que filtra borrado_en: 'lineas' (v_ui_lineas, con orden numerico por CAST del label), 'allEntities'/'entityOptions' (v_ui_todas_entidades / v_ui_entidades) y 'estados'/'estadoColectivo' (v_estado_colectivo). OJO, HALLAZGO QUE AGREGA TRABAJO: UpdateColectivoInput (src/types/vehiculos.ts) tiene estadoId y entidadId pero NO tiene lineaId, asi que hoy la linea no se puede editar por este camino. El servicio si tiene assignToLinea (src/services/vehiculos.ts:648) y la action registrarExpediente ya sabe validar que la linea nueva pertenezca a la entidad nueva contra linea_entidad_asignaciones (src/actions/vehiculos.ts:398-415). Esa validacion hay que conservarla al mover la edicion de linea al formulario: no alcanza con agregar el campo al input. Aplica la regla del 2026-09-03: los selectores SI filtran borrado_en, y el valor guardado que ya no este en el catalogo se agrega igual a la lista rotulado (conValorGuardado, ya shipeado en faa368f9 para chasis y carroceria). == PARTE 2, DETRAS DE MOVILBA-125 == Reponer en la pantalla los campos de expediente / fecha / motivo y persistirlos junto con el diff completo de columnas. No se puede construir contra la tabla angosta actual sin contradecir la decision de Elazar. Depende de 203 (writer) y 204 (lectores tipados), los dos de coder-mba-l-ca. == FUERA DE ALCANCE DECLARADO, MISMA FORMA == ChoferExpedienteForm tiene el mismo doble montaje en personas (src/app/personas/[id]/page.tsx:580 y [id]/editar/page.tsx:824).
-
coder04-mba-l-ca | 2026-09-24 03:56 ART. DEV dev source: editable Linea/Entidad/Estado selects in src/app/vehiculos/[dominio]/editar/colectivo/page.tsx; UpdateColectivoInput and action carry expediente/fecha/motivo; src/repositories/vehiculos.ts applyColectivoEditWithHistory writes APP history and predecessor. The 224 no-writer blocker is obsolete. Runtime save and PROD installation not exercised, so keep todo.
-
coder03assistant-mba-l-ca
-
coder03assistant-mba-l-ca | 2026-09-28 12:36 ART — Rechecked dev and main source (main 4ed8a5cd, v5.6.78; files match dev). The edit form at src/app/vehiculos/[dominio]/editar/colectivo/page.tsx carries expediente/fechaExpediente/motivoTramite through submit; VehiculoService.updateColectivo validates expediente/date and passes fields to applyColectivoEditWithHistory; repository writes the raw expediente and business date into app history in one transaction (src/repositories/vehiculos.ts:1257+). Runtime edit/save and DB persistence remain UNEXERCISED; keep open until a discriminating authenticated save is read back.
-
coder03assistant-mba-l-ca | 2026-09-28 14:05 ART — Read dev ref 657be353. Edit form carries expediente/fechaExpediente into actualizarColectivo (page.tsx:648-650); service validates a trimmed copy but passes the raw expediente to applyColectivoEditWithHistory (services/vehiculos.ts:800-808, 917-925); repository writes expediente into the history fields (repositories/vehiculos.ts:1590-1595). Static source path is present. Real authenticated edit and readback of the saved value remain unexercised; no app write or DB access from this lane. Keep inProgress pending the requested discriminating DEV UI save/readback.
-
coder03assistant-mba-l-ca | 2026-09-28 14:29 ART — Missing instrument: an authenticated DEV01 browser session that can submit the coletivo edit form and read back the saved expediente/history after reload. Proxy observed dev01.movilba.com redirect to /user/login at 14:06 ART. Source chain is present, but without that app session the requested discriminating edit/save cannot be exercised safely; no DB write or user-row edit was made. Resume using a designated QA app-created vehicle such as QA624XZ, then capture submitted expediente, persisted history value, and fresh detail/history readback.
-
coder03-mba-l-cc 2026-09-28 14:5x ART. Instrument check, measured not inferred: dev01 does NOT need a browser session. The headless NextAuth path is intact - GET https://dev01.movilba.com/api/auth/csrf returns a csrfToken, and POST /api/auth/callback/credentials with email+password+csrfToken+redirect=false, carrying a cookie jar, is answered normally (302 with the outcome in the Location, never a 401); a success leaves a session readable at GET /api/auth/session. dev01 itself answers 200 at /. Ran it once with the account in memory: 302 -> /user/login?error=CredentialsSignin&code=INVALID_CREDENTIALS, requestId 876c3f48-2ef7-4b7b-b52c-b50407abc510, and /api/auth/session returns null. So the single missing thing is a VALID dev01 password, not a browser, not the proxy, not an OIDC redirect. Recording a blocker as 'needs an authenticated browser session' overstates it and sends the next lane looking for the wrong instrument. Note also that elazar.pimentel@gmail.com on dev01 is group VIEWER (read-only), so even a working password for it would not satisfy a blocker that has to SUBMIT a form. I am not requesting a credential reset: standing order is that nobody rotates or requests a reset without Elazar's explicit ask. Escalated to him on the CLI.
-
coder03assistant-mba-l-ca | 2026-09-28 14:49 ART — Corrected instrument finding: a browser session is not the blocker. coder03 tested the headless NextAuth flow; the available account returned CredentialsSignin/INVALID_CREDENTIALS, and its DEV01 role is VIEWER, so it could not submit even with working login. Missing instrument is an authorized, valid DEV01 account with write access to submit the edit on designated QA vehicle QA624XZ and read the saved expediente/history. No credential reset requested; no app or DB write made.
-
2026-10-05 DEV01 app verification, build v5.6.161: authenticated via authorized DEV01_WRITE account; changed only QA624XZ's edit-form expediente/date to EX-2026-16800001-GCABA-DGGSM / 2026-10-05 and saved through /vehiculos/QA624XZ/editar/colectivo. The action returned to the vehicle detail. Opened a fresh page after login and reloaded the detail; latest Modificacion history displays the exact expediente, Creado por Elazar Pimentel, Desde 05/10/2026. No direct DB write. Credential not recorded.
-
cleared: coder03assistant-mba-l-ca | 2026-09-28 14:49 ART — Corrected instrument finding: a browser session is not the blocker. coder03 tested the headless NextAuth flow; the available account returned CredentialsSignin/INVALID_CREDENTIALS, and its DEV01 role is VIEWER, so it could not submit even with working login. Missing instrument is an authorized, valid DEV01 account with write access to submit the edit on designated QA vehicle QA624XZ and read the saved expediente/history. No credential reset requested; no app or DB write made.
-
Real DEV01 edit/save/readback PASS on v5.6.161; exact expediente persisted in latest Modificacion after fresh-page read and reload.
feature
6w ago by wi-cli-venus
1w ago
2026-10-05 18:17