SKU.md v0.10 × WebMCP: معرفة المنتج قبل الزيارة وإجراءات منظمة على الصفحة

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

يلتقي SKU.md v0.10 وWebMCP عند نقطة التسليم هذه من دون أن يصبحا شيئًا واحدًا. SKU.md طبقة معرفة وأدلة ينشرها التاجر. أما WebMCP فهو واجهة API لصفحة المتصفح تتيح إجراءات من الصفحة المفتوحة بالفعل أمام المستخدم. يستخدم الوكيل الجيد الأول لتكوين قصد مدعوم بالأدلة، ثم يستخدم الثاني لتنفيذ إجراء محدود ومرئي داخل الصفحة، ويعود أخيرًا إلى أنظمة التجارة الآنية لأي قرار قد تتغير قيمته.

يبدأ الشراء قبل وجود علامة تبويب

نادرًا ما يكون السؤال الأول «أي زر أضغط؟». قد يسأل المتسوق إن كان المنتج متوافقًا مع جهاز يملكه، أو إن كان ادعاء عن مادة ما مدعومًا باختبار محدد، أو إن كان تحذير لسلامة الأطفال ينطبق على إعداد معين. ينبغي أن تكون هذه الأسئلة قابلة للإجابة قبل فتح أي علامة تبويب، مع الاحتفاظ بالمصدر والنطاق وتاريخ المراجعة. ولا يكتسب سعر قديم أو وصف قديم للتوافر سلطة عرض سعر حالي لمجرد ظهوره بجوار شرح مفيد للمنتج.

هذه مهمة SKU.md v0.10. فهو يربط معرفات Product وVariant وSKU وGTIN المستقرة بالحقائق والادعاءات والإفصاحات وإرشادات التوافق والمواد المصدرية وأوقات التحقق التي راجعها التاجر. يفيد الملف عندما يخطط الوكيل لزيارة، أو يقارن المنتجات باحتياجات المشتري المعلنة، أو يعد شرحًا موثقًا بالمراجع، أو يتحقق من الطراز المقصود بدقة. لكنه ليس جلسة قابلة للتنفيذ، ولا استجابة آنية عن المخزون، ولا أمرًا بالشراء.

يبدأ WebMCP لاحقًا. توضح نظرة WebMCP العامة القيد العملي بوضوح: يلزم سياق صفحة المتصفح، ويجب أن تكون الصفحة مفتوحة بالفعل. يمكن لجلسة متصفح محلية أو جلسة متصفح بعيدة توفير هذا السياق، لكن WebMCP ليس واجهة API خلفية أو استدعاء دون اتصال أو آلية الاكتشاف قبل الزيارة. ولا يعمل WebMCP نقلاً خلفيًا لـ MCP أو قائمة أدوات ثابتة أو آلية اكتشاف عبر المواقع؛ فهو يتيح للصفحة النشطة عرض الإجراءات التي تناسب حالة واجهتها الحالية.

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

ما يعرضه WebMCP وما لا يعرضه

تعرّف مسودة WebMCP Community Group أدوات مبنية على JavaScript تقدمها تطبيقات الويب إلى الوكلاء. تسجل Imperative API الأداة عبر document.modelContext.registerTool()، وتقدم الصفحة الاسم والوصف ومخطط المدخلات ودالة التنفيذ والتعليقات التوضيحية الاختيارية. يناسب ذلك الإجراءات التي تحتاج إلى منطق التطبيق أو فحص الحالة أو التنقل أو نتيجة منظمة بعناية.

تعزز Declarative API نموذج HTML عاديًا. تسمي السمة toolname الإجراء وتشرح tooldescription غرضه. وعندما يستدعيه وكيل، يركز المتصفح النموذج المرئي ويملأ حقوله، فيرى المستخدم ما سيحدث. تؤدي إزالة أي من السمتين إلى إلغاء تسجيل الأداة. يفيد ذلك في طلب محدود، مثل طلب دعم لمنتج أو حجز مطعم، لا في التظاهر بأن متصفحًا ذاتي التشغيل يستطيع إتمام كل التزام تجاري من دون مراجعة.

