Alerty, które milczą, i granice między agentami

Dziś poszło 11 commitów w repozytorium agent-brain. Trzy wątki splotły się w jeden dzień: higiena alertów, granice uprawnień per agent i planer sprzedaży w funkcji Engineering Lab & DevLog.

Problem: alert, który krzyczy bez powodu, przestaje być alertem

Trzy rzeczy bolały równocześnie. Kanał powiadomień zamieniał się w strumień komunikatów, które wyglądały pilnie, ale nie wymagały żadnej decyzji ani poprawki. Gateway raportował restart, którego nie było, bo usługa startowała wolniej niż próg alertu. Licznik błędów pokazywał 113 pozycji, a wśród nich mieszały się prawdziwe awarie z odmowami sandboxa, które są dowodem, że guardrail działa poprawnie. Do tego agenci dostawali zbyt szeroką powierzchnię: pełny zestaw narzędzi deweloperskich i brak twardo zadeklarowanego katalogu domowego. Jeden agent mógł sięgnąć po pliki należące do innego.

Osobno bolała promocja umiejętności: nowa paczka mogła po cichu nadpisać istniejącą, jeśli nikt nie sprawdził kolizji nazw.

Co zrobiłem:

• Wyciszyłem rutynowe powiadomienia gateway (a24359e) i skonfigurowałem progi zysku dla alertów (064a233).
• Wyciąłem fałszywe alerty o restarcie gateway (8483243) i przyznałem usłudze okres łaski na starcie (efcdbf9).
• Dodałem interaktywny planer sprzedaży do funkcji Engineering Lab & DevLog (4ca8d8b).
• Ograniczyłem promocję do wyłącznie zweryfikowanych paczek umiejętności (8534e34) i dopisałem test potwierdzający działanie detekcji kolizji (f8cd4af).
• Skonsolidowałem umiejętność study-pack (b841734), usunąłem zmigrowane notatki narzędziowe (b2bd676), dodałem test odmawiający dostępu do narzędzia process (2e46cb3) i wymusiłem granice workspace oraz zestawu narzędzi (823916f).
• Zbadałem 113 błędów gateway. Próbki to odmowy wyjścia ze sandboxa, czyli listowanie poza dozwolonym rootem workshop-skills, oraz powtarzające się komunikaty MCP doctor found errors, które wciąż czekają na znalezienie przyczyny.
• Sprawdziłem warstwę jakości: skaner liści zwalidował plik 492 fiszek jako poprawny JSON i przeskanował 109, 96 oraz 113 plików u trzech agentów, nie znajdując obcych markerów. Weryfikator pamięci wykonał 12 cykli na 2 zapisanych rekordach i naprawił 0. Quiz watchdog zapisał przebieg 9 sekund i słusznie milczał w dniu bez zaplanowanych słów. Signal guardian zaraportował 12 kolejnych czystych pięciominutowych okien.
• Wszystkie zaplanowane monitory domknęły swoje okna z zerem błędów crona i zerem auto-napraw.

Dlaczego to ważne (Use Case):

Kanał alertów ma sens tylko wtedy, gdy każde jego wystąpienie wymaga decyzji albo naprawy. Wyciszenie trzech kategorii fałszywych trafień dało więcej niż jakikolwiek nowy monitoring: prawdziwa awaria nie tonie w szumie, a osoba czytająca powiadomienia nie uczy się ich ignorować. Wolny start usługi przestaje być raportowany jako awaria, więc deklaracja niezawodności opiera się na uczciwym sygnale.

Granice per agent zamieniają uprawnienia z założenia w sprawdzalny fakt: agent pracuje w zadeklarowanym katalogu z zadeklarowanym zestawem narzędzi, a test na odmowę dostępu do procesu pilnuje tego automatycznie. Wykryta kolizja nazw to mała poprawka, natomiast niezauważone nadpisanie potrafi zepsuć działającą funkcję na dni. Planer sprzedaży pozwala zobaczyć wynik decyzji przed jej podjęciem, zamiast liczyć z pamięci.

Czego się nauczyłem:

1. Błąd w liczniku to nie zawsze awaria. Odmowa sandboxa blokująca odczyt poza dozwolonym zakresem jest sukcesem guardraila, a liczenie jej jako porażki ukrywa ten jeden prawdziwy problem.
2. Cisza bywa poprawnym wynikiem. Monitor, który odróżnia brak pracy od awarii, zostaje włączony na stałe. Wpis "sprawdzone, nic nie znaleziono" ma wartość, bo potwierdza, że zadanie w ogóle wystartowało.
3. Weryfikacja jako warunek promocji, nie opcjonalny krok, zmienia "zwykle pamiętam o teście" w właściwość systemu.