Claude Code / Codex
موجهات التعليمات ومجموعة القوالب

اقرأ ملف التعليمات الذي تحمّله أنت (هذا الوكيل) (CLAUDE.md / AGENTS.md وغيرهما)،
وأشر إلى نقاط الضعف التي يميل وكلاء الذكاء الاصطناعي إلى تجاهلها، ثم أعد كتابته
إلى صيغة فعالة.

أمور يجب الانتباه إليها:
- حوّل الصياغة الغامضة إلى أوامر (افعل X دائما / لا تفعل Y أبدا)
- أضف "تعريف الاكتمال" وخطوات التحقق (تشغيل lint / test)
- اجعل المحظورات ملموسة وصولا إلى الهدف (أسماء المجلدات، أسماء الأوامر)
- إن كان طويلا جدا، قلّصه إلى الجوهر الذي تريد فرضه فقط

أولا اسرد نقاط الضعف على شكل نقاط، ثم أخرج النسخة المعاد كتابتها كاملة
وطبّقها على ملف التعليمات ذاك.

بعد تحديد أوامر build / test / lint الفعلية لهذا المستودع،
أضف قسم "تعريف الاكتمال" إلى ملف التعليمات الذي تحمّله
(CLAUDE.md / AGENTS.md وغيرهما).

المتطلبات:
- اجعله قائمة تحقق على هيئة "لا تبلّغ عن الإنجاز حتى تتحقق كل النقاط التالية"
- اذكر أوامر lint وtest الحقيقية صراحة
- ضمّن: لا تترك أي TODO أو سجلات تصحيح في الملفات المعدّلة، وأعد قراءة diff الخاص بك

لا تكسر المحتوى الموجود؛ أضف القسم فقط.

اكتشف تلقائيا لغة هذا المستودع وإطار عمله، وأضف القواعد
المطابقة لأفضل الممارسات إلى ملف التعليمات الذي تحمّله
(CLAUDE.md / AGENTS.md وغيرهما).

أمثلة:
- Next.js: حدود Server/Client (الافتراضي هو Server، أبقِ use client في حده الأدنى)
- Laravel: التحقق عبر Form Requests، اصطلاحات الترحيل (migration)
- Python: التعليقات التوضيحية للأنواع، لا تكتب فوق البيانات الخام أو تختلقها أبدا

أضف ملاحظة من سطر واحد عن أساس اكتشافك (من أي الملفات حكمت)
قبل الإضافة. لا تكرر أي شيء مكتوب بالفعل.

أضف "القواعد المطلقة" التالية إلى ملف التعليمات الذي تحمّله
(CLAUDE.md / AGENTS.md وغيرهما)، مفصلة حسب إعداد هذا المستودع.

- لا تودع الأسرار أو ملف .env أو بيانات الاعتماد أبدا
- لا تنفذ push / force-push أبدا ما لم يُطلب منك ذلك
- تحقق من المدخلات عند الحدود / لا تخفف المصادقة أو التفويض من تلقاء نفسك أبدا
- لا تنفذ أوامر مدمرة (DROP / TRUNCATE / migrate:fresh وغيرها) على قاعدة بيانات الإنتاج أبدا
- كلما غيّرت سلوكا، أضف أو حدّث الاختبارات دائما

إن كانت قواعد مماثلة موجودة بالفعل، فلا تكررها؛ أكمل ما هو ناقص فقط.

حوّل محتوى هذا الملف `CLAUDE.md` إلى صيغة `AGENTS.md` الخاصة بـ
OpenAI Codex واكتبه.

- حافظ على المعنى، لكن أعِد تشكيله إلى بنية يسهل على Codex قراءتها
  (عناوين، نقاط)
- أبقِ الأوامر والقواعد المطلقة وتعريف الاكتمال كما هي
- أخرجه على هيئة `AGENTS.md` في الجذر

حوّل محتوى هذا الملف `CLAUDE.md` إلى صيغة Project Rules الخاصة بـ Cursor
(ملفات `.mdc` ضمن المجلد `.cursor/rules/`).

- قسّم القواعد إلى وحدات ذات معنى
- افصل القواعد التي ينبغي تطبيقها دائما عن القواعد التي تنطبق
  على أنواع ملفات محددة فقط
- اضبط شروط التطبيق المناسبة (globs وغيرها) في أعلى كل ملف