ترتبط Chrome DevTools for agents بهذا الموضوع بوصفها واجهة لتصحيح الأخطاء فقط. تصف وثائق الإعداد خادم MCP يصل الوكيل بـ Chrome للفحص والاختبار. وهو جسر مستقل لتصحيح الأخطاء، وليس نقطة WebMCP طرفية للتاجر ولا بروتوكولًا بديلًا لاكتشاف المنتجات. يمكنه مساعدة الفريق في فحص عمليات التسجيل واستدعاء أداة تطوير ومراجعة المخرجات المنظمة، لكنه لا يحول أدوات الصفحة إلى واجهة API تجارية خلفية أو تعمل دون اتصال.

توضح العروض الرسمية هذا الحد. يسجل عرض Smart Home أداة rearrangeDOMComponents التي تغير مكونات لوحة محاكاة ظاهرة؛ وهي لا تتحكم في أجهزة حقيقية. ويعرض عرض French Bistro نموذجًا تصريحيًا ومرئيًا لطلب حجز، مع تفاصيل مثل التاريخ والوقت وعدد الأشخاص وتفضيل المقاعد والطلبات الخاصة، وتستخدم صفحته طبقة توافق عند غياب الدعم الأصلي. تثبت هذه العروض أن الأدوات تستطيع تحويل تفاعل معقد في الصفحة إلى قصد منظم، لكنها لا تثبت اكتشافًا عامًا أو تنفيذًا عبر المواقع أو إنجازًا موثوقًا أو تفويضًا للدفع أو معاملة تجارية مكتملة. العروض التوضيحية ليست معاملات حقيقية.

مصفوفة مسؤولية واضحة

الفصل التالي مقصود كي لا تجيب طبقة عن سؤال تملكه طبقة أخرى.

السطح	المسؤولية صاحبة السلطة	ما ينبغي للوكيل فعله
SKU.md	أدلة المعرفة: حقائق وادعاءات وإفصاحات وتوافق ومنشأ ومعرفات مستقرة خضعت للمراجعة.	الشرح والاستشهاد وتحديد Product وVariant وSKU وGTIN بدقة.
WebMCP وواجهة المستخدم المرئية	أدوات الصفحة الحالية وحالة التفاعل المرئية للمستخدم.	اكتشاف الأداة المسجلة بعد فتح الصفحة، ثم تنفيذ إجراء محدود داخلها.
Catalog الآني والنظام الخلفي للتاجر	السعر والمخزون والأهلية وخيارات التسليم ومدخلات الضرائب والقواعد الخاصة بالحساب في الوقت الحالي.	إعادة الاستعلام بدل الثقة بلقطة ثابتة.
Checkout	السعر النهائي والشحن والضريبة وتفويض الدفع والموافقة وتأكيد الشراء.	عرض الحالة النهائية وحفظ حد التأكيد.

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

ما تعلنه v0.10 فعلًا

لدى v0.10 طريقة محدودة للإشارة إلى أن زيارة الصفحة قد تتيح قدرة فيها. يمكن لإدخال في capabilities[] استخدام protocol: webmcp وتحديد page_runtime وتقييد الميزة بالنطاقات وpage_url_patterns واشتراط requires_user_presence: true. وهذا تلميح للوصول: يخبر المستهلك بأن التاجر قد يتيح قدرة ذات صلة داخل الصفحة بعد أن يفتح المستخدم عنوان URL مطابقًا.

وليست هذه نسخة من الواجهة الديناميكية. تبقى أسماء الأدوات ومخططات مدخلاتها ومخرجاتها وأوصافها وحالة تسجيلها في بيئة تشغيل الصفحة النشطة، ولا تُنسخ إلى SKU.md. يحدد JSON Schema للإصدار v0.10 حد المستند المقروء آليًا، وتظل المواصفة الإنجليزية للإصدار v0.10 النص المعياري الوحيد. لذلك يجب معاملة page_url_patterns بوصفه تلميحًا للتنقل، لا إذنًا لاستدعاء عملية غير منشورة ولا وعدًا بأن كل صفحة مدرجة تسجل أداة حاليًا.

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

