Od zasad prozy do mechanicznych bram: wzmacnianie zespołu agentów Claude Code

Każdy, kto używa agentów programistycznych od kilku tygodni, widział to: w pole instrukcji systemu znajduje się reguła, agent ją odczytuje, a dokładnie w momencie, gdy reguła ma znaczenie, agent i tak robi to, co jest zabronione, i zgłasza sukces. Przepisanie reguły, użycie wielkich liter lub dodanie słowa „WAŻNE” rzadko przynosi długotrwałe efekty. Ten artykuł opisuje historię wersji otwartego pluginu Claude Code o nazwie blackgoat-agentskills, obejmującą piętnaście wersji, i pokazuje wzorzec, który przyjęli jego utrzymujący: gdy obowiązująca instrukcja jest łamana, zastępuje się ją czymś, co musi zostać wykonane lub otwarte. Pod koniec powinieneś być w stanie rozpoznać, które z twoich własnych reguł dla agentów to nadal tylko życzenia, oraz znać kilka konkretnych sposobów na przekształcenie ich w warunki realizacji zadań.

Punkt wyjścia: zespół specjalistów

Plik dodatkowy organizuje pracę nad oprogramowaniem jako zespół specjalistycznych agentów. Lista obejmuje analizę wymagań, architekturę i planowanie; dwa role budujące; testowanie, przegląd kodu oraz audyt bezpieczeństwa; inżynierię wersji; oraz meta-inżyniera, którego zadaniem jest edytowanie pozostałych agentów. Orchestrator działający w głównej sesji Claude Code przekazuje im zadania. Każdy specjalista działa w swoim oddzielnym kontekście i zwraca ustrukturyzowany dokument przekazujący informacje, a nie swobodną rozmowę.

Wersja 1.0.0 zawierała trzynaście person i pięć pipeline’ów, obejmujących etapy odkrywania (/bgpdd-discovery), planowania (/bgpdd-plan), wersji uproszczonej (/bgpdd-lite), budowania (/bgpdd-build) oraz wysyłania (/bgpdd-shipping). Razem z nimi pojawił się również poleceń do naprawy błędów dla pojedynczego agenta, zestaw umiejętności metodologicznych, które agenty ładują tylko w razie potrzeby, narzędzie do oceny oraz jeden wczesny test deterministyczny: brama pokrycia, która potwierdzała, że każde wymaganie typu „Must-Have” odpowiada testowi z pozytywnym wynikiem.

Założenie projektowe w tym etapie było rozsądne i powszechne. Jeśli każda persona jest dobrze napisana, a każda metodyka jasna, agenci będą prawidłowo funkcjonować. Prawie każde zasad było akapitem prozy, a prawie każda decyzja stanowiła zdanie w raporcie. Reszta historii to stopniowe obalanie tego założenia.

Rozdzielenie agenta, który próbował wykonywać trzy zadania

Pierwszym problemem nie była nieposłuszeństwo, lecz przeciążenie. Persona testera, Quinn, miała trzy tryby: badanie zachowania starych funkcji podczas analizy, testowanie nowych wersji oraz weryfikację gotowości przed uruchomieniem. Umieszczenie wszystkich trzech funkcji w jednej osobowości skutkowało instrukcjami o długości około 5 000 słów, a powstały agent był przeciętny we wszystkich zadaaniach.

Wersja 1.1.0 podzieliła tę rolę na trzy części. Echo analizuje istniejące zachowania podczas fazy analizy. Vera odpowiada za listę kontrolną przed uruchomieniem. Quinn ma już tylko jedno zadanie: testowanie wersji ostatecznej.

To samo wydanie zawierało dwa istotne poprawki operacyjne, które warto skopiować. Każdy agent otrzymał czterominutowy limit czasu na wykonywanie poleceń w shellu, ponieważ procesy utknęły na wieki z powodu problematycznego procesu. A milesteony oznaczone jako istotne pod kątem bezpieczeństwa są teraz sprawdzane równolegle przez Cipher, audytora bezpieczeństwa, oprócz standardowej oceny kodu.

Ogólna lekcja jest znana z zespołów ludzkich: rola obejmująca kilka niespowiązanych ze sobą obowiązków ma zbyt ogólne i rozproszone instrukcje. W przypadku agenta LLM ta rozproszenie jest dosłowne, ponieważ każda dodatkowa instrukcja konkujuje o uwagę w tym samym kontekście.

Czysty raport, który nie był czysty

Wydanie 1.2.0 zostało uruchomione po pięciu etapach budowy, które zgłosiły sukces, ukrywając przy tym długą listę problemów:

