El libro escribe una B CIRILICA (U+0412) en chasis_modelo de AI230WN y la app la muestra: override documentado + normalizacion en el import
MEDIDO 2026-09-22 (db03), barrido de [Ѐ-ӿͰ-Ͽ] sobre TODA columna de texto de las tablas base de public+rutap, en DEV y PROD. EL DEFECTO ES DEL LIBRO, UNA SOLA FILA: dominio AI230WN (SCANIA, vehiculos.id 5948 en las DOS bases), Chasis_Modelo = 'K280 В4x2 (GAS)' donde la segunda palabra arranca con В CIRILICA U+0412 en vez de B latina U+0042. Sobrevive porque clean() de tools/rutap-snapshot-import.py documenta que NO hace NFKC a proposito (NFKC destruia identidad de caracter, p.ej. U+00BA->'o' en 52 celdas de ID MDVR). EL VALOR CORRECTO NO SE INVENTA: el propio libro lo escribia con B latina (0x42) el 2026-06-26 - docs/migrations/private/2026-07-15-0706-Parque Movil RUTAP 26_06_2026.tsv:1446. O sea es una REGRESION de un libro posterior, no una grafia del proveedor. Por eso entra como error obvio, no como decision. ALCANCE MEDIDO. PROD: 5 relaciones (public.parque_rutap_20260821_0624_raw.chasis_modelo, public.vehiculos.chasis_modelo, rutap.rutap_rows.chasis_modelo, rutap.vehiculo_historial_normalizado.chasis_modelo y .raw_chasis_modelo). DEV: las mismas 5 + parque_rutap_20260813_raw, parque_rutap_20260820_1601_raw y rutap.chasis_resolver.modelo_normalizado. Una fila cada una. LA FK YA ES CORRECTA Y NO SE TOCA: rutap.chasis_resolver tiene la grafia cirilica como alias APROBADO -> chasis_id 124, junto a cinco grafias latinas que van al mismo 124, en DEV y en PROD. Es lo que hace que el import resuelva hoy. Borrarlo rompe la resolucion. POR QUE NO ALCANZA UN UPDATE: reconciliar_snapshot compara v.chasis_modelo contra s.chasis_modelo y lo pisa (linea 193 lo marca como drift, 480 lo reescribe), y su fuente es rutap.vehiculo_historial_normalizado. materializar_snapshot_raices inserta vehiculos.chasis_modelo desde rutap.rutap_rows, o sea desde el CRUDO. Una fila corregida a mano vuelve al cirilico en el proximo import y ademas se reporta como deriva. FORMA DEL ARREGLO: una funcion rutap.chasis_modelo_desde_libro(text) con el override de esa unica grafia (precedente: expediente_desde_libro, observaciones_desde_libro, y el CASE de ELECTRICO-CABA), llamada desde los DOS escritores, mas el UPDATE de la fila viva. NO se toca ninguna columna raw_* ni rutap_rows ni las parque_rutap_*_raw: son la evidencia de lo que dijo el libro, y el trigger vh_norm_reject_book_column_update ya lo impide por patron. NO SE INSTALA UN DETECTOR GENERAL DE HOMOGLIFOS EN ESTA CORRIDA: un RAISE nuevo en el import es una condicion de aborto nueva y esa es una decision de Elazar, del mismo peso que sacarlo. Queda propuesto, no instalado. A EUGENIA: va a su planilla como hecho - como lo importamos y el pedido de que tenga a bien revisarlo. Orden de Elazar, CLI 2026-09-22.
Activity
-
APLICADO Y VERIFICADO EN DEV Y PROD, 2026-09-22, mismo archivo, md5 4a72975ea5b31f72d031f88ce2c5ea0a: docs/migrations/2026-09-22-movilba-536-chasis-modelo-cirilico-AI230WN-DEV-Y-PROD.sql. DEV primero (movilba_dev@10.9.10.54, movilba_user), despues PROD (movilba@10.78.42.168, postgres) con el MISMO instrumento. POSTCONDICION MEDIDA DESPUES DEL COMMIT, fuera del artefacto, en las dos bases: vehiculos id 5948 dominio AI230WN chasis_modelo='K280 B4x2 (GAS)' chasis_id=124 (sin cambio); 0 homoglifos en vehiculos.chasis_modelo y en vehiculo_historial_normalizado.chasis_modelo; 1 fila conserva la grafia del libro en raw_chasis_modelo y 1 en rutap.rutap_rows, o sea la evidencia sigue ahi; alias cirilico aprobado del chasis_resolver intacto -> 124. Las TRES funciones dan el mismo md5 en DEV y PROD: proyectar_snapshot 2dd1331514baf250ed094f4b9ac65c5c, materializar_snapshot_raices 0aa56e2e2f9271a9ffecdcf8b107b205, chasis_modelo_desde_libro 9d3a6db1864e4a9064cb464b85495c98. CONTROL POSITIVO: el gate 2h afirma que el override NO matchea una grafia vecina (misma cadena con X mayuscula) - se lo vio discriminar, no solo pasar. Y el artefacto YA ABORTO una vez de verdad: la primera corrida murio en el gate 5b porque el dominio tiene DOS periodos y el cerrado (2026-05-15 -> 2026-07-17) ya decia B latina. La postcondicion se reescribio a antes+1 con el conteo capturado antes de escribir. Esa aborcion es ademas la evidencia mas fuerte de que el valor corregido no se invento: el mismo libro, en el periodo anterior del mismo colectivo, lo escribe con B latina hoy. DIFF DE CUERPO, no solo gates: diff del pg_get_functiondef antes/despues en DEV da exactamente UNA linea por funcion, la parchada, en las dos. NO EJERCITADO, y es la cobertura que falta: no se corrio un import completo, asi que las dos llamadas nuevas se probaron por gate estatico (la funcion sola, y el texto instalado), no viendolas correr dentro de proyectar/materializar. El proximo import es quien lo ejercita. DOCUMENTADO: docs/reference/ssot-overrides.md (seccion Chasis_Modelo nueva; de paso se corrigio la ruta /resource -> /data-lezama y el punto 4 que todavia pedia un GO derogado). Planilla de Eugenia (/data-lezama/movilba/import-reports/todo-rutap-importacion-prestaciones.xlsx, respaldo PREV-2026-09-22-1616): hoja Convenciones fila 18 con el hecho, hoja 'Para Eugenia' fila 9 con el pedido de revisar el origen. PENDIENTE DE OTRO CARRIL: coder03 tiene que commitear el .sql, el ssot-overrides.md y tools/libro-valores-inventario.py.
-
CORRECCION DEL REGISTRO, mismo dia: el evento anterior dice 'DEV primero, despues PROD' y eso es falso sobre la PRIMERA corrida. El orden real fue PROD (abortada) -> DEV -> PROD. La primera ejecucion salio contra PROD por error de variable: en .env.local NO hay superuser de DEV - SUPERUSER_POSTGRES_URL y SUPERUSER_ELAZAR_URL apuntan LAS DOS a movilba@10.78.42.168, y DEV solo tiene movilba_user. Agarre 'la del superuser' y era PROD. EFECTO EN PROD: CERO, verificado, no inferido. Esa corrida murio en el gate 5b dentro de la transaccion y no llego al COMMIT. Medido inmediatamente despues: rutap.chasis_modelo_desde_libro no existia (to_regprocedure NULL) y seguia habiendo 1 fila con el homoglifo. Y la prueba mas fuerte es posterior: cuando PROD corrio de verdad, el gate 0 PASO contra los md5 VIEJOS (proyectar 4c47a51f78e933991602d1bcee804868, materializar b541344dabbb43bffa0739e353e8c842), o sea los dos CREATE OR REPLACE de la corrida abortada tambien se habian deshecho. Lo que la corrida abortada SI hizo, y es la parte util: encontro el defecto del gate 5b (el dominio tiene dos periodos) antes de que existiera cualquier escritura. El arreglo del artefacto salio de ahi. Que quede como riesgo de herramienta, no como anecdota: no hay URL de superuser de DEV, asi que 'la variable de superuser' es PROD por defecto. Verificar current_database() antes de correr un artefacto, no despues.
-
2026-09-23 tracker reconciliation: coder03 reports fresh SELECT verification in hub message coder03-mba-l-cc-mue7q7ef6j26: DEV and PROD vehiculos AI230WN Latin B; normalized history 2 Latin/0 Cyrillic; PROD raw rutap_rows retains 1 Cyrillic of2 rows. This is peer-reported measurement, not a new query by db04, and corroborates existing Sep22 verified event. Held refers only to artifact COMMIT, not database APPLY. Live tracker Para Eugenia B9:E9 combines completed DB correction with request to correct source; source correction has NOT been confirmed by this evidence. Do not remove the remaining stakeholder request merely because the implementation BWI is done; document and separate completed correction from pending source follow-up when reconciling Resueltos.