الانتقال إلى المحتوى

BLOG / sku-md-v0-9-interoperability-conformance.mdx

SKU.md v0.9: قابلية التشغيل البيني ونطاق المطابقة والاستهلاك الآمن

ما الذي تغير في v0.9، وكيف تتم الترقية من دون تغيير تنسيق التبادل، وكيف يتشارك المدقق والمستهلك والناشر عقدًا قائمًا على الأدلة.

تاريخ النشر

إصدار المواصفة الأصلي: v0.9

SKU.md v0.9 إصدار يركز على قابلية التشغيل البيني والاتساق. لا يضيف حقلًا خاصًا بـ Shopify ولا درجة ترتيب ولا نظام Checkout ثانيًا؛ بل يحدد كيف يصرح الناشر بما فحصه، وكيف يفسر المستهلك الأدلة، وأين يجب أن يعود الطرفان إلى أنظمة التجارة الآنية.

لم يتغير تنسيق التبادل

يحافظ Schema في v0.9 على أنواع المستندات وملفات Profile والحقول والخصائص الإلزامية والقيم المعددة وقواعد التوسعة وحدود الأمان في v0.8. لذلك تظل الترقية على مستوى البيانات محدودة عمدًا.

  1. غيّر schema_version إلى sku.md/0.9-draft.
  2. غيّر عنوان Schema إلى https://sku.md/schema/sku-md/0.9/schema.json.
  3. نفّذ كل فحص إلزامي لنطاق المطابقة الذي تنوي الادعاء بتحقيقه.

يمكن للمستهلك قراءة مستندات v0.8 للتوافق، لكن لا يجوز وصفها بأنها مطابقة لـ v0.9. هوية الإصدار ودليل المطابقة ادعاءان مختلفان.

تظل المواصفة الإنجليزية الكاملة للإصدار v0.9 النص المعياري الوحيد. يفحص JSON Schema العام للإصدار v0.9 البنية، لكنه لا يصدر وحده قرار مطابقة كاملًا.

ثلاثة نطاقات للمطابقة

تسمّي v0.9 الواجهة التي فحصها المدقق فعلًا.

النطاق ما يمكن إثباته ما لا يمكن إثباته
offline_document البيانات الأمامية وYAML الآمنان، وSchema، ودلالات المستند الواحد، وتطابق Markdown تسليم HTTP أو إمكانية الوصول إلى الموارد أو سلامة الرسم البياني للأصول
published_resource عنوان URL حي واحد، بما يشمل حالة HTTP وإعادات التوجيه وMIME والعنوان الأساسي والعودة الصامتة وإمكانية الوصول اتساق عائلة المستندات كاملة
document_graph سلاسل الأصول والتمثيلات وملفات Profile الخارجية والموارد المشار إليها والاتساق بين المستندات إذن الشراء أو الدفع أو تغيير الحالة التجارية

يسجل التقرير فحوص الصياغة وSchema والدلالات والاتصال بالشبكة في طبقات منفصلة. إذا فشل فحص إلزامي فالنتيجة failed. وإذا لم يُنفذ فحص إلزامي ولم يفشل غيره فالنتيجة incomplete وليست passed.

تقرير تحقق قابل للنقل

التقرير دليل يتعلق بالمستند، وليس جزءًا من البيانات الأمامية الخاصة بـ SKU-MD. وقد يبدو تقرير ناجح لمستند جذري مولد هكذا:

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

تجعل رموز المشكلات المستقرة النتيجة قابلة للاستخدام بين الأدوات، مثل YAML_DUPLICATE_KEY وSCHEMA_VALIDATION_FAILED وCANONICAL_MISMATCH وGTIN_CHECK_DIGIT_INVALID وKNOWLEDGE_DYNAMIC_STATE_FORBIDDEN وBODY_PARITY_INVALID. ولا يجوز تحويل انتهاء مهلة الشبكة إلى نجاح.

تنشئ مولدات الموقع تقارير offline_document فقط. وبعد الرفع يظل الناشر بحاجة إلى فحوص عبر الشبكة لحالة HTTP وtext/markdown والعودة الصامتة وعناوين URL الأساسية وروابط الأصول والتمثيلات ومراجع ملفات Profile الخارجية.

سلوك Reference Consumer

