Ponownie przyjrzałem się wtyczce ralph-wiggum od Anthropic. Pojedyncza sesja, gromadzenie kontekstu, brak ponownego zakotwiczenia. To naprawdę podważa sens. Oryginalna wizja @GeoffreyHuntley: - Świeży kontekst przy każdej iteracji - Operacje na plikach jako stan (nie transkrypcja) - Głupi pętla bash, deterministyczna konfiguracja Wersja Anthropic? Zatrzymanie hooka, który blokuje wyjście i ponownie wprowadza prompt w tej SAMEJ sesji. Transkrypcja rośnie. Kontekst się zapełnia. Nieudane próby zanieczyszczają przyszłe iteracje. Ironia: własne wytyczne Anthropic dotyczące długiego kontekstu mówią, że "agenci muszą ponownie zakotwiczać się w źródłach prawdy, aby zapobiec dryfowi." Ich wtyczka w ogóle nie zakotwicza ponownie. --- flow-next podąża za oryginalną wizją: ✅ Świeży kontekst przy każdej iteracji (zewnętrzna pętla bash) ✅ Operacje na plikach jako stan (.flow/ katalog) ✅ Deterministyczna konfiguracja (te same pliki ładowane przy każdej iteracji) Plus własne wytyczne Anthropic: ✅ Ponownie zakotwicz KAŻDE zadanie - ponownie przeczytaj specyfikację epicką, specyfikację zadania, stan git ✅ Ponownie zakotwicz po kompresji kontekstu (kompresja nie powinna mieć miejsca, ale jeśli już, jesteśmy gotowi) Plus to, co dodaliśmy: ✅ Wielowarstwowe bramy jakości: testy, lintery, kryteria akceptacji, I przegląd między modelami za pośrednictwem @RepoPrompt ✅ Przeglądy blokują do momentu SHIP - nie "oznacz i kontynuuj" ✅ Wyraźny plan → fazy pracy - plan przeglądany przed rozpoczęciem kodowania ✅ Automatyczne blokady zablokowanych zadań po N niepowodzeniach ✅ Ustrukturyzowane zarządzanie zadaniami - zależności, status, dowody Dwa modele > jeden. Procesuj niepowodzenia, a nie niepowodzenia modelu. Agenci, którzy naprawdę kończą to, co zaczynają.