Tab Mantenimiento en la UI esta permanentemente vacio: 119 MANTENIMIENTO esta catalogado pero nada lo escribe nunca

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  PREMISA CAMBIADA por Elazar: HARD delete, no soft. Razones: no hay dato historico, no tiene contraparte en el Excel, es ruido puro para LLMs y scripts. MEDIDO por db02 (no asumido): 19 columnas del esquema tienen FK a opciones(id) y las 19 tienen CERO filas con 119 - el gate recorre pg_constraint, no una lista hardcodeada, asi que un FK nuevo no puede colarse. Las tablas _archive no tienen FK y son invisibles a ese chequeo: verificadas aparte, cero filas historicas con 119. Ninguna definicion de vista contiene el literal 119. ORDEN CORREGIDO por coder-mba-l-cc - el que estaba en el archivo era al reves y daba error en runtime: (1) PRIMERO la base, drop de v_vehiculos_list_mantenimiento + hard delete del 119 en la misma transaccion; el catalogo deja de ofrecer Mantenimiento, la pestania desaparece sola y la entrada muerta del mapa queda inalcanzable. (2) DESPUES, como un solo cambio: introspect.sh, sacar las 3 referencias de src/repositories/vehiculos.ts (lineas 11, 98, 102), corregir el comentario de src/actions/vehiculos.ts:738-739 que va a describir un comportamiento que ya no existe, y desplegar. POR QUE al reves rompe: v_ui_vehiculo_estado_filtro solo ofrece los estados cuya vista de lista EXISTE, y src/repositories/vehiculos.ts:107-111 TIRA ERROR a proposito cuando el catalogo ofrece una relacion que el mapa no conoce (MOVILBA-41 - el fallback silencioso mentiria sirviendo la lista de Alta rotulada con otro filtro). Sacar el codigo primero deja la vista viva, el catalogo sigue ofreciendo Mantenimiento y la pestania TIRA ERROR en vez de desaparecer. NECESITA GO PROPIO: deshabilitar trg_soft_delete_opciones para que el DELETE sea real es gate duro; la direccion de Elazar no es el GO.
• wi-cli-venus note · 2026-08-21
  PARCIALMENTE OBSOLETO - la causa que enuncia el ticket es falsa, el sintoma es cierto. Verificado por coder02 2026-08-21 (codigo + PROD). El dato SI le da la razon: vehiculos_datos_colectivos con estado_id=119 MANTENIMIENTO = 0 filas en prod (ALTA 1977, BAJA 417). Pero 'nada lo escribe nunca' es falso como afirmacion de CODIGO: v_estado_colectivo (drizzle/schema.ts:2668) publica todo estado no borrado del grupo vehiculo/estado sin excluir MANTENIMIENTO, ExpedienteForm.tsx:122-125 lo carga y :418-425 lo renderiza como opcion, :214 lo submitea, y services/vehiculos.ts:513 changeVehiculoStatus lo valida contra opciones y lo escribe por repositories/vehiculos.ts:822. Tampoco esta 'estructuralmente vacio' el tab: v_vehiculos_list_mantenimiento existe. Conclusion: MANTENIMIENTO es elegible y escribible hoy; nadie lo eligio nunca. Eso lo convierte en una pregunta de producto para Eugenia (se usa o se retira del catalogo), no en un defecto de cableado.
