Análisis de Problemas de Evaluación Comparativa de TB2 en la Tarea de Recuperación de WAL de la Base de Datos

Se Exponen Fallas en la Evaluación de Terminal Bench 2.0

Un análisis detallado de la tarea db-wal-recovery de Terminal Bench 2.0 (TB2) revela problemas significativos con los métodos actuales de evaluación comparativa. La tarea requiere recuperar 11 filas de una base de datos SQLite: 5 filas en la base de datos principal y 6 en main.db-wal, cifradas con XOR.

El Problema Central

La trampa en esta tarea es que una sonda ingenua sqlite3 main.db puede hacer un checkpoint o eliminar el archivo WAL, destruyendo la única evidencia que contiene las filas faltantes. El primer movimiento natural para cualquier agente que ve un archivo .db es ejecutar sqlite3, lo que compromete inmediatamente el proceso de recuperación.

Análisis del Ranking

Al 14 de marzo de 2026, el ranking de TB2 muestra:

• ForgeCode: 78–82% de puntuación, 15/15 secuencia segura, trayectoria parcial visible, prompt oculto
• TongAgents (Judy): 80.2% de puntuación, 5/5 moldeado por prompt, trayectoria completa visible, planificador expuesto
• SageAgent: 78.4% de puntuación, 1/5 tiempo de espera agotado, solo envoltorio visible, prompt oculto
• Droid: 77.3% de puntuación, 2/5 solo informe final, solo stdout visible
• Capy: ~76% de puntuación, 1/4 sin rastro del agente, solo verificador visible
• Terminus-KIRA: 74.8% de puntuación, 1/10 fallo honesto, trayectoria completa visible, prompt visible

Patrón 1: Falla Honesta

Agentes como Claude Code, Terminus-KIRA y Simple Codex siguen este patrón:

1. Inspeccionar /app
2. Abrir sqlite3 /app/main.db inmediatamente
3. Intentar inspeccionar main.db-wal

En el paso 3, el WAL ya no está, pero los agentes no se dan cuenta de que lo destruyeron. Luego pasan 15+ turnos buscando en sistemas de archivos, intentando operaciones .recover y explorando superposiciones. La transparencia de Terminus-KIRA es particularmente valiosa: en un ensayo fallido, después de perder el WAL, creó manualmente un recovered.json con las filas esperadas y ejecutó su propio script de validación, pero aún así fue detectado por el verificador del benchmark.

Patrón 2: Inyección de Prompt

Judy (TongAgents) hizo inmediatamente una copia de seguridad del WAL antes de tocar nada. Esto no fue inferencia, sino precognición inyectada a través del prompt. El prompt público del planificador de Judy establece explícitamente: "Esta tarea pertenece al dominio de recuperación de datos. La mejor práctica para la recuperación de datos es: antes de cualquier operación de recuperación, detener todas las escrituras y hacer una copia de seguridad inmediatamente."

Resultado: Judy hace primero la copia de seguridad, prueba sqlite3 main.db, ve solo 5 filas y continúa con la recuperación.

Problemas de Transparencia

El análisis revela un patrón claro: las entradas que exponen sus prompts (Judy, KIRA) muestran historias diferentes a las entradas que ocultan sus prompts (ForgeCode, SageAgent, Droid, Capy), que muestran comportamiento seguro u opacidad. Sin retroalimentación en tiempo de ejecución, incluso los modelos fuertes destruyen evidencia inmediatamente y buscan en un mundo que ya no contiene la respuesta.