rutap-libro.ts une el export con su fila de historial por aritmetica (rutap_fila + 2) porque v_export_libro no expone la clave UNIQUE rutap_fila_excel
v5.6.66 dejo instalado en src/repositories/rutap-libro.ts un join que convierte a mano: eq(historial.rutapFilaExcel, sql(vExportLibro.rutapFila + 2)). rutap.v_export_libro proyecta n.rutap_fila (0-based, nullable, SIN UNIQUE) y la clave real de la tabla es vh_norm_raw_key (rutap_snapshot_id, rutap_fila_excel), 1-based. fila = fila_excel - 2 es una identidad OBSERVADA, no una restriccion: el dia que deje de valer, el join no falla - devuelve la fila equivocada o ninguna, en silencio. Orden: 1. db: dentro del snapshot pineado, sobre origen='import' AND borrado_en IS NULL, contar (a) filas con rutap_fila IS NULL, (b) valores de rutap_fila repetidos, (c) filas donde rutap_fila <> rutap_fila_excel - 2. Las tres cifras van al item. Cualquiera distinta de 0 significa que el join ya esta mintiendo hoy. 2. db: agregar rutap_fila_excel a la proyeccion de rutap.v_export_libro (CREATE OR REPLACE, nunca DROP - la ACL de PROD no es NULL), PROD primero y despues DEV, como columna AL FINAL sin reordenar las 41. 3. coder: cambiar el join a (rutap_snapshot_id, rutap_fila_excel) sin aritmetica y borrar el + 2. Sin el paso 2 el paso 3 no se puede hacer sin volver a convertir a mano.
Activity
-
db03-mba-l-cc 2026-09-24 11:42 ART: steps 1+2 done. Counts on current snapshot, import, borrado_en NULL: PROD snap 6 (5538 rows), DEV snap 18 (5528 rows); rutap_fila NULL 0, rutap_fila_excel NULL 0, repeated rutap_fila 0, repeated rutap_fila_excel 0, rutap_fila <> rutap_fila_excel-2: 0 in both. rutap_fila_excel added as trailing column 42 of rutap.v_export_libro via docs/migrations/2026-09-24-movilba-600-v-export-libro-rutap-fila-excel-PROD-Y-DEV.sql (untracked), PROD then DEV, definition md5 6c96ada0fd3c877c43f8c2c5ce47b650 in both, ACL unchanged. Not exercised: the new NULL/uniqueness asserts never failed (no violating data); consumer rutap-libro.ts.
-
audit pass: rutap-libro.ts join uses view rutapFilaExcel (no +2, sql import dropped); drizzle schema/relations regen; 600 migration statically (POST asserts, ROLLBACK default). Base HEAD+overlay. No DB/consumer run.
payload
{"scope":"rutap-libro.ts join uses view rutapFilaExcel (no +2, sql import dropped); drizzle schema/relations regen; 600 migration statically (POST asserts, ROLLBACK default). Base HEAD+overlay. No DB/consumer run.","outcome":"pass","evidence":"Clean tree: test:source 38/38, typecheck 0, eslint 0 on rutap-libro.ts. No test asserts the join key (no failing control). digitos drift in schema.ts is not 600 (585).","reportRef":null} -
coder03-mba-l-cc - shipped en dev v5.6.70 (67087802), 2026-09-24. Paso 3 cerrado: src/repositories/rutap-libro.ts une el historial por (rutap_snapshot_id, rutap_fila_excel), sin aritmetica. Entra tambien el artefacto de db03 (2026-09-24-movilba-600-v-export-libro-rutap-fila-excel-PROD-Y-DEV.sql, APLICADO PROD y despues DEV, md5 nuevo 6c96ada0fd3c877c43f8c2c5ce47b650) y drizzle regenerado con ./mba-introspect.sh. Audit PASS leido de bwi antes del push: test:source 38/38, typecheck 0, eslint 0, migracion leida estaticamente. SIN EJERCITAR, explicito: las tres cuentas de db03 dan 0 en las dos bases, asi que el join viejo y el nuevo devuelven HOY las mismas filas - este cambio solo es falsificable el dia que la identidad fila = fila_excel - 2 se rompa, y no existe control que lo haga fallar. Ningun consumidor de getLatestRutapLibroRows corrio contra la vista de 42 columnas, y las aserciones de unicidad/NULL de db03 tampoco dispararon. AJENO AL ITEM: el schema regenerado trae digitos en rutap.rutap_rows, deriva de DEV que el espejo levanto. No es de 600; va a MOVILBA-585.
-
coder03-mba-l-cc - correccion del renglon AJENO AL ITEM de la nota anterior, 2026-09-24. digitos NO es deriva de DEV. db04 leyo los catalogos instalados el mismo dia: rutap.rutap_rows.digitos existe como text nullable en el ordinal 58 en las DOS bases (PROD movilba/PG17.6, DEV movilba_dev/PG15.17), col_39..col_52 siguen en 44..57 en las dos, y BWI-373 registra la migracion aplicada PROD y despues DEV. O sea que la columna estaba en las dos bases y lo que estaba VENCIDO era drizzle/schema.ts, que no la tenia: ./mba-introspect.sh de este commit la incorporo. No hay nada que arreglar y no queda pendiente en MOVILBA-585 por esta columna. Lo que deja como metodo: el espejo lee UNA sola base, asi que una columna que aparece al regenerar no distingue entre 'DEV la tiene de mas' y 'el archivo estaba atrasado'. Las dos se ven igual en el diff.
-
coder03-mba-l-cc 2026-09-24 - shipped en dev v5.6.70 (67087802). v_export_libro expone rutap_fila_excel (columna 42, md5 6c96ada0..., aplicado PROD y despues DEV por db03) y rutap-libro.ts une por (rutap_snapshot_id, rutap_fila_excel) sin aritmetica. SIN EJERCITAR: las tres cuentas dan 0 en las dos bases, asi que ningun control puede fallar hoy; ningun consumidor corrio contra la vista de 42 columnas.