المسار الكامل للوكيل

يستطيع الوكيل اتباع هذا التسلسل من دون اختراع سلطة:

1. قراءة SKU.md وأدلته وإفصاحاته ونطاقه.
2. تحديد Product وVariant وSKU وGTIN؛ والسؤال عند الغموض.
3. فتح صفحة التاجر التي تطابق نمط عنوان URL الآمن، مع حضور المستخدم.
4. اكتشاف الأدوات المسجلة فعلًا في الصفحة النشطة.
5. اختيار أداة يطابق وصفها إجراء الصفحة المطلوب، ثم تنفيذها في واجهة المستخدم المرئية.
6. العودة إلى Catalog الآني أو النظام الخلفي للتاجر للحصول على الحالة التجارية الحالية.
7. استخدام Checkout للمجموع والضرائب والشحن وتفويض الدفع والتأكيد النهائي.

لا تندمج هذه الخطوات عمدًا في أداة «شراء» واحدة. قد تختار الأداة Variant معلومًا، أو تشرح مقارنة ظاهرة حاليًا، أو تبدأ طلب حجز، أو تفتح عرض Cart. يحتاج الشراء النهائي إلى عرض سعر حديث وتأكيد له معنى في لحظة الالتزام. لا نوصي باستخدام toolautosubmit للشراء النهائي. قد يدعم النموذج الإرسال التلقائي في Declarative API، لكن توفره سلوك في المتصفح، وليس دليلًا على أن التاجر ينبغي أن يتجاوز الفحوص التي يجريها الخادم أو القرار النهائي للمتسوق.

ممارسات تاجر تحافظ على الحد

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

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

وأخيرًا، عامل readOnlyHint وuntrustedContentHint بوصفهما تلميحين لا ضمانتين أمنيتين. لا تثبت علامة القراءة فقط أن التنفيذ لا يُحدث تغييرًا، ولا تنظف علامة المحتوى غير الموثوق مخرجاته. احتفظ بالتحقق والتفويض من جانب الخادم، ومعالجة تكرار الطلبات بأمان، وضوابط الاحتيال، وسجلات التدقيق، والتأكيد الصريح للعمليات عالية المخاطر. يجب أن تصف الصفحة آثار الإجراء بصدق، وأن يفرض النظام الخلفي قاعدة العمل بصورة مستقلة.

قيّم التكامل لا ادعاء الترتيب

تكون المقارنة المفيدة بين WebMCP وحده وWebMCP مع SKU.md ضمن سيناريوهات تسوق محدودة ومتماثلة. قِس ما إذا كان الوكيل يطابق Product وVariant المطلوبين، ويستشهد بالمصدر الصحيح، ويفصح عن القيود والأدلة، ويختار أداة الصفحة الحالية المناسبة، ويرفض عرض سعر منتهيًا، ويحافظ على حد التأكيد. وهذه نتائج يمكن فحصها ببيانات اختبار وصفحات مضبوطة ومراجعة بشرية مسجلة.

لا تحول هذا التقييم إلى ادعاء عن الترتيب أو معدل التحويل أو الاعتماد. يستطيع WebMCP تسهيل تشغيل واجهة مفتوحة بالفعل، ويستطيع SKU.md جعل فهم المنتج قبل الزيارة أكثر دوامًا وقابلية للتدقيق. لا يضمن أي منهما بمفرده عملية شراء، ولا يستبدلان معًا Catalog آنيًا أو نظام التاجر الخلفي أو Checkout. الوعد العملي أضيق وأقوى: معرفة المنتج الذي يقصده المتسوق قبل الزيارة، ثم التصرف بناءً على ما يستطيع رؤيته بعد فتح الصفحة.

راجع WebMCP Origin Trial وقت النشر لمعرفة تفاصيل التوفر والتسجيل، لأن نطاق التجربة وسلوك المتصفح قد يتغيران.

قراءة إضافية

يرد تسلسل التحقق الكامل قبل تنفيذ أي إجراء في خريطة سلطة التجارة