Reconcile current approved RUTAP book with installed DEV/PROD snapshots and fidelity

Sub-tickets — 8/9 done

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus assigned · 6w ago
  db03-mba-l-ca / db
• wi-cli-venus note · 6w ago
  Importer constraint (measured by coder02, 2026-08-31): each RUTAP book is a complete redeclaration per dominio. Preserve raw snapshots, but replace—not merge—the selected snapshot's operational/history projection per dominio. Reconciliation must compare deterministic row-content sets/signatures, not count(*); sort ties otherwise create false positives. Repairs already answered by the book: AG986KG stale erroneous baja and AD956UK self-referential baja.
• wi-cli-venus note · 6w ago
  CORRECTION to the 2026-08-31 importer-constraint note: AG986KG is a post-import verification case (book has one open row; after replace it must be ALTA with no fecha_baja), not a hand repair. AD956UK is NOT a stale-baja repair: PROD's live row matches the book; its other source-faithful rows are soft-deleted, making it a missing-history/source-defect case. Do not use expte_alta as a tie-breaker; compare row-content sets.
• wi-cli-venus decision · 6w ago
  Elazar policy, 2026-08-31: DEV must be the exact or documented-enhanced reflection of the selected RUTAP SSOT—no append-only carryover. Per dominio, selected-snapshot rows replace prior DEV projection: 4 source rows in snapshot 3 and 2 in snapshot 8 means DEV has 2, not 3/5. Intentional corrections/enhancements are documented and sent to Eugenia; otherwise source is fixed. After catalog resolution and verification, promote the same smart reconcile (insert/update/remove) to PROD; PROD must contain no data absent from DEV while app has no production users. App-created DEV test data is recorded, then removed/reconciled on the next SSOT. After go-live, app.movilba.com becomes SSOT.
• wi-cli-venus note · 6w ago
  CORRECTION / non-GO: the prior DEV→PROD wording is policy intent, not write authorization. Do not copy or delete PROD rows from DEV blindly. DEV rehearses the selected book; PROD must import the SAME selected book independently with the same replacement semantics, after a fresh PROD GO and exact-resource lock. Before any promotion, re-measure environment-specific columns and protect non-book/system fields; deletion/trigger disable is prohibited.
• wi-cli-venus note · 6w ago
  Clarification to the immediately prior note: deletion or trigger disable on public.vehiculo_historial is prohibited.
• wi-cli-venus decision · 6w ago
  Elazar clarification, 2026-08-31: RUTAP/Parodi Excel is the sole record of all pre-handoff changes. At handoff MovilBA user-facing vehiculo_historial must be zero; it starts recording only changes made in MovilBA after handoff. Do not materialize historical Excel rows as app change-history rows. Import projects the selected book's current vehicle state after catalog normalization; retain raw source snapshots separately for provenance/audit. Therefore source-row count has no arithmetic relationship to user-facing vehiculo_historial count before handoff.
• wi-cli-venus note · 6w ago
  IMPLEMENTATION HOLD: zero user-facing change history at handoff is a product target, not currently executable by import alone. Existing current linea/entity views derive from vehiculo_historial; physically emptying it removes those fields. No purge or history deletion is authorized. Requires a prior design decision: move current linea/entity state to a current-state carrier and rebuild dependent views, or retain one non-user-facing baseline per vehicle and exclude it from the displayed change history.
• wi-cli-venus decision · 6w ago
  Elazar data-model decision, 2026-08-31: ownership is entidad → linea → vehiculo. A vehicle has no direct entidad relation; its entity is derived through its current line. A line/entity transfer changes the entidad→linea relation and thereby all vehicles on that line. An individual vehicle sale/move changes the linea→vehiculo relation, with expediente and validity dates. RUTAP import establishes normalized current relationship baselines; pre-handoff Excel rows remain raw provenance, not app change history. This schema change is the prerequisite for zero user-facing vehicle history at handoff.
• wi-cli-venus note · 6w ago
  Los 6 dominios del libro sin vehiculo en PROD: medidos y clasificados (coder02-mba-l-cc, 2026-08-31, libro 2026-08-31-0939 hoja Base vs PROD 10.78.42.168). SON HUECOS DE IMPORT, NO BAJAS. Los 6 tienen Fecha_Baja y Expte. Baja VACIOS en el libro, o sea vigentes. Y no existen en PROD de ninguna forma: la consulta contra vehiculos sin filtrar borrado_en devuelve CERO filas para los seis. No estan soft-deleteados, no estan. AA195PH, AA195PJ, AB126BE, AI429RW, AI429SH, AI482RD. CINCO DE LOS SEIS YA ESTAN EXPLICADOS por el delta 08-27 -> 08-31 documentado en este mismo item, o sea que son consecuencia directa de que PROD este dos libros atras: - AA195PH, AB126BE, AA195PJ son los DESTINOS de las tres transferencias de equipo (AD482RQ int 4 -> AA195PH; AE548EX int 24 -> AB126BE; AE992PE int 49 -> AA195PJ). El dominio de destino es nuevo, por eso falta. - AI429SH es el Alta nueva del 2026-08-14. - AI429RW es la fila del cambio de mayuscula en Chasis_Modelo. AI482RD NO figura en el delta 08-27 -> 08-31 descrito arriba. O entro en el libro del 08-27 (que tampoco esta importado en PROD, que esta en snapshot 6 = libro del 08-26) o es un hueco aparte. Vale separarlo al correr el import: si despues del import sigue ausente, es un hueco real y ahi si es pregunta. NO ES PREGUNTA PARA EUGENIA: fila presente en el libro y ausente de nuestros datos se IMPORTA. Regla permanente de Elazar. Cierra la pregunta que levanto db02-mba-l-cc sobre si los 6 eran huecos de import o bajas legitimas: son huecos, y el import baseline los cubre.
• wi-cli-venus statusChanged · 6w ago
  DESBLOQUEADO POR MEDICION: MOVILBA-213 le pone numero al costo de no importar. 16 colectivos VIGENTES en el libro no existen en PROD (6 en el libro del 08-31, 10 en el del 09-01, 16 en el del 09-03: crecen libro a libro), y 15 mas figuran ALTA en la ficha cuando el libro ya los retiro. Son 32 vehiculos mal en la superficie que ve el usuario, a 4 dias del arranque. Target: /data-lezama/rutap-ssot/2026-09-03-1049-parque-rutap.xlsx. Deja de ser p0-bloqueado-en-Elazar: sincronizar DEV y PROD al libro es rutina por GO permanente del 2026-09-02.
• wi-cli-venus statusChanged · 6w ago
  Consolidated P0 re-import started: latest SSOT baseline; MOVILBA-190/186 and líneas 23/90/99 (220) are one reconciliation pass. Preserve 0 vs NULL; current projection is row-consistent; provenance audit-only.
• wi-cli-venus decision · 6w ago
  2026-09-03 directive: DEV-first replacement import. Rebuild vehiculos, vehiculos_datos_colectivos and vehiculo_historial from whole SSOT, including closed rows; keep catalogs/personas/entidades. Preflight validadoras_historial separately; never cascade it. Temporary trigger disable must be named, re-enabled, and verified. PROD only with fresh named GO and immediate dump. User-provenance marker is required before go-live because rebuild deletes non-SSOT edits.
• wi-cli-venus blocked · 6w ago
  DEV destructive preflight found FK dependencies omitted from initial scope: rendiciones.deudas_dominios.vehiculo_id→vehiculos; rutap.m95_cambios_backfill_dev.vehiculo_historial_id→vehiculo_historial; rutap.vehiculo_historial_normalizado.vehiculo_id→vehiculos; and validadoras_historial (2 rows, ON DELETE RESTRICT). Every dependent must have explicit preserve/repoint/rebuild treatment before delete order is approved; no trigger disable or delete executed.