• cztery skrypty kontrolne, których nigdy nie wywołał żaden skrypt pakietowy ani zadanie CI
• stwierdzenia tak bezwartościowe, że żaden z etapów kontrolnych nigdy nie odrzucił niczego

raport z testu, w którym pozycje zostały oznaczone jako PRZEJDŹ, ponieważ istniał plik, wypełniony wymyślonymi szczegółami

trzy kamienie milowe zapisane, podczas gdy decyzja recenzenta o „Żądaniu zmian” wciąż obowiązywała

Nieprzyjemne jest to, że zasady już obejmowały każdy z tych przypadków. Zasada „Zielony kolor to nie dowód” była aktywna. Rejestr blokerów również był aktywny. Model je odczytał i kontynuował pracę.

Odpowiedzią była pierwsza seria sprawdzalnych warunków wstępnych projektu:

• Bramka nie jest uznawana za wiarygodną, dopóki ktoś nie zaobserwował jej awarii spowodowanej celowym naruszeniem zasad, przy czym wynik tej awarii musi zostać zachowany.
• Plan nie może deklarować skryptu weryfikacji, jeśli nie poda jednocześnie nazwy wpisu manifestu oraz zadań CI, które go uruchomią.
• Aby zatwierdzić kamień milowy, konieczne jest odczytanie dwóch plików: najnowsza decyzja z przeglądu musi być pozytywna i musi być nowsza od różnicy między wersjami, a tablica blokerów musi być pusta.
• Poprawka dotycząca krytycznego problemu przechodzi ponownie przez testy i przegląd, zamiast być dodawana na końcu.
• Każdy wiersz typu PASS musi zawierać dokładną komendę, która została wykonywana, oraz jej dosłowny wynik.

Z tym zmianie przyszły ze sobą dwie modyfikacje procesu. Wszystkie delegacje zaczęły działać w tle, ponieważ jedna z blokujących delegacji uniemożliwiła dostęp do Orchestratora przez cały czas trwania procesu, co sprawiło, że długa faza była nierozróżnialna od zatrzymania. Ponadto każdy agent teraz tworzy swój plik wyników na początku i wypełnia go sekcja po sekcji, ponieważ przerwany proces niszczył wszystko, co zostało wygenerowane.

Pierwszy warunek wstępny wymaga szczególnej uwagi. Sprawdzenie, które nigdy nie zawiodło, to takie, któremu nie ma się powodu ufać; jest to ta sama zasada co obserwowanie, jak nowy test jednostkowy zmienia kolor z czerwonego na zielony, zastosowana do samego narzędzia.

Wydanie 2.0.0: przekształcanie instrukcji w programy

Warunki wstępne z wersji 1.2 były lepsze, ale nadal miały postać tekstu. „Wykonać dwie operacje odczytu plików” to instrukcja, a podczas późniejszej próby Orchestrator zrealizował trzy etapy kolejno, mimo że istniały negatywne decyzje dotyczące zmian w żądaniach.

W tym samym czasie pojawiły się dwa inne problemy. Jeden z kamieni milowych interfejsu Vue miał 51 000 znaków w treści początkowej, ponieważ jeden z twórców zajmował się jednocześnie schematem, API oraz interfejsem, a dostarczony interfejs miał słabe funkcje paginacji, pól wprowadzania tekstu i autodopasowywania. Tymczasem uruchamianie twórców równolegle na jednej gałęzi spowodowało, że ciągle przesuwali punkt HEAD względem siebie, więc przy każdej rundzie weryfikacji trzeba było ponownie sprawdzić całą zmianę.

Brama komitowania staje się skryptem

check_commit_gate.py teraz wykonywać zadania, które wcześniej realizował tekst. Czyta token werdyktu, potwierdza, że recenzja jest nowsza od różnicy, sprawdza rejestr blokerów, a następnie dokonuje samego komitowania. To ostatni detal jest najważniejszy: ponieważ tylko skrypt może dokonać komitowania, pominięcie bramy jest oczywiste – po prostu nie ma żadnego komitowania.

Budowniczowie podzieleni według dziedziny

Mason zajmuje się etapami w tle, a Nova – elementami interfejsu użytkownika. Każdy etap jest oznaczany podczas planowania, dzięki czemu przekierowanie go do odpowiedniego budowniczego jest procesem mechanicznym, a nie decyzją, którą Orchestrator musiałby podjąć później.

Koniec z równoległymi budowniczymi

Równoległe prace zostały całkowicie usunięte. Jeden budowniczy pracuje nad jednym etapem, co oznacza, że musi sprawdzić tylko jeden plik z różnicami.

