Seleccion de fila: 223 vehiculos vigentes muestran un expediente de alta que no es el suyo (mas 132 observaciones y 9 IDs) - el estado actual sale de una fila CERRADA

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 6w ago
  parent=#3153
• wi-cli-venus descriptionChanged · 6w ago
  was: Elazar requires Observaciones to match the approved RUTAP book exactly now and on every future import. Independent check of 2026-09-01-1440 confirms 'Se modifica N° de dominio a pedido de la empresa' is source text (279 rows), not a rewrite. Real fidelity defects: the source sentence 'Se cedió la línea a la empresa NUDO S,A,' appears 78 times, while existing DB data is split between source spelling and normalized 'S.A.'; and 289 DB rows contain 'Importacion RUTAP 2026-08-05', absent from the book. Identify the historical/canonical pipeline step causing each, stop mutating or stamping source Observaciones, reconcile from the approved snapshot, and prove per-dominio exact parity. Do not use a one-off patch; preserve source text verbatim except documented technical hygiene in a derived comparison field.
• wi-cli-venus note · 6w ago
  Falta el componente MAS GRANDE del gap de observaciones, medido por db02-mba-l-cc contra el libro 08-31 (PROD, 1594 vigentes con fila abierta): - 132 dominios: PROD guarda las observaciones de OTRA fila del mismo dominio, una fila CERRADA. Ejemplo AH846RA: el libro tiene fila cerrada (baja 2026-08-19) con 'Se modifica N° de dominio a pedido de la empresa' y fila ABIERTA con 'Se modifican datos a pedido de la empresa'; la ficha de PROD guarda la de la fila cerrada. Mismo patron en todo el bloque AH846R*, AI122P*, AI153B*, AI239R*, AI282F*. - 17 dominios: PROD guarda un texto que no coincide con NINGUNA fila de ese dominio en el libro. Hay que leerlos a mano. - Total 149 = 132 + 17. CONFIRMADO que NO es reescritura del importer: 'Se modifica N° de dominio a pedido de la empresa' esta en el libro 279 veces (276 en filas CERRADAS, 3 en abiertas). coder02 grepeo tools/ y src/ y no existe regla que genere ese string. Mi hipotesis anterior de 'una transformacion reescribiendo el texto' era FALSA y queda retirada. Lo que SI es: la ficha deriva un valor de un EVENTO CERRADO en vez de la fila abierta. Es exactamente [[reference_derive_values_from_the_open_ssot_row_never_a_closed_event]], registrada como REPARADA el 2026-08-25. Volvio, o nunca se reparo del todo, en 132 de 1594 vigentes. Por eso 174 no se puede cerrar con una recarga de datos: si el importer sigue eligiendo la fila cerrada para observaciones, los 132 vuelven identicos despues de reimportar. El arreglo es 'derivar observaciones de la fila ABIERTA, como todo otro campo de estado corriente'. METODO, para que no se repita el error: comparar DEV contra PROD NO prueba fidelidad - los dos los cargo el mismo importer, asi que coinciden por construccion. El test es contra el libro, y contra la FILA CORRECTA del libro.
• wi-cli-venus descriptionChanged · 6w ago
  was: Elazar requires Observaciones to match the approved RUTAP book exactly now and on every future import. The source string 'Se modifica N° de dominio a pedido de la empresa' is legitimate (279 book rows), not an importer rewrite. Measured root cause for current-state mismatch: 132 of 149 mismatched current vehicles derive Observaciones from a DIFFERENT CLOSED RUTAP row of the same dominio instead of its exactly-one OPEN row. Fix the current-state projection/reconciliation so every field, including Observaciones, derives from the open source row; do not fix it with a text rewrite or one-off patch. The remaining 17 current mismatches require per-dominio review. Also reconcile two provenance defects from the approved source: 78 NUDO comments are split between source and normalized in DB; 289 DB comments do not exist in any book. Preserve raw source comment text exactly; technical comparison normalization must remain derived, never overwrite provenance. Proof: per-dominio current-row parity against the approved snapshot, plus no non-source stamp rows.
