---
name: design-storefront-structure
description: صمّم بنية متجر إلكتروني قابلة للعثور والشراء قبل اختيار الزخرفة، عبر تحويل وعد المتجر وسجل المنتج المعتمد ومهام العميل إلى خريطة صفحات وتصنيفات وتنقل وسيناريوهات قبول للبناء. استخدمها عند بناء متجر جديد أو إعادة تنظيم متجر يصعب تصفحه، ثم سلّم البناء الفعلي إلى مدقق الجوال والإتاحة.
---

# منظّم أقسام المتجر

رتّب ما يحتاجه العميل ليجد المنتج ويفهمه ويقرر، ولا تخترع تصنيفات أو فوائد أو حقولًا لا تثبتها بيانات التاجر.

## سير العمل

1. اقرأ `references/structure-method.md` و`references/source-register.md`.
2. افحص بوابة المدخلات أولًا. عند غياب اللغة أو الاتجاه أو وعد المتجر أو بيانات المنتج أو السياسات، سلّم **هيكلًا أوليًا** وقائمة نقص؛ لا تسمّه تصميمًا نهائيًا.
3. ثبّت العميل والمناسبة الشرائية ووعد المتجر والتشكيلة المعتمدة.
4. استهلك سجل المنتج الناتج من `define-product-record`. لا تعيد بناء المتغيرات أو السعر أو المخزون داخل هذه المهارة.
5. اجمع المنتجات حسب طريقة بحث العميل، لا حسب هيكل المورد، وأنشئ تصنيفًا أساسيًا عندما يخدم الوصول فعلًا. المتجر أحادي المنتج يمكن أن يستخدم رابط المنتج مباشرة مع سبب موثق.
6. صمّم التنقل والبحث والمرشحات والصفحات الداعمة، وحدد وظيفة صفحة المنتج دون كتابة محتواها النهائي.
7. اكتب سيناريوهات قبول قابلة للاختبار بعد البناء: العثور على المنتج، مقارنة بديلين إن وجد بديلان، ومعرفة الشحن/الاسترجاع قبل الدفع.
8. أنشئ JSON وفق المخطط في `references/structure-method.md`، وشغّل `node scripts/validate-store-structure.mjs <store-structure.json>` ثم سلّم النتيجة بقالب `assets/output-template.md`. بعد توفر رابط بناء، شغّل `audit-mobile-rtl-accessibility`.

## الحد الأدنى من المدخلات

- السوق واللغة واتجاه الواجهة.
- وصف سلوكي للعميل والمناسبة الشرائية.
- وعد المتجر وما لن يبيعه.
- رابط أو مسار سجل منتج اجتاز `define-product-record` وحالته.
- الكلمات التي يستخدمها العملاء إن توفرت، والمهام الثلاث الأكثر شيوعًا.
- خيارات الشحن والدفع والسياسات الفعلية.
- قيود قالب زد أو المكونات المتاحة.

## قواعد القرار

- لا تجعل «الرئيسية» مكانًا لكل المحتوى؛ لكل كتلة وظيفة واحدة.
- استخدم أسماء تصنيفات يفهمها العميل، ولا تنشئ تصنيفًا فارغًا أو لمنتج واحد بلا سبب واضح.
- لكل منتج ضمن تشكيلة متعددة تصنيف أساسي واحد. يسمح لمتجر أحادي المنتج بعدم إنشاء تصنيف واجهة إذا سُجل السبب `single_product_launch` وكان الوصول المباشر واضحًا.
- لا تعتبر سجل المنتج جاهزًا من هذه المهارة؛ استخدم حالة ملف `define-product-record` كما هي.
- لا تكتب ادعاءً أو مكوّنًا أو تحذيرًا من عندك. المنتج المنظم يحتاج المصدر الرسمي الخاص بسوقه.
- لكل ادعاء أو مكوّن أو تحذير مصدر خاص بالمنتج والسوق؛ سجل المصادر العامة للمنصة لا يثبت محتوى المنتج.
- سيناريو المقارنة لا ينطبق عند وجود منتج إطلاق واحد؛ سجل السبب بدل اختراع بديل.
- جاهزية البنية تعني أنها صالحة للبناء فقط. الاختبار الفعلي يمر عبر `audit-mobile-rtl-accessibility` وقرار الإطلاق عبر `pass-store-launch-gate`.

## عقد المخرجات

1. وعد المتجر والعميل والمناسبة الشرائية.
2. خريطة الصفحات ووظيفة كل صفحة.
3. جدول التصنيفات والمنتجات والتصنيف الأساسي والروابط الثانوية.
4. بنية التنقل والبحث والمرشحات مع سبب كل خيار.
5. مرجع سجل المنتج ووظيفة صفحة المنتج والحقول التي تعرضها؛ المحتوى النهائي منفصل.
6. مخطط الصفحة الرئيسية دون نصوص أو ادعاءات مخترعة.
7. سيناريوهات قبول للبناء مع نقطة بداية وفعل ونتيجة قابلة للملاحظة.
8. قرار البنية: هيكل أولي / جاهز للبناء / يحتاج بيانات / يعاد تنظيمه، والخطوة التالية. اكتب صراحة أن القرار لا يعني الجاهزية للبيع أو اجتياز الجوال والإتاحة.

## مثال

راجع `examples/example-request.md` و`examples/example-output.md`. المثال يوضح البنية ولا يفرض عدد تصنيفات ثابتًا.