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).
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.
-
coder02-mba-l-cc 2026-08-20: contamination scan widened from NBSP-only to 5 classes x 9 columns, detect-and-report only. Snapshot 4 results: chasis_nro newline 4 rows (AG196RL, AG732SW, AG771OC, AG806JI); motor_nro newline 6 rows, SAME BATCH - nobody had ever looked at motor_nro, so the contamination is batch-scoped, not column-scoped, and it hits at least two columns. expte_alta 1004 rows / expte_baja 928 rows with double internal spaces are the KNOWN deliberate runs the importer must not collapse (collapsing changes the natural key, 685 vs 1140 prod-match split measured 08-14) - reported with their class so a reader can tell deliberate from defect. ZERO findings for tab, edge whitespace and NBSP: the one class we used to scan for is currently clean while two we never scanned are not. motor_nro contamination has no ticket and belongs to this one.
-
coder02-mba-l-cc / coder
-
ALCANCE RESUELTO (coder02, medido). El sqlite es FIEL para contaminacion de MEDIO de valor (salto de linea, CRLF, NBSP interno, homoglifo, '0' textual) y CIEGO para la de BORDE: rutap-snapshot-import.py linea 77 hace strip() en cada celda de texto, asi que los 8 expedientes con salto AL FINAL ('...-GCABA-DGGSM\\n') dan 0 en el sqlite y 8 en el xlsx. CONSECUENCIA: el scanner corre sobre el XLSX en el INGEST, antes de la linea 77 - medido despues, el borde no existe. La linea 77 se queda (limpiar el borde al cargar es correcto); lo que falta es REPORTAR antes de limpiar. Toda medicion de contaminacion de borde hecha contra el sqlite dio 0 POR CONSTRUCCION, no por limpieza - rehacer sobre el xlsx la que definio este alcance.
-
Scanner CONSTRUIDO y corrido, commit 0f1d434c (solo tools/rutap-snapshot-import.py, staged por path). Corre en la INGESTA sobre celdas crudas del xlsx antes de clean(); read_sheet/read_csv devuelven un tercer valor con los valores crudos. 9 clases en dos familias. Salida ordenada por CLASE y COLUMNA (nunca por conteo: ordenar por cantidad hace que una mejora reordene el bloque y el diff no distingue progreso de ruido) - dos corridas dan diff vacio. Tope 3 ejemplos por clase/columna. DEFECTO PREEXISTENTE ARREGLADO en el mismo commit: el archivo nunca tuvo 'if __name__ == main' pese a documentar uso por CLI - corrido como script salia EXIT 0 sin importar nada ni imprimir una linea. Silencio + exit 0 se lee como exito. Grep del resto de tools/: cero casos mas.
-
Construido, corrido y desplegado a dev en v5.3.216 (commits 0f1d434c + fb0e08cb). Scanner de 9 clases en la INGESTA sobre el xlsx crudo, dos familias (AL LIBRO / HIGIENE), salida diffeable ordenada por clase y columna, tope de 3 ejemplos, gate de reorden con clave (dominio, fecha_alta, interno). Arreglo de paso: el archivo nunca tuvo 'if __name__ == main' pese a documentar uso por CLI.