• wi-cli-venus verified · 6w ago
  AMPLIACION DE ALCANCE MEDIDA (db02-mba-l-cc, 2026-09-01, PROD 10.78.42.168 SELECT, libro aprobado 2026-09-01-1440, hoja Base, header fila 2, fila ABIERTA de cada dominio contra v_vehiculos_export). El defecto de 'derivar de una fila cerrada' NO esta limitado a observaciones. Medido campo por campo sobre 1590 dominios vigentes: expediente_alta 223 dominios <- el mas grande, no reportado hasta hoy observaciones 132 dominios id_adas/id_mdvr 9 celdas Los 223 de expediente_alta son todos rastreables: el valor que guarda PROD existe en el libro, en OTRA fila del mismo dominio, nunca en la abierta. Cero casos sin origen. Ejemplos: AE144FA (libro abierto EX-2026-36597770, PROD EX-2026-05471312), AD411ZK (libro EX-2026-36597770, PROD EX-2025-30122493), PIK914 y AF395VO/AF395VM (libro 'Resol-2026-186-GCABA-SECT', PROD un EX- de otra fila). Consecuencia: arreglar 174 solo en observaciones deja 223 vehiculos vigentes mostrando el expediente de alta equivocado, que es un instrumento legal en la ficha y en el PDF. Es UN solo defecto - de que FILA se deriva el estado corriente - sobre al menos tres columnas. El fix tiene que ser la regla de seleccion de fila, no un parche por columna. Separado y NO es este defecto: 15 celdas de expediente_alta difieren solo por NBSP->espacio, y 0 por colapso de espacios. El importer respeta su propia regla (tools/rutap-snapshot-import.py:125-126 en dev/dev: no colapsa espacios internos porque el run de 3 espacios es parte de la clave natural). 570 de 617 runs de 3 espacios se conservan en PROD. Sin escritura propuesta. Reparar necesita GO explicito de Elazar describiendo la escritura.
• wi-cli-venus verified · 6w ago
  Verificado de forma independiente por coder02-mba-l-cc el 2026-09-01, reproduciendo el hallazgo de db02-mba-l-cc con mi propio script contra PROD y el libro 2026-09-01-1440. Comparacion: expediente_alta de v_vehiculos_export contra la fila ABIERTA (Fecha_Baja IS NULL) de cada dominio, plegando NBSP y espacios repetidos antes de comparar. coinciden con la fila abierta : 1367 DIFIEREN : 223 de otra fila del mismo dominio : 223 de ninguna fila del libro : 0 Cero inexplicados: los 223 valores existen en el libro, siempre en OTRA fila del mismo dominio, nunca en la abierta. Es exactamente la firma de este item. Ejemplos: PIK914, AF395VO, AF395VM, AA217GL, PFS811 y PHN935 tienen todos 'Resol-2026-186-GCABA-SECT' en su fila abierta y PROD guarda un EX- sacado de otra fila (EX-2026-30084951 o EX-2026-10798296). POR QUE ESTO SUBE LA PRIORIDAD: son 223 vehiculos VIGENTES mostrando en la ficha y en el PDF un expediente de alta que no es el suyo. Un expediente es el instrumento legal del tramite, no un campo cosmetico como una observacion. Y EL ALCANCE DEL ITEM CAMBIA: este defecto NO es de observaciones, es de SELECCION DE FILA, y se manifiesta en al menos tres columnas medidas hoy - expediente_alta 223, observaciones 132, id_adas/id_mdvr 9. Un parche por columna va a dejar afuera las que nadie midio todavia. Lo que hay que arreglar es la regla que elige de que fila sale el estado actual, una sola vez, para todas las columnas derivadas. Cobertura de mi medicion: solo expediente_alta, solo fila abierta, solo PROD. NO ejercitado: DEV, el resto de las columnas, y los 798 dominios de PROD que no tienen fila abierta en el libro.
• wi-cli-venus priorityChanged · 6w ago
  0
• wi-cli-venus priorityChanged · 6w ago
  1
• wi-cli-venus titleChanged · 6w ago
  Seleccion de fila: 223 vehiculos vigentes muestran un expediente de alta que no es el suyo (mas 132 observaciones y 9 IDs) - el estado actual sale de una fila CERRADA
• wi-cli-venus verified · 6w ago
  PASADA 2 - DOMINIOS TODO-CERRADOS, y una CLASE NUEVA que la seleccion de fila NO repara (db02-mba-l-cc, 2026-09-01, PROD SELECT, libro aprobado 2026-09-01-1440). Cobertura completa: los 2388 dominios de PROD = 1590 con fila abierta + 798 todo-cerrados + 0 resto. expediente_alta en los 798 todo-cerrados, contra su ULTIMA fila cerrada: coincide con la ultima cerrada 561 valor de OTRA fila del dominio 148 <- mismo defecto de seleccion de fila PROD vacio 9 no esta en NINGUNA fila 80 observaciones, misma pasada: 569 coincide, 86 de otra fila, 93 vacio, 50 sin origen. Con esto el defecto de seleccion de fila en expediente_alta suma 223 vigentes + 148 cerrados = 371 dominios. Los 80 'sin origen' NO son una sola cosa y no deben contarse juntos: 42 SOLO MAYUSCULAS. El libro trae 'Ex-2025-29534573- -GCABA-DGGSM' y PROD 'EX-...'. El importer YA normaliza a mayusculas, en silencio, en 42 casos medidos. Relevante para MOVILBA-179: la pregunta a Elazar no es si empezar a normalizar, es si conservar una normalizacion que ya corre. 22 AUSENTE DEL LIBRO. PROD guarda un expediente que no esta en ninguna fila de ese dominio. Testigo ONM510: el libro solo tiene EX-2026-15533461, PROD guarda EX-2025-30119373. 16 PROSA INVENTADA - clase nueva, la mas grave. Dos cadenas que NO existen en ninguna parte del libro: 'Se modificaron datos a solicitud de la empresa' 10 dominios 'Segun Planilla presentada por la empresa' 6 dominios La frase del libro es 'Se modifican datos a pedido de la empresa' - otro verbo, otra redaccion. Testigos AE971FA y AE751LL. No es prosa del libro puesta en el campo equivocado: es texto que NOSOTROS escribimos y que el SSOT no contiene, en una columna de instrumento legal. Por que importa para el alcance de este item: un fix de seleccion de fila repara los 371 y NO repara estos 16 - no hay fila que elegir, el valor no existe en la fuente. Son dos defectos distintos bajo el mismo sintoma y necesitan dos verificaciones distintas. Sin escritura propuesta.
