UCP-08 Çözümlendi: Satıcıların Geliştiriciyle Tartışması Gereken 14 Kırıcı Değişiklik

UCP 2026-08 (spec version string 2026-08-07) küçük bir güncelleme değildir. Nisan ile Ağustos 2026 arasında 40 katılımcıdan gelen 142 commit içinde 88 iyileştirme getirdi ve bunlardan 14'ü kırıcı olarak işaretlendi. Mağazanız yapay zeka ajanlarını, bölünmüş ödemeleri veya değişken ağırlıklı ürünleri kullanıyorsa, bu PR'lardan en az biri geliştiriciniz bunu zaten düzeltmedikçe mevcut yapınızda bir şeyleri kıracaktır.

Temel çıkarımlar

• 2026-08 sürümünde 14 kırıcı değişiklik; yanında 24 yeni özellik.
• En büyük yapısal değişiklikler kimlik alanında (ajan kimlik doğrulaması artık imza tabanlı), birimler (her miktar artık bir tam sayı artı bildirilen ölçek) ve ödemeler (bölünmüş ödemeler ve ödeme koşulları yeni temel unsurlar) alanlarında.
• Politikalar artık birleştirme yoluyla değil JSONPath özgüllüğü ile çözülüyor; çakışan kurallar çoğu geliştirici tarafından beklenenden farklı davranıyor.
• Kalıcı bağlantılar tasarım gereği durumsuz; continue_to bir tercih, güvenilir alışveriş durumu değil.
• Geliştiricinizin ödeme sayfasına dokunmadan önce kaynak materyale ihtiyacı var, sonra değil.

Sekiz bölge: spec aslında neyi organize ediyor

UCP 2026-08 yüzeyini sekiz adlandırılmış alana ayırıyor. Bu isimleri bilmek geliştiricinizle muğlak bir konuşma yerine yararlı bir konuşma yapmanıza yardımcı olur.

Her bölgenin kendine ait kırıcı PR'ları var. Agentic akışları çalıştıran satıcılar için en önemli olanlar Güven Mahallesi, Para Değiştiricisi ve Tartı Evi.

Kırıcı değişiklik grubu 1: kimlik (Güven Mahallesi)

Geliştiriciniz sürüm notlarını okumadıysa yapay zeka ajanı entegrasyonunu sessizce kıracak alanlardır.

Alıcı kimlik doğrulaması OAuth RFC 8693 ve RFC 7523'e business_schema profili ile kaydı (PR #354, 2026-05-05 tarihinde kırıcı şekilde birleşti; takip eden PR #423 2026-06-12 tarihinde birleşti). Pratik etki: ajanlar artık tarayıcı yönlendirmesi olmadan kimliği zincirleyebiliyor. Spec'in kullandığı kapsam örneği dev.ucp.shopping.checkout:manage dir. Mevcut ajan akışınız yönlendirme tabanlı bir kimlik doğrulama döngüsüne güveniyorsa, burada kırılır.

