chimera-carry-the-failure-forward

Hai un ciclo che esegue un tentativo, lo giudica, e ne esegue un altro con del feedback: un agente con un verificatore, un correttore di codice contro una suite di test, una pipeline genera-e-controlla. Il budget è di più di due tentativi, e il workspace viene riportato indietro tra l'uno e l'altro, così ogni tentativo parte pulito.

Non si applica a un retry idempotente su un trasporto instabile — una chiamata di rete fallita per motivi che non hanno nulla a che vedere con ciò che hai inviato. Lì non c'è niente da imparare dal tentativo 1, e portarselo dietro è solo zavorra.

1. Conserva i tentativi in una lista, non in una variabile che riassegni. Un record per tentativo: l'output del verificatore, la patch che il tentativo ha effettivamente scritto, e quale passo di tool ha dato errore per primo.
2. Prendi la patch dallo snapshot del workspace, prima del revert — il diff reale, non la descrizione che il modello dà di ciò che ha cambiato. È il revert a rendere tutto questo necessario: una volta che l'albero è tornato indietro, nulla su disco registra nemmeno la strada sbagliata, quindi il tentativo successivo non ha alcun ostacolo a riderivare la stessa.
3. Componi il prompt del retry da tutti i record, dal più vecchio al più recente, ciascuno etichettato con il numero del tentativo e il suo verdetto, sotto un'intestazione che dica che questi sono già stati provati e annullati.
4. Poni un limite a ogni record. Chimera limita un diff reimmesso a 2000 caratteri e tronca con un marcatore; una storia di tre tentativi senza limiti dominerà il prompt.
5. Deduplica per firma del fallimento. Se due tentativi sono falliti allo stesso modo, tienine uno e annota che si è ripetuto — la ripetizione è il segnale, la seconda copia non è informazione nuova.
6. Quando la firma si ripete, smetti di accodare e cambia qualcosa di strutturale: ripianifica usando le cause accumulate come contesto del planner (TaskLedger.context() le rende sotto "Why earlier attempts failed (do NOT repeat these):"), oppure sali a un modello più forte. Altro feedback sullo stesso vicolo cieco non fa uscire dal vicolo cieco.
7. Emetti un evento contabile ogni volta che inietti la storia, così un braccio di benchmark può dimostrare che l'iniezione è davvero avvenuta.

L'ancoraggio è la contro-ipotesi registrata, non un'ipotesi teorica: mostrare a un modello la patch sbagliata può fissare la sua attenzione su quella patch e produrre variazioni di un approccio morto invece di uno diverso. È per questo che in Chimera il comportamento è opt-in e misurato (--diff-feedback) anziché attivo di default. Trattalo come una tesi da testare sui tuoi task, non come un miglioramento acquisito.

Il secondo costo è il budget di contesto. Tre diff, tre dump del verificatore e una revisione del manager possono spingere il prompt oltre la sua soglia di compattazione — e a quel punto un compattatore senza ripristino butterà via esattamente la storia accumulata che hai pagato per costruire. Poni un limite ai record e conosci il tuo budget prima di abilitare tutto questo, altrimenti i due meccanismi si scontreranno e il sintomo visibile non sarà nessuno dei due.