افحص بنية هذا المستودع الأحادي (monorepo) وأنشئ ملفات التعليمات التي
تحمّلها أنت (هذا الوكيل) (يستخدم Claude Code الملف CLAUDE.md، ويستخدم Codex الملف AGENTS.md وغيرهما)،
مقسّمة كما يلي.

- في الجذر: القواعد المشتركة للمستودع بأكمله
  (اصطلاحات الإيداع، وحماية الأسرار، وتعريف الاكتمال الشامل)
- في كل مجلد حزمة/تطبيق: فقط القواعد والأوامر الخاصة بذلك المكدس

تجنب التكرار، وأضف ملاحظة من سطر واحد في كل حزمة تقول "اتبع
القواعد المشتركة في الجذر". في النهاية، أبلغ بقائمة بما وضعته في أي مجلد.

# المشروع: <name>

## ما هذا
نظرة عامة من فقرة واحدة على التطبيق. ماذا يفعل، ومن يستخدمه، والمكدس
التقني (اللغة، إطار العمل، قاعدة البيانات، بيئة التشغيل).

## الأوامر
- خادم التطوير: `npm run dev`
- البناء:       `npm run build`
- الاختبار:     `npm test`
- التحقق:       `npm run lint`

## الاصطلاحات
- اللغة هي TypeScript (الوضع الصارم strict). لا تستخدم `any`.
- طابق نمط الملف الذي تحرره حاليا. اجتز lint دائما قبل الإنهاء.
- أبقِ التغييرات في حدها الأدنى؛ لا تمس الأسطر غير ذات الصلة (دون إعادة تنسيق غير ضروري).

## القواعد المطلقة (تُفرض بصرامة)
- قبل الإبلاغ عن الإنجاز، شغّل الاختبارات وlint أعلاه دائما واجعلها تنجح.
- لا تودع الأسرار أو ملف .env أو نواتج البناء أبدا على الإطلاق.
- فضّل تحرير الملفات الموجودة على إنشاء ملفات جديدة.
- عندما تكون المتطلبات غامضة، اسأل سؤالا توضيحيا واحدا بالضبط قبل إجراء تغيير كبير.

## نطاق محظور (ما لم يُطلب خلاف ذلك)
- إعدادات CI، إصدارات التبعيات، إعداد البنية التحتية.

# <name>

- المكدس: <مثال: Next.js + TypeScript + PostgreSQL>
- شغّل دائما قبل الإنهاء: `npm run lint` و`npm test` (يجب أن ينجح كلاهما)
- طابق النمط الموجود. لا تعِد تنسيق الأسطر غير ذات الصلة.
- لا تودع الأسرار أو ملف .env. لا تنفذ push حتى يُطلب منك ذلك.
- عند الغموض، لا تخمن؛ اسأل سؤالا واحدا بالضبط.

# Next.js (App Router) + TypeScript

## المكدس
Next.js (App Router), TypeScript strict, Tailwind CSS, <your-ORM>

## الأوامر
- التطوير: `npm run dev`
- البناء:  `npm run build`   # يجب أن ينجح دون أخطاء أنواع
- التحقق:  `npm run lint`
- الاختبار: `npm test`

## قواعد البنية المعمارية
- اجعل المكوّنات الخادمة (Server Components) هي الافتراضي. أضِف "use client" فقط عند
  الحاجة إلى الحالة أو التأثيرات أو واجهات المتصفح. أبقِ المكوّنات العميلة صغيرة وعند الأطراف.
- اجلب البيانات في المكوّنات الخادمة أو في Route Handlers.
  لا تجلب البيانات الأولية في useEffect.
- ضع المكوّنات بجانب مقطع المسار الخاص بها. واجهة المستخدم المشتركة تذهب في `components/`.
- تحقق دائما من المدخلات الخارجية بمخطط عند الحدود (مثل Zod).

## الاصطلاحات
- لا `any`. امنح الدوال العامة أنواع إرجاع صريحة.
- استخدم رموز التصميم / فئات Tailwind الموجودة. لا تضِف ألوانا من تلقاء نفسك.
- أبقِ `page.tsx` رقيقا؛ ادفع المنطق إلى الدوال والمكوّنات.

