19 fichas de PROD con estado_id contradiciendo al historial

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  db02-mba-l-cc, 2026-09-12: este item esta APLICADO Y COMMITEADO EN PROD desde el 2026-09-07 bajo GO fresco, con verificacion posterior desde una conexion real de svc_nextjs, y su propio doc de ensayo. Sigue en backlog. Propongo cerrarlo - un item hecho que figura abierto vuelve a entrar en cada propuesta de escritura, y hoy entro en una.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The original 19 PROD ficha state corrections were not rechecked as a cohort against the current book and current vdc state. BWI show and recent events were read; status unchanged and no DB write.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 18:20: re-ran the cohort against the CURRENT book, which the 2026-09-24 sweep recorded as not done. The repair holds in PROD and does not hold in DEV. Instrument: the same comparison the 2026-09-07 record defines, not a re-derived one - public.vehiculos_datos_colectivos.estado_id resolved through public.v_opciones against rutap.v_vehiculo_historial_actual.estado_derivado, both vehicle and VDC row filtered on borrado_en IS NULL. Read-only, no write. PROD, snapshot 8: population 2419, discrepancies 0, and 0 fichas pointing at an estado_id with no label in v_opciones. The zero is a measured control and not a green line: the same query with the expected value inverted ALTA for BAJA reports 2419 of 2419, so the comparison does detect a mismatch when one is there. DEV, snapshot 20: population 2446, discrepancies 6, inverted control 2440. All six have the ficha at BAJA and the book at ALTA: AB370CU id 3469, AC774RY id 3609, AD463UE id 3672, PHN934 id 5017, PMP111 id 5087 and AB091XZ id 5651. All six are origen_ingreso='ssot_import' on both the vehicle and the VDC row, so none was created by a user through the app. What I cannot assert, and nobody should write otherwise: origen_ingreso is stamped on INSERT and never re-stamped, so it proves these six were not CREATED by a user and says nothing about whether a user later EDITED them. Elazar's first ruling of 2026-09-24 protects what users created OR edited, and this column cannot see the second half. Deciding these six needs the audit_log CREATE and UPDATE trail for those VDC rows, the way MOVILBA-182's cohort was built, not the provenance tag. Recommended next step for the db lane: run the same 316 update restricted to those six in DEV, rehearsed under ROLLBACK, only for the ones whose audit trail shows no user edit, and leave the rest alone. PROD needs nothing. UNEXERCISED: I did not pull the audit_log trail for the six, and I ran no write in either base.
• db04-mba-l-ca completed · 2w ago
  db04-mba-l-ca 2026-10-01 18:20 ART. Closed the original PROD repair scope on coder03-mba-l-cc's 2026-10-01 SELECT-only remeasurement against current snapshot8: 2419 live ficha/history comparisons, 0 state discrepancies, 0 invisible estado labels; inverted-expectation control 2419/2419. DEV snapshot20 has six ficha BAJA/book ALTA differences (AB370CU/3469, AC774RY/3609, AD463UE/3672, PHN934/5017, PMP111/5087, AB091XZ/5651), but these are NOT eligible for automatic SSOT overwrite under Elazar's DEV carve-out. My SELECT-only audit_log join by both vehiculos.id and VDC.id found all six have an app UPDATE by Leandro Baez (user 20349069890), paired vehicle/VDC entries with the same requestId; VDC UPDATE details include estadoId in the change list. Audit pairs: 1743/1744, 1740/1741, 1764/1765, 1761/1762, 1690/1691, 1737/1738. origen_ingreso='ssot_import' proves only imported creation and cannot override this edit evidence. No DEV data write; preserve all six user-edited rows. This closes the verified PROD defect, not a claim that DEV matches the book or that audit_log records direct SQL writes.