• wi-cli-venus note · 6w ago
  RE-MEDIDO 2026-09-03 contra el libro VIGENTE 2026-09-03-1049 (md5 b9880577fb9d886bfca4aaadba124ea5) y PROD de hoy. db02-mba-l-cc, SELECT. Fuente lado base: v_vehiculos_export. DENOMINADOR: 1586 dominios VIGENTES (con fila abierta en el libro y ficha viva en PROD). Normalizacion IDENTICA en los dos lados (NFKC + NBSP + colapso de espacios + minusculas) y declarada. El defecto CRECIO contra lo que decia la fila 19 de la hoja Convenciones (01/09): | campo | 01/09 | HOY 09-03 | denominador | |---|---|---|---| | expediente_alta de otra fila | 223 | 253 | 1586 | | observaciones de otra fila | 132 | 236 | 1586 | | ids (adas+mdvr+canbus) de otra fila | 9 | 37 (8+28+1) | 1586 | Total 526 celdas sobre 5 columnas, contra 364 el 01/09. Ademas 2 celdas SIN ORIGEN en ninguna fila del dominio (1 observaciones, 1 id_adas) - esas no son eleccion de fila equivocada, son valores que el libro no contiene en ningun lado. Sigue siendo UN defecto (de que fila se deriva el estado corriente) sobre 5 columnas, y sigue sin repararse. El crecimiento es esperable: cada libro nuevo agrega filas cerradas por dominio, asi que hay mas filas equivocadas para elegir. Confirma que no se cierra con una recarga. TRAMPA DE MI PROPIO INSTRUMENTO, y casi publico el numero: mi primera corrida dio 627 expediente_alta 'sin origen en el libro'. De esos 458 eran SOLO diferencia de espacios - PROD guarda 'EX-2026-10225370- -GCABA-DGGSM' con la corrida de 3 espacios y mi parser colapsaba los espacios del LADO DEL LIBRO y no del lado de PROD. Normalizacion ASIMETRICA. PROD es FIEL en esos 458. La corrida de 3 espacios en los expedientes es real en el libro y rutap-snapshot-import.py:125-126 la preserva a proposito porque colapsarla altera la clave natural. Regla: aplicar la MISMA funcion a los dos lados y decir cual, o el numero mide al parser. NO EJERCITADO: solo la pasada de dominios VIGENTES; no medi los 798 todo-cerrados contra su ultima fila cerrada. No medi DEV. Cero escrituras.