## تعريف الاكتمال
ينجح `npm run build` و`npm run lint` و`npm test` جميعها برمز خروج 0.
لا `any`، ولا صادرات (exports) غير مستخدمة، ولا console.log متروك.

# React (Vite) + TypeScript

## الأوامر
- التطوير: `npm run dev`
- البناء:  `npm run build`
- التحقق:  `npm run lint`
- الاختبار: `npm test` (Vitest + Testing Library)

## القواعد
- مكوّنات دوال وHooks فقط. لا تستخدم مكوّنات الأصناف (class components).
- أبقِ الحالة في حدها الأدنى، بالترتيب "محلية -> Context -> مكتبة حالة".
  لا ترفع الحالة إلى المستوى العام بلا داع.
- احصر التأثيرات الجانبية في useEffect، واكتب مصفوفة التبعيات بشكل صحيح.
- افصل واجهة المستخدم عن المنطق. اجمع جلب البيانات في hooks مخصصة (useXxx).
- إمكانية الوصول: امنح العناصر التفاعلية أدوارا مناسبة وتشغيلا بلوحة المفاتيح.

## الاصطلاحات
- لا `any`. عرّف الـ props بالأنواع.
- طابق نمط المكوّنات والأنماط الموجودة.

## تعريف الاكتمال
ينجح `npm run build` و`npm run lint` و`npm test` برمز خروج 0.

# Node.js API (Express / Hono) + TypeScript

## الأوامر
- التطوير: `npm run dev`
- البناء:  `npm run build`
- الاختبار: `npm test`
- التحقق:  `npm run lint`

## القواعد
- تحقق بمخطط من كل المدخلات (body, query, params, headers) عند الحدود.
- لا تبتلع الأخطاء. أعدها مكتوبة بالأنواع عبر معالج أخطاء مركزي.
- اقرأ الأسرار من متغيرات البيئة. لا تكتبها مباشرة في الكود.
- صنّف وصول قاعدة البيانات إلى طبقات (route -> service -> repository).
- أعِد شكل JSON متسقا (وحّد شكلي النجاح والفشل).

## القواعد المطلقة
- لا تتخطّ أو تخفف منطق المصادقة / التفويض من تلقاء نفسك.
- تحقق من التفويض دائما عند إضافة نقطة نهاية معرّضة للعموم.
- لا تسجّل المعلومات الشخصية أو الرموز (tokens) أو كلمات المرور.

## تعريف الاكتمال
ينجح `npm test` (المسار السليم + حالات الخطأ) و`npm run lint`.

# Laravel + PHP

## الأوامر
- التشغيل: `php artisan serve`
- الترحيل:  `php artisan migrate`
- الاختبار: `php artisan test`
- التنسيق:  `./vendor/bin/pint`   # شغّله قبل الإنهاء

## الاصطلاحات (اتبع طريقة Laravel)
- استخدم علاقات Eloquent. تجنب SQL الخام دون سبب واضح.
- تحقق من المدخلات في أصناف Form Request. لا تفعل ذلك داخل المتحكمات.
- أبقِ المتحكمات رقيقة. ادفع منطق العمل إلى Services / Actions.
- كل تغيير في المخطط ينال ترحيلا جديدا. لا تحرر الترحيلات التي نُفّذت بالفعل.
- استخدم المسارات المسماة وربط نموذج المسار (route model binding).

## القواعد المطلقة
- لا تودع `.env` أو بيانات اعتماد حقيقية أبدا على الإطلاق.
- لا تنفذ أوامر مدمرة مثل `migrate:fresh` على قاعدة بيانات الإنتاج.
- كلما غيّرت سلوكا، أضف أو حدّث الاختبارات دائما (`php artisan test`).

## تعريف الاكتمال
ينجح كل من `php artisan test` و`./vendor/bin/pint --test`.

# Python / تحليل البيانات

## البيئة
- استخدم بيئة المشروع الافتراضية venv `.venv`. لا تثبّت بشكل عام.
- التثبيت: `pip install -r requirements.txt`
- التشغيل: `python -m src.main`
- الاختبار: `pytest`
- التنسيق: `ruff check .` و`ruff format .`

## الاصطلاحات
- أضِف تعليقات توضيحية للأنواع إلى كل توقيع دالة. شغّل `mypy src` إن كان مُعدّا.
- لا تضع المنطق في الدفاتر (notebooks). الكود القابل لإعادة الاستخدام يذهب في `src/`.
- ثبّت البذرة (seed) لأي شيء يستخدم العشوائية، كي تكون النتائج قابلة لإعادة الإنتاج.