• wi-cli-venus decision · 6w ago
  Dependency handling decided: is parked keyed by dominio and remapped after rebuild; every parked dominio must resolve or the operation fails. remains untouched only after execution-time verification that every vehiculo_id is NULL. Rebuild rutap.m95_cambios_backfill_dev and rutap.vehiculo_historial_normalizado as snapshot-derived scratch. Stable cross-rebuild key is dominio, never vehiculos.id. Related pre-go-live blocker: MOVILBA-225.
• wi-cli-venus decision · 6w ago
  Correction to prior event: public.rendiciones.deudas_dominios is parked keyed by dominio and remapped after rebuild; public.validadoras_historial remains untouched only after execution-time verification that every vehiculo_id is NULL. Rebuild rutap.m95_cambios_backfill_dev and rutap.vehiculo_historial_normalizado as snapshot-derived scratch. Stable cross-rebuild key is dominio, never vehiculos.id. The previous event lost identifiers due shell quoting; this event is authoritative.
• wi-cli-venus decision · 6w ago
  DEV dependency correction from live preflight: rendiciones.deudas_dominios.dominio cannot be used as parking key. In 233/233 rows it differs from the linked vehiculos.dominio; 231 are blank and 2 stale. Before deleting vehicles, park each debt row with normalized old public.vehiculos.dominio obtained by joining its old vehiculo_id; after rebuild resolve new vehiculo_id by that captured domain and abort on any unresolved value. MOVILBA-224 is the provenance/go-live blocker; MOVILBA-225 is unrelated legacy history-view repair.
• 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
  PREMISA FALSIFICADA - re-medida por db02-mba-l-cc el 2026-09-12 04:05, DEV y PROD, solo lectura. Este item dice que el libro del 2026-08-31 esta sin importar y que PROD esta DOS libros atras. Ninguna de las dos cosas describe el estado de hoy. Medido contra rutap.snapshots en los dos entornos: la punta de DEV es el snapshot 12, archivo 2026-09-07-2350-parque-rutap.xlsx, importado 2026-09-08 00:09:48, 5388 filas. La punta de PROD es el snapshot 11, archivo 2026-09-05-0649-parque-rutap.xlsx, importado 2026-09-05 06:57:22, 5388 filas. PROD ademas NO tiene el snapshot 10: sus snapshots son 9 y 11. El libro mas nuevo en disco es /data-lezama/movilba/libro/2026-09-10-1150-parque-rutap.xlsx y no esta importado en ningun entorno. O sea: PROD esta UN libro detras de DEV y DOS libros detras del disco. Y el libro del 08-31 que este item nombra NO llego a ser snapshot en ninguno de los dos entornos - no esta 'sin importar todavia', quedo saltado: la serie va 09-01, 09-03, 09-04, 09-05, 09-07, 09-10. Antes de trabajar este item hay que decidir si sigue siendo sobre el libro del 08-31 (que nadie importo y que el 09-10 ya superpone) o si es sobre la brecha PROD-contra-disco, que es lo que existe hoy. La correccion del dato en si es una ESCRITURA - correr un import - y necesita autorizacion por mecanismo de Elazar; este carril no la ejecuta.
• 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:01 ART — SELECT-only rutap.snapshots check: current DEV movilba_dev snapshot id 18 and PROD movilba snapshot id 5 both name 2026-09-19-0648-parque-rutap-corrected.xlsx and contain 5528 source rows. The older 2026-08-31 unimported-book premise is obsolete; full fidelity gates against this current book were not exercised, so status remains inProgress.
• db04-mba-l-ca descriptionChanged · 3w ago
  was: Hallado y medido por db02-mba-l-cc el 2026-08-31 10:20. Asignado a db03-mba-l-ca porque reclamo el proceso de import RUTAP como suyo bajo MOVILBA-13; si Elazar lo reasigna, que se reasigne. EL LIBRO NUEVO NO ESTA DONDE DEBE Y NO ESTA IMPORTADO. Vive en /data-lezama/rutap-ssot/2026-08-31-0939-parque-rutap.xlsx, md5 828f2005d50b9eddb93f7b1ca6c065c0, 1734648 bytes. La ubicacion canonica segun docs/reference/rutap-ssot-location.md es rutap-ssot/ dentro del checkout, y ahi el archivo mas nuevo sigue siendo el del 08-27. DEV esta en snapshot 7 (libro del 08-27) y PROD en snapshot 6 (libro del 08-26), o sea PROD esta DOS libros atras, no uno. DELTA MEDIDO 08-27 -> 08-31 (Base, cabecera identica, 5257 -> 5260 filas): 6 filas borradas, 9 agregadas. No es ruido, es contenido: 1. AF875JB: borrada la fila hibrida 013040/403033383040. Cierra MOVILBA-154. Sobrevive 13061/403033383061. 2. TRES TRANSFERENCIAS DE EQUIPO, misma forma las tres: el dominio viejo recibe Fecha_Baja 2026-08-27 y aparece un Alta nueva del 2026-08-27 con EL MISMO ID ADAS y EL MISMO ID MDVR. AD482RQ int 4 -> AA195PH int 4 (ADAS 20250730A10018X, MDVR 16400014799); AE548EX int 24 -> AB126BE int 24 (20250730A100163 / 16400014717); AE992PE int 49 -> AA195PJ int 49 (20250730A100170 / 16400010881). El equipo se muda de patente y conserva interno. Esto es exactamente el caso de continuidad fisica de docs/design/movilba-125-physical-continuity-resolver.md, y es la explicacion legitima de por que 363 de 2334 id_mdvr distintos aparecen en mas de un dominio: no es contaminacion, es historia del equipo. 3. PQW567 int 4515: Fecha_Baja 2026-08-28, sin reemplazo. 4. AI429SH int 206: Alta nueva, fecha 2026-08-14. 5. AI429RW: unica diferencia Chasis_Modelo 'MA 6.0 LEe' -> 'MA 6.0 LEE'. Cambio de mayuscula, cosmetico, pero cuenta como fila borrada+agregada en cualquier diff por contenido - ojo al medir el delta del proximo libro. QUE HACE FALTA: mover el archivo a la ubicacion canonica y correr el importer contra DEV con el ensayo primero (apply=false), despues PROD con GO propio y explicito de Elazar. La proyeccion operativa de DEV (2026-08-28-movilba59-rutap-snapshot7-operational-dev.sql) excluye AF875JB a proposito; con este libro esa exclusion deja de hacer falta y hay que rehacer la proyeccion, no reusarla. NO ESCRIBI NADA. Todo lo de arriba es lectura del xlsx y SELECT.