Zasada leżąca u podstaw wszystkiego, co nastąpiło później

Własne instrukcje repozytorium otrzymały zasadę dotyczącą zasad. Mówiąc prościej: gdy obowiązująca zasada jest naruszana, nie należy jej przepisywać ani podkreślać; należy ją zamienić na mechaniczną bramkę kontrolną. Każda zasada, która każe agentowi zwlekać w momencie, gdy najbardziej chce kontynuować, musi być poparta artefaktem, który należy uruchomić lub otworzyć.

To jest istota całego projektu, która dobrze sprawdza się poza tym pluginem. Jeśli spojrzysz na swój własny plik CLAUDE.md lub instrukcje dla agenta, zasady, które najczęściej zawodzą, to właśnie te wymagający powściągliwości pod presją: nie podejmuj jeszcze decyzji, nie pomijaj testów, nie oznaczaj tego jako zakończonego. Aby dowiedzieć się więcej na temat zawartości tego pliku, zapoznaj się z naszym przewodnikiem po tworzeniu skutecznego pliku CLAUDE.md.

Definicja tego, co stanowi dowód

W drugiej połowie wersji 2.0.0 zajęto się subtelniejszym problemem. Zestaw testów przekazowych informuje o tym, jakie zadania zostały wykonywane, ale nic nie mówi o tym, co zostało pominęte. Na przykład host testów wewnątrz procesu nie może pokazać, co rzeczywisty klient otrzymuje przez sieć: struktury zserializowanej odpowiedzi, kolejności uruchamiania komponentów pośredniczących oraz konfiguracji środowiska. Agenty deklarowali, że dane funkcje są „sprawdzone”, opierając się na jednym teście jednostkowym i pewnym stwierdzeniu.

Trzy poziomy dowodów

W projekcie zdefiniowano trzy poziomy:

• Poziom 1 to test jednostkowy.
• Poziom 2 przesyła żądania przez rzeczywisty pipeline aplikacji, ale przy użyciu mechanizmu transportu przechowywanego w pamięci.
• Poziom 3 obserwuje działającą aplikację z zewnątrz za pomocą rzeczywistego klienta.

Twierdzenie wymagające poziomu 3 nigdy nie może zostać potwierdzone za pomocą certyfikatu poziomu 2. Opis umiejętności jasno pokazuje tę asymetrię: obserwacja prowadzona w trakcie procesu może obalić twierdzenie dotyczące przewodu, ale nigdy go nie udowodnić.

Powierzchnie weryfikacji wybrane podczas planowania

Każdy kamień milowy otrzymuje podczas planowania tag powierzchni weryfikacji, a ten tag określa, jakie dowody będą wymagane przez poszczególne bramy kontrolne. Powierzchnia API wymaga odpowiedzi uzyskanej poza procesem oraz dokumentu OpenAPI, do którego można faktycznie uzyskać dostęp. Powierzchnia UI wymaga wygenerowanego wyniku. Nadanie nazwy klientowi testowemu działającemu w trakcie procesu, takiemu jak WebApplicationFactory lub supertest, jako narzędziu transportowego jest uznawane za niepowodzenie bramy kontrolnej, a nie za sprytną alternatywę.

Zapisy z elementami potwierdzającymi nienaruszalność

Dowody są gromadzone w postaci zapisu: polecenie jest wykonywane za pośrednictwem cichego narzędzia, które zapisuje wynik wraz z plikiem pomocniczym utworzonym przez maszynę. Ten plik pomocniczy rejestruje argumenty polecenia, katalog roboczy, identyfikator procesu, daty i godziny, rzeczywisty kod wyjścia oraz hashe obu plików. Narzędzia Gates przeliczają te hashe, więc edycja zapisu później psuje proces weryfikacji.

To standard rozprzestrzenił się następnie we wszystkich miejscach, gdzie twierdzenie miało formę zdania. Wpis dotyczący pokrycia, który zawiera jedynie „PASS, done”, jest oznaczony jako UNEVIDENCED i traktowany jako nierozpatrzony. Agenty bezpieczeństwa i uruchamiania muszą zakończyć każdą linię sprawdzania, wskazując na odpowiedni zapis. Każda postać ma również możliwość uczciwego wyjścia: jeśli weryfikacja nie mogła zostać przeprowadzona, wynik jest oznaczony jako BLOCKED, nigdy jako PASS, i musi wskazywać, co brakowało. Jak stwierdza projekt, „zweryfikowane” to opis, a nie dowód.