• wi-cli-venus note · 5w ago
  Premisa RE-MEDIDA el 2026-09-10 por db02-mba-l-cc recorriendo pg_constraint en los DOS entornos, no una lista hardcodeada. La premisa del ticket es CIERTA EN PROD y FALSA EN DEV. PROD 10.78.42.168 (PG 17.6): 37 columnas con FK a opciones(id), 0 filas con 119; 0 en tablas archive/hist; la vista existe; listo para el retiro directo. DEV 10.9.10.54 (PG 15.17): 39 columnas con FK, 2 filas con 119 en vehiculos_datos_colectivos.estado_id (vdc.id 5545 y 5566, vehiculos 5186/5216, los dos dominio NEA182, los dos creados por system_import, los dos con borrado_en NOT NULL y CERO filas en rutap.rutap_rows: dato de la era de pruebas, fuera del libro). borrado_en NO desbloquea un FK, asi que el DELETE falla en DEV y pasa en PROD. Ademas DEV tiene 51 filas historicas con 119 en vehiculos_datos_colectivos_archive (16 vehiculos, 2026-01-21 a 2026-07-31, todas por UPDATE) que PROD no tiene: la frase 'no hay dato historico' de la direccion del 08-20 vale para PROD y no para DEV. El archive no tiene FK a opciones, ninguna vista lo lee (medido) y no se toca: es el testigo. La cifra 19 columnas del gate del 08-20 no se sostiene hoy contra ninguno de los dos entornos (37 PROD / 39 DEV) - no se afirma cual era el alcance de aquella medicion, solo que la de hoy se re-derivo entera. El 39 vs 37 es deriva de esquema DEV->PROD. PAQUETE PREPARADO, NO APLICADO EN NINGUN ENTORNO: docs/migrations/2026-09-10-movilba-77-reapuntar-2-vdc-mantenimiento-a-baja-DEV.sql (DEV-only, reapunta las 2 filas a BAJA resuelto POR NOMBRE) y docs/migrations/2026-09-10-movilba-77-retirar-opcion-119-mantenimiento.sql (agnostico de entorno, DROP VIEW + DELETE fisico en la MISMA transaccion). Se REAPUNTA y no se borra la fila de negocio: conserva el registro y ademas evita desactivar trigger alguno en vdc, porque trg_soft_delete_vehiculos_datos_colectivos es BEFORE DELETE y un UPDATE ni lo roza; borrar dispararia ademas trg_archive y agregaria DOS filas mas con 119 al archive, o sea que borrar ensucia en vez de limpiar. BAJA y no ALTA por la respuesta de Eugenia del 09-10. Ensayado en DEV con COMMIT->ROLLBACK: paso 1 UPDATE 2 y controles posteriores verdes (0 vivas con 119, 2 en BAJA, archive 51->53 por el trigger); paso 2 corrido SOLO aborta correctamente con 'Hay 2 filas referenciando 119 en 39 columnas con FK' (control no vacuo: puede salir distinto); secuencia 1+2 completa verde, DROP VIEW + DELETE 1 real con el soft-delete desactivado, matview v_estado_colectivo refrescada por trg_refresh_catalog_matviews y ya sin MANTENIMIENTO, trigger re-habilitado. DEV verificado SIN CAMBIOS despues del rollback: 119 presente, 2 en vdc, 51 en archive, vista presente, matview todavia lo ofrece. NO EXERCITADO: nada corrio en PROD (solo SELECT), no se ejecuto el deploy de codigo, y no se probo la pantalla. pg_depend: 0 dependientes de la vista, asi que el DROP va sin CASCADE. Handoff de codigo DESPUES de la DB y como un solo deploy: introspect.sh, src/repositories/vehiculos.ts:17,264,268, el comentario de src/actions/vehiculos.ts:432-433, tools/import/01_add_missing_opciones.sql:10 (el SEED que recrea la fila - sin sacar esa linea un rebuild deshace la migracion en silencio), docs/reference/view-catalog.md:53,69 y tools/import/ver-parque.sql. DECIDE PRODUCTO, no este carril: docs/reference/parque-movil-api/data-contract.md:342,356 enumera 119 como estado valido para consumidores externos de parque-movil-api - retirarlo es un cambio de contrato. NO se agrega ningun trigger ni CHECK que prohiba estados fuera de ALTA/BAJA: la prevencion es la ausencia en el catalogo + el FK + sacar el seed. Indice en docs/migrations/README.md y entrada en pending-prod-changes.md. Ambos archivos sin commitear: los commitea el carril coder.
• wi-cli-venus note · 3w ago
  Medido db03 2026-09-22, read-only: public.v_estado_colectivo (matview detras de vEstadoColectivo) emite 116 ALTA / 117 BAJA / 119 MANTENIMIENTO en PROD, y solo 116/117 en DEV - 119 ya esta podado en DEV. Esto le da a 77 una razon operativa, no cosmetica: el form de edicion inline /vehiculos/<dominio>/editar/colectivo escribe vdc.estado_id via repositories/vehiculos.ts:1220-1224 sin allowlist ALTA/BAJA, y su dropdown sale de /api/vehiculos/detail-dropdowns (route.ts:58-62) sin filtrar (paths nombrados por coder03). En PROD un usuario puede entonces elegir 119; el proximo import lo devuelve a ALTA (rutap.reconciliar_snapshot asigna estado_id = estado_objetivo incondicional) - reversion deseada por regla de Elazar, pero el estado no existe en el libro y la UI no deberia ofrecerlo. Filas vivas de vdc con estado_id=119: 0 en DEV y 0 en PROD, asi que podar 119 en PROD no toca datos. Es replay a PROD de un arreglo ya aplicado y verificado en DEV (regla Elazar 09-19): usar el mismo instrumento que lo podo en DEV, no uno re-derivado. Viene de MOVILBA-259, cerrado hoy.
• wi-cli-venus parentChanged · 3w ago
  parent=MOVILBA-534
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca
• coder03assistant-mba-l-ca note · 1w ago
  Re-measured 2026-10-09, SELECT-only PROD then DEV (db04): old premise no longer holds. Option 119 MANTENIMIENTO is absent from both canonical catalog views; v_ui_vehiculo_estado_filtro offers only alta/baja/todos; v_vehiculos_list_mantenimiento is absent in both bases. Current VDC estado_id=119: 0 active / 0 deleted in PROD (2,424 total) and DEV (2,462 total). Archive retains 53 historical DEV references (0 PROD); no current historial/RUTAP normalized-history refs. The state cannot currently be stored because 119 is absent and the only FK is to opciones.id; app read/write allowlist is ALTA/BAJA. No DDL or writes performed; do not execute the prior GO/package against this state. Evidence: /data-lezama/movilba/evidencia/MOVILBA-77/2026-10-09-current-mantenimiento-census.md (SHA256 0017a6ed24e7f0662c951000fae82d9b813e1ff2b0609bb34fd900ff4fff6ecf); query /data-lezama/movilba/evidencia/MOVILBA-77/2026-10-09-mantenimiento-census.sql (SHA256 6277b9e7ddaec588e838a95b20eed0d16bd3d45fc0cc72b9265fc554f53a3404).
• coder03assistant-mba-l-ca canceled · 1w ago
  Canceled as obsolete after 2026-10-09 SELECT-only re-census: 119 and the maintenance list view are already absent in PROD and DEV, so the original empty-tab premise and proposed cleanup no longer apply. DEV retains 53 archive-only historical references; no writes performed.