• wi-cli-venus note · 6w ago
  db02 2026-09-03: bounded 174 across the 9 vehicles named in the tracker sheet 'Bajas' (AA914MC AE512KL AE512KK AE352LC AC958LX AE618VI AA935OF AF106VS AB674IP). Book = 2026-09-03-1049-parque-rutap.xlsx (md5 b9880577fb9d886bfca4aaadba124ea5). Compared 4 columns per vehicle, not just expediente: expediente_alta, observaciones, id_adas, id_mdvr. Correct source row per commons s12 = the OPEN row (max fecha_alta) for a vigente, the last closed row for a baja. RESULT 3 of 9 hit, 6 clean. Widening from expediente-only to 4 columns took the count from 1/9 to 3/9 - the two extra cases have a CORRECT expediente and wrong obs/ids, so an expediente-only gate reports them green. 1. AE618VI (vigente, linea 102). Book open row 3375 alta 2026-08-18 exA EX-2026-37164952- -GCABA-DGGSM, obs 'Se modifican datos a pedido de la empresa'. Book closed row 3374 alta 2026-07-22 baja 2026-08-18 exA EX-2026-33347644- -GCABA-DGGSM, obs vacio. PROD ficha carries EX-2026-33347644 and obs NULL - both from the CLOSED row. id_adas 3028 / id_mdvr 403033363028 match either row, so they do not discriminate. 2 columns wrong. 2. AB674IP (vigente, linea 4). Book open row 158 alta 2026-08-10 exA EX-2026-36096231- -GCABA-DGGSM, obs vacio, id_adas 3902-70127, id_mdvr 88000006626. PROD ficha: expediente CORRECT (36096231) but obs 'Se modifican datos a pedido de la empresa', id_adas 0, id_mdvr 0 - all three from closed row 1144 (linea 34, alta 2026-04-21 baja 2026-08-10). 3 columns wrong. 3. AF106VS (vigente, linea 107). Book open row 3849 alta 2026-08-07 exA EX-2026-35826642- -GCABA-DGGSM, obs vacio, id_adas 0, id_mdvr 71448. PROD ficha: expediente CORRECT, but obs 'Se cedio la linea a la empresa NUDO S,A,' and id_adas BK11FBCPA00026 - both from closed row 332 (linea 7, alta 2026-04-01 baja 2026-08-07). id_mdvr 71448 matches both rows. 2 columns wrong. CLEAN 6: AC958LX AA914MC AA935OF (vigentes, all 4 columns match the open row) and AE352LC AE512KL AE512KK (bajas, all 4 columns match the last closed row). SUB-SHAPE worth separating in 174: cases 2 and 3 are NOT 'the whole ficha came from the wrong row'. Their expediente_alta comes from the OPEN row while obs and the ID columns come from an earlier CLOSED row - the newest period was applied to some columns and not others. Case 1 is the uniform shape (every discriminating column from the closed row). A fix that only corrects row selection for expediente leaves 2 and 3 broken. POSITIVE CONTROL the comparison did fire: it reproduced the known AE618VI expediente mismatch, so the 6 clean results are a measured match and not an empty matcher. NOT exercised: the other ~34 book columns, and any vehicle outside these 9.
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus note · 4w ago
  db03 2026-09-18 RE-MEASURED (SELECT only, DEV+PROD, inet_server_addr checked). Comparison: v_vehiculos_export current fields vs the single OPEN live import row (fecha_baja is null, borrado_en is null, origen='import') of rutap.vehiculo_historial_normalizado, per vehiculo with exactly one such row, folded (upper, NBSP/space collapse) both sides. PROD n=1600: expediente_alta differs 1 (1 of them equals a closed row's), observaciones differs 344 (341 equal a CLOSED row's observaciones of the same vehiculo), id_adas 1, id_mdvr 1. DEV n=1600: expediente 8, observaciones 19 (0 from closed rows), adas 2, mdvr 2. The 09-03 figure (253 expediente / 236 obs / 37 ids) has collapsed for expediente and ids; observaciones is the live remainder and is PROD-only: public.vehiculos_datos_colectivos.observaciones still exists in PROD (472 DROP applied in DEV only, PROD artifact held pending 479), so PROD export still reads the closed-row-derived VDC value. That is MOVILBA-472's PROD apply, not a new fix. NOT exercised: the 78 NUDO S,A/S.A. split (child MOVILBA-217), the 289 'Importacion RUTAP 2026-08-05' stamp comments, the 17 per-dominio review cases, the 1+1+1 residual expediente/adas/mdvr dominios (not enumerated yet).
• coder03-mba-l-cc note · 3w ago
  coder03-mba-l-cc 2026-09-24 - This defect is now visible in the vehicle PDF, not only in the row selection, and it says the opposite of the truth to the reader. Evidence: /data-lezama/movilba/import-reports/2026-09-24-0507-movilba-AC736PL-reporte01.pdf, exported from dev01 at 05:07. Informacion General prints 'Estado actual: Alta'. The Estado Actual block immediately below prints 'Baja registrada el 17/03/2026', 'Expediente de Baja: EX-2026-13178914- -GCABA-DGGSM' and 'Observaciones de Baja: Se modifican datos a pedido de la empresa'. AC736PL is not de baja: DEV v_vehiculo_historial shows its 2026-03-17 period with periodo_hasta NULL, and the PDF's own Historial block prints that same row as 'Tramite: Modificacion | Fecha de Alta: 17/03/2026 | Fecha de Baja: -'. So the page reads the CLOSE of the preceding period and relabels it a baja, which is this item's shape on the PDF surface. Two details that sharpen it. The expediente printed as 'Expediente de Baja' is EX-2026-13178914, which is the same string the same block prints as the current 'Expediente' - one expediente rendered as both the alta and the baja of the vehicle. And the text under 'Observaciones de Baja' literally says datos are being MODIFIED at the company's request, so the source row identifies itself as a modification inside the block that calls it a baja. Note for whoever fixes it: 'Vigencia desde' in that same block is now CORRECT (MOVILBA-525, verified on this same PDF), so the block mixes a correctly derived original-alta date with a wrongly derived baja - do not assume one selector feeds the whole box.
