chimera-carry-the-failure-forward

Vous avez une boucle qui lance une tentative, la juge, et en lance une autre avec du feedback : un agent doté d'un vérificateur, un correcteur de code face à une suite de tests, un pipeline générer-puis-vérifier. Le budget dépasse deux tentatives, et l'espace de travail est restauré entre elles pour que chaque tentative démarre propre.

Cela ne s'applique pas à un réessai idempotent sur un transport instable — un appel réseau qui a échoué pour des raisons sans rapport avec ce que vous avez envoyé. Il n'y a rien à apprendre de la tentative 1 dans ce cas, et la transporter n'est que de la charge inutile.

1. Stockez les tentatives dans une liste, pas dans une variable que vous réaffectez. Un enregistrement par tentative : la sortie du vérificateur, le patch que la tentative a réellement écrit, et quelle étape d'outil a échoué en premier.
2. Prenez le patch depuis l'instantané de l'espace de travail, avant la restauration — le vrai diff, pas la description que le modèle donne de ce qu'il a changé. C'est la restauration qui rend cela nécessaire : une fois l'arbre revenu en arrière, plus rien sur le disque ne conserve non plus la mauvaise piste, et la tentative suivante n'a donc aucun obstacle pour la redériver à l'identique.
3. Composez le prompt de réessai à partir de tous les enregistrements, du plus ancien au plus récent, chacun étiqueté avec son numéro de tentative et son verdict, sous un titre indiquant que ces pistes ont déjà été essayées puis annulées.
4. Bornez chaque enregistrement. Chimera plafonne un diff réinjecté à 2000 caractères et le tronque avec un marqueur ; un historique de trois tentatives sans borne dominera le prompt.
5. Dédupliquez par signature d'échec. Si deux tentatives ont échoué de la même façon, gardez-en une et notez que l'échec s'est répété — la répétition est le signal, la seconde copie n'apporte aucune information nouvelle.
6. Quand la signature se répète, arrêtez d'ajouter et changez quelque chose de structurel : replanifiez en donnant les causes accumulées comme contexte au planificateur (TaskLedger.context() les rend sous « Why earlier attempts failed (do NOT repeat these): »), ou passez à un modèle plus puissant. Plus de feedback sur la même impasse ne fait pas sortir de l'impasse.
7. Émettez un événement comptable à chaque injection d'historique, pour qu'un bras de benchmark puisse prouver que l'injection a bien eu lieu.

L'ancrage est la contre-hypothèse enregistrée, pas une hypothèse en l'air : montrer à un modèle le mauvais patch peut fixer son attention sur ce patch et produire des variations d'une approche morte plutôt qu'une approche différente. C'est pourquoi le comportement est optionnel et mesuré dans Chimera (--diff-feedback) plutôt qu'activé par défaut. Traitez-le comme une affirmation à tester sur vos propres tâches, pas comme une amélioration acquise.

Le second coût est le budget de contexte. Trois diffs, trois vidages de vérificateur et une revue de gestionnaire peuvent pousser le prompt au-delà de son seuil de compaction — et un compacteur sans restauration supprimera alors exactement l'historique accumulé que vous avez payé pour construire. Bornez les enregistrements et connaissez votre budget avant d'activer ceci, sinon les deux mécanismes se combattront et le symptôme visible ne sera ni l'un ni l'autre.