fix(learner): eliminate false-positive proposals (structural error detection + by-design file exclusions + trigram filter)

[juanparisma]

Problema

En una sesión real del 2026-07-16, el session-learner generó 190 proposals de las cuales 189 eran basura. Tres causas raíz, verificadas contra las observaciones reales:

1. error_resolution fantasma — observe_v3.py marcaba is_error=True si el output contenía la subcadena error/failed en cualquier parte, incluido el contenido de archivos leídos con éxito (p. ej. código fuente con throw new Error). Prueba: en las proposals falsas, err_msg era idéntico a sample_output y no contenía ningún error.
2. user_correction falsas — contaba como corrección cualquier archivo editado 3+ veces, pero los diarios/paneles de control (hot.md, brief.md, working-memory.md, daily summaries, wikis) se re-editan por diseño en los flujos de cierre (/eod). Una bitácora con 11 ediciones ≠ 10 correcciones del usuario.
3. workflow_chain ruido — proponía cualquier trigrama de tools repetido 2+ veces; eso lo domina la actividad genérica de programar (Bash>Bash>Bash ×380 en una sesión → 154 proposals inútiles).

Fix

• observe_v3.py: detección de errores (a) estructural para toda tool (dict con campo error, marcador tool_use_error, output que EMPIEZA con Error/InputValidationError) + (b) marcadores duros (Permission denied, command not found, Traceback, npm ERR!…) solo para Bash, cuyo output es resultado de ejecución y no contenido arbitrario.
• _session-learner.sh:
  • isRealError(): re-valida el flag is_error contra marcadores duros — necesario porque las observaciones ya escritas por observers viejos siguen contaminadas y el learner relee esa ventana.
  • user_correction: excluye archivos re-editados por diseño (BYDESIGN_RE).
  • workflow_chain: exige 5+ repeticiones, ≥2 tools distintas y ≥1 tool no-genérica (MCP/custom).
  • PATTERN 5 (agent errors): usa isRealError en vez de sniffing de keywords.

Verificación

• 6 tests unitarios del observer con payloads sintéticos: los 3 casos de falso positivo (Read con throw new Error, Bash exitoso, Grep sobre logs con "error") dan False; los 3 errores reales (Permission denied, String to replace not found, File does not exist) dan True.
• A/B sobre una ventana real de 8.000 observaciones: 134 proposals con el código viejo → 17 con el fix, y las 17 supervivientes son señales legítimas (3 fallos reales de tools, 7 archivos fuente iterados de verdad, 7 secuencias MCP repetidas 5-14×).

Corriendo en producción en mis 2 PCs desde hoy sin regresiones.

🤖 Generated with Claude Code

[Luispitik]

Merged y publicado en v4.9.0. Gracias, y perdona la espera desde el 16 de julio.

Tu diagnóstico era el correcto y era el difícil de ver: el observador marcaba is_error por el contenido de ficheros leídos con éxito, así que leer código con un throw new Error dentro contaba como fallo de herramienta. Medido sobre una ventana real de 8.000 observaciones, tu fix baja de 1.074 observaciones marcadas a 22.

Encima de lo tuyo he añadido una cosa, y quiero que sepas por qué. Restringir los marcadores duros a Bash era correcto para matar los falsos positivos, pero dejaba sin detectar los fallos reales de Edit y Read (String to replace not found, File does not exist): no tienen forma de harness, así que la rama estructural tampoco los cogía. La detección para esas herramientas pasa a mirar la forma — un fallo devuelve un veredicto en texto plano, un éxito devuelve un payload que serializa empezando por { o [, y los payloads no se escanean nunca, que es justamente el bug que tu PR arregla. Cero falsos positivos sobre 7.931 observaciones no-Bash reales.

O sea que tu regla se mantiene entera; lo que se añade es el caso que quedaba al otro lado. Si al verlo crees que se me ha ido la mano en algún borde, dilo y lo miramos.