• db04-mba-l-ca titleChanged · 3w ago
  Reconcile current approved RUTAP book with installed DEV/PROD snapshots and fidelity
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:12 -03 — Replaced obsolete 08-31/PROD-two-books-behind description and title with the surviving current-source reconciliation task. Measured 2026-09-24: DEV snapshot 18 and PROD snapshot 5 both name the 09-19 corrected workbook (5528 source rows); 09-23 top-level workbook exists but approval/current-source diff and full field fidelity remain unverified. Old evidence remains in BWI descriptionChanged history. Status inProgress; no DB write.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 05:55 -03 — Authorized current-book import preflight, PROD first. Verified source SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19 and importer MD5 a7b14f7c2f6fa9bcb3383aaf2a7136cf; dry run parsed 5538 rows/52 columns. Importer scan reported 35 source-content contamination cells (report only), 4636 hygiene cells (technical normalization only), 5736 numeric ID cells, 0 impossible dates, and 3 substring ID findings. It EXITED 1 at the PROD schema/header gate: Base headers differ from rutap.rutap_rows; expected col_39 and col_52 missing, unexpected digitos present, order_igual=false. Independently read-only checked Base column 40 Digitos: 0 nonblank values across 5538 vehicle rows. Downstream PROD reconciliation/fidelity/catalogue/history/application-health gates NOT RUN because preflight stopped at header mismatch. No --apply, no schema or data writes. Post-check SELECT: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 still 2026-09-19-0648-parque-rutap-corrected.xlsx, each 5528/5528 rows; count of new importer MD5 in rutap.snapshots=0 in both. Import lock released. Need resolve/authorize handling of the source-header/schema mismatch before retrying PROD preflight; DEV refresh remains gated on healthy PROD.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 06:08 -03 — Read-only MOVILBA-155 follow-up, exact header via tools/rutap-snapshot-import.py::read_sheet on current XLSX (SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19): 5538 rows, 52 normalized headers, ordered: 1 cuit; 2 identificador_empresa; 3 tipo_servicio; 4 linea; 5 nro_dominio; 6 nro_interno; 7 ano_modelo; 8 unidad_propulsora; 9 chasis_marca; 10 chasis_modelo; 11 chasis_nro; 12 tipo; 13 piso; 14 carroceria; 15 carroceria_categoria; 16 motor; 17 motor_nro; 18 tipo_motor; 19 asientos; 20 aire_acondicionado; 21 consumo; 22 cabina_antivandalica; 23 adas; 24 mdvr; 25 id_canbus; 26 camaras_adas; 27 id_adas; 28 camaras_internas; 29 id_mdvr; 30 pantallas; 31 wifi; 32 conexionesusb; 33 identidad; 34 fecha_alta; 35 fecha_baja; 36 observaciones; 37 expte_alta; 38 expte_baja; 39 tramite; 40 digitos; 41 col_40; 42 col_41; 43 col_42; 44 col_43; 45 col_44; 46 col_45; 47 col_46; 48 col_47; 49 col_48; 50 col_49; 51 col_50; 52 col_51. (Source workbook Digitos is blank on all 5538 vehicle rows.) DEV current snapshot 18 and PROD current snapshot 5, each 5528 rows, SELECT census across current snapshot: col_39 through col_52 each 0 non-NULL / 5528. Live catalog output columns (both bases) shows all col_39..col_52 from rutap.v_rutap_latest, v_rutap_latest_norm, v_rutap_latest_projection_eligible, v_rutap_rows_norm, v_rutap_ultima_alta_por_dominio. Direct pg_depend refs from rutap.rutap_rows are v_rutap_latest and v_rutap_rows_norm; v_snapshot_catalog_preflight also references col_39..52 but does not project them as output columns. No writes.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca | 2026-09-24 06:25 ART — PROD import completed from the current pinned SSOT /data-lezama/movilba/libro/2026-09-24-0434-parque-rutap.xlsx (SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19): snapshot 6, 5538 Base rows, 2414 domains; previous snapshot 5 replaced. Reconciliation reported 0 deletes; final parity 2414 vehicles, 0 state/date differences. PROD checks: rutap-sync-checks all pass (815 live bajas preserved; export 2414 rows, 1599 Alta/815 Baja; no missing/extra domains), fidelity gate found only documented transformations (MOVILBA-248 observation/expediente routing and CR/LF flattening for four motor/chassis values), history has 5538 imported rows/2414 vehicles with 0 unresolved normalizations/conflicts, current/history/export cardinalities agree; health endpoint returned status=ok (anonymous branch, so not evidence of DB connectivity). DEV refresh NOT applied. DEV dry run reported 17 absent-from-book candidates, all origen_ingreso=app_dev, plus 54 origen=app history rows (48 tied to candidate vehicles; 6 on survivors) that apply would delete. Installed DEV rutap.reconciliar_snapshot was SELECT-inspected and deletes candidates without provenance filtering and requires all app history deleted. This conflicts with CLAUDE.md's preservation of independently created DEV test rows and no silent app-history erasure; stopped pending safe resolution. DEV remains on snapshot 18 (5528 rows).
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca | 2026-09-24 06:52 ART — Correction to my earlier interpretation: the installed reconciliation bodies are not DEV-only drift. Read both with , and measured in each: DEV (, ) = f576d7fc0c1872cec25a2e350ebaacf0; PROD (, ) = the same f576d7fc0c1872cec25a2e350ebaacf0. In both bodies, = false; the exact 486 non-import-history guard marker = false; marker = true and prosrc contains MOVILBA-517 = true. Thus both bodies match each other, neither matches the 486 behavior (whose recorded applied prosrc md5 is f59c5c3304a39762c9361a1ddb0bb76d and whose migration has the provenance filter at line 340 and non-import RAISE at line 499). The current body reports non-import history but follows its app-history deletion path rather than the 486 abort. This is a PROD finding too: the 09/24 import ran against the same filterless installed body; its zero-delete result does not demonstrate the 486 provenance protection. No body repair or DEV import was run in this check.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca | 2026-09-24 06:53 ART — This event supersedes the malformed prior event body, whose backtick-quoted text was stripped by the shell. Reproducing query on each connection: SELECT current_database(),current_user; SELECT md5(p.prosrc), position('v.origen_ingreso = ''ssot_import''' in pg_get_functiondef(p.oid))>0, position('esta funcion no decide si un evento de app sobrevive al vehiculo' in pg_get_functiondef(p.oid))>0, position('rutap_reconcile_app_borrar' in pg_get_functiondef(p.oid))>0, position('MOVILBA-517' in p.prosrc)>0 FROM pg_proc p WHERE p.oid='rutap.reconciliar_snapshot(integer,boolean)'::regprocedure. Results DEV movilba_dev/movilba_user: f576d7fc0c1872cec25a2e350ebaacf0, provenance filter false, 486 non-import history RAISE marker false, app-history deletion marker true, 517 marker true. PROD movilba/postgres: identical results and hash. Therefore both installed bodies are the same and neither matches 486: the 486 applied-body hash recorded in its migration is f59c5c3304a39762c9361a1ddb0bb76d; that file has the ssot_import candidate predicate at line 340 and hard RAISE on non-import history at line 499. Current function instead contains the 517 app-history deletion path; it counts non-import history but has no 486 guard. This is a PROD finding too. The 09/24 import used the same filterless body; zero deletes do not prove the 486 provenance protection. No reconciler change or DEV import was run for this check.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca | 2026-09-28 10:58 ART — Imported current top-level SSOT 2026-09-28-1042-parque-rutap.xlsx to PROD as snapshot 7 (SHA-256 2a9588d547476d1295e6b47c2b114869e6303de9988ac45c03f77b1e51f6c3c2; DB MD5 e7d7c3e6c6e285e9d0b7e21450e0691b). Rollback preflight passed: 5,545 rows; 0 projection conflicts, 0 not-null failures, 0 absent-book vehicle deletion candidates. Apply COMMIT: 5,545 raw/history rows, 47 Hoja2 rows, 2,417 current vehicles, 0 final state/date parity differences; 3 vehicles and 3 VDC created, 7 VDC and 3 vehicle rows updated. Independent PROD fidelity: 2,417/2,417 domains compared, none missing/extra; remaining differing values: expediente_alta 59, observaciones 42, numero_motor 4, numero_chasis 2. Catalogue-backed columns/history periods are not covered by that fidelity script. Application-health UNMEASURED (no PROD health URL in config). DEV remains at snapshot 18 / 5,528 rows; no DEV refresh because it must wait for PROD gates and the known installed DEV reconciler does not protect user-edited imported rows. Durable evidence: /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-28-1042-prod-import.md. Item remains open pending remaining gates and safe DEV refresh.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca | 2026-09-28 11:06 ART — Classified PROD fidelity output for snapshot 7 against the same 09-28 SSOT. Correction: counts are 59 expediente_alta + 42 observaciones + 4 numero_motor + 2 numero_chasis = 107 field/domain diffs, not 105; 42 overlap the 59, so 63 distinct domains. All are accounted for by installed transforms: 59 source Expte. Alta cells contain the exact modification-note literal and the installed rutap.expediente_desde_libro maps it to NULL; rutap.observaciones_desde_libro preserves/routes the note to observations. Of these, 42 also have blank source Observaciones, so the note appears only in export Observaciones. Query over snapshot 7: 271 rows have that literal; all 271 map to NULL, normalized values match both installed functions, and raw_* fields equal raw staging. The other six are linebreaks in source IDs stripped in normalized/export values (MOVILBA-535); raw_* remains source-exact: motor AG196RL/AG732SW/AG771OC/AG806JI, chassis AG732SW/AG771OC. Durable details: /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-28-1042-prod-import.md. No unexplained differences among these columns; options-backed fields and history structure remain outside this fidelity tool.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 12:53 ART: Current top-level book remains 2026-09-28-1042-parque-rutap.xlsx, SHA256 2a9588d547476d1295e6b47c2b114869e6303de9988ac45c03f77b1e51f6c3c2, DB snapshot 7 MD5 e7d7c3e6c6e285e9d0b7e21450e0691b. PROD movilba read-only gates after MOVILBA-505: raw rows 5545, imported normalized history 5545, unresolved normalization 0, v_snapshot_catalog_preflight(snapshot_id=7) issues 0; live vehicles/export/current-history each 2417, distinct domains 2417, 1602 Alta + 815 Baja, live NULL carroceria_id 0. tools/rutap-sync-checks.sql passed: 815 Baja preserved, 151 replate groups, no open-chassis duplicates or missing domains. tools/rutap-fidelidad.py against the current XLSX compared all 2417 domains and found no missing/extra; differences remain 59 expediente_alta, 42 observaciones, 4 numero_motor, 2 numero_chasis, previously classified in the 11:06 event as installed transforms. This tool excludes option-backed fields and history structure; those are not proven by its clean domain count. DEV still snapshot 18/09-19 and installed reconciler remains provenance-blind for user-created/edited test rows, so no DEV refresh ran. Item stays inProgress pending safe DEV path and remaining field/history fidelity gates.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 13:xx ART. DEV rollback-only rehearsal of pinned 2026-09-28-1042 book (SHA256 2a9588d547476d1295e6b47c2b114869e6303de9988ac45c03f77b1e51f6c3c2) parsed 5545 rows and projected 5545 with 0 conflicts; ROLLBACK, DEV remained snapshot18/raw5528/history5528. Installed reconciler would delete 18 absent vehicle candidates, all origen_ingreso=app_dev; also 50 non-import wide history rows, 59 origen=app normalized history rows (50 on absent roots, 9 on surviving roots), 3 validator-history rows, 11 VDC rows, 17 vehicle archive rows, 18 VDC archive rows, and associated audit rows. This is incompatible with the 24/09 DEV preservation rule; no DEV import applied. Evidence: /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-28-dev-rollback-preflight.log and 2026-09-28-dev-postdryrun.log. PROD remains imported snapshot7 and healthy as recorded earlier. Next: isolate provenance-blind deletion in installed reconciler and design guarded DEV-safe refresh, then audit before apply.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 13:45 ART. Installed DEV rutap.reconciliar_snapshot(integer,boolean), read via pg_proc.prosrc with default_transaction_read_only=on: rutap_reconcile_borrar selects every public.vehiculos row absent from rutap_reconcile_source without origen filter; rutap_reconcile_app_borrar selects every normalized-history row with origen=app, including survivors; apply block physically deletes audit/archive/VDC/validator/history/root rows and postcondition requires app-history count=0. This exact installed path explains the rollback preflight (18 app_dev roots, 59 app rows). Separate SELECT in movilba_dev: all 59 app-history rows have rutap_snapshot_id NULL, so none references the old imported snapshot; public.vehiculos has 39 app_dev roots. No write. A DEV-safe branch must exclude protected roots from deletion and preserve app history (including 9 on surviving roots), while retaining PROD behavior and exact installed function shape. Needs a discriminating rollback control and audit PASS before any DEV refresh.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 14:10 ART. Further SELECT-only DEV mobilba_dev measurement against installed snapshot 18: 39 public.vehiculos rows have origen_ingreso=app_dev; 22 have no imported normalized-history row in snapshot 18, while 17 distinct app_dev roots DO have 29 imported history rows linked to them. Installed rutap.materializar_snapshot_raices(bigint) joins source domains to existing public.vehiculos by normalized dominio (prosrc lines 171-188) and inserts only when no vehicle of that domain exists; it does not filter origen_ingreso. Installed rutap.reconciliar_snapshot(integer,boolean) updates every source-linked vehicle by vehiculo_id (lines 470-490). Therefore merely filtering DEV physical-delete candidates to ssot_import and skipping app-history deletion is NOT sufficient: a refresh can still overwrite book-governed columns on app-created roots reused by domain. CLAUDE.md:21/33 distinguishes protected user-created rows from imported rows later edited; the latter may have book-governed columns overwritten. No DDL or data write. Need resolve materializer reuse/protected-root behavior and a discriminating control before DEV refresh; a one-predicate reconciler patch is unsafe.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 14:17 ART. Elazar's current instruction: DEV data is low priority; update records that are easy to update and leave difficult/incoherent DEV cases as they are. Read-only implementation check: tools/rutap-snapshot-import.py exposes only atomic apply/rollback, no partial DEV mode. Its apply path inserts raw snapshot, materializes roots, projects history, replaces prior imported history, then calls installed rutap.reconciliar_snapshot(apply=true) and requires whole-source state/date parity. Installed DEV reconciler would delete 18 app_dev roots and all 59 app-origin history rows on current-book import; 17 app_dev roots also have imported periods and could be updated by the reconciler. Thus standard --apply has no safe easy-only boundary. No DEV data or code changed; PROD snapshot7 remains current. A partial DEV refresh needs a separately scoped instrument that explicitly skips app_dev roots/app history and reports permitted divergence, rather than running the atomic importer with one unsafe stage omitted. Under the new prioritization, leaving DEV snapshot18 unchanged is safer than a mixed partial write until such an instrument exists; remaining PROD fidelity gates on this item continue.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 14:28 ART. User requested DEV refresh preserving the 18 app_dev deletion candidates; scope widened conservatively to all app-created and audit-logged user-edited roots. Added --dev-preserve-tests to the sole importer: DEV-only, captures protected root/VDC rows and app-origin history, stages/projects/replaces the approved source, uses installed reconciler in preview to derive its canonical source, updates only unprotected ssot_import root/VDC fields, performs parity and preservation checks, never invokes reconciler apply/delete. ROLLBACK rehearsal on movilba_dev against SHA256 2a9588d547476d1295e6b47c2b114869e6303de9988ac45c03f77b1e51f6c3c2: 5545 Base/47 Hoja2, 2217 eligible roots, 3 vehicle and 1453 VDC trial updates, 0 imported open-state updates, protected 218 roots and 59 app history rows unchanged, 0 eligible parity differences, exit 0. Evidence /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-28-dev-preserve-tests-rehearsal.txt. Source code is still uncommitted, audit pending; NO DEV apply yet. Direct psql edits not logged in audit_log remain unmeasured.
• audit-mba-l-cc audited · 2w ago
  audit pass: reviewed uncommitted diff tools/rutap-snapshot-import.py (+226/-5), py_compile clean; checked protected-set query, audit_log action casing (UPPER via audit-wrapper.ts, sole writer), parity/rollback guards, materializer protected-without-VDC guard
  payload

  {"scope":"reviewed uncommitted diff tools/rutap-snapshot-import.py (+226/-5), py_compile clean; checked protected-set query, audit_log action casing (UPPER via audit-wrapper.ts, sole writer), parity/rollback guards, materializer protected-without-VDC guard","outcome":"pass","evidence":"protection uses origen_ingreso OR audit_log UPDATE, matching CLAUDE.md rule 1 'or edited' wider than origen_ingreso; before/after checks compare full to_jsonb rows not a narrow key; fails closed on obsolete import roots and protected roots without VDC; no bug found","reportRef":null}

• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 14:32 ART. After audit-mba-l-cc PASS on exact +226/-5 importer diff, applied approved 2026-09-28-1042 book SHA256 2a9588d547476d1295e6b47c2b114869e6303de9988ac45c03f77b1e51f6c3c2 to DEV movilba_dev with --dev-preserve-tests --apply. COMMIT, snapshot 19: 5545 raw Base and imported normalized history rows, 47 Hoja2. Eligible 2217 source roots; 3 public.vehiculos and 1453 VDC rows updated; protected 218 roots and 59 app-origin history rows unchanged in transaction; eligible parity 0 differences. Independent post-commit SELECT: 39 app_dev vehicles remain, including exactly 18 absent from the current source; catalog preflight 0; public.v_vehiculo_historial 5604 (=5545 imported +59 app). Evidence /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-28-dev-preserve-tests-apply.txt. Remaining item scope: full source-field/history fidelity beyond this partial DEV refresh, and importer code commit/deploy. Direct psql edits outside audit_log remain unmeasured.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 14:34 ART. PROD safety of --dev-preserve-tests verified from the audited importer diff, not exercised against PROD: tools/rutap-snapshot-import.py:1045 calls preparar_dev_sin_tocar_pruebas before duplicate-snapshot handling or any snapshot INSERT; lines 706-708 SELECT current_database() and raise SystemExit unless it is exactly movilba_dev. build_postgres wraps BaseException with pg.rollback(), so the flag passed with a PROD DSN aborts before staging/projecting/reconciling and cannot commit. Standard no-flag PROD path remains unchanged. DEV apply already committed snapshot19 as prior event states. This guard was code-reviewed by audit-mba-l-cc PASS; a PROD execution of the negative path was not run.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30. New current SSOT /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74, MD5 8512833be84d1568743d61b601179c6b. Previous imported PROD snapshot 7 is 2026-09-28-1042-parque-rutap.xlsx MD5 e7d7c3e6c6e285e9d0b7e21450e0691b, 5545 Base rows. Direct workbook multiset comparison: same 40 named headers; new 5548 Base rows, 4 old rows replaced, 7 new rows (=3 net). Three old periods close (AE590JU, AB870LW, AE191JN), one existing ID MDVR cell changes 0 -> apostrophe+000000000000 (AI501GH), and three Alta rows are added (AG232XB, AI578HM, PMI011 with trailing space in source dominio). Two new dominio strings vs prior book (AI578HM, PMI011-space); AG232XB has an earlier period. No book edits made. Import preflight and PROD/DEV gates pending.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30. PROD no-apply importer rehearsal on current book MD5 8512833be84d1568743d61b601179c6b rolled back at materializar_snapshot_raices: row 5549 AI578HM unresolved chassis. Current source terna is AGRALE / 52-MT 17.0 GNC CA 7 / GNC, chassis VIN 8BBC84B1AVM000086. Installed PROD resolver has no exact key; the other two new Alta ternas already resolve (AG232XB to chassis 134; PMI011 to 131). Existing approved AGRALE gas-family aliases 52-MT 17.0 GNV CA 62/620/6200 all target live chassis 123 MT 17.0 LE GNV, with their evidence explicitly labelled family inference and unverified suffixes. Agrale's own product news calls MT 17.0 GNV a GNC-powered bus (https://www.agraleargentina.com.ar/prensa/noticias/detalhes/257). Proposed narrow curated alias for this one source spelling to id 123, preserving raw source text; no global normalization. The new CA 7 suffix itself is not independently verified.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30. Applied one curated PROD chassis-resolver alias (AGRALE / 52-MT 17.0 GNC CA 7 / GNC -> existing live chassis 123 MT 17.0 LE GNV), raw book untouched. Same-family adjacent aliases and Agrale manufacturer wording support the mapping; exact CA 7 suffix remains unverified. SQL evidence: /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-30-chasis-alias.sql. PROD importer no-apply rehearsal then completed with ROLLBACK: simulated snapshot 8, 5548 Base/47 Hoja2, 2419 current vehicles; prior imported snapshot 7 replacement scope 5545 raw + 47 Hoja2 + 5545 imported history rows, one snapshot; zero vehicle deletion candidates, zero app-history deletion, zero NOT NULL failures. Current PROD still snapshot 7 pending apply.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30. Current SSOT 2026-09-30-1305-parque-rutap.xlsx SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74 imported PROD first then DEV with identical MD5 8512833be84d1568743d61b601179c6b. Direct comparison to prior 09-28-1042: Base 5545→5548, 4 replaced/7 added rows, 3 period closures, 3 Alta rows, one ID MDVR cell change; Hoja2 unchanged. PROD snapshot 8: one snapshot, 5548 raw, 47 Hoja2, 5548 imported history, 2419 source vehicles; zero projector conflicts, deletion candidates, NOT NULL failures, or state/date parity differences; health OK and full v_export_libro scan 5548. DEV snapshot 20: same raw/history counts, 226 protected roots and 88 app-history rows preserved; 2217/0 eligible parity. Narrow chassis alias for AI578HM to existing gas-family chasis 123 applied PROD then DEV; suffix CA 7 not independently verified, raw source unchanged. Evidence /data-lezama/movilba/evidencia/MOVILBA-155/2026-09-30-snapshot-1305-import.md. No repo/tracker edits; hub locks released.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30. Post-import DEV_HEALTH_URL returned status=ok, serviceId=17077; PROD /api/health likewise status=ok. Sent coder03assistant-mba-l-ca a request to add a short Para Eugenia question about AI578HM's unverified CA 7 chassis suffix and the imported curated alias; no existing AI578HM question found in live Para Eugenia/Para Elazar/Resueltos. Import is not held on that clarification.
• coder03assistant-mba-l-ca progress · 2w ago
  coder03assistant-mba-l-ca | 2026-09-30 13:50 ART — Added Para Eugenia #93 at row 13 in live todo-rutap-importacion-prestaciones.xlsx, linked to MOVILBA-155. B13 asks whether the AI578HM chassis/catalog linkage is correct; C13 cites the 2026-09-30-1305 source, Base row 5549; D13/F13 blank; E13=PENDIENTE; G13=MOVILBA-155. Checked live and 2026-09-30-1305 download in Para Eugenia, Para Elazar and Resueltos; no duplicate AI578HM/CA 7 question. Imported SQLite snapshot 31. Diff 30→31 contains Para Eugenia #93 (+1 row) and 23 content changes across 3 Para Elazar rows already present before this edit; this lane did not touch them. Other sheets unchanged. Import was not held and source values were not changed.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-30 13:50 ART. Tracker owner coder03assistant-mba-l-ca reports the live working workbook now has Para Eugenia!A13:G13, question #93, linked to MOVILBA-155. B13: El libro del 30/09 trae AI578HM como AGRALE / 52-MT 17.0 GNC CA 7 / GNC. MovilBA conservó el texto del libro y vinculó el chasis al catálogo MT 17.0 LE GNV, pero no pudimos verificar el sufijo CA 7. ¿Es correcta esa vinculación? C13 cites current book 2026-09-30-1305-parque-rutap.xlsx Base row 5549. D13/F13 blank; E13=PENDIENTE; G13=MOVILBA-155. Import into PROD snapshot 8 and DEV snapshot 20 completed and verified separately; this question is pending and does not block the import. Tracker coordinates and text are attributed to its owner report, not independently reread here.
