--- name: production-readiness-gate description: Mandatory production-readiness gate for any code/app/site — security (DoS/injection/auth) + performance (N+1/scalability) + maintainability + PoC-not-Production. Auto-apply before delivering any code. version: v1 date: 2026-08-31 ---
🛡️ Production-Readiness Gate — بوابة جاهزية الإنتاج الإلزامية
> الأصل: استُخلصت من مراجعة هندسية حقيقية لنظام ERP بُني بالكامل عبر AI (Vibe Coding) — 2026-08-31. النقد أُجري على 5+ مستويات وثُبّت كقواعد دائمة بأمر د. وائل. > > متى تُستخدم (auto-trigger): أي طلب لبناء/تعديل كود أو برنامج أو موقع أو API — أساسي (flagship) أو أكاديمي. تُطبَّق تلقائياً دون طلب صريح. > > القاعدة الحاكمة: لا يُسلَّم أي كود كـ Production قبل المرور على هذه البوابة. الديمو/PoC مسموح صراحةً بوسمه «Proof of Concept». الأساسي = إلزامي؛ الأكاديمي = يُطبَّق ما لم يتعارض مع هدف تعليمي/دفاعي صريح (وحينها يُوسَم القيد).
> 🔏 ضمانة صفر-سلبية (خط أحمر — مُتحقّق بالكود + اختبار عملي حيّ):
> - التكلفة: البوابة = قواعد إرشادية تُطبّق ضمن استدلال الموديل الجاري — صفر استدعاء LLM/API إضافي، صفر زيادة tokens/تكلفة. أداة loadtest.py مبنية على urllib/stdlib فقط → تشغيلها = صفر دولار مهما تكرّر.
> - استقرار/أداء التطبيق المبني: الفحوصات = checklist ذهني للمهندس، ليست كوداً يُحقَن في التطبيق → مستحيل تُبطئه أو تُفشله. الحماية تُضاف بحساب (لا over-engineering يُبطئ المستخدم الشرعي).
> - الأداة معزولة: loadtest.py لا تُستدعى تلقائياً؛ تُشغّل يدوياً فقط على هدف مصرّح به بعد اكتمال البناء (لا تؤذي عملية البناء). degradation-safe: أي خطأ يُسجّل ويُكمل، لا يُسقِط شيئاً.
---
🎯 المبدأ الجوهري (الجذر الفلسفي — أهم نقطة)
❌ الخطأ القاتل: بناء البرنامج feature-by-feature بلا فهم الـ big-picture context. الـ AI (وأي مبرمج مبتدئ) يعالج مشكلة واحدة معزولة في كل مرة، فيُنتج نظاماً «ملزوقاً» بلا معمارية موحّدة. يعمل في الديمو، وينهار في الإنتاج.
✅ القاعدة: افهم الصورة الكاملة أولاً (كل الـ entities + العلاقات + الـ scale المتوقّع + نمط الاستخدام) ثم ابنِ المعمارية الموحّدة، ثم املأ الـ features داخلها. البيت يُبنى كوحدة واحدة بأساسات، لا غرفة-غرفة بلا تصميم.
الاستعارة الحاكمة: الـ Vibe Coding = ماكيت البيت (منظر جميل)، لا البيت نفسه (أساسات تتحمّل توسّعاً/أحمالاً/عواصف). وترقيع أي باج بالـ AI = لزق «سولوتيب» فوق الخرم بدل إصلاح الجذر.
---
🚪 البوابة — 4 أعمدة إلزامية (تُفحص قبل تسليم أي Production)
① الأمن (Security) — صفر تهاون
- DoS/DDoS: أي endpoint عام يجب أن يكون خلف حماية: rate-limiting على مستوى التطبيق + WAF/CDN (Cloudflare أو ما يكافئ). السيرفر المكشوف = سكربت بربع دولار يسقط النظام والبزنس. يشمل الديمو والإنتاج معاً.
- Rate-limiting واعٍ (لا محفوظ): على الـ login + endpoints الحسّاسة + الـ mutations الثقيلة. يجب أن يكون مقصوداً ومُختبَراً ومربوطاً بمستوى السيرفر لا الفرونت فقط.
- Injection (SQL/NoSQL/XSS/Command): parameterized queries حصراً + input validation + output encoding. لا concatenation خام أبداً.
- AuthN/AuthZ: access token قصير العمر + refresh token طويل العمر مربوطان صحيحاً (rotation عند 401 عبر refresh فعلي، لا re-generate أعمى). فحص authorization على كل endpoint (منع رؤية بيانات مستخدم آخر عبر تغيير id/ORDER). أسرار خارج الكود.
- الجذر لا الترقيع: أي باج أمني/auth يُصلَح من السبب الجذري لا بترقيعة تُخفي العرَض.
② الأداء والقابلية للتوسّع (Performance & Scalability)
- ❌ N+1 queries — الخطأ الأشهر: لا تبعث request منفصلاً لكل قائمة (dropdowns: الدول/العملات/الفروع...). استخدم JOIN واحد أو request مجمّع واحد أو batching/DataLoader. فورم واحد = أقل عدد ممكن من الـ round-trips.
- تمييز القراءة عن الكتابة: الكتابة أثقل من القراءة — تمرّ على validation ثم serialization ثم sanitization ثم DB write (عنق الزجاجة). صمّم لها بحساب (transactions، indexing، write-path optimization).
- Caching مقصود: cache للبيانات القابلة للتخزين + invalidation صحيح عند التعديل. لا requests متكرّرة لبيانات ثابتة.
- Pagination + limits: لا سحب صفوف غير محدود؛ pagination إلزامي بسقف معقول + تجاوزه عند الحاجة الحقيقية.
- Load-testing إلزامي قبل ادّعاء «Production»: حاكِ مستخدمين متزامنين بمضاعفة تصاعدية (4، 8، 16، 32...) + قِس p50/p75/p95 latency. النظام الذي «ينهار عند 8 مستخدمين» ليس production. صمّم للـ scale الحقيقي المتوقّع.
python3 skills/production-readiness-gate/loadtest.py --url <target> --i-own-this --stages 4,8,16,32 --requests-per-user 10 [--json out.json] — تقيس p50/p75/p95/p99 + throughput + error-rate لكل مرحلة وتعطي حكم PASS/FAIL + نقطة الانهيار (breaking point). حواجز أمان صارمة: ❌ يرفض أي هدف عام بلا --i-own-this+--allow-public (ليس سلاح DoS) · GET/HEAD فقط (الكتابة تحتاج --allow-writes) · سقوف تزامن/طلبات. الاختبار الذاتي: loadtest.py --selftest.
- اختيار Tech-Stack صحيح: لا تختر أداة خارج غرضها (Next.js RSC كباك-إند كامل لـ ERP = خطأ؛ هو front-end layer). الـ stack يخدم طبيعة الحمل (OLTP/OLAP/real-time/batch).
③ القابلية للصيانة (Maintainability) — أهم بُعد طويل المدى
- معمارية + بنية واضحة: طبقات مفصولة (routes/services/data)، مسؤولية واحدة لكل وحدة، عقود واجهات واضحة. لا كود «ملزوق».
- قابلية القراءة: الكود يُقرأ من مهندس آخر (أو منك بعد شهرين). الإضافة المستقبلية لا تصير «شبه مستحيلة».
- Refactoring مستمر + منع Technical Debt: كل feature تُوضع في مكانها الصحيح ضمن المعمارية. راجع الـ diff بحيث لا يكسر الـ architecture.
- ❌ مقياس القبول: «هل يقدر مهندس آخر أن يبني على هذا الكود بعد 3 أشهر؟» — إن لا → مرفوض كـ production.
④ حدّ PoC ≠ Production (الوسم الإلزامي الصادق)
- أي كود سريع لإثبات فكرة = يُوسَم صراحةً «Proof of Concept / Demo» ولا يُقدَّم كجاهز للإنتاج.
- ادّعاء «وفّرت X ألف» أو «جاهز للاستخدام» ممنوع ما لم تُجتَز الأعمدة أعلاه بدليل (خصوصاً load-test + security scan).
- الصدق المطلق: «هذا يثبت الفكرة، لكنه يحتاج تصليباً أمنياً/أدائياً/معمارياً قبل الإنتاج».
🔗 الدمج في السلسلة الذهبية (11 مرحلة)
هذه البوابة تُطعّم المراحل القائمة (لا تستبدلها):
- المرحلة 1-4 (Discovery→Architecture): أضف «فهم الـ big-picture + الـ scale المتوقّع» كمخرَج إلزامي قبل أي كود. Fable architect يُنتج: data model كامل + العلاقات + الحمل المتوقّع + قرار الـ stack المبرَّر.
- المرحلة 8-9 (Review→Security): أضف بوابة الأعمدة الأربعة كـ checklist إلزامي في مراجعة الـ diff + security scan.
- المرحلة 10 (Test+Deploy): أضف load-test (concurrent users) قبل TestSprite gate. لا deploy بادّعاء production قبل اجتيازه.
- قبل كل تسليم: أجب صراحةً: «هل هذا PoC أم Production؟» ووسِمه.
🎓 الشقّ الأكاديمي (بصفر سلبيات)
في السياق التعليمي/الدفاعي (أمن سيبراني، تحليل هجمات، CTF): البوابة تُثري لا تعيق — تُستخدم لشرح لماذا يسقط نظام غير محمي (تعليم الهجوم يوضّح قيمة الدفاع). أي قيد أمني نتجاوزه لغرض تعليمي صريح = يُوسَم «سياق مختبر/تعليمي». لا تُطبَّق البوابة كحاجز على كود تعليمي يُوضّح ثغرة عمداً.
✅ الخلاصة العملية (checklist سريع قبل أي تسليم Production)
[ ] فهمتُ الصورة الكاملة (entities + relations + scale) قبل الكود؟
[ ] لا N+1 (JOIN/batch بدل request-per-list)؟
[ ] حماية DoS (rate-limit + WAF/CDN) على الـ endpoints العامة؟
[ ] Injection مغلق (parameterized + validation + encoding)؟
[ ] AuthZ على كل endpoint + token rotation صحيح (لا ترقيع)؟
[ ] Write-path مُصمَّم (transactions/index/validation/sanitize)؟
[ ] Caching + invalidation + pagination؟
[ ] Load-test concurrent (4، 8، 16، 32) + p95 مقبول؟
[ ] Tech-stack مناسب للحمل (لا أداة خارج غرضها)؟
[ ] Maintainable (طبقات/قابل للقراءة/يُبنى عليه بعد 3 أشهر)؟
[ ] وسمتُ الكود بصدق: PoC أم Production؟
أي بند غير محقّق على كود يُدّعى أنه Production = توقّف + إصلاح جذري قبل التسليم.