## قواعد البيانات المطلقة (الأهم)
- لا تملأ القيم المفقودة أو تختلقها بصمت. إن وجدت قيم مفقودة،
  فأبلغ عنها وتأكد من كيفية التعامل معها.
- لا تكتب فوق ملفات البيانات الخام. اكتب الناتج في `data/processed/`.
- وثّق كل الافتراضات (المرشحات، الأسطر المستبعدة، الوحدات) في تعليقات الكود.

## تعريف الاكتمال
ينجح `pytest`، ويكون `ruff check .` نظيفا، وتُعاد إنتاج النتائج من حالة نظيفة.

# Go

## الأوامر
- البناء:  `go build ./...`
- الاختبار: `go test ./...`
- التنسيق: `gofmt -w .` و`go vet ./...`

## الاصطلاحات
- لا تبتلع الأخطاء. عالجها دائما بـ `if err != nil`، وأعدها
  مع سياق (`fmt.Errorf("...: %w", err)`).
- أبقِ التداخل ضحلا باستخدام الإرجاع المبكر.
- استخدم التزامن (concurrency) فقط عند الحاجة. انتبه لتسرب goroutine والتسابقات
  (اجعل `go test -race` ينجح).
- علّق على الرموز المصدَّرة. فضّل المكتبة القياسية.

## القواعد المطلقة
- لا تضِف تجريدات أو واجهات غير ضرورية (أنشئها عند الحاجة).
- قبل إضافة تبعية، تحقق أولا مما إذا كانت المكتبة القياسية تكفي.

## تعريف الاكتمال
ينجح `go build ./...` و`go vet ./...` و`go test -race ./...` جميعها.

# Rust

## الأوامر
- البناء:  `cargo build`
- الاختبار: `cargo test`
- التحقق:  `cargo clippy -- -D warnings`
- التنسيق: `cargo fmt`

## الاصطلاحات
- لا تستخدم `unwrap()` / `expect()` باستهتار في كود الإنتاج.
  عالج `Result` / `Option` بشكل صحيح بـ `?` أو match.
- `unsafe` محظور من حيث المبدأ. إن كان ضروريا حقا، فاذكر السبب في تعليق.
- اتبع المُصرّف في الاستعارة (borrowing) ودورات الحياة. أعِد التفكير في التصميم
  قبل الهروب بـ `clone()`.
- اجعل أنواع الأخطاء ذات معنى بـ `thiserror` / `anyhow` وغيرهما.

## تعريف الاكتمال
ينجح `cargo build` و`cargo test`،
ويبلّغ `cargo clippy -- -D warnings` عن صفر تحذيرات.

# Ruby on Rails

## الأوامر
- التشغيل: `bin/rails server`
- الترحيل:  `bin/rails db:migrate`
- الاختبار: `bin/rails test` (أو `bundle exec rspec`)
- التنسيق:  `bundle exec rubocop -A`

## الاصطلاحات (اتبع طريقة Rails)
- احترم "الاصطلاح قبل الإعداد"؛ لا تخترع بنيتك الخاصة.
- تجنب المتحكمات / النماذج السمينة. ادفع المنطق إلى Services / Concerns.
- قيّد المدخلات بالمعاملات القوية (strong parameters).
- تجنب N+1 (استخدم `includes`).
- تغييرات المخطط تنال ترحيلا جديدا. لا تحرر الترحيلات التي نُفّذت بالفعل.

## القواعد المطلقة
- لا تودع `.env` أو بيانات الاعتماد أبدا على الإطلاق.
- لا تنفذ أوامر مدمرة على قاعدة بيانات الإنتاج.
- عندما تغيّر سلوكا، أضف أو حدّث الاختبارات.

## تعريف الاكتمال
ينجح الاختبارات و`bundle exec rubocop`.

# SQL / ترحيلات قاعدة البيانات

## القواعد المطلقة (حماية البيانات أولا)
- لا تنفذ عمليات مدمرة على بيانات الإنتاج من تلقاء نفسك
  (DROP / TRUNCATE / DELETE أو UPDATE دون شرط).