• audit-mba-l-ca audited · 3w ago
  audit pass: Commit 39a2b0ad page.tsx presentation gate only (PDF data + screen card). Focused source control, test:source, pnpm typecheck, targeted ESLint, git show --check. No DB/source-row parity, auth PDF export or visual render.
  payload

  {"scope":"Commit 39a2b0ad page.tsx presentation gate only (PDF data + screen card). Focused source control, test:source, pnpm typecheck, targeted ESLint, git show --check. No DB/source-row parity, auth PDF export or visual render.","outcome":"pass","evidence":"HEAD=39a2b0ad; page.tsx and its focused test are clean/committed. Both PDF and screen gate fechaBajaUltima, expteBajaUltimo, bajaObservacionesUltima on estadoCicloActual==='BAJA'; the previous 93ef9620 page had no such gate (git show|rg exit 1). Focused control passed 11 guarded reads; test:source 37/37, typecheck, targeted ESLint, commit check exit 0. This PASS does not resolve 174's incorrect current-source-row selection, PROD Observaciones parity, or provenance populations; ticket remains open.","reportRef":null}

• db03-mba-l-cc progress · 2w ago
  db03-mba-l-cc, 2026-09-28 12:30 -03. Scoped the remaining PROD observaciones defect (341/344 residual mismatches, per the 09-18 measurement). Root cause per MOVILBA-479 census (docs/reference/movilba-479-dev-prod-schema-census.md:129-137): PROD v_vehiculos_export_vdc/v_vehiculos_detalle/v_vehiculos_export still project observaciones FROM vdc.observaciones (app-editable, vehicle-level), not from the OPEN period row - same shape DEV already fixed in MOVILBA-472's DEV migration. TWO SEPARATE ACTIONS, not one: (a) swap the view source to the periodo-current row, leaving vdc.observaciones column and its 1545 rows of data untouched in PROD - no data loss, no GO needed, this alone fixes the projection defect this item is about; (b) DROP COLUMN vdc.observaciones on PROD (what DEV's migration also did) - BLOCKED, census flags 3/2413 vehicles whose text exists ONLY in vdc with no periodo counterpart, so that DROP destroys populated data and needs Elazar's explicit decision per commons carve-out, independent of this item. Proposing (a) as a scoped PROD view migration (same 7-object shape as the DEV artifact, DROP+CREATE no CASCADE, dependents checked via pg_depend first). Not yet written - next step. The other 3 residual cells (1 expediente, 1 adas, 1 mdvr) and the 289 unsourced stamp comments and 17 per-dominio reviews remain unmeasured this pass.
• db03-mba-l-cc progress · 2w ago
  Rehearsed PROD fix (ROLLBACK): public.v_vehiculos_detalle.observaciones was sourced from vdc.observaciones (vehicle-level, app-editable) instead of the current periodo row - v_vehiculos_export already resolved this via periodo_veh.observaciones, v_vehiculos_detalle never got the same fix. pg_depend checked: no second-hop consumer reads v_vehiculos_export_vdc.observaciones (the other vdc.observaciones projection), so this single-view swap is the whole scope, not a 3-object shape. Migration: docs/migrations/2026-09-28-movilba-174-vdetalle-observaciones-periodo-actual.sql - extends the view's existing cur_fa LATERAL (rutap.v_vehiculo_historial_actual) to carry observaciones, swaps the SELECT column. Control vehicle 3953 (AE631MI): old view returned stale closed-row text, new view returns '' (correct, matches periodo_actual). Rehearsed clean under ROLLBACK via SUPERUSER_ELAZAR_URL (PROD_DATABASE_URL has no CREATE on public), 60 cols/2417 rows unchanged. Ready for audit PASS, fixes a broken field so no GO needed. Fixes something broken (project CLAUDE.md), no GO needed. Separate from this: identified the 3 PROD vehicles whose observaciones text exists only in vdc with no periodo counterpart (per coder03's copy-forward-then-drop plan) - vehiculo_id 3502/AB674IP, 3953/AE631MI, 4433/AG202SZ, each has a live current periodo row (rutap.vehiculo_historial_normalizado ids 117203/116491/117992) with empty observaciones ready to receive the copy. That write and the follow-on DROP vdc.observaciones are tracked as their own step, not bundled into this migration.
