ENGINEERING DEVLOG
Codzienny zapis decyzji architektonicznych, testów systemów agentowych, postępów w Pythonie/TypeScript oraz automatycznych syntez dnia generowanych przez model Gemini z commitów w Git.
Rozdzielenie błędów dostawcy od kondycji klucza
Przeniosłem klasyfikację odpowiedzi dostawcy do reguły kodu, żeby nie mylić awarii usług z problemem klucza. Sprawdziłem też powracające błędy operacyjne i trafienia skanera.
Timer floty zapisany bez uruchomienia
Zarejestrowałem timer floty, pozostawiając jego uruchomienie do czasu zgody człowieka. Sprawdziłem też nowe wyniki powracających odmów dostępu i sygnałów monitoringu.
Powracające błędy i korekty rejestru
Sprawdziłem powtarzające się błędy autoryzacji i kontroli oraz ograniczyłem fałszywe alarmy. Zdecydowałem też, że wyłączone zadania pozostają w rejestrze z odpowiednią adnotacją.
Awaria briefingu kalendarza ukryta jako brak wydarzeń
Naprawiłem briefing kalendarza, który po błędzie importu zwracał taki sam wynik jak przy pustym dniu. Zmieniłem też obsługę błędów tak, by awaria była widoczna w logach i alarmach.
Pomiar czasu obsługi zadań w panelu
Wtyczka bramki zapisuje teraz czas obsługi każdego żądania do pliku logu. Przy okazji zmniejszyłem hałas w logach, który rósł bez ograniczeń.
Dynamiczny port autodeploy i izolacja restartu przed samozapętleniem watchdoga
Wyliczam port awaryjny autodeploy z adresu origin gita i izoluję restart w systemd-run, dzięki czemu watchdog nie wszczyna fałszywych alarmów na własnych śladach.
Cicha awaria dispatchu po nocnym reloadzie pluginów
Zszedłem ślad trzygodzinnej przerwy w działaniu bota do nocnego polecenia `plugins reload memory-core` o 03:07 i dodałem watchdog oraz obserwator reloadów, które wykrywają ten podpis i restartują proces w tle.
Pamięć agenta przez kilka nocy nie zapisywała nic, a cron mówił ok
Nocna konsolidacja pamięci przestała tworzyć pliki, mimo że zadanie zwracało sukces. Znalazłem przyczynę, przeładowałem wtyczkę i sprawdziłem, że pamięć znów działa od początku do końca.
Canary i storm guard: cooldown per problem i per sesja
Naprawiłem fałszywe alarmy canary w health_monitor.py i wzmocniłem outbound_storm_guard.py o cooldown per klucz. Kanał alarmowy milczy, gdy nic się nie dzieje, a prawdziwe incydenty nie toną w powodzi powtórzeń.
Alerty, które milczą, i granice między agentami
Wypuściłem 11 commitów w agent-brain: wyciszenie fałszywych alertów, twarde granice workspace i narzędzi dla każdego agenta oraz planer sprzedaży w Engineering Lab & DevLog.
Cztery watchery w bezczynności i dwa ciche sygnały awarii
Przepuściłem end-to-end cztery zaplanowane watchery i zebrałem dwa sygnały awarii: padnięty heartbeat cron joba oraz niestabilny odczyt SQLite w gatewayu. Sprawdziłem też, że brak aktywności w repo to prawdziwa cisza, a nie zepsuty zbierak danych.
Brakujący import time, atomowy zapis stanu i watchdog, który rozumie retry
Naprawiłem panel Telegram, który przy każdym odświeżeniu wysyłał nową wiadomość, oraz wyciszyłem fałszywe alarmy watchdoga floty dla tur, które same się wyleczyły przez retry. Zacząłem też analizować niestabilność read-only workera w gatewayu SQLite.
Dzień nadzoru floty agentów: fałszywy alarm i dwa throttlingi
Utrzymałem flotę agentów w ruchu przez cały dzień: skany wycieków, kontrola pamięci i quiz dzienny przeszły czysto, a dwa krótkie błędy limitu u dostawcy modeli obsłużyłem automatycznie, bez utraty pracy.
Weryfikator pamięci złapał 1 brakujący zapis na 372
Przeskanowałem 372 rekordy pamięci, znalazłem jeden brakujący zapis i odtworzyłem 2691 znaków w pliku dziennym. Zbadałem też nowy odcisk błędu providera, który wywołał trzy nieudane tury między 17:35 a 18:05 UTC.
Backup nie działał przez dobę, bo ktoś pomylił kolejność argumentów
Kopia zapasowa przez około dobę w ogóle się nie uruchamiała, bo wrapper w cronie źle odczytywał argumenty. Naprawiłem ją, sprawdziłem pełnym przebiegiem i dodałem zabezpieczenie.
Logi na VPS rosły bez końca. Ustawiłem limity i wyłapuję ciche błędy crona
Na małym serwerze logi zajmowały coraz więcej miejsca, a zadania w tle padały bez śladu. Ustawiłem limity, czas przechowywania i prosty wrapper, który zapisuje wynik każdego zadania.
Ślepe monitory kontekstu i zielone logi
Przepiąłem dwa monitory kontekstu na pola, które sessions API faktycznie zwraca, i dodałem strażnika schematu. Progi kompakcji 65% i 85% zaczęły działać, co potwierdziłem na żywej sesji o 06:51 UTC.
Detektor błędów tury: od cichego logu do alertu i auto-recovery
Prześledziłem błąd providera udający 'LLM request failed' i dodałem trwały detektor błędów tury z alertem oraz auto-recovery odpowiedzi. Cicha awaria stała się głośna i mierzalna.