- يجب أن توفر الترحيلات إجراء تراجع (rollback)، لا الاتجاه الأمامي فقط.
- لا تحرر الترحيلات التي نُفّذت بالفعل. أضِف دائما ترحيلات جديدة.
- احذف الأعمدة أو أعِد تسميتها على مراحل ("إضافة -> ترحيل -> إيقاف")؛ لا تفعل ذلك دفعة واحدة.

## اصطلاحات الاستعلام
- تجنب `SELECT *`؛ حدد الأعمدة التي تحتاجها.
- تأكد من أن شروط WHERE / JOIN يمكنها استخدام فهرس (index).
- قسّم التحديثات الكبيرة إلى دفعات لإبقاء وقت القفل قصيرا.
- لاستعلامات التحقق المدمرة، تأكد أولا من عدد الصفوف المتأثرة بـ `SELECT` قبل التنفيذ.

## تعريف الاكتمال
ينجح كل من التطبيق والتراجع في بيئة مكافئة للتجهيز (staging)، وتأكدت
من عدم وجود تغييرات غير مقصودة على البيانات الموجودة.

# نهج التطوير المدفوع بالاختبار

عند تغيير السلوك، اتبع هذه الحلقة في كل مرة:
1. اكتب أولا "اختبارا فاشلا" يعبّر عن السلوك المرغوب.
2. شغّل الاختبار وتأكد من فشله للسبب الصحيح.
3. اكتب الحد الأدنى من الكود اللازم لإنجاح الاختبار.
4. شغّل مجموعة الاختبارات الكاملة وتأكد من أن كل شيء أخضر.
5. أعِد الهيكلة (refactor) مع الإبقاء عليها خضراء.

## القواعد المطلقة
- لا تحذف أو تتخطّ الاختبارات لإنجاح المجموعة.
- لا تُضعف التأكيدات (assertions) لجعل الأمور خضراء.
- إن كان اختبار خاطئا حقا، فاشرح السبب قبل تغييره.
- الكود الجديد دون اختبارات ليس "منجزا".

## تعريف الاكتمال
تنجح المجموعة الكاملة، ولم تنخفض التغطية، وإعادة التطبيق
إلى حالته السابقة تجعل الاختبار الجديد يفشل (أي أنه اختبار ذو معنى).

# نهج تصحيح الأخطاء

تابع بهذا الترتيب. لا تصلح بالتخمين:
1. حدد خطوات إعادة الإنتاج (كيف يُثار الخطأ).
2. اكتب السلوك المتوقع والسلوك الفعلي، جملة واحدة لكل منهما.
3. كوّن فرضية. تحقق منها بالسجلات أو بإعادة إنتاج مصغّرة قبل الإصلاح.
4. بمجرد تحديد السبب، طبّق الإصلاح الأدنى.
5. بعد الإصلاح، تأكد من اختفاء الخطأ عبر خطوات إعادة الإنتاج ومن نجاح الاختبارات الموجودة.
6. إن أمكن، أضف اختبار انحدار (regression test) يلتقط هذا الخطأ.

## القواعد المطلقة
- لا تغيّر عدة أماكن دفعة واحدة بينما السبب مجهول.
- لا تتوقف عند "إنه يعمل الآن". اشرح سبب إصلاحه.
- لا تخلط إعادة هيكلة غير ذات صلة بتصحيح الأخطاء.

# نهج إعادة الهيكلة

## المبدأ الأساسي
لا تغيّر السلوك القابل للملاحظة من الخارج. لا تغيّر المخرجات أو التأثيرات
الجانبية لأي مدخل على الإطلاق.

## الخطوات
1. تأكد أولا من وجود اختبارات للمنطقة المستهدفة ومن أنها خضراء.
   إن لم توجد، فاكتب أولا اختبارات توصيف (characterization tests) تثبّت السلوك الحالي.
2. غيّر بخطوات صغيرة مفردة، وشغّل الاختبارات بعد كل خطوة.
3. أبقِ إيداعا واحدا = نوعا واحدا من التحسين.

## القواعد المطلقة
- لا تخلط إضافات الميزات أو إصلاحات الأخطاء بإعادة الهيكلة (اجعلها أعمالا منفصلة).
- إن تحول اختبار إلى الأحمر، فتوقف هناك فورا. لا تتابع.
- لا تغيّر تواقيع واجهة برمجة التطبيقات العامة من تلقاء نفسك (تأكد أولا إن لزم).