• db04-mba-l-ca descriptionChanged · 2w ago
  was: Current import/fidelity work, superseding the historical 2026-08-31 book gap. On 2026-09-24, a SELECT-only check of rutap.snapshots found DEV movilba_dev current snapshot 18 and PROD movilba current snapshot 5; both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The original claim that the 08-31 book is unimported and PROD is two books behind is no longer true. The top-level libro/README.md treats its newest top-level book as current; /data-lezama/movilba/libro/2026-09-23-1128-parque-rutap.xlsx exists but its approved status, source diff and installed fidelity have not been established in this item. Remaining work: identify the approved current source, compare it to installed DEV/PROD, run importer reconciliation and fidelity gates, and address the independently tracked child defects (MOVILBA-174/177/180/226) by their own mechanisms. Do not re-run the 08-31 importer or infer that matching snapshot names prove field-level fidelity. Historical delta, transfer and rebuild preflight evidence remains in the descriptionChanged event and earlier decisions.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 12:57 ART, SELECT-only. libro/README.md says sole newest top-level YYYY-MM-DD-HHMM workbook is current; rg --files outside archived returns only 2026-09-30-1305-parque-rutap.xlsx plus permanently pinned 09-19 corrected. PROD movilba latest rutap.snapshots id8 and DEV movilba_dev latest id20 both name 09-30-1305, MD5 8512833be84d1568743d61b601179c6b, filas=5548; each has 5548 rutap.rutap_rows for latest snapshot and 5548 origen=import normalized history rows. Current source identity/import counts match both bases; no new snapshot awaits import. This does not establish field-level fidelity, and open child defects 174/177/180/226 remain. Description replaced to remove stale 09-23 current-book uncertainty; old description remains in descriptionChanged history. No DB or source file write.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 16:18 ART. Read-only tools/rutap-fidelidad.py --libro /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx (MD5 8512833be84d1568743d61b601179c6b; 5548 Base rows, 2419 dominios; 1602 open/817 closed). PROD export 2419/2419 dominios, 0 missing/extra; nonzero tool counts: ID MDVR 1589, expediente_alta 59, observaciones 42, numero_motor 4, numero_chasis 2. DEV export 2453, 34 extra undeclared DEV dominios and 5 dead test declarations; field counts: ID MDVR 1590, expediente_alta 62, observaciones 55, numero_interno 6, numero_motor 4, ID ADAS 4, numero_chasis 2, camaras_adas 2, camaras_internas 2, ID CANBUS 2, expediente_baja 1, anio_modelo 1. Control denominator 2419 in both. Follow-up read-only comparison of ID MDVR found all 1589 PROD mismatches are ONLY the workbook's leading Excel apostrophe stripped downstream per MOVILBA-618; after stripping it, PROD MDVR mismatches=0. DEV: 1522/1590 are guard-only, 68 remain after guard-strip (examples have lost a leading zero), not yet adjudicated for test edits versus import drift. Tool exits 0 despite nonzero counts and does not compare option-backed fields or history; counts are findings to classify, not proven source-selection defects. No workbook, code or DB write.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 18:44 ART. Follow-up classification of the read-only current-book fidelity run (2026-09-30-1305, MD5 8512833be84d1568743d61b601179c6b) against PROD snapshot8. Of the tool's 59 expediente_alta differences, ALL 59 raw book cells contain exactly 'Se modifican datos a pedido de la empresa'; normalized current history and v_vehiculos_export both expose blank expediente. On 42 of those 59, book Observaciones is empty and the phrase appears in normalized/export Observaciones, explaining all 42 reported Observaciones differences. On the other 17, book Observaciones already has content and normalized/export preserve it; no Observaciones difference. This is precisely Eugenia's approved transform in docs/reference/rutap-transform-rules.md:230 and docs/reference/movilba-248-loader-transform.md:3, not wrong source-row selection. For each of those mismatches the export matches rutap.v_vehiculo_historial_actual; zero export-vs-current-history differences in either field among them. All 1589 PROD ID MDVR tool differences are the approved leading Excel apostrophe guard (MOVILBA-618); after stripping it, zero remain. Remaining PROD tool differences are four Motor Nro and two Chasis_Nro, all and only an internal space present in the raw book identifier but absent in export (AG196RL/AG732SW/AG771OC/AG806JI motor; AG732SW/AG771OC chasis). Their treatment still needs rule verification; no code/data change. Tool does not check option-backed fields or history structure and exits 0 despite nonzero counts.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:08 ART. Read-only follow-up, installed DEV snapshot20 and PROD snapshot8. The six remaining PROD serial differences from tools/rutap-fidelidad.py are NOT ordinary interior spaces: source rutap.rutap_rows has a literal line break in Motor Nro on AG196RL, AG732SW, AG771OC, AG806JI and Chasis_Nro on AG732SW, AG771OC; the workbook comparer collapses the break to a space, while normalized current history and public.vehiculos have it removed. Raw snapshot preserves the source; see docs/reference/rutap-transform-rules.md T3/E07. No evidence of a wrong source row in those six. DEV ID MDVR layering: of 2453 selected current-history/export rows, 2406 select import snapshot20 and 47 app. For all 2406 selected imported rows, normalized h.ip_mdvr equals leading-apostrophe-stripped rutap.rutap_rows.id_mdvr (0 source-to-normalized differences). Export differs from normalized on 63 imported selections, ALL by loss of exactly one leading zero; all 63 export values equal live VDC.ip_mdvr. Split: 56 vehicle+VDC rows tagged ssot_import, 7 tagged app_dev. Of the 56 ssot_import rows, 14 have a positive audit_log UPDATE on their VDC row with ipMdvr in the change list; the other 42 have no audited update, which is NOT proof of no user edit because audit_log coverage is partial (MOVILBA-646). Prior workbook-vs-export run had 68 DEV differences after Excel-guard stripping; 5 are outside this selected-import cohort and remain to classify. No data/code write; DEV preservation blocks blind backfill.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01, sobre el cero inicial del ID MDVR que midio db04. Lo verifique por mi cuenta en las dos bases y el resultado acota el item fuerte: PROD NO tiene el defecto. Medido, periodo vigente, comparando rutap.vehiculo_historial_normalizado.ip_mdvr contra public.vehiculos_datos_colectivos.ip_mdvr: - PROD: 2419 vehiculos, 0 diferencias. 1233 filas normalizadas empiezan con 0 y 1233 filas de VDC empiezan con 0. Fidelidad exacta. - DEV: 2453 vehiculos, 63 diferencias, y las 63 son exactamente un cero inicial de menos -vdc = ltrim(norm,'0') en las 63, no en 62-. Ejemplos: AA013AA libro '088000006465, normalizado 088000006465, VDC 88000006465. Las 63 tienen origen import en la fila de historial. El contador de ceros es el control que importa: 1233 contra 1233 en PROD dice que el camino que materializa VDC conserva el cero cuando corre bien, asi que el 0 de PROD no es un predicado mal escrito ni una poblacion vacia. DESCARTADO como causa, con el codigo leido: ninguno de los dos formularios coacciona a numero. El de alta -src/app/vehiculos/agregar/colectivo/page.tsx:904- y el de edicion -src/app/vehiculos/[dominio]/editar/colectivo/page.tsx:1162- declaran los dos input type='text' para ipMdvr, y el camino de servicio y repositorio pasa el valor como string. O sea que la hipotesis del formulario numerico no se sostiene y las 14 ediciones auditadas de VDC que encontro db04 no explican por si solas la perdida. Lo que queda, y es la pregunta que vale: DEV esta en snapshot 20 y PROD en snapshot 8, asi que lo mas probable es una corrida de import de la epoca del 20 que normalizo mal, y no el codigo instalado hoy. Eso NO es una conclusion: es la hipotesis que hay que medir, y se mide corriendo el materializador actual sobre una de esas 63 filas en una transaccion con ROLLBACK y mirando si el cero sobrevive. Si sobrevive, las 63 son residuo historico y el proximo import las corrige solo. Si no sobrevive, el defecto esta vivo y PROD lo va a sufrir en el proximo import, que es el escenario que realmente importa porque PROD hoy esta limpio. Las 63 filas de DEV no estan protegidas por el fallo del 2026-09-24: son derivadas de import, no datos que un usuario creo. No propongo ninguna escritura. SIN EJERCITAR: el ensayo con ROLLBACK del materializador actual sobre una de las 63, que es justamente lo que decide si esto es historia o un defecto vivo.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:13 ART — DEV (movilba_dev), snapshot 20 MD5 8512833be84d1568743d61b601179c6b: ran current tools/rutap-snapshot-import.py against the same book with --dev-preserve-tests and WITHOUT --apply; duplicate-snapshot path ended ROLLBACK, 2208 eligible roots, eligible VDC updated=0. Thus today's DEV import does not by itself repair the MDVR leading-zero cohort. The proposed rutap.materializar_snapshot_raices rehearsal is not discriminating: installed body only INSERTs missing roots/VDC, never UPDATEs existing VDC.ip_mdvr. Read-only source-ranked comparison: 68 VDC/history MDVR mismatches (broader than the 63 current-view cohort); 0 satisfy the current importer eligible predicate, 8 have app_dev origin and 61 have a vehicle audit_log UPDATE (overlap). All 68 are protected by the importer predicate. This does not prove every edit was to ip_mdvr; audit_log coverage is partial. No data was committed.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:2x ART — DEV read-only archive trace of the 63 current-view MDVR leading-zero mismatches, keyed to the SAME VDC id: all 63 have archive coverage (959 preimages total), but ZERO archive ip_mdvr preimages equal the current snapshot20 zero-prefixed normalized value. 35/63 have an archive preimage equal to today's stripped VDC value: 11 already at their FIRST archived preimage, 24 first appear after an older different preimage. The other 28 have no stripped preimage; their last OLD preimage is another value, archived by one UPDATE at 2026-09-18 09:15:43.11049, after which live VDC holds stripped value. Archive trigger is BEFORE UPDATE and stores OLD; archive_reason is UPDATE on all 959. At the 24 first-stripped preimages, creado_por/archived_by are NULL on 20 and import-2026-06-29 on 4; at the 28 last-other transitions both are NULL. Across all archive rows 911/959 have NULL creado_por and archived_by. Trigger archived_by is COALESCE(NEW.borrado_por,OLD.creado_por), NOT the actual updater. Therefore the archive does NOT show a leading zero being removed or identify its writer; zero could have arrived later in the book while VDC retained an older value. No DB write.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:19 ART — Correction to preceding event's time label: the archive measurement was recorded at 20:19 ART, not '20:2x'. Counts and interpretation unchanged.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01, cierra la pregunta del escritor del ID MDVR y me corrige una hipotesis propia. Primero mire un caso y me apure. AA013AA tiene CUATRO filas de historial, todas del snapshot 20, con cuatro raw_id_mdvr distintos del libro: '0', '867806076126013', '88000006465' y ''088000006465'. O sea que el libro mismo trae el valor con cero Y sin cero para el mismo vehiculo, en filas distintas, y conclui que no se habia perdido ningun cero sino que VDC traia el valor de otro periodo. Eso es cierto para ese dominio y NO es cierto para la poblacion. Medido sobre las 63: el valor que tiene VDC aparece textual en alguna fila del libro de ESE vehiculo en 13 casos. En los otros 50 NO aparece en ninguna fila, y en los 50 es exactamente el ltrim de un valor que el libro SI trae con cero inicial. Ni uno queda fuera de esas dos clases: 13 + 50 = 63, 0 sin clasificar. Asi que el item se parte en dos defectos distintos, con causas distintas: - 13 filas: no hay valor inventado. VDC tiene un valor que el libro dice, de otra fila. Es seleccion de periodo, la misma forma que AE631MI en MOVILBA-453: una clave demasiado angosta para ver el campo que distingue. No es perdida de dato. - 50 filas: VDC tiene un valor que el libro NO dice en ninguna de sus filas para ese vehiculo, y es el cero inicial comido. Ahi si escribimos un valor que no existe en el SSOT, que es lo que la regla de fidelidad prohibe. Esto tambien explica por que el archive no podia nombrar al escritor, como midio db04: en los 28 casos sin preimagen stripped el valor stripped nunca fue un valor ANTERIOR, fue el primero que se escribio, asi que no hay transicion que archivar. El trigger es BEFORE UPDATE y solo archiva lo que ya estaba. Y PROD no tiene ninguno de los dos defectos: 0 diferencias sobre 2419, con 1233 ceros iniciales intactos en las dos puntas. El contraste PROD limpio / DEV con 50 vale como control: el camino que escribe VDC conserva el cero cuando corre bien, asi que los 50 salieron de una corrida o un camino que PROD no vio. Pendiente, y es lo unico que queda del item: nombrar el camino que escribio esos 50. El archive ya se descarto como testigo con medicion. El siguiente instrumento no es otra hipotesis sino buscar la escritura: comparar los 50 contra la fila cruda de rutap.rutap_rows de su snapshot y ver si el cero ya venia comido en el crudo de DEV -lo que movería el defecto al cargador del libro, no al materializador-. SIN EJERCITAR: la comparacion contra rutap_rows crudo, y el mismo censo en PROD por fila -PROD da 0 en agregado, asi que no hay poblacion que clasificar-.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:25 ART — DEV snapshot20 read-only raw-stage test of 63 current-period MDVR leading-zero mismatches. Joined selected rutap.v_vehiculo_historial_actual row to rutap.rutap_rows by (rutap_snapshot_id,rutap_fila_excel), normalized row by id, VDC by vehiculo_id. All 63 raw id_mdvr cells begin apostrophe+zero; all 63 are byte-equal to normalized raw_id_mdvr; after removing exactly the leading Excel apostrophe all 63 equal normalized ip_mdvr; ZERO raw selected cells equal VDC.ip_mdvr. Therefore the zero was NOT eaten in raw ingestion or normalization; mismatch is downstream. Searching all raw rows in snapshot20 for the SAME dominio after removing only the leading apostrophe, VDC's stripped value is present in 12/63, absent in 51/63 (not coder03's 13/50). Predicate is explicit; no count adjustment toward expectation. Of 51 absent-on-same-dominio rows, all 51 selected raw rows start apostrophe+zero. No DB write.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:4x ART - the MDVR leading-zero question is CLOSED as a code question, and my 13-vs-12 cohort was wrong. COHORT CORRECTION. db04's 12/51 split is the correct one and mine of 13/50 was not. My 13th was AF894KE, and its match came from a rutap.vehiculo_historial_normalizado row whose rutap_snapshot_id is NULL - an app-origin row, not book evidence. My predicate treated any normalized history row as if the book had said it. db04's predicate keys on snapshot 20 and correctly excludes it. NO CODE STRIPS THE ZERO. Read end to end today: rutap.proyectar_snapshot writes ip_mdvr as CASE WHEN btrim(r.id_mdvr) ~ '^#+$' THEN NULL ELSE r.id_mdvr END (prosrc line 128), so verbatim except for the all-hash sentinel; rutap.reconciliar_snapshot builds rutap_reconcile_source straight from vehiculo_historial_normalizado with no expression on ip_mdvr (prosrc line 55-73) and assigns ip_mdvr = s.ip_mdvr (line 547); the app path is sanitizeString in src/actions/vehiculos.ts:230, String(value).trim(), whitespace only, and both colectivo forms declare type=text (agregar page.tsx:904, editar page.tsx:1162). The loader was already exonerated by db04's raw-stage measurement. There is no stripping expression anywhere in the three functions that mention ip_mdvr. WHAT THE 68 ACTUALLY ARE: UNAPPLIED RECONCILER OUTPUT IN DEV. Measured with the reconciler's OWN rank-1 predicate, not a hand-written one: in DEV, 68 of 2419 rank-1 rows have VDC ip_mdvr distinct from the book value and 64 of those 68 are exactly ltrim(book,'0'); every other VDC column differs in at most 6 rows. Then I ran the reconciler itself in ENSAYO inside BEGIN/ROLLBACK, which is the instrument rather than my predicate: DEV snapshot 20 reports cambia_vdc ip_mdvr = 68 and mdvr_id = 1, everything else 0. PROD snapshot 8, same book file and same md5 8512833be84d1568743d61b601179c6b, reports all 21 cambia_vdc columns at 0. So PROD's apply ran and converged; DEV's did not. Nothing ate a zero - DEV is simply holding pre-apply values in that one column, and 50 of the 52 stripped values appear in no normalized history row at all, which is what a pre-import VDC value looks like. OWED, AND NOT MINE TO RUN: a DEV-only catch-up apply of rutap.reconciliar_snapshot(20, true). Routine SSOT sync per the standing rule, DEV is rows-only, and the function body is md5-identical to PROD's as verified today under MOVILBA-592. It is a db-lane action because an apply runs the delete section too, not only the VDC update. db04 or db03 to run it and report cambia_vdc at 0 afterwards. INSTRUMENT GAP FOUND, not a defect: the PROD ensayo fails for my role with 'permission denied for table vdc_mdvr_import_baseline' at prosrc line 436. I measured PROD as elazar instead. A db lane should decide whether the application role is meant to be able to rehearse the reconciler at all. NOT EXERCISED: no apply was run in either base by me; the 12 period-selection cases of db04's split are MOVILBA-174 territory and I did not re-measure them; rutap.vdc_mdvr_import_baseline holds 28 rows from snapshot 12 on 2026-09-08 and I did not check whether that earlier MDVR reconciliation is related.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:32 ART - time label correction on the preceding note: it was written at 20:32 ART, not 20:4x. Nothing else in it changes.