Zablokowana opcja ucieczki ma takie samo znaczenie jak ścisłe zasady. Jeśli jedyne możliwości agenta to sukces lub porażka, znajduje się on pod presją, by wymyślić sukces. Nadanie mu legalnego trzeciego stanu znacznie zmniejsza tę presję.

Audyt audytorów: wersja 2.1.0

Narzędzie do sprawdzania treści wstępnej dodane podczas procesu wzmacniania bezpieczeństwa odkryło dwie umiejętności, których opisy w formacie YAML nie mogły zostać przetłumaczone bez żadnego błędu. bgpdd-verify nigdy nie zostało zarejestrowane od dnia premiery, a doubt-driven-development nie zostało zarejestrowane ani razu od początkowego komitowania. Zanim pojawiło się to narzędzie, pełny audyt wtyczki dał pozytywny wynik we wszystkich osiemnastu wskaźnikach.

Poprawki w tej wersji eliminują różnice pomiędzy tym, co kontrola wydawała się weryfikować, a tym, co faktycznie weryfikowała:

• Wszystkie audyty teraz rozpoczynają się od uruchomienia narzędzia do sprawdzania kodu – pliki są analizowane przed przeczytaniem jakiegokolwiek tekstu.
• Zapisy w księdze rejestru są teraz powiązane za pomocą hasha, dzięki czemu można wykryć dodawanie, edycję lub usuwanie zapisów.
• Oznaczanie etapu jako ukończonego odbywa się teraz poprzez napisanie skryptu, zamiast wpisywania trzech znaków przez model.
• Klient sondy zapisany w pliku zrzutu musi pochodzić z listy dozwolonych prawdziwych klientów.
• Dowód na wyświetloną interfejs użytkownika musi teraz stanowić rzeczywisty obrazek: niepusty, zawierający właściwe bajty specjalne i nowszy od zmienionych plików. Takie rozwiązanie pojawiło się po tym, jak odkryto, że plik screenshot.png o rozmiarze zero bajtów spełniał dawne wymagania.
• Tekst werdyktu pojawiający się w przykładzie zamkniętym w tagach lub pod nagłówkiem dodatku jest ignorowany przy określaniu wyniku przeglądu. Wcześniej blok ilustracyjny potajemnie zastępował prawdziwy wniosek o zmiany.

Przypadek z zrzutem ekranu jest dobrym przypomnieniem, że agenci optymalizują działania pod kątem tego, co dokładnie sprawdza dana procedura. Jeśli procedura polega na sprawdzeniu „czy istnieje plik o tej nazwie”, w końcu pojawi się plik o rozmiarze zero bajtów.

Szlak naprawy błędów oparty na udokumentowanych dowodach

Początkowo komenda do naprawy błędów przez pojedynczego agenta zachowywała się jak pośpieszny programista: czytał kod, go zmieniał, coś uruchamiał i zapisywał zmiany. Podczas pierwszej pełnej oceny naprawa została zapisana aż siedemnaście minut przed uruchomieniem jakiegokolwiek bramy kontrolnej.

Wersja 2.2.1 przekształciła ten szlak w sześć faz z bramą kontrolną pomiędzy każdą z nich:

• Raport o błędzie, który musi przejść weryfikację.
• Zapis RED wykonany przez testera przed jakąkolwiek zmianą w kodzie, aby udokumentować problem.
• Krok routingu, decydowany przez skrypt, a nie przez model, który wybiera szybką ścieżkę, pełną ścieżkę lub eskalację do działu planowania.

Sama poprawka.

Zdjęcie w kolorze ZIELONYM tego samego polecenia, zweryfikowane przez skrypt wymagający, aby oba zrzuty zawierały elementy sidecar, ten sam argv, niezerowy kod wyjścia dla koloru CZERWONY, zerowy kod wyjścia dla ZIELONEGO oraz to, by wersja ZIELONA była nowsza.

Nowy recenzent, a następnie brama komitowania.

W przypadku błędów niestabilnych ścieżka może wymagać N prób w kolorze ZIELONYM przeprowadzonych przez N różnych procesów, ponieważ cztery udane próby z pięciu nie oznaczają, że błąd został naprawiony. Ponadto narzędzie budujące w ogóle nie ma możliwości dokonania komitowania.

Ścieżki dla małych zmian

Do wersji 2.3.0 plugin dobrze radził sobie z dużymi projektami, ale nie miał żadnych rozwiązań dla małych zmian. Przenoszenie nazw, modyfikacje konfiguracji czy dodanie jednego testu nie miały przypisanej ścieżki, więc ludzie wykonywali je ręcznie, a dyscyplina znikała dokładnie w tym stopniu, gdy błędy łatwo umykać uwadze.

Dodatkowe elementy:

• /bg – brama wejściowa, która klasyfikuje każdą prośbę i kieruje ją dokładnie do jednego kanału.
• /bgpdd-quick – do zmian dotyczących mniej niż trzech plików. Nie tworzy żadnych agentów; prosi o krótką notatkę składającą się z trzech wierszy, przechwytuje jeden check i kończy proces bramą, która realizuje commit.
• Hook sesji zawsze aktywnej, dzięki któremu zwykła sesja czatowa wie o istnieniu kanałów.
• Pakiet do przeglądania: recenzent otrzymuje sam diff, zrenderowany i sp hashed, zamiast ścieżek plików do przeglądania w drzewie roboczym, gdzie poprawka już wygląda jak status quo, a usunięty wiersz jest niewidoczny.

Ostatni punkt jest przydatny nawet bez agentów. Przeglądanie plików w ich końcowym stanie ukrywa to, co się zmieniło; przeglądanie diff pokazuje to.

Wykorzystywanie audytów do znajdowania następnej bramy

Wersja 2.4.0 powstała w wyniku audytu metryk wersji 2.3 trwającego 21 dni, podczas którego zidentyfikowano sześć problematycznych metryk. Dwa przykłady: agenty bezpieczeństwa i uruchamiania nadal mogły oznaczyć wynik sprawdzenia jako „PASS” bez żadnych dowodów potwierdzających, a także nie porównano kodu wyjścia z treścią zapisu z kodem wyjścia z pliku sidecar. Nawet przykładowy plik integracyjny tego pluginu zawierał zapis, w którym data pliku sidecar różniła się od daty głównego pliku o 223 dni.

Poprawki łączą twierdzenia z plikami. Każda przeprowadzona w tych raportach weryfikacja teraz podaje nazwę swojego zapisu, którego plik towarzyszący musi być obecny, mieć spójny hash oraz odpowiadać kodowi wyjścia podanemu w danej linii. Każdy element przetwarzający taki zapis porównuje również jego treść z plikiem towarzyszącym. Rejestr blokerów otrzymał ustrukturyzowany schemat zawierający informacje o stopniu powagi i zakresie etapu. Zespół zmierzył również koszt wykonywania oceny triggera – w tym czasie wynosił on około 1,77 dolarów i 250 sekund na jedno uruchomienie – i użył tej wartości do określenia częstotliwości ich wykonywania.

Późniejsza audytacja wersji 2.6.0 wykorzystała dziewięć obiektywów oraz te same 21 metryk i potwierdziła istnienie 23 blokerów, z których wszystkie zostały usunięte w wersji 2.6.1. Dwa z nich wyróżniają się szczególnie. Proces weryfikacji pochodzenia dowodów nie powiódł się: twórca i osoba przeglądająca dzielili się tym samym katalogiem dowodów, więc przegląd, który nie dał żadnych rezultatów, mógł odnosić się do zrzutu ekranu twórcy. Ponadto w środowisku bez narzędzi przeglądarki utknął jeden z etapów interfejsu użytkownika – nie był w stanie spełnić wymagań, a system odrzucił jedyną alternatywę, jaką była ocena samego kodu źródłowego.

The fixes split evidence directories by producer, made UI milestones stop and ask the user when no browser is available instead of looping, and insisted, without exceptions, that a capture match the command its note says was executed. Wake-up payloads were slimmed by moving rationale out of the core persona text into references, without losing any rules. The changelog also gained a "Known, not fixed" section, because a commit gate that would accept an entirely forged evidence base is a limit that should be documented rather than hidden.

From checking afterwards to refusing beforehand

Up to release 2.5.0 every gate ran after the fact, and the model still decided whether to run it. A rule like "do not commit by hand while a lane is active" can still be read and ignored.

Odpowiedzią był hook PreToolUse, który blokuje wywołania narzędzi przed ich wykonaniem. Odrzuca on:

• ręczne wywołanie git commit, gdy jakaś ścieżka jest aktywna
• modyfikację istniejącego już pliku testowego w trakcie naprawy błędu
• uruchomienie subagenta, dopóki dane wejściowe nie zostaną jeszcze przetworzone
• ręczne zmiany w dowolnym pliku generowanym przez mechanizm kontrolny

Aby określić, czy ścieżka jest aktywna, hook sprawdza pliki stanu na dysku i uznaje je za aktualne przez 12 godzin; nigdy nie ufa temu, co model mówi o swoim własnym stanie. Ponadto zakończa działanie przy każdym błędzie wewnętrznym. To celowe kompromis: zabezpieczenie, które przerywa sesje, zostanie usunięte, a usunięte zabezpieczenie niczego nie egzekwuje.