## تعريف الاكتمال
تبقى كل الاختبارات خضراء، ويصبح الكود أكثر قابلية للقراءة مع تكرار أقل.

# كيفية كتابة مستند تصميم

قبل التنفيذ، اكتب أولا ما يلي نثرا (لا تكتب كودا):

## 1. الهدف
المشكلة المراد حلها، وشروط اعتبارها محققة (معايير النجاح).

## 2. الحالة الراهنة والقيود
الإعداد الموجود، والتبعيات، والقيود الواجب احترامها (الأداء، التوافق، الموعد النهائي).

## 3. مقترح التصميم
- النهج المختار، والأنهج التي درستها ورفضتها (ولماذا).
- تدفق البيانات، والواجهات الرئيسية، والملفات المراد تغييرها.

## 4. المخاطر والأسئلة المفتوحة
ما قد ينكسر، والافتراضات التي تحتاج تأكيدا، والنقاط التي تحتاج قرارا.

## 5. الخطة
قسّم التنفيذ إلى خطوات صغيرة، مرتبة في وحدات قابلة للتحقق.

## القواعد
- لا تبدأ التنفيذ حتى يُعتمد هذا التصميم.
- اسرد المجهولات تحت "الأسئلة المفتوحة"؛ لا تملأها بافتراضاتك الخاصة.

# كيفية إجراء التغييرات الكبيرة

## المبدأ الأساسي
تجنب تغييرا عملاقا واحدا. قسّمه بحيث تكون كل خطوة قابلة للمراجعة
والاختبار و(بشكل مثالي) للنشر بشكل مستقل.

## الخطوات
1. فكّك التغييرات المؤدية إلى الشكل النهائي إلى سلسلة من خطوات صغيرة
   مستقلة، واعرضها.
2. لكل خطوة، اكتب "ماذا / لماذا / نطاق التأثير" في سطر أو سطرين.
3. بعد كل خطوة، شغّل مجموعة الاختبارات الكاملة وتأكد من اللون الأخضر قبل المتابعة.
4. تابع مع الحفاظ على التوافق مع الإصدارات السابقة (إضافة -> ترحيل -> إيقاف المسار القديم).

## القواعد المطلقة
- لا تعِد كتابة منطقة واسعة دفعة واحدة و"اختبرها كلها معا لاحقا".
- إن نمت خطوة أكثر من اللازم، فقسّمها أكثر.
- أبقِ كل خطوة عند درجة تفصيل يمكن التراجع عنها (revert).

## تعريف الاكتمال
الاختبارات خضراء بعد اكتمال كل الخطوات، وكل إيداع وسيط غير مكسور أيضا.

# تعليمات مراجعة الكود

راجع التغييرات، واجمعها حسب الخطورة، وأبلغ بهذا الترتيب:
1. CRITICAL - ثغرات أمنية، فقدان بيانات، أعطال، مصادقة مكسورة
2. HIGH     - أخطاء منطقية، حالات تسابق، معالجة أخطاء مفقودة
3. MEDIUM   - مشكلات أداء، اختبارات مفقودة، تسميات مربكة
4. LOW      - ملاحظات نمط طفيفة (فقط إن لم توجد مشكلات أعلى)

## كيفية الإبلاغ
- لكل ملاحظة: file:line / ما الخطأ / لماذا يهم / إصلاح ملموس.
- اقتبس أصغر مقتطف ذي صلة فقط. لا تلصق الملف بأكمله.
- إن كان تغيير صحيحا، فقل ذلك صراحة. لا تختلق مشكلات.

## أمور يجب عدم فعلها
- لا تدفن الأخطاء الحقيقية تحت كومة من ملاحظات LOW.
- لا تعِد كتابة ملفات كاملة. اقترح أصغر diff.
- ما لم يكن هناك ضرر حقيقي، لا تشر إلى أسطر خارج نطاق diff.

## المخرجات
اختم بحكم من سطر واحد: APPROVE / REQUEST CHANGES / BLOCK، مع سبب.

# قواعد Git / PR

## الإيداعات
- استخدم Conventional Commits: `type(scope): summary`
  النوع: feat, fix, refactor, test, docs, chore.
- إيداع واحد = تغيير منطقي واحد. أبقِه صغيرا وقابلا للمراجعة.
- في النص، اكتب "لماذا" بدلا من "ماذا".