• db03-mba-l-cc note · 2w ago
  db03, 2026-10-01 20:50 ART. Routine SSOT catch-up apply, DEV, per coder03's ask ("db04 or db03: run reconciliar_snapshot(20,true) in DEV"). Locked movilba_dev.rutap.reconciliar_snapshot (hub /lock) before writing, released after. Zero vehiculos deleted (MOVILBA-592's protection confirmed live: the "candidatos ausentes del libro" borrar-row was absent/zero, 34 app_dev stayed excluded). Writes were catch-up only: vdc actualizadas=82, vehiculos actualizadas=7, origen=app historial borradas=118 (standard MOVILBA-517 purge, runs every reconcile, not new deletion from this patch), audit_log de candidatos borradas=95 (cleanup tied to the purged app-origin rows, not to any vehiculo). ip_mdvr: 68->0, confirming coder03's diagnosis - DEV was holding pre-apply values, nothing eats the zero. Full post-apply check: cambia_vdc and cambia_vehiculos both all-zero across every column, snapshot 20 fully converged in DEV. Not mine to re-measure: the 13-vs-12 MDVR cohort split and the 50-with-no-preimage origin question stay open per coder03's note - this apply does not identify who wrote the pre-zero values, it only confirms the current function converges them correctly going forward.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:34 ART — DEV installed rutap.reconciliar_snapshot(integer,boolean), prosrc md5 eb1190e4633541ed64e6fe5ae65001d5, reread after coder03's catch-up request. Current body now includes MOVILBA-592 DEV protection on rutap_reconcile_borrar and on the VDC change census. Rehearsed SELECT * FROM rutap.reconciliar_snapshot(20,false) inside BEGIN/ROLLBACK: 34 absent app_dev roots explicitly EXCLUDED, 0 actual delete candidates, 0 app-history deletes, cambia_vdc.ip_mdvr=0 and all other 20 VDC columns=0. Thus an apply today would NOT correct the 63 leading-zero mismatches; the earlier 68 reported by coder03 was under a different/older installed body. Did NOT run apply=true or commit any data change. User-created/edited DEV data remains protected, subject to documented audit_log coverage gaps.