W tym wydaniu dodano również sterownik, który uruchamia następny obowiązkowy krok zamiast polegać na Orchestratorze, który ma go pamiętać, oraz walidator do przenoszenia obowiązków między agentami. Walidator sprawdza, czy istnieją wymienione ścieżki, czy pliki wskazane jako zmienione faktycznie znajdują się w raporcie różnic, oraz zaznacza sprzeczności, takie jak status BLOCKED obok wiersza z informacją o przeszkodach, który podaje „None”.

Zarządzanie pracą pomiędzy funkcjami

Przed wersją 2.6.0 kilka typów rutynowych zadań inżynieryjnych w ogóle nie miało żadnej metodologii, między innymi aktualizacja zależności, wprowadzanie flag funkcji, tworzenie zadań w tle, dodawanie możliwości obserwacji oraz zmiana umów API. Agenci radzili sobie z nimi improwizując. Zespół szybkiego rozwoju również zgadywał komendy testowe projektu.

W tym wydaniu dodano pięć umiejętności dotyczących tych obszarów, z których każda ma umowę realizacji oraz ocenę sprawdzającą tę umowę. Detektor stosu proponuje teraz polecenie sprawdzenia oraz zamrożone elementy testowe z repozytorium, a osoba je potwierdza zamiast tego, by ścieżka wybierała je automatycznie. W przypadku kamieni milowych API brama komitów wykonywa również porównanie w formacie OpenAPI, co oznacza, że zmiana zakłócająca funkcjonowanie nie może zostać przyjęta bez pisemnego uzasadnienia. Gdy wybór projektowy dotyczył co najmniej dwóch opcji, konieczny jest dokument ADR, a narzędzie lint sprawdza, czy rejestr projektów na niego odwołuje się. Wreszcie każda metodologia otrzymała „Kartę szybką”: pięć zasad istotnych przy zmianach w trzech lub mniej plikach, z których każda odnosi się do odpowiedniego rozdziału, dzięki czemu szybka ścieżka może załadować krótką kartę zamiast całej umowy.

Zmienianie nawyków, zanim staną się one nieodłączną częścią codzienności

Wersja 2.6.2 powstała po prawdziwej walce. Quinn został ponownie przydzielony do rozwiązania tego samego problemu środowiskowego cztery razy, co kosztowało około 1,2 miliona tokenów. Przekaz z oznaczeniem COMPLETE wskazywał na artefakt wciąż pełen znaczników TODO. Ponadto ponowne uruchomienie istniejącego agenta byłoby rejestrowane jako zupełnie nowe zadanie, co powodowało zwiększenie ilości danych w dzienniku wykonywania.

Proces uczenia się wyodrębnił trzy lekcje i przekształcił każdą z nich w warunek przed jej zapisaniem. Przekaz, którego artefakt nadal zawiera tymczasowe elementy, teraz nie przechodzi weryfikacji. Ponowne uruchomienie jest rejestrowane jako taka sama czynność. A gdy przeszkodą jest coś, co może rozwiązać tylko człowiek – na przykład brak uprawnień lub usługa odmawiająca uruchomienia – proces zostaje zatrzymany i może być wznowiony tylko na podstawie wyraźnego polecenia wydanego przez osobę. To właśnie to zatrzymanie mogłoby uratować większość tych 1,2 miliona tokenów.

Złapanie testów, które same się testują

Wersja 2.7.0 rozwiązała jeden z najbardziej niepokojących problemów stwierdzonych podczas testowania. W rzeczywistym projekcie trzynaście z dwudziestu specyfikacji Playwright wygenerowanych przez poszczególne ścieżki testowe okazało się fałszywych. Takie specyfikacje ponownie implementowały testowaną funkcję, bezpośrednio lub wewnątrz wywołania page.evaluate, a następnie sprawdzały ją w odniesieniu do własnej kopii. Taki test za każdym razem bez trudu zmienia kolor z czerwonego na zielony, a mechanizm monitorowania kolorów nie jest w stanie tego wykryć, ponieważ ta tautologia przechodzi oba etapy testu.

check_test_authenticity.py jest teraz uruchamiany przy każdym zarejestrowanym wyniku czerwonym we wszystkich ścieżkach, które tworzą testy. Program szuka czterech typów fałszywych specyfikacji:

• specyfikacja, która nie importuje nic z kodu produkcyjnego
• wewnętrzna ponowna implementacja testowanej funkcji
• wykonanie kodu źródłowego bezpośrednio w specyfikacji
• syntetyczny DOM zastępujący prawdziwą aplikację

