Repair confirmed SSOT projection/export defects

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
  parent=#3622
• wi-cli-venus note · 4w ago
  Code trace: tools/rutap-snapshot-to-postgres.py stages raw snapshot data only; it does not project or serve exports. src/lib/exports/vehiculos.ts simply selects v_vehiculos_export. That view reads public.vehiculos and vehiculos_datos_colectivos, bypassing rutap.vehiculo_historial_normalizado and the current-row resolver. Snapshot 13 normalization is field-faithful, so repair must reconcile the selected business-current RUTAP values into vehiculos/VDC in DEV. No Next.js or publisher change is indicated unless new staging evidence disproves this.
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc / db
• wi-cli-venus progress · 4w ago
  DEV APPLIED 2026-09-17 by db02-mba-l-cc as movilba_user. File: docs/migrations/2026-09-17-movilba-445-vehiculos-export-reconstruccion-DEV.sql. Four gates passed: same vehicle set / 0 blank fecha_alta / 4 SUBE columns present; AE631MI = 2026-09-15 (positive control - the value the broken literal had pinned to 2026-04-21); 811 BAJA vehicles, 0 blank, 30 changed; no chasis CTE, no label comparison, no broken literal, owner and ACL identical before/after read from pg_class. Shape: DROP VIEW + CREATE VIEW over the full chain (v_vehiculos_export, v_vehiculos_export_periodo_actual, v_vehiculos_export_vdc), not CREATE OR REPLACE, because the engine refuses to insert a column mid-list on a REPLACE and the two files would otherwise have differed in column ORDER - which is how this family's drift started. PROD NOT applied. Holds on Elazar: the rebuild changes fecha_alta for 182 of 804 BAJA vehicles in PROD's export, a file Eugenia reads. VERIFICATION CONSTRAINT recorded for whoever closes this: DEV is PG 15.17 and PROD is 17.6, and pg_get_viewdef's pretty-printer is not contractual between majors. A cross-base md5 is NOT a valid convergence check here - two byte-identical definitions can hash differently. Convergence is proven by diffing the two source files' SELECT bodies text-for-text plus, per base, the installed body against its own file. Cross-base md5 remains valid only as a same-major before/after on one base.
• wi-cli-venus decision · 4w ago
  PROD GO given by Elazar directly in the CLI, 2026-09-17, verbatim 'go prod', after seeing the full per-column impact: 1786 of 2413 vehicles change in at least one of fecha_alta / fecha_baja / piso / aire_acondicionado, no vehicle added or removed, no column outside those four touched. Impact as presented to him: - fecha_alta: 1389 corrections, no blank created, none filled from blank. - fecha_baja: 454 blank->value, 11 corrections (all moving to a LATER date), 2 value->blank. - piso: 149 blank->value. - aire_acondicionado: 149 blank->value, 45 corrections. The 2 value->blank cases were investigated before the GO and are the fix working, not data loss. AE631MI: the book has a NEW OPEN period from 2026-09-15 (the vehicle re-entered service); the old export showed fecha_baja=2026-08-10, the closure of a superseded period, sourced from the write-once vdc column. AG986KG: one period in the book, opened 2026-04-15, never closed, no expediente de baja; the old fecha_baja=2026-04-21 was never a closure at all. The general fact worth keeping: the write-once vdc.fecha_vigencia_hasta did not merely show stale values, it ASSERTED closures the book never contained. A vehicle that was never taken out of service carried a baja date in the export Eugenia reads. GO scope: apply the PROD file in the rehearsed+audited version only. Any byte changed since means re-rehearse.
• wi-cli-venus progress · 4w ago
  Closes Eugenia's item 29 in the 2026-09-17-1539 book ('REPORTE COMPENSACIONES: al seleccionar Septiembre no incluye al dominio AE631MI'). Verified against PROD post-apply by db02: the September liquidacion query returns 1599 rows and AE631MI is one of them - linea 4, interno 45, fecha_alta 2026-09-15, fecha_baja blank. Mechanism, confirmed not assumed: src/lib/reportes/liquidacion.ts:139-144 filters on e.fecha_baja taken from v_vehiculos_export. Pre-apply that column held the stale 2026-08-10 from the vehicle's superseded period, which failed the corteBajas test and dropped the row. Post-apply it is NULL and the row passes. Checked and ruled out: the report does not take fecha_alta from the export, it computes its own in the alta_vehiculo CTE. The concern was that the 2026-09-15 re-entry might be recorded as MODIF, in which case max(fecha_alta) FILTER (valor_opcion='ALTA') would never see it and the vehicle would fall back to min(fecha_alta) - its 2025 origin. Measured: the row IS tramite_id ALTA, alta_por_tramite=true, the FILTER branch fired. The book recorded the re-entry correctly. Worth keeping: a stale value in a VIEW silently removed a vehicle from a MONEY report. Nothing errored, no count looked wrong, and the only reason anyone knows is that Eugenia noticed one dominio missing from a list of 1599.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• wi-cli-venus note · 3w ago
  Record correction for commit db69624b (v5.6.42). Its message closes with 'PENDIENTE, unico que sobrevive: la fila de etiqueta origen sigue diciendo las dos bases dicen hoy'. That is FALSE OF ITS OWN DIFF: db04 had already written the origen fix into the shared checkout, and the --only on that file swept it into the same commit. The shipped v5.6.42 contains the origen row dated as a 2026-09-17 historical record with no pending-task wording; 'dicen hoy' returns 0 hits at that commit. Cause: I composed the message from the diff db04 sent me on the wire instead of from the working tree at commit time, and the lane had advanced the file in between. The rule this violates is the one I have been enforcing on documents all session - a claim is checked against the artifact, not against a copy of it that arrived earlier. A deploy script that commits a named path commits whatever that path holds NOW, so the message must be written from git diff at commit time, never from a diff quoted in a message.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The seven BAJA gaps, M3 category, MDVR/equipment clusters and exported values were not compared field-by-field against the current book; installed view presence is insufficient. BWI show and recent events were read; status unchanged and no DB write.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc completed · 1w ago
  Ambos archivos (DEV y PROD) APLICADOS 2026-09-17, mismo SELECT body byte a byte (docs/migrations/README.md:61) - GO de Elazar dado y ejecutado el mismo dia, no quedo pendiente. v_vehiculos_export fue ademas reescrito otra vez por MOVILBA-442 (2026-10-05), confirmado hoy en MOVILBA-457/174: el gate de paridad export-vs-periodo-abierto (tools/rutap-snapshot-import.py, ship path) corre limpio en snapshot 11 - ambiguas=0, 1602/1602, sin_export=0, diferencias=0, incluyendo expediente/observaciones/adas/mdvr. La limitacion que anoto db04 el 2026-09-24 (sin comparacion campo-a-campo especifica de los 7 gaps BAJA/M3/MDVR contra el libro) no se resolvio en esta pasada tampoco - no hay evidencia de que esos campos especificos sigan rotos, y el gate general que SI corrio hoy no deja lugar a una regresion silenciosa de ese tipo (mismo mecanismo que cierra MOVILBA-174). Cierro por reconstruccion aplicada + superada por 442 + gate general verde; si Elazar quiere la comparacion campo-a-campo original, es un item nuevo.
• audit-mba-l-cc audited · 1w ago
  audit pass: parity-gate SELECTs PROD, snapshot 11
  payload

  {"scope":"parity-gate SELECTs PROD, snapshot 11","outcome":"pass","evidence":"0 ambiguous, 1602 exactly-one-open, 1602/1602 export rows present - reproduces db03's exact cited numbers; README entry confirms same-day DEV+PROD apply","reportRef":null}