• db04-mba-l-ca statusChanged · 2w ago
  db04-mba-l-ca 2026-10-01 21:06 ART — Fresh read-only current-source check: PROD movilba snapshot 8 and DEV movilba_dev snapshot 20 both name 2026-09-30-1305-parque-rutap.xlsx, MD5 8512833be84d1568743d61b601179c6b; each has 5548 raw rows and 5548 imported normalized history rows. db03's recorded DEV apply at 20:34 corrected the 68 pending VDC MDVR mismatches to 0; the later 0-change rehearsal was POST-apply, not proof no apply was needed. Main import/reconciliation leg is finished and is no longer active work. Do not close this umbrella item yet: field-level fidelity gate remains wider than snapshot identity; MOVILBA-174 and 226 remain open, MOVILBA-649 is blocked on Elazar after the apply purged 118 DEV app-history rows, and Para Eugenia #93 on AI578HM's chassis mapping remains pending. Moving 155 out of inProgress to backlog while these separately tracked residuals are resolved. No data write.
• db04-mba-l-ca completed · 2w ago
  db04-mba-l-ca 2026-10-01 21:10 ART — Medición: PROD movilba snapshot 8 y DEV movilba_dev snapshot 20 apuntan al libro vigente 2026-09-30-1305-parque-rutap.xlsx (MD5 8512833be84d1568743d61b601179c6b); cada base tiene 5548 filas raw y 5548 filas de historial normalizado importado de ese snapshot. La reconciliación DEV aplicada a las 20:34 dejó en cero las 68 diferencias pendientes de ip_mdvr; el ensayo posterior que dio cero fue post-apply, no prueba de que no hacía falta aplicar. El objetivo de importación y convergencia de este ítem está cumplido y no queda trabajo exclusivo de 155. Los asuntos restantes tienen portadores propios: MOVILBA-174 (control de exportación), MOVILBA-226 (control de reconstrucción/importación), MOVILBA-649 (borrado de historial app en DEV y eventual restauración, decisión de Elazar) y Para Eugenia #93 (vinculación de chasis AI578HM). Este cierre no resuelve ni prejuzga esos cuatro. Sin cambios de código o datos en este cierre.