Po kalibracji względem tego rzeczywistego zestawu testowego odrzuca dokładnie trzynaście fałszywych specyfikacji, a przyjmuje siedem prawdziwych, bez konieczności hardkodowania żadnych nazw plików. Metodyka testowania obejmuje również tak zwaną próbę usunięcia: jeśli test nadal przepada po usunięciu kodu produkcyjnego, który rzekomo ma testować, jest to krytyczne stwierdzenie. Jest to szybka weryfikacja umysłowa, którą można zastosować do każdego testu, napisanego ręcznie lub nie; nasz artykuł o antypatronom w testowaniu React omawia powiązane sposoby, w których takie zestawy testowe dają fałszywe poczucie pewności.

Lekcje z innego narzędzia do przeglądania kodu

Dla wersji 2.7.1 administratorzy przeanalizowali system otwartych recenzji kodu firmy Alibaba, który według doniesień osiąga dokładność około 34% w publicznych testach porównawczych, w porównaniu z od 7 do 16% przy recenzjach dokonywanych przez Claude Code bez dodatkowych narzędzi, przy użyciu identycznych modeli. Należy traktować te wartości jako interpretację projektu danego standardu w tym czasie, a nie jako niezależny wynik. Interesującym spostrzeżeniem było to, że obie metody oceny były niemal identyczne. Różnica polegała na strukturze: zamrożonej liście plików, które muszą zostać uwzględnione, plikach generowanych usuwanych przed tym, jak recenzent zobaczy różnice, limicie rozmiaru oraz etapie weryfikacji faktów, który może odrzucić stwierdzenie tylko z jednego z dwóch określonych powodów.

Dwa incydenty związane z eval trafiły do tej samej wersji oprogramowania. Test bezinterfejsowy z brakiem repozytorium git w swoich plikach konfiguracyjnych szukał go na całym komputerze i sprawdzał rzeczywisty system śledzenia błędów. Ponadto jedna sesja naprawy błędów z użyciem pluginów kosztowała 11,06 dolarów, a mimo to nie powstał żaden test zdolny do wykrycia błędów w wersji uszkodzonej, co oznacza, że nikt by nie zauważył odwołania tej naprawy.

Wynikowe zmiany:

• Brama komitów odrzuca zatwierdzenie, jeśli w sekcji recenzji pojawi się jakikolwiek nierozwiązany błąd krytyczny lub ważny. W praktyce werdykt jest obliczany na podstawie tych błędów, a regularny wyrażenie potwierdza to obliczenie.
• Bez dedykowanej linii recenzji dla każdego pliku w różnicy, komit jest odrzucany.
• Pakiet recenzji usuwa pliki lockfile, skompresowane pliki oraz pliki wygenerowane na dowolnej głębokości, wymienia to, co usunął, i odrzuca różnice przekraczające 1500 wierszy, chyba że osoba odpowiedzialna napisze oświadczenie o zrzeczeniu się tego wymogu.

Każde briefing pracownika w bezgłowym środowisku testowym teraz powtarza wprowadzenie dotyczące zakresu, a mechanizm bezpieczeństwa izoluje każdy proces, który wykracza poza jego przestrzeń roboczą.

W ocenach wyników dodano nowy kryterium: naprawa liczy się tylko wtedy, gdy jest dostarczona wraz z testem regresji, który wyświetliłby błąd w przypadku cofnięcia tej naprawy.

Audyt zmian wykrył pięć zatwierdzonych komitetów bez żadnej wpisy, które zostały zamknięte.

Porównanie nie było jednostronne. Dokumenty z 51 reguł językowych drugiego narzędzia nie zawierały żadnych informacji dotyczących C#, Vue, PowerShell czy SQL – w tych przypadkach stosuje się ogólny wykaz sprawdzania, a to dokładnie te technologie obejmują umiejętności tego pluginu.

Po ponownym przeczytaniu w sekcji 2.7.2 powstały trzy zasady precyzji, dodane przed tym, jak jakakolwiek awaria zażądała ich stosowania. Przeglądający może przeczytać dowolny plik w celu uzyskania kontekstu, ale ustalenia dotyczą wyłącznie plików będących częścią spakowanego diffu; obserwacje dotyczące innych plików stają się adnotacją poza zakresem działania Orchestratora. Metodologia baz danych otrzymała zasadę dotyczącą unikania niepotrzebnych raportów, zawierającą wyraźną listę rzeczy, których nigdy nie należy zgłaszać, takich jak parametryzowane powiązania i statyczne wyrażenia, ponieważ fałszywe ustalenia wobec poprawnego kodu skłaniają przeglądających do pomijania prawdziwych problemów. Metodologia bezpieczeństwa wymaga teraz struktury składającej się z pięciu sekcji dla dokumentów bezpieczeństwa, a każda z kategorii OWASP musi zawierać albo odniesienie, albo uzasadnioną odpowiedź „Nie ma zastosowania”, ponieważ pozostawienie wiersza pustego nie stanowi werdyktu.