Ajan kimlik doğrulaması artık RFC 9421 ve Web Bot Auth tabanlı (PR #483 2026-07-03 tarihinde birleşti; PR #566 2026-07-12 tarihinde kırıcı şekilde birleşti). Ajanın UCP profili artık geçerli bir JWK Set olarak çalışıyor. Bir imza UCP-Agent, Signature-Agent, gerekli bileşenler ve gövde özeti ile kapsamalı. Kanonik anahtar parmak izi tag="web-bot-auth" kuralı kullanıyor. Örnek algoritma Ed25519 (OKP, crv Ed25519). Bağlama anahtarı dev.ucp.common.identity_linking dir.

Geliştiricinize sormanız gerekenler: Ajanımızın imzalama akışı RFC 9421 için güncellendi mi? Ed25519 mı yoksa başka bir OKP eğrisi mi kullanıyor ve JWK Set'i UCP profiline karşı yeniden kaydettik mi?

Kırıcı değişiklik grubu 2: birimler ve miktarlar (Tartı Evi)

PR #653 2026-08-12 tarihinde kırıcı şekilde birleşti. Bu sürümdeki en kavramsal olarak farklı değişiklik ve doğru şekilde işlenmezse sessiz fiyatlandırma hatalarına en çok sebep olacak olanı.

Yeni quantity_unit şekli { unit, scale, increment? } dir. Kritik kural: miktar adımları sayar, birimleri değil. 2 ölçeğine sahip 150 değeri, 150 lb değil 1.50 lb anlamına geliyor.

Unit alanı uygun olduğunda UN/CEFACT Rec 20 kodlarını kullanıyor. Pound LBR dir. Hiçbir standart kod uygun değilse, kendinizinkini tanımlayabilirsiniz. display_text alanı alıcılara gösterilen etiketi tutuyor (örneğin, "lb"). increment alanı yalnızca danışmanlık amaçlıdır ve asla bir sınır olarak hareket etmez.

Her tel üzerindeki sayı, bildirilen bir yorumlamaya sahip tam sayıdır. Spec açık: 120 USD centi anlamına geliyor; 150 pound yüzdeleri anlamına geliyor. Sürümdeki çalışılmış örnek: 80 çarpı (pound başına sent) 2 ölçeğinde 150 adım tarafından çarpılmış 120 sent veya 1,20 dolar eşittir, yuvarlama yok ve aritmetikte ondalık yok. Kısmi gönderiler aynı şekilde çalışıyor: 0,50 göndersene, 0,25 iade ettikçe, 25 adım hala borçlusun, bu tam olarak 20 sent.

Size neden önemli: Ağırlık, hacim veya herhangi bir tam olmayan birim satıyorsanız ve geliştiriciniz miktar mantığını güncellememişse, fiyatlarınız yanlış hesaplanacak. Bu görüntü hatası değil; fatura hatası.

Kırıcı değişiklik grubu 3: ödeme temelleri (Para Değiştiricisi)

Bu sürümde iki yeni temel iniş yaptı:

• Bölünmüş ödemeler (PR #409, 2026-05-23 tarihinde birleşti): yeni şekil allowed_combinations -> payment.instruments[] -> payment.instruments[].amount dir. Alıcılar artık işletmenin açıkça izin verdiği yollarla araçları birleştirebiliyor. Ödeme sayfanız allowed_combinations bildirmiyorsa, bölünmüş ödeme denemeleri başarısız olacak veya öngörülemeyen şekilde davranacak.
• Ödeme koşulları (PR #602, 2026-08-14 tarihinde birleşti): şekil payment.terms[] -> payment.selected_term_id dir, totals[], messages[] ve payment_handlers içinde akar, alıcının kabulü payment.accepted_term içinde kaydedilir. Net-30 veya taksit tarzı koşullar artık bir geçici çözüm değil birinci sınıf temel.

3DS hakkında ayrı not: PR #458 (2026-08-04 tarihinde birleşti) dev.ucp.common.payment.three_ds_challenge eylem anahtarını formalleştiriyor. Spec'in açık olduğu 3DS yüzeyini tamamlamak ödemenin başarılı olduğunu kanıtlamıyor. Get Checkout işletmenin yetkili sonucunu döndürüyor. Bunu kısa devre yapan ve tamamlanmış bir 3DS mücadelesi olarak kabul edilen geliştirici gerçek para hatası sunuyor.

Politikalar: geliştiricinizin bilmesi gereken özgüllük kuralı

Politika Forumu (PR #572, 2026-07-23 tarihinde birleşti) policies[] öğesini [{ type, description, applies_to? }] olarak sunuyor. applies_to alanı JSONPath kullanıyor. Atlanırsa, politika tüm yanıta uygulanıyor.

Geliştiriciyi takılı bırakan kural: aynı türde iki politika çakıştığında, daha spesifik hedef daha geniş olanı değiştiriyor. Platformlar asla politika gövdelerini birleştirmiyor. Bu bir birleştirme değil bir değiştirmedir. İade politikanız (dev.ucp.shopping.policy.return) geniş bir şekilde tanımlanmış ve sonra ürün kategorisi için daha dar bir kural eklenmişse, dar kural o kategori içindeki öğeler için tamamen kazanıyor. Geniş kural kısmi olarak uygulanmıyor.

Kalıcı bağlantılar: tasarım gereği durumsuz

PR #523 2026-07-17 tarihinde birleşti. Anahtar dev.ucp.shopping.permalink dir, şekil {endpoint}/{items}?{field_paths} dir ve tam olarak bir kontrol parametresi vardır: continue_to.

Tasarım ilkesi açık: kalıcı bağlantılar kendi alışveriş durumu alanları yok. continue_to güvenilmeyen aynı orijin yolu tercihi. İşletme bunu doğruluyor ve kanonikalleştiriyor. Asla alışveriş durumu değil. Bu bağlantılar e-posta, SMS, sosyal, reklamlar, açılış sayfaları, baskı, ambalaj ve QR kodlar arasında durum çatışmaları oluşturmadan seyahat etmek için tasarlandı.

Bu bölgeyi etkileyen iki sonraki kırıcı giriş: PR #589 (2026-08-25 tarihinde kırıcı şekilde birleşti) ve PR #688 (2026-08-18 tarihinde kırıcı şekilde birleşti). Takımınız bu tarihlerden önce kalıcı bağlantı mantığı oluşturmuşsa, yeniden kontrol edilmesi gerekiyor.

İşlemler: yeni görev devir modeli

PR #582 2026-07-22 tarihinde birleşti. Şekil actions[<type>] -> [{ id, config? }] dir. Model sorumlulukların temiz bir ayrılması: uzantı engelleyici işi adlandırıyor ve platform sonra ne olacağını tanımlayan yapılandırılmış bir görev hand yapıyor. Uzantı işleme ve geri döndürmeye sahip; ebeveyn yetenek yaşam döngüsüne sahip.

Satıcılar için bu önemli çünkü daha önce işlemleri satırda çözen agentic akışları yeniden yapılandırılması gerekebiliyor. Bir ajan 3DS mücadelesi, politika kapısı veya kimlik adımı vurursa, eylem yüzeyi bu devir resmi yapıldığı yer.

Satıcılar için pratik briefing kontrol listesi

Sonraki geliştirici sprintinizden önce aşağıdaki öğelerin ele alındığını doğrulayın:

• [ ] Alıcı kimlik akışı RFC 8693 / RFC 7523 ve business_schema profili için güncellendi (PR #354)
• [ ] Ajan imzalama RFC 9421, Ed25519 ve tag="web-bot-auth" için güncellendi (PR #566)
• [ ] Tüm miktar alanları quantity_unit tam sayı-artı-ölçek modeline taşındı (PR #653)
• [ ] allowed_combinations bölünmüş ödemeler sunuluyorsa bildirdi (PR #409)
• [ ] Ödeme koşulları şekli (payment.terms[], payment.accepted_term) ertelenmiş ödeme kullanıyorsa uygulandı (PR #602)
• [ ] 3DS mücadelesi eylemi ödeme doğrulaması değil sinyal olarak davranıyor (PR #458)
• [ ] Politika applies_to JSONPath çakışma ve özgüllük için incelendi (PR #572)
• [ ] Kalıcı bağlantı continue_to güvenilmez olarak davranıyor; post-PR #589 ve #688 değişiklikleri uygulandı

Her RFC'yi anlamak için bilmeniz gerekmez. Listeyi geliştiricinize verip hangi öğelerin tamamlandığını, devam ettiğini veya başlanmadığını sorabiliyor olmanız gerekir.

Bu ne kadar iş?

Dürüst cevap mevcut yapınıza bağlıdır. Henüz herhangi bir agentic özelliği uygulamayan bir mağaza, değişken ağırlıklı ürünler satıyorsa sadece miktar birim değişikliğini ele almak zorunda kalabilir ve ilk olarak ajan eklediğinde kimlik değişiklikleri. Bölünmüş ödemeler, ajan odaklı sepet doldurma ve ağırlık tabanlı fiyatlandırmayla özel bir ödeme sayfası uzantısı olan bir mağaza, üç bölge arasında anlamlı bir sprint'i göz önüne alıyor olabilir.

Mevcut Shopify geliştiricinizin bu sürümde doğru bir şekilde gezinme bilgisine sahip olup olmadığını değerlendiriyorsanız, kimlik bölümü en iyi litmus testidir. Onlardan özellikle RFC 9421'in önceki ajan kimlik doğrulama modelinden nasıl farklı olduğunu ve tag="web-bot-auth" pratikte ne anlama geldiğini sorun. Cevap hızlı bir şekilde spec okumuş mu yoksa tahmini yapıyor mu olduğunu söyleyecek.

Shopify Plus üzerinde agentic ödeme sayfası akışları çalıştıran mağazalar için bu isteğe bağlı okuma değildir. Güven Mahallesi ve Para Değiştiricisindeki kırıcı değişiklikler canlı işlem mantığını etkiliyor. Diğer satıcıların benzer spec geçişlerinde nasıl gezindiğini görmek için /case-studies bölümüne bakın.

UCP 2026-08'i tamamen okumamış ve işi özel olarak kapsayabilen geliştirici istiyorsanız, /hire adresinde iletişime geçin.