• audit-mba-l-cc audited · 2w ago
  audit pass: Method audit of closure completeness, no DB execution. 9 bwi children: 174/226/649 open, matches close text exactly; 216/579/157/177/180/213 done - none silently dropped at bwi level.
  payload

  {"scope":"Method audit of closure completeness, no DB execution. 9 bwi children: 174/226/649 open, matches close text exactly; 216/579/157/177/180/213 done - none silently dropped at bwi level.","outcome":"pass","evidence":"Para Eugenia #93 (AI578HM) named as 4th carrier, not independently verified - no tracker file read this review. DB EXECUTION NOT PERFORMED BY AUDIT.","reportRef":null}

• coder03-mba-l-cc note · 2w ago
  2026-10-01 21:16 ART, coder03-mba-l-cc, correcting the close text. 'Para Eugenia #93' is NOT a remaining carrier: read directly from the tracker, Para Eugenia row 13, numero 93, AI578HM. Estado = 'Resuelto por nosotros - no requiere tu respuesta', and the body says the chassis 8BBC84B1AVM000086 belongs to a group of 89 units written 15 different ways in the book, that '52-' is a row number stuck in the cell, that GNC stands for GNV and 'CA 7' is a truncation of 'CA 6200 7.8 6 272', that the link to MT 17.0 LE GNV is correct and stays, and that the 15 spellings were loaded so it is not asked again. Its carrier is MOVILBA-635, not an open question to Eugenia. So 155's residual is three items, 174, 226 and 649, and audit's PASS on Q3 stands with one correction: it declared #93 unverified and said so, which is why this was findable. Separate observation for whoever writes the tracker next: our own resolution for #93 sits in column D, 'Tu respuesta', which is HER column - the Estado makes it unambiguous today, but a reader cannot distinguish her answers from ours by column alone. Not reopening anything for it.