chimera-carry-the-failure-forward

Tienes un bucle que ejecuta un intento, lo juzga, y ejecuta otro con feedback: un agente con un verificador, un corrector de código contra una suite de pruebas, una tubería de generar-y-comprobar. El presupuesto es de más de dos intentos, y el workspace se revierte entre ellos, de modo que cada intento empieza limpio.

No aplica a un reintento idempotente sobre un transporte inestable — una llamada de red que falló por razones ajenas a lo que enviaste. Ahí no hay nada que aprender del intento 1, y arrastrarlo hacia adelante es solo carga.

1. Guarda los intentos en una lista, no en una variable que reasignas. Un registro por intento: la salida del verificador, el parche que el intento escribió realmente, y qué paso de herramienta falló primero.
2. Toma el parche del snapshot del workspace, antes de la reversión — el diff real, no la descripción que el modelo hace de lo que cambió. La reversión es lo que hace esto necesario: una vez que el árbol vuelve atrás, nada en disco registra tampoco el camino equivocado, así que el siguiente intento no tiene obstáculo para volver a derivar el mismo.
3. Compón el prompt de reintento con todos los registros, del más antiguo al más reciente, cada uno etiquetado con su número de intento y su veredicto, bajo un encabezado que diga que estos ya se probaron y se revirtieron.
4. Acota cada registro. Chimera limita un diff realimentado a 2000 caracteres y lo trunca con un marcador; un historial de tres intentos sin acotar dominará el prompt.
5. Deduplica por firma de fallo. Si dos intentos fallaron de la misma manera, conserva uno y registra que se repitió — la repetición es la señal, la segunda copia no es información nueva.
6. Cuando la firma se repite, deja de añadir y cambia algo estructural: replanifica con las causas acumuladas como contexto del planificador (TaskLedger.context() las renderiza bajo "Why earlier attempts failed (do NOT repeat these):"), o escala a un modelo más fuerte. Más feedback sobre el mismo callejón sin salida no saca del callejón sin salida.
7. Emite un evento contable cada vez que inyectes historial, para que un brazo del benchmark pueda demostrar que la inyección siquiera se disparó.

El anclaje es la contrahipótesis registrada, no una hipótesis lejana: mostrarle a un modelo el parche equivocado puede fijar su atención en ese parche y producir variaciones de un enfoque muerto en lugar de uno distinto. Por eso el comportamiento es opcional y está medido en Chimera (--diff-feedback) en vez de estar activado por defecto. Trátalo como una afirmación a probar en tus propias tareas, no como una mejora zanjada.

El segundo costo es el presupuesto de contexto. Tres diffs, tres volcados del verificador y una revisión del gestor pueden empujar el prompt más allá de su umbral de compactación — y entonces un compactador sin restauración descartará exactamente el historial acumulado que pagaste por construir. Acota los registros y conoce tu presupuesto antes de activar esto, o los dos mecanismos pelearán y el síntoma visible no será ninguno de los dos.