DEV y PROD tienen que ser un reflejo fiel del libro RUTAP vigente
Elazar, 2026-09-02: DEV y PROD tienen que ser un reflejo fiel del libro RUTAP vigente antes del go-live (2026-09-07). Este epic ordena el trabajo y define el gate. MEDICION BASE, 2026-09-02, libro 2026-09-01-1440-parque-rutap.xlsx (md5 95f878f0), hoja Base, comparando la fila ABIERTA de cada dominio contra v_vehiculos_export. Libro: 2398 dominios, 1600 vigentes. PROD - 2388 dominios, 10 del libro ausentes, 0 de mas, 1 vigente que no figura en Alta. Dominios vigentes que difieren, por campo: expediente_alta 223, observaciones 203, numero_linea 170, camaras_adas 160, camaras_internas 24, id_mdvr 22, id_adas 7, numero_chasis 4, numero_motor 4, cantidad_asientos 3, expediente_baja 1, id_canbus 1. DEV - 2394 dominios, 8 ausentes, 4 de mas (datos de prueba), 0 con estado mal. id_canbus 1445, id_adas 513, expediente_alta 225, observaciones 202, numero_linea 172, camaras_adas 161, id_mdvr 51, camaras_internas 25, numero_chasis 4, numero_motor 4, cantidad_asientos 4, numero_interno 2. GATE DE CIERRE: se vuelve a correr esta misma medicion y toda columna da 0, salvo los dominios de prueba de DEV que esten declarados y protegidos. Un cero no vale sin el control positivo de cuantos dominios se compararon. Escritura pre-autorizada: sincronizar DEV y PROD al libro es rutina hasta el go-live y no pide GO por fila (Elazar 2026-09-02). Sigue pidiendo GO lo destructivo o no validado.
Sub-tickets — 9/9 done
Activity
-
Auditado por audit-mba-l-cc el 2026-09-02, contra PROD y con sondas propias, read-only. CONFIRMADO: (1) el plegado no genera ni tapa diferencias - fold() solo toca blanco y NBSP, y el float->int solo dispara cuando el float ES entero; (2) ninguna de las 14 columnas mapeadas pasa por un join a opciones, verificado contra el viewdef de v_vehiculos_export una por una, asi que no hay trampa de id-contra-etiqueta; (5) control positivo sobre anio_modelo - su cero esta ganado, los dos lados traen valores reales que coinciden, no es NULL==NULL ni una columna mal indexada. CONFIRMADA LA TESIS DE MOVILBA-190, con datos que yo no habia sacado: expediente_alta 223, observaciones 203 y numero_linea 170 colapsan a 228 dominios distintos. 169 de los 170 de numero_linea estan DENTRO del conjunto de expediente_alta, 199 de los 223 de expediente_alta tambien fallan observaciones, y la triple interseccion es 145. Es el mismo conjunto de dominios golpeado en varios campos, o sea un defecto de seleccion de fila y no doce defectos. Se arregla 190 primero y se vuelve a medir antes de decidir si id_mdvr 22, numero_chasis 4 y el resto son residuo del mismo bug o son propios - eso NO se chequeo. HALLAZGO: la medicion cubre el 67% del libro, no el 100%. 798 de 2398 dominios no tienen fila abierta y el script les compara cero campos. Abierto como MOVILBA-196. NO EJERCITADO por audit, dicho por el explicitamente en vez de darlo por bueno: los asuntos 4, 5, 6, 7, 10 y 11 del reporte de Eugenia. Al citar cualquier cero de esta medicion hay que decir sobre que 67% se calculo, hasta que cierre 196.
-
Implementation started 2026-09-02: catalog-aware projection and parity gates, then normal-import reconciliation DEV -> audit -> PROD. No delete/soft-delete; source snapshot is authoritative.
-
DB audit adds non-resurrection invariant: matching for historial insertion sees all rows; soft-delete filtering only chooses update target. Validate 5319 SSOT data rows / 1600 open rows and exact per-domain parity after projection.
-
Reconciliation prerequisite: fail-closed chassis gate correctly stops AG045KB and AE100DI. Both DEV/PROD match: AE100DI SSOT chassis 8AB368187LA149594 is unused; AG045KB SSOT chassis 8AB368187PA151842 is only on two soft-deleted older AG045KB records (ids 5203/5204), current active is B368187PA1518. No expected-count bypass. Resolve through normalized identity import/update before executing sync.
-
Resolved chassis prerequisite from SSOT in both DEV and PROD: AE100DI 8AB368187LA148664→8AB368187LA149594; AG045KB B368187PA1518→8AB368187PA151842. Guarded transaction updated exactly 2 active rows per DB; vehicle archive trigger retained prior values. Fail-closed reconciliation gate can now evaluate the remaining importer prerequisites.
-
Applied line-26 SSOT cesion in both DEV and PROD: retired assignment 72 (line 26 -> 17 de Agosto), inserted assignment 109 (line 26 -> Nuevos Rumbos, Resol-2026-186-GCABA-SECT), and changed exactly 57 current vehiculo_historial entity IDs in the same guarded transaction. v_vehiculos_export now shows all 57 line-26 vehicles as Nuevos Rumbos; entidad_distinta remains 0. Existing unrelated audit rows retained.
-
db03-mba-l-cc
-
db02-mba-l-cc
-
ESTADO DEL GATE, RE-MEDIDO - db02-mba-l-cc, 2026-09-12, SOLO LECTURA. Mido solo la parte de PRESENCIA DE DOMINIOS; no re-medi la tabla de diferencias por campo de la descripcion. Referencia: la punta IMPORTADA de cada entorno. DEV snapshot 12 (2026-09-07-2350), PROD snapshot 11 (2026-09-05-0649). Los dos libros tienen los mismos 2407 dominios y las mismas filas por dominio+fecha_alta+fecha_baja, asi que para esta pregunta el desfasaje entre entornos no cambia nada. El libro 2026-09-10-1150 existe en disco y no esta importado en ningun lado: toda cifra de abajo es contra el libro IMPORTADO. - PROD: 2407 del libro, 2407 vivos, faltan 0, sobran 0. - DEV: 2407 del libro, 2425 vivos, faltan 0, sobran 18. La mitad de 'faltan' del gate da CERO en los dos entornos. Detalle y cierre propuesto en MOVILBA-192. LA MITAD DE 'SOBRAN' NO DA CERO EN DEV Y EL MECANISMO QUE LA CONTIENE ENVEJECIO. MOVILBA-193 declaro 4 dominios de prueba en tools/rutap-dominios-prueba.json. Hoy: 3 de esos 4 estan borrados (entradas muertas) y hay 17 dominios de mas sin declarar, todos dados de alta por pantalla entre el 09-08 y el 09-11. Ademas la entrada declarada de DHU474 apunta al vehiculo_id 6621, borrado el 09-08; el DHU474 vivo es el 6737, creado el 09-11. El gate excluye por NOMBRE DE DOMINIO, asi que hoy esta tapando una fila que nadie declaro y cuya evidencia declarada ya no existe. CONSECUENCIA PARA EL GATE, que es lo unico que este epic tiene que decidir: 'cero dominios de mas en DEV salvo los declarados' no se puede cumplir mientras la declaracion se verifique por dominio y la poblacion de prueba crezca por pantalla sin declararse. La exclusion tiene que anclar a la FILA (vehiculo_id o huella), no al dominio, o el gate da verde tapando altas que nadie miro. Es un cambio en tools/, o sea trabajo de un carril de codigo, no una escritura de base. Nada ejecutado.
-
PROPUESTA DE CORTE - db02-mba-l-cc, 2026-09-12. Completa la medicion que puse en este mismo item hace un rato. El epic pide un gate; hoy el gate tiene una mitad cumplida, una mitad rota por su propio mecanismo de exclusion, y una tercera parte sin medir. ESTADO POR MITAD: a. PRESENCIA DE DOMINIOS: cumplida. PROD 2407 de 2407, cero faltantes cero de mas. DEV cero faltantes, 18 de mas. b. DOMINIOS DE MAS EN DEV: no se puede cumplir con el mecanismo actual. La declaracion de dominios de prueba excluye por NOMBRE DE DOMINIO y envejecio: 3 de los 4 declarados estan borrados, hay 17 altas de pantalla sin declarar, y la entrada de DHU474 nombra una fila que ya no existe mientras tapa otra que nadie miro. c. DIFERENCIAS POR CAMPO (expediente_alta 223, observaciones 203, numero_linea 170, camaras, ids, etc): NO RE-MEDIDAS en esta pasada. Son del 2026-09-02 contra el libro 2026-09-01-1440, que ya no es el vigente. Ninguna de esas cifras se puede citar hoy. PROPUESTA, y es partir, no cerrar: 1. CERRAR MOVILBA-192 (dominios ausentes): sin objeto, cero en los dos entornos. 2. ITEM NUEVO, y es el que desbloquea el gate: la exclusion de datos de prueba de DEV ancla a la FILA, no al dominio, y se decide que pasa con 17 altas de pantalla sin declarar y 3 entradas muertas. Es trabajo de tools/ mas una decision de Elazar sobre datos de DEV. 3. ITEM NUEVO o re-apertura de 194: re-correr el medidor de fidelidad campo por campo contra el libro importado de CADA entorno, nombrandolo en la salida. Hasta que eso corra, el epic no tiene numero vigente para su mitad mas grande. 4. EL EPIC SIGUE ABIERTO hasta que 2 y 3 den resultado. Cerrarlo con la mitad (a) cumplida seria declarar fidelidad midiendo presencia de dominios, que es la parte barata. Y una condicion que no estaba escrita y hoy se ve necesaria: el gate tiene que IMPRIMIR contra que libro corrio -archivo y snapshot- en cada corrida y en cada entorno. Hoy DEV y PROD estan en libros distintos (12 y 11) y una cifra sin ese encabezado no se puede comparar con la de la semana pasada ni con la del otro entorno.
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:03 -03 — SELECT-only current-state check: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The full field-by-field PROD/DEV fidelity gate was not run. Status unchanged; no DB write.
-
coder03-mba-l-cc 2026-09-24 04:07 - measurement handed over from audit-mba-l-ca, which reran tracked tools/rutap-fidelidad.py against the pinned workbook 2026-09-23-1128-parque-rutap.xlsx on both bases on 2026-09-24. 2413 dominios compared in each (1599 open, 814 closed). Differences by column: expediente_alta 66 in PROD, 68 in DEV. DEV additionally reports 18 undeclared extra dominios and 5 dead declarations; PROD does not. Independently reproduced - coder03assistant-mba-l-ca and audit-mba-l-ca ran the tool separately and got the same numbers, so this is the instrument agreeing with itself across two operators, not one run. Fidelity is NOT green in either base and the DEV excess is the larger gap. Caveat that bounds all of it: the tool exits 0 regardless of differences, so no run of it has ever failed - filed as MOVILBA-570. NOT EXERCISED: nothing here says whether the 18 DEV extras are disposable test data, which DEV is allowed to carry, or real drift.
-
db04-mba-l-ca 2026-10-01 21:57 ART — Gate SELECT-only tools/rutap-fidelidad.py contra /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx, MD5 8512833be84d1568743d61b601179c6b, 5548 filas/2419 dominios (1602 con período abierto, 817 sólo cerrados). PROD: export 2419, faltantes 0, extras 0; 2419 dominios comparados; diferencias informadas: id_mdvr 1589, expediente_alta 59, observaciones 42, numero_motor 4, numero_chasis 2. DEV: export 2453, faltantes 0, extras 34 sin declarar, cinco declaraciones de prueba muertas; los mismos cinco conteos de diferencias sobre los 2419 dominios del libro. IMPORTANTE: detalle positivo AE971FE y 59 ejemplos muestran que el medidor compara apóstrofo inicial del libro en ID MDVR contra valor normalizado sin apóstrofo, aunque MOVILBA-618 estableció que es guarda de transporte; por eso 1589 NO pueden llamarse diferencias de negocio sin corregir el instrumento. El script tampoco compara opciones ni estructura de historial, y sale 0 pese a diferencias (MOVILBA-570). Esta corrida no satisface el gate de cierre del epic. Próximo paso: medir el residuo de id_mdvr después de quitar sólo esa guarda en la comparación, clasificar 59/42/4/2 y las 34 extras DEV según la regla de datos de prueba. Sin escritura de DB/código.
-
db04-mba-l-ca 2026-10-01 22:05 ART — Clasificación read-only de los 34 dominios extra de DEV frente a rutap.rutap_rows snapshot20 (control: v_vehiculos_export 2453 = 2419 del libro + 34 extras). Los 34 public.vehiculos activos tienen origen_ingreso='app_dev': la etiqueta de INSERT sí explica que estos 34 fueron creados por la app en DEV y la regla 1 los protege, de modo que NO se los llama drift ni se borran para forzar 2419. Audit_log sobre vehiculos, con upper(action) para no perder 'create' minúscula: 27/34 tienen CREATE, 17/34 tienen UPDATE; los siete sin CREATE son ZX000ZX..ZX006ZX y sí tienen creado_por y app_dev. La etiqueta no registra ediciones posteriores ni prueba si un vehículo originalmente importado fue luego editado; los UPDATE de audit_log son cobertura parcial del camino app y no demuestran qué columna cambió, y escrituras psql directas quedan fuera. Por ello esta clasificación sólo justifica preservar estos 34 por creación; no certifica que todos los 2419 importados de DEV estén libres de edición de usuario. Sin DB write.
-
db04-mba-l-ca 2026-10-01 22:10 ART — Clasificación completa del reporte de tools/rutap-fidelidad.py sobre libro 30/09 MD5 8512833be84d1568743d61b601179c6b, control 2419/2419 dominios en PROD y DEV. En ambas bases: 1589/1589 id_mdvr son exactamente el apóstrofo inicial de guarda de Excel retirado por MOVILBA-618; 0 residuales al comparar el valor de negocio quitando sólo ese primer carácter. 59/59 expediente_alta son la frase literal 'Se modifican datos a pedido de la empresa' del libro guardada como NULL, y 42/42 observaciones son esa frase trasladada desde Expte. Alta a Observaciones vacías: comportamiento intencional de MOVILBA-248, docs/reference/rutap-transform-rules.md § Prosa. Las 4 diferencias numero_motor (AG196RL, AG732SW, AG771OC, AG806JI) y 2 numero_chasis (AG732SW, AG771OC) son todas espacios interiores que el libro/columnas raw conservan pero numero_serie_motor/chasis y public.vehiculos quitan; en raw son saltos de línea y el medidor los muestra como espacios por plegar(). No queda diferencia al comparar esos seis quitando whitespace interior, PERO la custodia no destructiva de la fuente sólo autoriza limpieza técnica en staging y normalización fuerte en claves/vistas derivadas, de modo que esta pérdida en el valor publicado necesita veredicto de contrato, no se declara fiel por coincidencia compactada. No se escribió DB/código. Pendientes del epic: definir/arreglar el medidor para las transformaciones autorizadas, resolver esos seis valores publicados y completar gates de catálogos/historial; los 34 extras DEV son app_dev protegidos por creación, no drift PROD.
-
db04-mba-l-ca 2026-10-01 22:13 ART — Corrección al análisis posterior: las seis diferencias NO son etiquetas de modelo/catálogo. Consulta del cuerpo INSTALADO de public.v_vehiculos_export en movilba y movilba_dev: numero_chasis := v.numero_serie_chasis (línea 12) y numero_motor := v.numero_serie_motor (línea 17), ambos identificadores textuales del vehículo; no se proyecta chasis_id ni una etiqueta de catálogo en estas columnas. En rutap.vehiculo_historial_normalizado, raw_chasis_nro/raw_motor_nro conservan el salto de línea que trae la celda, mientras numero_serie_chasis/numero_serie_motor y public.vehiculos lo quitan; medido en AG196RL, AG732SW, AG771OC, AG806JI, idéntico en las dos bases. Por tanto la regla de catálogos para marca/modelo no resuelve estas seis discrepancias de números de serie. Sigue pendiente verificar el contrato de normalización de estos campos y su writer; no se autoriza cierre del epic por equivalencia de catálogo. Sin DB write.
-
db04-mba-l-ca 2026-10-01 22:16 ART — Localizado el mecanismo de los seis números de serie: el cuerpo INSTALADO PROD de rutap.v_rutap_latest_norm expone el valor fuente chasis_nro/motor_nro y además chasis_nro_norm/motor_nro_norm mediante regexp_replace(...,'[\r\n]','', 'g'); esas columnas derivadas quitan el salto interior. El historial normalizado y public.vehiculos llevan la versión sin salto, y v_vehiculos_export publica directamente las dos columnas textuales de vehiculos, sin resolver catálogo. raw_chasis_nro/raw_motor_nro conservan el salto exacto del libro. No es un fallo de match de chasis_id ni de etiqueta de motor; es la elección de propagar la clave normalizada al valor publicado. Docs/reference/rutap-transform-rules.md § Custodia sólo permite normalización fuerte en claves/vistas derivadas de comparación, por lo que sigue abierto si este uso como valor publicado cumple el contrato. No cambié DB/código.
-
db04-mba-l-ca 2026-10-01 22:22 ART — Verificación de FUENTE por celda, libro vigente /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74, openpyxl read_only/data_only=False sobre Base: K4445 AG732SW='8AB368185P'+U+000A+'A151744'; Q4445='924996U1402'+U+000A+'003'; Q4500 AG806JI='924996U1402'+U+000A+'071'; Q4523 AG196RL='924996U1391'+U+000A+'309'; K4652 AG771OC='8AB368185P'+U+000A+'A151966'; Q4652='924996U1419'+U+000A+'078'. K=Chasis_Nro, Q=Motor Nro; exactamente seis celdas con LF real dentro del XLSX, no artefacto de nuestra lectura. Writer INSTALADO en PROD y DEV: rutap.proyectar_snapshot(bigint), prosrc md5 9692440fbef91143dac23c97d93af8b4, construye motor_nro_norm/chasis_nro_norm con regexp_replace(btrim(r.<campo>,v_ws),'[\r\n]','','g') y los inserta como numero_serie_motor/chasis (líneas 130-131, 291/293); raw_* conserva LF. rutap.reconciliar_snapshot(integer,boolean), md5 eb1190e4633541ed64e6fe5ae65001d5, copia esos normalizados a public.vehiculos (líneas 523-524), y v_vehiculos_export publica directamente v.numero_serie_*. Es remoción deliberada y específica, existente desde la vista normalizadora del 14/08, no efecto accidental de trim. Falta confirmación de Eugenia de que los seis seriales deben concatenarse sin el LF; no se modifica el XLSX ni se inventa un serial alternativo. Sin DB write.
-
db04-mba-l-ca 2026-10-01 22:23 ART — Resolución de las seis diferencias de número de serie, corrige la hipótesis de pregunta a Eugenia del evento anterior. El XLSX vigente SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74 contiene LF U+000A dentro de la MISMA celda: Base!K4445 y Q4445 (AG732SW), Q4500 (AG806JI), Q4523 (AG196RL), K4652 y Q4652 (AG771OC). K4445 concatena 8AB368185P + A151744 en un VIN de 17 caracteres; K4652 concatena 8AB368185P + A151966, mismo patrón. Los cuatro motores son un solo identificador al unir ambos tramos de su propia celda. El LF es salto de presentación, no separador entre dos seriales; la remoción específica CR/LF en rutap.proyectar_snapshot es deliberada, deja el serial legible y raw_* conserva los bytes fuente. Los 4 numero_motor y 2 numero_chasis del medidor son diferencias textuales de formato, no seis seriales distintos ni fallos de catálogo. No se requiere pregunta a Eugenia por estas celdas. Con 1589 guardas MDVR, 59 expedientes/42 observaciones por MOVILBA-248 y estos seis wraps, todas las diferencias de las 14 columnas que reportó la corrida actual quedan clasificadas; el gate del epic sigue abierto por cobertura de catálogos/historia y por el instrumento que sale 0 e informa falsos positivos (MOVILBA-570). Sin escritura de DB/código.
-
2026-10-01 22:20 ART, coder03-mba-l-cc. Positive control for the six LF cells, pinned book sha256 21e98b9a1331, hoja Base. The cells are ONE serial wrapped inside the cell, not two serials concatenated. Chassis column K: the 90 values starting 8AB368185P are 17 characters (39) or 18 with one trailing space (51), and K4445 '8AB368185P\nA151744' and K4652 '8AB368185P\nA151966' join to exactly 17. Motor column Q: the dominant length of the 1324 values starting 924996U is 14 (982), with 15 and 18 being trailing-space variants, and all four Q cells (4445, 4500, 4523, 4652) join to 14. So the deliberate [\r\n] strip in proyectar_snapshot reconstitutes the book's canonical form and is correct normalization, not a repair. No question for Eugenia. Side observation, not a defect: 8AB368185PA151744 also appears unwrapped on another row, which is the documented shape of one chassis under two live dominios (replate), not a duplicate.
-
2026-10-01 22:28 ART, coder03-mba-l-cc, correcting my 22:20 note on two points. (1) WRONG: I called the unwrapped 8AB368185PA151744 a replate, meaning one chassis under two dominios. It is not. All four book rows carrying that VIN are the SAME dominio, AG732SW: Excel rows 509, 806, 3886 and 4445, the same vehicle's history periods. Rows 509 and 806 write the chassis and motor serials UNWRAPPED, as 8AB368185PA151744 and 924996U1402003, so the book itself confirms that the join is the true serial. That is stronger evidence than the length control. (2) The count: the book has 16 LF cells in Chasis_Nro (K) and Motor Nro (Q), not 6. Excel rows: K+Q 802 AG196RL, K+Q 812 AG806JI, K+Q 3879 AG771OC, Q 3881 AG196RL, K+Q 3886 AG732SW, Q 3891 AG806JI, K+Q 4445 AG732SW, Q 4500 AG806JI, Q 4523 AG196RL, K+Q 4652 AG771OC. All 16 belong to the same four dominios. db04's six are the subset it measured, and which rank that subset is was not verified here. The conclusion stands for all 16: the [\r\n] strip reconstitutes the serial the book writes elsewhere for the same vehicle. No question for Eugenia.
-
db04-mba-l-ca 2026-10-01 22:20 ART — Aclaro denominadores contra libro vigente 2026-09-30-1305-parque-rutap.xlsx, SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74, hoja Base leída read-only. Mis seis LF eran sólo las celdas de la fila ABIERTA elegida por tools/rutap-fidelidad.py por dominio: K+Q4445 AG732SW, Q4500 AG806JI, Q4523 AG196RL, K+Q4652 AG771OC; las cuatro filas tienen Fecha_Alta 2026-09-11 y Fecha_Baja vacía. El censo de TODAS las filas del libro es 16 celdas LF: además de esas seis, diez en períodos CERRADOS: K+Q802 AG196RL, K+Q812 AG806JI (17/11-12/12/2025); K+Q3879 AG771OC, Q3881 AG196RL, K+Q3886 AG732SW, Q3891 AG806JI (12/12/2025-11/09/2026). Por tanto 6/16 no es contradicción: seis afectan la comparación estado actual; diez quedan fuera de esa comparación y pertenecen a historia. No hubo escritura de libro ni DB.
-
2026-10-05 PROD read-only current-book census: tools/rutap-fidelidad.py --libro /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx --entorno PROD, SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74 (MD5 8512833be84d1568743d61b601179c6b). Book 5548 rows/2419 dominios: 1602 open, 817 closed-only. Export 2419 unique; missing 0, extras 0; positive control 2419 compared =1602+817. All 14 mapped literal columns 0 residual differences; gate exit 0. Exercised approved transforms: MDVR leading Excel apostrophe 1589, expediente phrase move 59, Observaciones 59, Motor Nro in-cell CR/LF 4, Chasis_Nro CR/LF 2. This is a full-domain census for the tool's 14 mapped columns, NOT a full-fidelity clearance: options/catalog-backed fields and history topology are explicitly unexercised. Earlier 42 Observaciones raw discrepancies were reclassified by MOVILBA-248; today's transform counter is 59 because it counts source-row phrase moves, not residual mismatches. No DB or source write.
-
Additional 2026-10-05 PROD SELECT-only structural/control census against installed snapshot 8 (archivo 2026-09-30-1305-parque-rutap.xlsx, md5 8512833be84d1568743d61b601179c6b): raw rutap_rows 5548 rows/2419 domains; normalized imported history 5548 rows/2419 vehicle ids, normalizacion_estado='conflicto' 0, elegible_actual=false 0. For six sampled catalog-backed axes, every raw field is nonblank in 5548/5548 and its normalized FK is non-NULL in 5548/5548: chasis, carroceria, linea, piso, ADAS, MDVR. This is a non-vacuous resolution-presence control, NOT proof that each FK is the correct catalog value or that historical dates/events round-trip. Full semantic catalog+history comparison still belongs to the epic; no false full-fidelity PASS claimed.
-
2026-10-05 PROD snapshot8 / approved book SHA256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74: 2419/2419 domains present; 1602 open + 817 closed-only; tools/rutap-fidelidad.py reports zero residual differences across all 14 mapped literal export columns, with approved MDVR guard, MOVILBA-248 phrase relocation and in-cell serial-wrap normalization exercised. Raw and normalized history row counts both 5548; zero conflict/non-eligible rows. This closes the measured current-domain/literal-column scope, not every fidelity dimension. MOVILBA-704 now owns semantic catalog-backed value and full-history row/event comparison, both explicitly unexercised by the 14-column gate. No data write.