Hallazgos y tratamiento — RETP-158

1. Pérdida de procedencia: el parser anterior entregaba sólo IR. Se añade un sidecar generado durante la tokenización y el análisis, con rangos de declaraciones; la IR permanece idéntica. Los rangos son intervalos de bytes semiabiertos y el EOF es len..len de la unidad responsable.
2. Causa reducida a prosa: E004 vacío/repetición, E115 y colisiones se estructuran en sus propios emisores. Las API heredadas reciben la misma decisión y el mismo error, descartando únicamente la información adicional.
3. Fallo del instrumento de edición: la primera versión de modificar.py buscaba fn tokenize(; la función real tiene un parámetro de vida y empieza por fn tokenize<'a>. Falló con ValueError: substring not found, antes de escribir los archivos de la candidata. Se conserva modificar-01.py y la corrección modificar.py. No fue un fallo de compilación ni se cambió un esperado para ocultarlo. El tiempo de esa llamada no fue incorporado al registro automático de procesos y no se inventa.
4. Cobertura multifuente insuficiente en la primera batería focal: las colisiones y EOF estaban cubiertos; faltaba una relación E115 distribuida. Se fijó ESPERADO_RELACIONAL.json antes de ejecutar ese caso adicional. Tres declaraciones de cuatro unidades con igual nombre de archivo se localizan por índice y rol; sus cuatro SHA-256 se cotejan con Python. No se cambió la candidata.
5. Límites explícitos: los rangos sintácticos distintos de EOF permanecen pendientes cuando su emisor no da una ubicación inequívoca. Los caracteres léxicos inválidos sí conservan su rango. Los errores de perfil se rechazan y conservan el perfil, pero aún no tienen una subcausa específica de palabra extranjera. Otros validadores se identifican por etapa como CD.UNMIGRATED, sin deducir códigos de su texto.

No se observaron fallos inesperados de la candidata en las dos ejecuciones conservadas. Los rechazos del corpus inválido y los errores de acceso de los clientes negativos son resultados exigidos, no fallos del instrumento.