El sync al libro pisa vehiculos_datos_colectivos.estado_id, y la UI ya deja al usuario editarlo: MANTENIMIENTO vuelve a ALTA en el proximo sync
coder02, 2026-09-05, leido del codigo. MOVILBA-224 dice que una edicion de usuario en la tabla ANCHA la borra el proximo import. Lo mismo pasa en vehiculos_datos_colectivos, y esta parte YA ESTA SHIPEADA Y ES ALCANZABLE POR PANTALLA. EL CAMINO COMPLETO: MOVILBA-168 parte 1 (en dev desde b21a616a, mas 2e030841 y 46b58db5) deja Estado editable inline en /vehiculos/<id>/editar/colectivo y lo persiste en vehiculos_datos_colectivos.estado_id. tools/rutap-sync-prod.sql pisa esa misma columna desde el libro en las dos pasadas: la de vigentes escribe estado_id = ALTA para todo dominio con una fila abierta, la de cerradas escribe BAJA. Ninguna de las dos mira lo que habia antes salvo para saltear la escritura si ya coincide. CONSECUENCIA: un usuario pone un colectivo en MANTENIMIENTO (opcion 119, que existe en el catalogo y la UI ofrece) y el proximo sync al libro lo devuelve a ALTA. Sin error, sin log, sin diferencia visible - el mismo modo de falla que 224 y que el no-op silencioso de MOVILBA-221. Y la vuelta atras no necesita un rebuild ni un GO especial: sincronizar al libro es RUTINA por regla permanente de Elazar, asi que es la operacion mas frecuente que hay. POR QUE NO ES 224: 224 es sobre rutap.vehiculo_historial_normalizado, que es un espejo de snapshot y todavia no tiene consumidor de escritura de usuario - por eso 168 parte 2 quedo bloqueada. Este es sobre vehiculos_datos_colectivos, que SI tiene consumidor de escritura de usuario, en produccion de dev, hoy. Misma clase de defecto, distinta tabla, y esta llegó primero. NO MEDIDO: cuantas filas de vdc tienen hoy un estado que el libro contradice. El sync no corre end to end (MOVILBA-255), asi que nadie observo todavia una reversion real - el defecto esta leido del codigo, no visto. Medirlo es un SELECT y es el primer paso. QUE DECIDIR, y es la misma pregunta que 224 con otra tabla: o estado_id deja de ser una columna que el sync pisa (el estado del usuario vive en otro lado, o el sync lo respeta), o se declara explicitamente que el libro gana siempre y la UI no debe ofrecer estados que el libro no puede expresar - hoy ofrece MANTENIMIENTO, que el libro no tiene. Una de las dos, escrita, antes del arranque.
Activity
-
PREMISA ACTUALIZADA y PRIMER PASO MEDIDO - db02-mba-l-cc, 2026-09-10, DEV, SOLO LECTURA. La bifurcacion que este ticket dejaba abierta ('o estado_id deja de ser una columna que el sync pisa, o se declara que el libro gana siempre y la UI no ofrece estados que el libro no puede expresar') quedo DECIDIDA por Elazar, por la segunda via. Eugenia contesto el 09-10 (Q3 del tracker en /data-lezama/movilba/import-reports/2026-09-10-1441-todo-rutap-importacion-prestaciones.xlsx): 'Actualmente tomamos unicamente BAJA (independientemente de lo que se haga con el vehiculo)'. Elazar dirigio que Agregar ofrezca solo ALTA/BAJA; ya esta en DEV como MOVILBA-432 (v5.5.137, valida ademas en servidor). El retiro del catalogo va por MOVILBA-77, paquete preparado y no aplicado. LA PATA DE MANTENIMIENTO DE ESTE TICKET MUERE CON 77: cuando 119 no este en el catalogo, un usuario no puede poner un colectivo en MANTENIMIENTO y por lo tanto el sync no puede revertirlo. NO MEDIDO -> MEDIDO. El ticket pedia como primer paso 'cuantas filas de vdc tienen hoy un estado que el libro contradice'. Corrido en DEV cruzando vehiculos_datos_colectivos vivas (borrado_en IS NULL, y el vehiculo tampoco borrado) contra rutap.v_rutap_latest por dominio, con el mismo criterio que usa el sync (dominio con alguna fila de fecha_baja NULL = abierto = ALTA; si no, BAJA): 2417 filas vivas de vdc, de las cuales 2407 tienen dominio en el libro y 10 no lo tienen (esas 10 quedan FUERA del denominador, no se cuentan como acuerdo ni como desacuerdo). Sobre las 2407: 1601 abierto+ALTA y 805 cerrado+BAJA coinciden; 1 SOLA fila contradice, dominio AA013AD, vdc.id 3705, abierto en el libro y BAJA en la app. CERO filas vivas con MANTENIMIENTO (las 2 que existen con 119 estan borradas y son de la era de pruebas, ver 77). O sea: la reversion silenciosa que el ticket describe es real como mecanismo pero hoy tiene UNA fila expuesta en DEV, no un lote. No medido en PROD y no se pide: el alcance de esta corrida es DEV. LO QUE NO MUERE CON 77, y es lo unico que queda abierto aca: el editor inline de Estado en /vehiculos/<id>/editar/colectivo (MOVILBA-168 parte 1) sigue dejando que un usuario cambie ALTA<->BAJA, y tools/rutap-sync-prod.sql sigue pisando vdc.estado_id desde el libro en sus dos pasadas sin mirar lo que habia. El modo de falla de 224/221 sobrevive con dos estados en vez de tres: el usuario pone BAJA sobre un dominio abierto en el libro, el proximo sync lo devuelve a ALTA, sin error y sin log - y sincronizar al libro es RUTINA, no pide GO. AA013AD es exactamente esa fila. La pregunta de producto que queda, y que NO contesta este carril: se acepta que el libro pise siempre (y entonces el editor de Estado no deberia ofrecerse), se saca el editor, o el sync respeta la edicion del usuario. Las tres son decisiones de Elazar/Eugenia, no de un carril.
-
AA013AD RESUELTO como NO-DEFECTO, con actor medido - db02-mba-l-cc, 2026-09-10, DEV, solo lectura. La unica fila que contradice al libro NO es una reversion del sync ni deriva de import: es un fixture de QA hecho por pantalla. vdc.id 3705 (vehiculo 3346) estuvo en ALTA hasta el 2026-09-08 05:42:16, cuando audit_log 724-727 registran una edicion de la app por el usuario l2eptUQd81rhJSECul6Qe = qa-editor@movilba.test ('QA Editor DEV'), requestId 8946e992-f3fe-4aa9-afc9-706c2789b679, con operation close-period-baja sobre el historial 177665. El archive lo corrobora: 22 filas de pre-estado, TODAS con estado 116 ALTA, la ultima archivada exactamente a las 05:42:16. Ademas la fila es una BAJA incoherente a proposito: expte_baja NULL y fecha_vigencia_hasta NULL, dos columnas que la pasada de bajas de tools/rutap-sync-prod.sql siempre completa - o sea que no la escribio un sync. Por regla permanente de Elazar (2026-08-21, escrita en docs/reference/ssot-overrides.md) solo prod tiene que ser 100% fiel al libro y en dev 'filas que un tester edito probando la app son NORMALES y no son drift': esta fila no es drift y no se reconcilia. IMPORTA PARA ESTE TICKET POR OTRO MOTIVO: es hoy el UNICO ejemplo vivo en DEV del mecanismo que este ticket describe - un usuario puso BAJA por pantalla sobre un dominio que el libro tiene ABIERTO, y el proximo sync lo va a devolver a ALTA sin error y sin log. Si alguien la sobrescribe se pierde el unico caso trabajado del defecto. Pedido de db03 el 09-10 de reconciliar esa fila a ALTA antes de proyectar el snapshot 13: contestado que NO. El gate W5 de rutap.proyectar_snapshot (MOVILBA-269/333) esta haciendo exactamente lo que dice su propio mensaje, 'book contradiction, not written over'; reconciliar seria hacer lo que el gate existe para impedir, y relajarlo por una fila es la forma clasica de un control que aborta por ruido y termina desactivado. Las dos salidas limpias, ninguna es una escritura de este carril: (1) que QA retire su propio fixture por la misma pantalla, con lo cual W5 pasa solo y la trazabilidad queda honesta - recomendada; (2) si DEV tiene que proyectar con fixtures de QA vivos, W5 tiene que distinguir fila de test de contradiccion real, y eso es un cambio en proyectar_snapshot que ownea 269.
-
Medicion del 'NO MEDIDO' de este item, db02-mba-l-cc 2026-09-12, DEV movilba_dev @ 10.9.10.54 PG 15.17, read-only. Poblacion re-derivada contra la punta de rutap.snapshots (12, que sigue siendo la punta: el libro 2026-09-10 11:50 no se importo). Normalizacion de dominio identica a la del proyector, upper(regexp_replace(...,'[^A-Za-z0-9]','','g')), y fecha_baja vacia con btrim NBSP-aware. 1602 dominios abiertos en el libro, 1602 resueltos a exactamente una ficha viva, 4 con estado que el libro contradice, los 4 en estado 119: AA013AD/vdc 3705 (09-08 05:42), AC213TA/3901 (09-10 15:58), AC363OK/5621 (09-10 16:02), AF894KI/4744 (09-11 10:13). Dos cosas que la cifra dice y que la cifra sola no dice. La reversion ya no esta solo leida del codigo: las cuatro filas son ediciones por pantalla, atribuidas en audit_log. Y la poblacion crece con el USO, no con el tiempo - el 09-11 hubo tres rafagas de escritura de la app (10:13, 10:48, 10:56), dos fueron altas de vehiculos nuevos y la unica edicion de una ficha existente produjo el cuarto caso. Una tasa sobre esta poblacion pide denominador de actividad; un conteo quieto significa app ociosa, no defecto frenado. El 'QUE DECIDIR' de este item es la misma pregunta que hoy espera resolucion de Elazar como politica de app para MOVILBA-435 (avisar / bloquear / excepcion atribuida), y su forma general es MOVILBA-353. No es una pregunta nueva ni pide item nuevo.
-
Cerrado 2026-09-22 por blackboard bb-db03-mba-l-cc-mucyhi59-rmp1c1 (orden de Elazar en CLI: 'if you all agree it is done, close it'). db03 y audit DONE; coder03 NOT-DONE condicionado a un SELECT, corrido y resuelto: v_estado_colectivo SI emite 119 en PROD, asi que por su propia rama 2) eso va a MOVILBA-77 (nota puesta) y 259 cierra. Fundamento del cierre: la bifurcacion que el ticket dejaba abierta quedo decidida por Elazar el 09-10 por la segunda via (el libro gana) y esta implementada en el instrumento - rutap.reconciliar_snapshot instalada (md5 cd18795a, identica DEV y PROD) asigna vdc.estado_id = estado_objetivo incondicional en cada import. Bajo la regla de Elazar del 09-22 esa sobrescritura de una edicion de usuario es el comportamiento buscado, no el defecto. El cierre se apoya en esa asignacion incondicional, NO en el conteo de hoy (0 filas en 119 en las dos bases): un conteo quieto es app ociosa, no defecto frenado. MOVILBA-77 no bloquea: es otra falla (opcion catalogada que la UI ofrece y el libro no expresa) y queda viva con la evidencia de PROD.
-
completed
-
AUDITADO el cierre, audit-mba-l-cc 2026-09-22 14:40 ART. Revisado contra bb-db03-mba-l-cc-mucyhi59-rmp1c1: la nota de cierre transcribe correctamente el resultado del SELECT de coder03 (v_estado_colectivo emite 119 en PROD, no en DEV) y la ruta a MOVILBA-77. Concuerdo con el fundamento: el reconciler instalado (md5 cd18795a) asigna estado_id incondicional, eso es lo que hace el cierre correcto, no el conteo de 0 filas en 119. Sin objeciones. APROBADO.