• audit-mba-l-cc audited · 2w ago
  audit pass: 174 SQL full read: md5-pinned viewdef, single-field swap via existing LATERAL, OR REPLACE preserves relacl/columns. Positive control 3953: old stale text, new ''. Row/col sanity. NOT exercised: apply=true commit.
  payload

  {"scope":"174 SQL full read: md5-pinned viewdef, single-field swap via existing LATERAL, OR REPLACE preserves relacl/columns. Positive control 3953: old stale text, new ''. Row/col sanity. NOT exercised: apply=true commit.","outcome":"pass","evidence":"file full read; control lines 38-52 vs post-change 155","reportRef":null}

• db03-mba-l-cc verified · 2w ago
  Applied to PROD (SUPERUSER_ELAZAR_URL, PROD_DATABASE_URL has no CREATE on public): public.v_vehiculos_detalle.observaciones now sources from the current periodo row (rutap.v_vehiculo_historial_actual via the existing cur_fa LATERAL) instead of vdc.observaciones. Verified live post-commit: vehiculo 3953/AE631MI reads '' (was the stale closed-row text). Audit PASS from audit-mba-l-cc (md5-pinned viewdef, positive control, row/col sanity). Not yet ported to DEV (structure PROD->DEV per project CLAUDE.md; next step). Separate follow-on tracked, not part of this fix: copy-forward the 3 orphan vehicles' vdc.observaciones text into their periodo rows (3502/3953/4433, periodo ids 117203/116491/117992), then DROP vdc.observaciones - per coder03's plan, needs its own audit PASS, no GO (SSOT repair, not mass delete).
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 13:04 ART, PROD snapshot8 SELECT-only: among 1602 vehicles with exactly one open imported period, public.v_vehiculos_export has 1602 matches, zero missing, and zero byte mismatches in observaciones, expediente_alta, id_adas, id_mdvr versus that period. public.v_vehiculos_detalle observaciones also matches 1602/1602. The old Importacion RUTAP 2026-08-05 stamp appears zero times in current normalized history, VDC and export. Legacy VDC.observaciones still differs from open period on 574 rows, but this column is not the installed export/detail source (tracked 562/537). Preventive gap: importer final gate checks only state/dates; it can commit a future published-field drift. Added narrow open-period/export parity gate to tools/rutap-snapshot-import.py under lock: aborts on ambiguous open source, missing/duplicate export row, or any of the four field mismatches, PROD apply path only. Read-only query of that SQL on current PROD returns ambiguous=0, open=1602, export=1602, missing=0, mismatch=0; substituting legacy VDC observations gives 574 mismatches, a discriminating comparator. No import run or repo gates; diff pending audit.
• audit-mba-l-cc audited · 2w ago
  audit pass: Static review of new gate in rutap-snapshot-import.py: SQL logic, ambiguous-pop subquery, column names vs schema.ts, py_compile OK
  payload

  {"scope":"Static review of new gate in rutap-snapshot-import.py: SQL logic, ambiguous-pop subquery, column names vs schema.ts, py_compile OK","outcome":"pass","evidence":"No DB creds this lane; relied on db04 live SELECT-only run (1602/0/0/0); confirmed no automated gate covers this .py file","reportRef":null}

• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 12:54 ART. PROD movilba snapshot8, BEGIN READ ONLY/ROLLBACK; no table, view, or workbook write. Negative control for the shipped MOVILBA-174 export parity gate: exact open_source population, joins, five count outputs, comparison predicates, and Python abort condition from tools/rutap-snapshot-import.py; the only mutant is export_mutant.expediente_alta for vehiculo_id=4248 AF266JD, substituted with its real closed-period expediente EX-2026-14518564- -GCABA-DGGSM (open period has Res. SECT 56/2026). Unmutated counts (ambiguous,open,export,missing,differences)=(0,1602,1602,0,0), PASS. Mutant counts=(0,1602,1602,0,1), expected SystemExit 'export no sigue el periodo abierto' with differences=1. This exercises the gate SQL and abort branch with a controlled read-only export-row substitution, not a full importer run and not an actual stale installed view. No data changed.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc note · 1w ago
  Re-medido contra snapshot 11 PROD, solo lectura - db03-mba-l-cc 2026-10-08. Gate de paridad (tools/rutap-snapshot-import.py, ya en el ship path) re-corrido manualmente: ambiguas=0, filas_abiertas=1602, filas_export=1602, sin_export=0, diferencias=0 - identico al resultado shipeado 2026-10-01, sin regresion. DEV ya tiene el mismo fix portado: v_vehiculos_detalle.observaciones en PROD y DEV leen AMBOS cur_fa.observaciones (verificado via pg_get_viewdef, byte a byte identico) - el port a DEV que la nota del 09-28 marcaba pendiente YA ESTA HECHO (por otra mano, no documentada aca). Queda abierto SOLO lo que ya estaba parqueado: (a) el DROP de vdc.observaciones sigue bloqueado en la decision de Elazar (3 vehiculos 3502/3953/4433 con texto solo en vdc, destruye dato poblado) - sin cambio; (b) 289 comentarios de sello sin origen, 17 revisiones por dominio, y las 3 celdas residuales (1 expediente/1 adas/1 mdvr) de la medicion original siguen SIN medir en esta pasada - no bloquean el fix principal, que ya esta shipeado y verde en ambas bases.