## القواعد المطلقة
- لا تنفذ `git push` ما لم يُطلب منك ذلك.
- لا تنفذ force-push أو rebase أو amend على الفروع المشتركة / main.
- لا تودع الأسرار أو .env أو بيانات الاعتماد أو الملفات الثنائية الكبيرة.
- أضِف الملفات بالاسم. لا تجرف كل شيء بـ `git add -A`.

## طلبات السحب
- العنوان ضمن 70 حرفا. النص هو "ملخص" + "خطة اختبار (قائمة تحقق)".
- اذكر أي تغييرات كاسرة.
- لا تدمج. أنشئ طلب السحب وأبلغ بالرابط (URL).

# تعليمات المراجعة الأمنية

افحص التغييرات بالترتيب مقابل الزوايا التالية، وأبلغ عن أي
مشكلات تجدها مع تقييم للخطورة:
- التحقق المفقود من المدخلات (الحقن: SQL / command / XSS / SSRF)
- ثغرات المصادقة/التفويض (فحوص أذونات مفقودة، تصعيد الامتيازات)
- كشف الأسرار (مفاتيح/رموز مكتوبة مباشرة، الإخراج إلى السجلات)
- الإعدادات الافتراضية غير الآمنة (تعريض مفرط، CORS متساهل، عمليات إعادة توجيه غير متحقَّق منها)
- الثغرات المعروفة في التبعيات، استخدام تشفير / مولد أرقام عشوائية (RNG) غير آمن

## كيفية الإبلاغ
- لكل ملاحظة: الموقع / سيناريو الهجوم (كيف يمكن استغلاله) / إصلاح ملموس.
- ضع علامة على الشكوك التي لست متيقنا منها بأنها "تحتاج تأكيدا" (لا تتخطّها بصمت).
- إن لم توجد مشكلة، فاذكر "لا مشكلات" مع الزوايا التي فحصتها.

## أمور يجب عدم فعلها
- لا تولّد كود هجوم فعليا أو خطوات استغلال (أظهِر الإصلاحات فقط).

# قواعد عمل Docker / البنية التحتية

## القواعد المطلقة (منع التدمير أولا)
- لا تنفذ أوامر مدمرة على بيئات الإنتاج أو المشتركة من تلقاء نفسك
  (`docker system prune`، حذف وحدات التخزين، `down -v` وغيرها).
- ثبّت الصور بوسوم (tags) ثابتة. لا تعتمد على `latest`.
- مرّر الأسرار عبر متغيرات البيئة / إدارة الأسرار.
  لا تدمجها داخل Dockerfile أو الصورة.
- أبقِ المنافذ المعرّضة والامتيازات (privileged وغيرها) في الحد الأدنى الضروري.

## الاصطلاحات
- أبقِ ملفات Dockerfile صغيرة ببناء متعدد المراحل، مع مراعاة التخزين المؤقت للطبقات.
- شغّل كمستخدم غير جذري (non-root).
- بعد التغييرات، ابنِ وشغّل محليا للتحقق قبل الإبلاغ.

## تعريف الاكتمال
ينجح `docker build`، وتبدأ الحاوية، ويمكن تأكيد فحص الصحة / التشغيل الأساسي.

# قواعد التبعيات

## القواعد المطلقة
- قبل إضافة تبعية، تحقق مما إذا كانت المكتبة القياسية أو تبعية
  موجودة تكفي.
- عند إضافة تبعية جديدة، أضِف ملاحظة من سطر واحد عن غرضها وبدائلها
  وحالة صيانتها.
- لا ترفع الإصدارات الرئيسية من تلقاء نفسك (فقط عند الطلب).
- لا تعِد توليد ملفات القفل (package-lock.json وغيرها) من تلقاء نفسك.
- تجنب الحزم مشكوكة المصدر أو ذات النجوم القليلة جدا أو الصيانة الضعيفة.

## الخطوات
1. اذكر سبب الإضافة أو التحديث.
2. بعد إضافتها، تأكد من نجاح البناء والاختبارات.
3. تأكد من أن الترخيص لا يتعارض مع حالة استخدامك.

## تعريف الاكتمال
ينجح البناء والاختبارات بعد تغيير التبعية، ويمكنك شرح الفرق (diff) في ملف القفل.