يمثل Reference Consumer عقدًا سلوكيًا للقارئ، لا تنسيق تبادل جديدًا. وتسلسله الآمن هو:

  1. اكتشاف الملف الجذري الذي يستضيفه التاجر والتحقق من أصله وتمثيله.
  2. اتباع نقاط دخول Catalog والتقسيمات المعلنة من دون تخمين منتجات مخفية.
  3. اختيار Variant المطابق بدقة باستخدام معرفات مستقرة وخيارات وسوق ولغة وعنوان URL أساسي للمتغير.
  4. التمييز بين الحقائق والادعاءات والإفصاحات والإرشادات والقيود والتوافق وعناوين URL للمصادر وتواريخ التحقق.
  5. معاملة offer_snapshot بوصفها ملاحظة، واستخدام live_lookup أو live_verification لمعرفة السعر والتوافر والشحن والضرائب والمبالغ الحالية.
  6. إحالة Cart وCheckout والدفع والطلبات إلى السلطة الآنية المعلنة، مع تأكيد صريح من المستخدم.

إذا لم تكف الهوية أو الأدلة أو الحداثة أو السلطة، يجب أن يتوقف المستهلك بأمان بدل ملء الفجوة باستنتاج من نموذج.

تبقى حوكمة المصادر في طبقة الأدوات

يحتاج الناشر إلى معلومات داخلية لا ينبغي إرسالها إلى المستهلك. تستطيع Source Map خاصة تسجيل أصل كل قيمة وما إذا كانت Detected أو Derived أو Verified. ثم تقارن عملية Audit–Plan–Apply بين HTML وProduct JSON-LD وMerchant Feed وCatalog الخاص بالمنصة وSKU-MD القائم، وتُعد قائمة تغييرات قابلة للمراجعة ولا تنشر إلا بعد تأكيد بشري.

لا تدخل خرائط المصادر وسجلات المراجعة وحالة المسودة وفروق الإصدارات وسجلات المشكلات ومقاييس القنوات إلى Schema العام. وإذا فشلت إعادة بناء جزئية أو عملية تحقق عبر الشبكة، فعلى نظام التسليم الاحتفاظ بآخر إصدار صالح بدل استبداله بمخرجات ناقصة.

تعاون مع المنصة لا تكرار لها

يصف SKU-MD المعرفة المستقرة وحدود المصادر الصريحة. يظل Catalog الخاص بالمنصة المرجع المعتمد للتوزيع والسعر والتوافر الحالي، وتعالج واجهات API الآنية أو UCP/MCP الاستعلامات الحالية، ويتولى Checkout مصادقة المشتري وحساب المبالغ والدفع وإنشاء الطلب.

حتى 2026-08-01 توثق Shopify واجهات Shopify Catalog وCatalog وCart وCheckout وOrder التي تتوافق مع UCP. لكنها لا توثق أن تلك الأنظمة أو ChatGPT أو أي قناة أخرى في Shopify تقرأ SKU-MD أو تثق به. لذلك تستخدم إرشادات التكامل مؤشرات وحدودًا واضحة للسلطة بدل نسخ حالة الدفع أو الطلب.

قياس SEO وGEO وAEO دون وعود

السؤال المفيد ليس هل «يرفع ملف ثابت ترتيب AI»، بل يمكن لتجربة مضبوطة قياس:

  • دقة تحديد Variant المطابق؛
  • الاستشهاد بحقائق موثقة المصدر بدل النص التسويقي؛
  • استرجاع الإفصاحات والقيود؛
  • استخدام التحقق الآني قبل تقديم إجابة حساسة للوقت؛
  • الاتساق بين HTML وProduct JSON-LD وMerchant Feed وCatalog الخاص بالمنصة وSKU-MD.

يمكن لهذه المقاييس أن تكشف ما إذا كان عقد النشر يقلل الغموض والإجابات القديمة، لكنها لا تثبت أن زاحفًا سيجلب المستند أو أن منصة سترتب المنتج أو تستشهد به أو توصي به أو تحوله إلى عملية شراء.

تسلسل ترقية عملي

ابدأ بتحديث معرف الإصدار وإنشاء تقرير محلي. لا تنشر إلا بعد مراجعة بشرية، ثم تحقق من المورد الحي والرسم البياني للمستندات. أبقِ الحالة التجارية المتغيرة خارج طبقة المعرفة، واحتفظ بآخر مراجعة صالحة عند فشل الأتمتة، وقارن النتائج باختبارات مضبوطة لا بادعاءات اعتماد بلا دليل.

قراءة إضافية

طبّق هذه المتطلبات عمليا باتباع دليل نشر أول SKU.md