اختر المنتجات اللي تبدأ فيها

ابدأ بتشكيلة تعلّمك ما يشتريه العميل ويمكن تشغيلها، لا بأكبر عدد من المنتجات. لا تفرض عدد وحدات أو منتجات دون بيانات المورد والطلب والهامش.

سير العمل

1. اقرأ references/assortment-method.md.
2. اجمع بطاقة مستقلة لكل منتج مرشح وفق الحد الأدنى أدناه.
3. استبعد أي منتج تمنعه سلامة أو نظام أو توريد غير قابل للتحقق، وسجّل السبب.
4. قيّم المنتج على أربعة محاور منفصلة: قيمة للعميل، دليل طلب، اقتصاديات، وقابلية تشغيل.
5. صنّف كل منتج إلى:
   • أساسي: يشرح وعد المتجر ويمتلك أدلة وتشغيلًا مقبولًا.
   • تجريبي: فرضية مهمة تستحق كمية صغيرة أو طلبًا مسبقًا واضحًا.
   • مؤجل: واعد لكن تنقصه معلومة أو قدرة تشغيلية.
   • مستبعد: يشتت الوعد أو يفشل شرطًا حرجًا.
6. راجع التغطية: استخدامات العميل، نطاقات السعر، الاعتماد بين المنتجات، والمتغيرات.
7. اقترح مخزونًا أوليًا كنطاق مشروط بزمن التوريد والحد الأدنى والطلب، لا كرقم عشوائي.
8. استخدم assets/output-template.md.
9. إذا جهزت JSON للقرار، شغّل node scripts/validate-assortment.mjs <assortment.json>.

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

اجمع الحقول التالية لكل منتج مرشح:

• المعرّف والاسم ووظيفته للعميل.
• السوق الجغرافي، نوع المنتج، وهل يخضع لتنظيم خاص بحسب التاجر أو الجهة الرسمية.
• دليل الطلب ومصدره وتاريخه وفترته: اهتمام/حجز/عربون/شراء، هل هو مدفوع، وعدد الأشخاص المؤهلين أو الزوار إن توفر.
• سعر البيع المتوقع وتكلفة البضاعة والتكلفة المتغيرة إن توفرت.
• المورد، حد الطلب الأدنى، زمن التوريد، والقدرة على إعادة الطلب.
• الصلاحية أو التخزين أو الحجم/الوزن أو قيود الشحن عند انطباقها.
• المتغيرات الفعلية مثل اللون والمقاس، وعدد التركيبات الناتجة.
• التوافق أو الاعتماد على منتج آخر.
• أكبر مخاطرة أو معلومة مفقودة.

قواعد القرار

• لا تستخدم «منتج رائج» سببًا وحيدًا.
• لا تفترض العميل أو المناسبة الشرائية. إذا لم يقدمهما التاجر، اجعلهما فجوة تمنع صياغة وعد نهائي.
• لا تصنّف منتجًا «تجريبيًا» إذا كانت السلامة أو الامتثال أو تكلفة التوريد أو القدرة على الوفاء مجهولة. يمكن اقتراح اختبار اهتمام غير بيعي فقط، ويبقى المنتج مؤجلًا.
• استخدم «تجريبي» فقط عندما تكون البوابات الحرجة معروفة ويكون الالتزام صغيرًا وقابلًا للعكس، مثل عينة أو طلب مسبق شفاف بموعد وشروط استرداد.
• عبارة «بيانات المورد كاملة» لا تكفي. تحقق على الأقل من: الهوية والتفويض عند الحاجة، التكلفة الواصلة، MOQ، زمن التوريد وتذبذبه، إعادة الطلب، المواصفات/المكونات، الملصق، السلامة والصلاحية والتخزين، ومتطلبات السوق المعني.
• قارِن قوة الدليل قبل عدده: شراء مدفوع حديث أقوى من حجز غير مدفوع، وسجّل الفترة والمقام والإلغاءات بدل مقارنة 20 و5 كرقمين مجردين.
• إذا كان الجمهور مجهولًا، لا تكتب وعدًا نهائيًا. قدّم «وعدًا تشغيليًا مؤقتًا» ثم وجّه إلى validate-store-idea لإغلاق فجوة العميل والمناسبة الشرائية.
• منتج واحد يكفي للإطلاق إذا حقق وعدًا واضحًا واجتاز البوابات ويمكن خدمته وربحه؛ لا تضف منتجات لتبدو التشكيلة كبيرة.
• إذا اتضح أن حجزًا مدفوعًا لا يمكن الوفاء به بسبب سلامة أو امتثال أو توريد، أوقف التحصيل والتنفيذ، احفظ السجلات، أخطر العميل بوضوح، واتبع سياسة الاسترداد والمتطلبات الرسمية. لا تقدّم استشارة قانونية من الذاكرة.
• لا تجعل كل لون أو مقاس منتجًا مستقلًا عند تحليل الوعد؛ لكنه يبقى وحدة مخزون مستقلة عند التخطيط.
• لا تنشئ متغيرات لا يستطيع التاجر توريدها أو تصويرها أو خدمتها.
• لا تُدخل منتجًا ضعيف الهامش لتكبير العدد إلا إذا كان دوره الاستراتيجي مثبتًا.
• افصل بين منتج جذب، منتج أساسي، إضافة للسلة، وتجربة؛ ولا تفترض أن كل متجر يحتاج الأدوار كلها.
• مرّر المنتجات ذات الأرقام الكافية إلى model-store-unit-economics بدل تقدير الربحية نصيًا.

عقد المخرجات

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

راجع references/source-register.md عند بناء حقول المنتج أو بنية الكتالوج.

مثال

راجع examples/example-request.md وexamples/example-output.md. الأرقام والتصنيف خاصان بالمثال ولا يعاد استخدامهما كقاعدة.