Importador RUTAP: el scan de contaminacion cubre solo NBSP (1 de 5 clases) - detectar y reportar, nunca auto-corregir
Medido por db02-mba-l-cc en tools/rutap-snapshot-import.py: NO hay scan de contaminacion. Hay UNA funcion de normalizacion (linea 77) que hace value.replace(chr(160),' ').strip(), con el comentario de la linea 48 explicando que el NBSP es el contaminante recurrente. Eso es todo: ni CRLF, ni en dash, ni variantes de case. El gap medido es 'el scan cubre 1 de 5 clases de contaminacion conocidas'. PEDIDO: que la ingesta CUENTE Y LISTE los valores con U+2013 (en dash), U+2014 (em dash), CR/LF, NBSP y prefijo case-variante (Ex- vs EX-). OBJECION DE DISEÑO QUE MANDA SOBRE LA IMPLEMENTACION (db02, adoptada): NO reescribir esos caracteres en la ingesta. Es la misma trampa que los 928 expedientes con espacios internos multiples: si el importador los 'arregla', el valor guardado deja de ser el del libro, la correccion es invisible, y despues no se puede saber si el expediente real tenia en dash o no. Fidelidad al origen + visibilidad: DETECTAR Y REPORTAR; la decision de normalizar es del ticket MOVILBA-39, no del script. CONTEXTO: el en dash NO lo introduce el importador, VIENE EN EL LIBRO - rutap.v_rutap_latest tiene 9 filas con U+2013 en expte_alta y 9 en expte_baja, exactamente las 9 que se ven en prod; prod refleja fielmente el origen y no hay nada corrupto de nuestro lado. El libro tambien trae 262 filas con 'Ex-' minuscula en expte_alta (en prod se ven 206 porque no todas cerraron periodo).
Questions
Activity
-
FORMA DE SALIDA (db-mba-l-cc via db02, parte del pedido, no cosmetica): el scan tiene que reportar POR CLASE Y CON EJEMPLO CONCRETO, no solo contar. '9 valores con caracteres unicode inesperados' no se acciona; '9 valores con U+2013 EN DASH, ej. fila_excel 1234: EX-2026-07797873- -GCABA-DGGSM' se acciona solo. Evidencia: las cinco poblaciones de MOVILBA-39 salieron TODAS de mirar el valor concreto - ningun conteo agregado las hubiera identificado, y la del en dash menos que ninguna, porque el conteo se ve normal y el valor se ve normal hasta que lo comparas byte a byte. COROLARIO: el reporte tiene que incluir la fila de origen (fila_excel) ademas del valor, asi quien va a reclamar a Permisos senala la CELDA y no el sintoma. RAZON EXTRA PARA NO REESCRIBIR EN LA INGESTA (db): si el importador normaliza el en dash, perdemos la evidencia para pedirle a Permisos que lo corrija EN EL ORIGEN, que es el unico lugar donde se arregla de verdad. Reescribir en silencio no solo oculta el dato: tambien nos saca el argumento.