| name | ecommerce-store-auditor |
| description | تدقيق المتاجر الإلكترونية العامة أو المتصلة بالأدلة والدرجات وخطة إصلاح: الصفحة الرئيسية، التصنيفات، البحث، الفلاتر، صفحة المنتج، السلة، الدفع، الجوال، الأداء، الإتاحة، الثقة، الامتثال، الشحن، ما بعد الشراء، القياس، ومتطلبات القطاع. استخدمها عندما يطلب المستخدم تقييم متجر أو CRO audit أو UX audit أو كشف أخطاء رحلة الشراء أو مقارنة جاهزية الإطلاق أو إعادة التحقق بعد الإصلاح. |
مدقق المتجر الإلكتروني
افحص رحلة حقيقية، لا انطباعاً بصرياً. كل نتيجة تحتاج دليلاً قابلاً لإعادة الاختبار وإصلاحاً ومعيار قبول.
اختر نطاق التدقيق
- فحص سريع عام: الرئيسية + تصنيف + بحث + منتجان + سلة، على جوال وسطح مكتب. لا يمنح درجة شاملة إذا لم تُختبر رحلة كافية.
- تدقيق شامل عام: عينات من كل قالب ورحلة حتى آخر خطوة آمنة قبل إرسال طلب أو دفع.
- متصل بالتحليلات: أضف funnel والجهاز والقناة والصفحة وSKU والمرتجعات، وثبّت الفترة والمقارنة.
- إعادة تحقق: اختبر finding IDs السابقة فقط ثم عينة regression للرحلات المتأثرة.
اسأل عن السوق والقطاع والهدف إن لم يمكن استنتاجها بأمان. استخدم references/sector-overlays.md لإضافة اختبارات القطاع.
بروتوكول التدقيق
- ثبّت النطاق: النطاق الجغرافي والعملة واللغة والقطاع والأجهزة والصفحات وحالة الدخول.
- ابنِ العينة: الصفحة الرئيسية، أعلى 2 إلى 3 تصنيفات، 5 إلى 10 استعلامات، ومنتجات تمثل bestseller/new/discounted/out-of-stock/multi-variant/high-risk.
- اختبر الرحلة: استخدم
references/journey-checklists.md. على الجوال أولاً، ثم سطح المكتب. اختبر happy path وحالتين حديتين على الأقل.
- اجمع الدليل: لكل عيب سجّل URL والوقت والviewport والخطوات والمتوقع والملاحظ وصورة/لقطة إن أمكن.
- صنّف السبب: محتوى، بيانات، واجهة، منطق، أداء، تكامل، تشغيل، ثقة/امتثال، أو قياس.
- امنح الشدة: طبق
references/audit-scorecard.md. الشدة أثر وثقة، لا تفضيل شخصي.
- اكتب الإصلاح: الحالي → المقترح → السبب → الاعتماديات → معيار القبول → المؤشر.
- احسب الدرجة: استخدم
scripts/score_audit.py فقط من controls مختبرة، وأظهر coverage.
- سلّم التقرير: اتبع
references/report-template.md، والنتيجة التنفيذية أولاً.
قواعد الأدلة
- لا تقل «بطيء» بلا قياس أو سلوك ظاهر؛ لا تقل «مربك» بلا مهمة فشل أو دليل احتكاك.
- لا تمنح pass لصفحة لم تختبرها، ولا تحول not-tested إلى fail.
- لا تستخدم benchmark عاماً كأنه بيانات المتجر. المصدر يشرح لماذا الاختبار مهم، والدليل يثبت حالة المتجر.
- عند تغير المحتوى حسب الموقع أو الحساب، وثق الحالة ولا تعمم.
- إذا منع الموقع التصفح أو فشل التحميل، سجله كقيد تدقيق لا كعيب مؤكد في المتجر.
الشدة
- P0 حرج: تسرب بيانات، سعر/مخزون خاطئ، ادعاء أو سلامة عالية المخاطر، تعطل شراء واسع، خصم/طلب مكرر، أو دفع بلا تأكيد.
- P1 مرتفع: عائق متكرر يمنع أو يغير قرار الشراء، خطأ توافق/مقاس/شحن، أو غموض تكلفة/إرجاع مؤثر.
- P2 متوسط: احتكاك أو نقص يبطئ القرار وله إصلاح واضح.
- P3 تحسين: تحسين تجريبي بلا دليل على مشكلة حالية؛ لا يدخل درجة العيوب.
حدود العمل
- لا تسجل الدخول أو تستخدم حساباً أو بيانات دفع إلا إذا وفر المستخدم بيئة اختبار وطلب ذلك صراحة.
- لا ترسل طلباً، رسالة، نموذجاً، تقييماً، أو تغييراً أثناء التدقيق العام.
- لا تختبر كوبونات عشوائية أو تحاول تجاوز ضوابط المتجر.
- لا تجمع بيانات شخصية في screenshots؛ أخفها أو استخدم بيانات اختبار.
- لا تفسر المتطلبات القانونية أو الطبية نهائياً. تحقق من المصدر الرسمي الحالي ووسم ما يحتاج مختصاً.
بوابة الاكتمال
لا تسمِّ التقرير «شاملاً» إلا إذا:
- اختُبرت جميع قوالب الرحلة الأساسية على الجوال.
- توجد coverage معلنة لكل بُعد.
- كل P0/P1 له دليل وإعادة وخطوة إصلاح ومعيار قبول.
- تم تطبيق overlay القطاع والسوق.
- تم فصل الحقائق عن الفرضيات وعن البيانات غير المتاحة.
- توجد خطة 7 أيام و30 يوماً وترتيب أثر/ثقة/جهد.
المراجع
references/journey-checklists.md، اختبارات كل مرحلة.references/audit-scorecard.md، الأبعاد والأوزان والشدة والحساب.references/sector-overlays.md، اختبارات إضافية لـ16 قطاعاً.references/report-template.md، عقد finding وقالب التسليم.references/source-register.md، مصادر المنهج والمعايير الرسمية.
