chimera-carry-the-failure-forward

Masz pętlę, która uruchamia próbę, ocenia ją i uruchamia kolejną z feedbackiem: agent z weryfikatorem, naprawiacz kodu wobec zestawu testów, potok generuj-i-sprawdź. Budżet to więcej niż dwie próby, a workspace jest cofany między nimi, więc każda próba zaczyna od czysta.

Nie dotyczy to idempotentnego ponowienia po zawodnym transporcie — wywołania sieciowego, które padło z przyczyn niezwiązanych z tym, co wysłałeś. Z próby 1 nie ma się tam czego nauczyć, a przenoszenie jej dalej to sam ładunek.

1. Przechowuj próby w liście, a nie w zmiennej, którą nadpisujesz. Jeden rekord na próbę: wyjście weryfikatora, łatka, którą próba faktycznie zapisała, i który krok narzędzia zawiódł pierwszy.
2. Weź łatkę ze snapshotu workspace'u, przed cofnięciem — prawdziwy diff, a nie opis modelu, co zmienił. To właśnie cofnięcie czyni to koniecznym: gdy drzewo zostanie wycofane, nic na dysku nie zapisuje również złej ścieżki, więc następna próba nie ma żadnej przeszkody, by wyprowadzić tę samą na nowo.
3. Złóż prompt ponowienia ze wszystkich rekordów, od najstarszego, każdy opisany numerem próby i jej werdyktem, pod nagłówkiem mówiącym, że to już zostało wypróbowane i cofnięte.
4. Ogranicz każdy rekord. Chimera ucina zwracany diff na 2000 znakach i skraca go znacznikiem; nieograniczona historia trzech prób zdominuje prompt.
5. Deduplikuj po sygnaturze porażki. Jeśli dwie próby padły tak samo, zachowaj jedną i zanotuj, że się powtórzyła — powtórzenie jest sygnałem, druga kopia nie jest nową informacją.
6. Gdy sygnatura się powtarza, przestań dopisywać i zmień coś strukturalnie: przeplanuj, podając zebrane przyczyny jako kontekst dla plannera (TaskLedger.context() renderuje je pod "Why earlier attempts failed (do NOT repeat these):"), albo eskaluj do mocniejszego modelu. Więcej feedbacku o tej samej ślepej uliczce nie wyprowadza ze ślepej uliczki.
7. Emituj policzalne zdarzenie za każdym razem, gdy wstrzykujesz historię, żeby ramię benchmarku mogło udowodnić, że wstrzyknięcie w ogóle zadziałało.

Zakotwiczenie (anchoring) to zarejestrowana kontrhipoteza, nie hipotetyczna możliwość: pokazanie modelowi złej łatki potrafi przykuć jego uwagę do tej łatki i wyprodukować warianty martwego podejścia zamiast innego. Dlatego to zachowanie jest w Chimerze opcjonalne i mierzone (--diff-feedback), a nie włączone domyślnie. Traktuj je jako twierdzenie do przetestowania na własnych zadaniach, a nie jako ustalone ulepszenie.

Drugim kosztem jest budżet kontekstu. Trzy diffy, trzy zrzuty weryfikatora i przegląd menedżera potrafią przepchnąć prompt ponad próg kompaktowania — a wtedy kompaktor bez przywracania wyrzuci dokładnie tę zebraną historię, za której zbudowanie zapłaciłeś. Ogranicz rekordy i poznaj swój budżet, zanim to włączysz, bo inaczej oba mechanizmy będą ze sobą walczyć, a widocznym objawem nie będzie żaden z nich.