Sytuacja projektu

W chwili pisania tego tekstu plugin posiada 16 postaci agentów, 45 umiejętności oraz 32 skrypty kontrolne, w tym 1 656 samotestów. Wszystkie te skrypty są deterministyczne i nie wykorzystują żadnych wezwań do modeli językowych, a wszystkie są uruchamiane przed każdym wydaniem. Zbiór testów obejmuje 69 przypadków rozłożonych na cztery poziomy; poziom wyników porównuje działanie z pluginem włączonym i wyłączonym na podstawie ukrytych testów, zamiast sprawdzać, czy aktywowano konkretną ścieżkę. Od pierwszego tagu 119 komitetów dodało około 67 000 linii kodu.

Metryką, o której twórcy mówią, że naprawdę im zależy, nie jest żadna z tych wymienionych. Chodzi o liczbę reguł, które nadal są sformułowane w prozie i proszą model o powstrzymanie się w momencie, gdy najbardziej chce kontynuować. Ta liczba maleje z każdym wydaniem, a każde zmniejszenie wynika z jakiegoś błędu zaobserwowanego podczas aktywności danej reguły.

Główne wnioski

• Traktuj zasadę, której naruszono w czasie jej obowiązywania, jako zgłoszenie błędu dotyczącego tej zasady i napraw ją za pomocą bramy kontrolnej, a nie silniejszych sformułowań.
• Pozwól skryptom na wykonywanie nieodwracalnych działań, takich jak komitowanie, aby pominięcie sprawdzenia pozostawiało widoczną brakującą informację zamiast bezgłośnego przejścia.
• Zdefiniuj poziomy dowodów i wymagaj zapisanego, haszowanego wyniku wykonywania poleceń zamiast zdania mówiącego „sprawdzone”.
• Daj agentom prawomocny wynik BLOCKED, aby wymyślanie wyniku PASS nigdy nie było najłatwiejszą drogą.
• Dowódź poprawności każdej bramy kontrolnej, obserwując jej niepowodzenie przy celowym naruszeniu zasad, oraz przeprowadź audyt samych bram, ponieważ sprawdzenia często sprowadzają się do weryfikacji nazw i obecności plików.
• Zablokuj niebezpieczne wywołania narzędzi przed ich uruchomieniem, ale ustaw zabezpieczenia tak, aby mogły zostać ominięte, by nikt nie miał pokusy ich usunięcia.

Zastosuj test usuwania do wygenerowanych testów: jeśli usunięcie kodu produkcyjnego nie spowoduje awarii testu, ten test jest bezwartościowy.

Metoda polega na pętli: obserwuj jedno uruchomienie, znajdź instrukcję, która została zignorowana, zastąp ją czymś, co musi zostać wykonywane lub otwarte, a następnie obserwuj kolejne uruchomienie.

Literatura pokrewna

• Gdzie należą instrukcje Claude Code: CLAUDE.md, reguły path lub hooki — Dowiedz się, dlaczego Claude Code traktuje CLAUDE.md jako kontekst, jak go skrócić, jak ograniczyć zasady do określonych ścieżek, jak przenieść kroki wymagające wykonywania do hooki oraz jak sprawdzić, co faktycznie zostało załadowane.
• Praktyczny przewodnik po stworzeniu skutecznego pliku CLAUDE.md — Poznaj 21 konkretnych, sprawdzalnych zasad służących do uproszczenia rozbudowanego pliku CLAUDE.md, aby Claude Code pozostał niezawodny, przewidywalny i godny zaufania podczas długich sesji.
• Nauka używania Claude Code do konfiguracji routingu w monorepo NestJS: zasady i umiejętności — Jak skonfigurować plik CLAUDE.md, zasady, umiejętności oraz uprawnienia, aby Claude Code umieszczał kod we właściwej usłudze NestJS i przestrzegał konwencji zespołu.
• Wdrażanie reguł agenta w kodzie: PreToolUse, PostToolUse i Stop Hooks — Dowiedz się, dlaczego autoryzacja agentów LLM powinna znajdować się w deterministycznych hookach do wywoływania narzędzi, jak bezpiecznie odrzucać żądania oraz jak otoczyć dispatcher bez użycia rekurencji.