• audit-mba-l-cc audited · 1w ago
  audit pass: docs/migrations/README.md hunk, DEV-convergence wording
  payload

  {"scope":"docs/migrations/README.md hunk, DEV-convergence wording","outcome":"pass","evidence":"viewdef md5 byte-identical PROD/DEV (ef7570b7...), cur_fa.observaciones present in both","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  Elazar GO 2026-10-08 12:55 ART (CLI, nqla 7a): DROP vehiculos_datos_colectivos.observaciones PROD then DEV; the 3 texts (vehiculos 3502, 3953, 4433) are quoted in the migration doc before the DROP. Executor: db03, audit, SHIP; coder04 removes the column from Drizzle/readers in the same ship.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• coder03-mba-l-cc statusChanged · 1w ago
  coder03-mba-l-cc 19:2xZ - promoted from backlog so the db03 lane has work while audit's queue clears 123. db03 is idle-by-queue, not idle-by-choice.
• db03-mba-l-cc note · 1w ago
  db03-mba-l-cc 2026-10-08, SELECT-only on PROD movilba and DEV movilba_dev. The two halves my own 14:27Z note left SIN MEDIR are now measured. Both come back clean, and in both cases the figure the ticket carries is NOT reproducible at the current state. HALF A - the 289 origin-less stamp comments: ZERO occurrences of the pattern Importacion RUTAP, in every store that has an observaciones column, in BOTH bases. rutap.vehiculo_historial_normalizado 0 of 5558, public.vehiculos_datos_colectivos 0 of 2424, public.vehiculos_datos_colectivos_archive 0 of 5685, public.v_vehiculo_historial 0 of 5558, rutap.rutap_rows 0 of 5558; DEV normalizado 0. POSITIVE CONTROL on the LIKE pattern, because a zero from a misspelled pattern is indistinguishable from a true absence: the same query for a pedido de la empresa returns 3734 in PROD and 3767 in DEV. So the 289 are gone, and this confirms db04's 2026-10-01 reading rather than resting on it. HALF B - the 17 per-dominio reviews: not reproducible, and the measurement that mattered is parity against the WRITER's own expression. observaciones is NOT a copy of the book cell: the projector derives it with rutap.observaciones_desde_libro(raw_observaciones, raw_expte_alta, raw_expte_baja). Against that derivation the current row reproduces 2424 of 2424 in PROD and 2400 of 2400 in DEV, ZERO divergences, every current row keyed to a real book row by (rutap_snapshot_id, rutap_fila_excel) with 0 orphans in both directions. TWO INSTRUMENT ERRORS OF MINE, both found by the controls and both corrected before concluding. First I joined the book by DOMINIO and got 5558 pairs for 2424 vehicles with 2238 differing - the book holds several periods per dominio, so dominio is a key too narrow and the join exploded; the current row carries its own book key and that is what to join on. Then I compared the stored value against the RAW book cell and got 642 differing, which measures the wrong expression. WHAT THOSE 642 ACTUALLY ARE, since the number will be quoted: all 642 have a NULL raw observaciones cell. 600 store the empty string and 42 store Se modifican datos a pedido de la empresa. That is not invention - the body of observaciones_desde_libro moves the phrase into observaciones when the book put it in an EXPEDIENTE column instead of an expediente number, which is the documented 174 handling. The control is inert for exactly those 642, by construction: mutating the raw cell cannot change an output that does not read it, so CONTROL insumo mutado returns 1782 and not 2424, and 1782 + 642 = 2424. The control discriminates for every row whose output depends on the raw cell and is provably inert for the rest - stating that is the point, since an inert control reported as green is a false gate. ONE RESIDUAL WORTH A NAME, not a defect I am fixing here: 600 current rows in PROD and 585 in DEV store the EMPTY STRING where the book has NULL. Faithful would be absent, not blank. It comes from the coalesce(observaciones,'') in the first branch of observaciones_desde_libro, it is consistent across both bases, and no surface distinguishes blank from absent today, so it is a fidelity nuance and not a visible defect. If Elazar wants NULL preserved it is a one-branch change to that function plus a re-projection, and it is a DECISION, not an obvious fix. NOT EXERCISED: no live HTTP request and no surface rendered - this is a database measurement, and the four-surface rule means export XLSX, PDF, the ficha and the JSON API each resolve observaciones through their own query. I measured the stored current row and the derivation, not what each surface serves. The 3 vehicles of the vdc DROP question and the vdc column itself are MOVILBA-745, parked on Elazar, deliberately out of scope here.
• db03-mba-l-cc blocked · 1w ago
  Both halves measured clean (note 20:25:16Z): 0 origin-less stamps in every store in both bases with the LIKE control at 3734/3767, and derivation parity 2424/2424 PROD and 2400/2400 DEV with 0 key orphans. The two remaining blockers are both OUTSIDE this item: MOVILBA-745, waiting on Elazar re-confirming the vdc observaciones DROP scope, and the three vdc texts that belong to 745. One residual is also on Elazar as a decision, not a fix: 600 PROD / 585 DEV current rows store the empty string where the book has NULL, from the coalesce in the first branch of rutap.observaciones_desde_libro. Moved off todo so it stops reading as work in hand.
• db04-mba-l-ca note · 1w ago
  db04 SELECT-only residual census 2026-10-08 22:21 ART, PROD snapshot 11 then DEV snapshot 21, each ROLLBACK. Known NULL->empty column is observaciones: current imported period 600/2424 PROD, 585/2400 DEV where book rutap_rows.observaciones IS NULL but normalized/view/export observations is ''. Full imported history: 1303/5558 periods per base empty vs raw NULL; 154 per base instead carry the approved derived phrase, outside this cohort. Raw normalized copy stays NULL for all 1457 book-NULL periods per base. On current cohort public.v_vehiculo_historial and v_vehiculos_export each show 600/585 empties. PROD live VDC observations: 595 NULL, 0 empty, 5 nonblank; DEV VDC column absent. Decision is NULL preservation vs blank rendering, not a row repair. Evidence /data-lezama/movilba/evidencia/MOVILBA-174/2026-10-08-null-observaciones-empty-census.md sha256 426243cc08ef5563b14d0a1d4ab4ccc7fb1f8d51b8cce115c567af29d0082e39; SQL sha256 25be8886ede2f56083b45e52c75ecc2e435b8ea498b11749f88659929403baa5. Scope: known observaciones residual, not all-column scan; no writes.
• db04-mba-l-ca note · 1w ago
  db04 22:23 ART SELECT-only attribution supersedes prior report pin 426243cc with c7615daa; companion SQL da41a0dd. Installed projector md5(prosrc)=a7c701fd in both bases calls rutap.observaciones_desde_libro for normalized observaciones and copies raw separately. Helper first CASE arm explicitly returns coalesce(observaciones,''); helper md5(prosrc) PROD c1a4b0fe / DEV 19234437 (formatting differs). On each base all 1457 book-NULL imported periods: installed helper returns '' on 1303, stored normalized is '' on the same 1303, 0 helper/stored mismatches. Installed materializar_snapshot_raices md5(prosrc)=b609ef7d both bases reads raw rutap_rows for roots but has 0 observaciones references; INSERTs to vehiculos/VDC omit that field. Thus it is not a second writer of normalized observaciones. VDC column split already covered by MOVILBA-585 and MOVILBA-745: DEV target removed by 472, PROD leg pending scope re-confirmation; no new item. Evidence /data-lezama/movilba/evidencia/MOVILBA-174/2026-10-08-null-observaciones-empty-census.md sha256 c7615daa017603848404aa495b58bb490f83640cfffca501fb78a94b210110fe; attribution SQL sha256 da41a0dd193770b75612432572fa30992c2ecfde0bd902486442549dfa43e3b1. No function was executed as a writer; no DDL/data change.
• db04-mba-l-ca note · 1w ago
  db04 SELECT-only closure of 1457=1303+154 and helper digest difference, 22:25 ART, PROD snapshot 11 then DEV 21, ROLLBACK both. On book-NULL periods, installed helper output equals stored normalized observaciones on every row (0 mismatches): empty current/historical PROD 600/703 and DEV 585/718; modification phrase current 42 each, historical alta 23 each, historical baja 89 each. Thus 154 phrase periods per base = 42 current + 112 historical, all 1457 have public.vehiculos row; not absent or unexplained. Helper raw md5(prosrc) PROD c1a4b0fe (523 chars), DEV 19234437 (541), but removing [[:space:]]+ from installed prosrc gives identical 457 chars/md5 14b7f1b576dfb0964c82cdbf96223925; direct CASE-body read shows line-break/indentation only. This is not a functiondef/deparser comparison. New evidence report /data-lezama/movilba/evidencia/MOVILBA-174/2026-10-08-observaciones-154-closure.md sha256 3875a23221385c753146bd1eb825a7cfd7d746aa3d0e0447dcd4748d4dd8363a; SELECT SQL sha256 267f6a59d56693dfb8c8a2e4041e95112070459fa1265a04cad59113958169ba. Prior census report c7615daa unchanged.