@tera-system/pro 0.1.4 → 0.2.0

package/core/tera-system/Tera_Project_Preparation_Files.md

@@ -1,1045 +0,0 @@
-# Tera Agent — Project Preparation Files Guide
-
-## الهدف من هذا الملف
-
-هذا الملف يحدد الملفات التي يمكن أن يجهزها **العميل تيرا** عند بدء أي مشروع جديد، بعد استلام:
-
-1. ملف فكرة التطبيق العامة.
-2. ملف المعلومات التقنية المتاحة.
-3. أي مرفقات داعمة مثل صور، ألوان، أمثلة، ملفات Excel، أو مراجع.
-
-ليس المطلوب أن ينشئ العميل تيرا جميع الملفات دائمًا.
-المطلوب أن يقرر، حسب طبيعة التطبيق، أي الملفات ضرورية للتنفيذ المنظم والدقيق.
-
----
-
-# قاعدة العمل العامة
-
-يقسم العميل تيرا الملفات إلى ثلاث فئات:
-
-| الفئة | المعنى | متى تُستخدم؟ |
-|---|---|---|
-| ملفات رئيسية | ملفات أساسية لأي مشروع تقريبًا | تُنشأ غالبًا في كل مشروع |
-| ملفات مشروطة | ملفات مهمة حسب طبيعة التطبيق | تُنشأ إذا وُجد سبب واضح لها |
-| ملفات ثانوية | ملفات داعمة أو تنظيمية | تُنشأ في المشاريع المتوسطة والكبيرة أو عند الحاجة |
-
----
-
-## Relationship Between project-inputs and project-preparation
-
-- `project-inputs/` contains the user's initial raw project inputs.
-- `project-preparation/` contains the formal preparation files produced by Tera after understanding those inputs.
-- `00_PROJECT_INPUTS.md` does not replace `project-inputs/`; it summarizes and normalizes them.
-- ApplicationBlueprintAgent (مُهندس — SCP-2026-07-28-118) must not start formal preparation files before minimum `Project Intake Gate` completion.
-- `clients/` contains official client-facing records, approval packages, assets, communication summaries, and delivery material for external client projects.
-- Client-facing approval files must not be mixed with internal `project-preparation/` files.
-
-External client project structure:
-
-```text
-clients/
-  CLIENT-[client-name-or-id]/
-    CLIENT_PROFILE.md
-    CONTACTS.md
-    applications/
-      APP-[app-name-or-id]/
-        client-approval/
-        client-assets/
-        client-communications/
-        delivery/
-```
-
----
-
-# Client-Facing Files
-
-هذه الملفات ليست بديلة عن ملفات التحضير الداخلية، بل هي مخرجات موجهة للعميل للمراجعة والاعتماد قبل التنفيذ.
-
-الموقع الرسمي:
-
-```text
-clients/CLIENT-[client-name-or-id]/applications/APP-[app-name-or-id]/client-approval/
-```
-
-## Mandatory Client Approval Package
-
-في مشاريع العملاء الخارجيين، حزمة اعتماد العميل إلزامية قبل التنفيذ.
-
-الملفات الافتراضية، بوابات الاعتماد، وقواعد الاستثناء المحدود موثقة رسميًا في:
-
-```text
-tera-system/TeraClientPolicy.md (Section 7)
-tera-system/runtime/TERA_RUNTIME_TEMPLATES.md
-```
-
-قواعد إلزامية:
-
-- الوثائق الموجهة للعميل تكتب بالعربية افتراضيًا.
-- لا تذكر تفاصيل Tera الداخلية أو العملاء الفرعيين أو سياسات التشغيل.
-- لا يدخل المشروع Build Mode قبل اعتماد النطاق وحزمة العميل.
-- أي ملف غير مناسب لمشروع صغير يجب توثيق سبب عدم استخدامه في سجل اعتماد العميل.
-
----
-
-# Blueprinting Artifacts (Pre-Preparation, Non-Baseline)
-
-هذه المواد تُنشأ فقط إذا فُعّل `ApplicationBlueprintAgent` (مُهندس) بعد handoff عميل مؤكد. **SCP-2026-07-28-118: مُهندس يملك الآن phases 1–4 كاملة — من blueprint حتى baseline.**
-
-ليست بديلة عن ملفات التحضير الرسمية، ولا تُستهلك downstream مباشرة.
-
-## APPLICATION_BLUEPRINT.md
-
-**الموقع الرسمي:**
-
-```text
-project-preparation/APPLICATION_BLUEPRINT.md
-```
-
-**الغرض:**
-تحويل handoff المعتمد إلى blueprint داخلي عالي المستوى يساعد Tera لاحقاً في بدء التحضير الرسمي.
-
-**قاعدة إلزامية:**
-
-```text
-APPLICATION_BLUEPRINT.md starts as Draft.
-It must not be used for formal preparation until status = approved_for_preparation.
-```
-
-## BLUEPRINT_OPEN_QUESTIONS.md
-
-ملف اختياري لتجميع الأسئلة التي تمنع إكمال الـ blueprint أو تحتاج قراراً قبل التحضير الرسمي.
-
-## BLUEPRINT_DECISION_CANDIDATES.md
-
-ملف اختياري لتوثيق المرشحات والتوصيات (مثل التقنية، الاستضافة، قاعدة البيانات) بصيغة candidates فقط، لا كقرارات نهائية.
-
-## draft-seeds/
-
-```text
-project-preparation/draft-seeds/
-```
-
-يحوي Draft Seeds فقط عند الحاجة وضمن الضوابط التالية:
-
-- اختيارية وليست افتراضية
-- مبررة بوضوح
-- الحد الموصى به 3 ملفات فقط
-- تجاوز 3 يحتاج موافقة صريحة
-- كل ملف يجب أن يحمل: `Draft Seed` / `Not Baseline` / `Not approved for downstream execution`
-
-لا تُعد Draft Seeds جزءاً من baseline التحضيري، ويجب إعادة إنتاج محتواها أو اعتماده رسمياً ضمن ملفات التحضير المعتادة قبل أي استهلاك downstream.
-
----
-
-# Project Control Files
-
-هذه الملفات ليست ملفات تحليل أو تصميم للتطبيق.
-
-هي سجلات إدارية لتتبع التنفيذ:
-
-```text
-project-control/TASK_REGISTRY.md
-project-control/PROJECT_ACTIVITY_LOG.md
-project-control/ISSUES_AND_GAPS.md
-project-control/DECISIONS_LOG.md
-project-control/tasks/
-```
-
-لا تُنشأ كبديل عن ملفات `project-preparation/`.
-
-تستخدم عند بدء التنفيذ أو عند الحاجة إلى تتبع المهام والنتائج والمراجعات والفجوات والقرارات.
-
----
-
-# أولًا: الملفات الرئيسية Core Files
-
-هذه الملفات تمثل الحد الأدنى المنظم لبدء أي تطبيق بشكل صحيح.
-
----
-
-## PROJECT_RULES.md
-
-### الغرض
-توثيق القواعد الخاصة بالمشروع الحالي بين صاحب المشروع وTera.
-
-هذا الملف اختياري، لكنه يصبح ملزمًا عند وجوده.
-
-### ماذا يحتوي؟
-- قيود تقنية خاصة بالمشروع.
-- قيود تصميم أو هوية.
-- قيود على المكتبات أو APIs.
-- قواعد تشغيل محلي أو نشر.
-- قواعد مستبعدة من النسخة الأولى.
-- أي تعليمات يجب ألا تضيع داخل المحادثة.
-
-### متى يُنشأ؟
-ينشأ إذا قدم صاحب المشروع قواعد خاصة أو قيودًا يريد إلزام Tera والعملاء الفرعيين بها.
-
-### أهميته
-يمنع ضياع القواعد داخل المحادثة، ويجعلها جزءًا من التفويض والمراجعة.
-
----
-
-## 00_PROJECT_INPUTS.md
-
-### الغرض
-ملف منظم ينتجه Tera من:
-
-- `project-inputs/01_APPLICATION_IDEA.md`
-- `project-inputs/02_TECHNICAL_CONTEXT.md`
-
-ويجمع فكرة التطبيق، والسياق التقني، والقيود الأولية في صيغة موحدة قبل بقية ملفات التحضير.
-
-### ماذا يحتوي؟
-- اسم المشروع.
-- وصف الفكرة العامة.
-- ملفات الـ intake المستلمة.
-- المعلومات التقنية المتوفرة.
-- الصور أو المراجع أو الألوان إن وجدت.
-- الافتراضات الأولية.
-- المعلومات الناقصة.
-- الأسئلة التي تحتاج توضيحًا لاحقًا.
-
-### أهميته
-يمنع ضياع المعلومات، ويجعل بداية المشروع مبنية على مدخلات واضحة لا على ذاكرة أو فهم متفرق.
-
----
-
-## 01_PROJECT_BRIEF.md
-
-### الغرض
-تحويل فكرة التطبيق إلى ملخص تنفيذي واضح ومفهوم.
-
-### ماذا يحتوي؟
-- ما هو التطبيق؟
-- من المستخدمون المستهدفون؟
-- ما المشكلة التي يحلها؟
-- ما الهدف من التطبيق؟
-- ما نطاق النسخة الأولى؟
-- ما مؤشرات نجاح المشروع؟
-
-### أهميته
-يمثل مرجع الفهم الرئيسي للمشروع، ويمنع اختلاف تفسير الفكرة بين العميل تيرا والعملاء الفرعيين والمطور.
-
----
-
-## 02_SCOPE_AND_BOUNDARIES.md
-
-### الغرض
-تحديد حدود المشروع بوضوح.
-
-### ماذا يحتوي؟
-- ما هو داخل النطاق.
-- ما هو خارج النطاق.
-- الميزات المؤجلة.
-- الأمور غير المطلوبة في النسخة الأولى.
-- حدود التطبيق الوظيفية.
-- حدود التطبيق التقنية.
-
-### أهميته
-يحمي المشروع من التوسع العشوائي، ويمنع إدخال طلبات جديدة أثناء التنفيذ بدون قرار واضح.
-
----
-
-## 03_MODULES_AND_FEATURES.md
-
-### الغرض
-تقسيم التطبيق إلى موديولات وميزات واضحة.
-
-### ماذا يحتوي؟
-- الموديولات الرئيسية.
-- الميزات داخل كل موديول.
-- أولوية كل ميزة: أساسي، مهم، لاحق.
-- علاقة الموديولات ببعضها.
-- ملاحظات خاصة بكل موديول.
-
-### أهميته
-يساعد في تنظيم التحليل والتنفيذ، ويمنع التعامل مع التطبيق ككتلة واحدة غير واضحة.
-
----
-
-## 04_USERS_ROLES_PERMISSIONS.md
-
-### الغرض
-تحديد المستخدمين والأدوار والصلاحيات الوظيفية.
-
-### ماذا يحتوي؟
-- أنواع المستخدمين.
-- الأدوار Roles.
-- صلاحيات كل دور.
-- من يستطيع الإضافة.
-- من يستطيع التعديل.
-- من يستطيع الحذف.
-- من يستطيع الاعتماد.
-- من يستطيع العرض فقط.
-- قواعد الوصول للبيانات.
-
-### أهميته
-الصلاحيات تؤثر على الشاشات، العمليات، الأمان، التقارير، والاختبارات. تأخيرها يسبب إعادة عمل كبيرة.
-
----
-
-## 05_BUSINESS_WORKFLOWS.md
-
-### الغرض
-تحديد مسارات العمل الأساسية داخل التطبيق.
-
-### ماذا يحتوي؟
-- دورة كل عملية رئيسية.
-- الحالات Statuses.
-- الانتقالات بين الحالات.
-- من ينفذ كل خطوة.
-- شروط الانتقال من حالة إلى أخرى.
-- حالات الرفض أو الإلغاء.
-- الاستثناءات المهمة.
-
-### أهميته
-يضمن أن التطبيق يعكس دورة العمل الحقيقية، وليس مجرد شاشات إدخال وعرض.
-
----
-
-## 06_DATA_MODEL_PREPARATION.md
-
-### الغرض
-تجهيز تصور أولي للبيانات قبل تصميم قاعدة البيانات النهائي.
-
-### ماذا يحتوي؟
-- الكيانات الأساسية.
-- الجداول المتوقعة مبدئيًا.
-- أهم الحقول.
-- العلاقات بين الكيانات.
-- البيانات المرجعية.
-- القيود المهمة.
-- ملاحظات حول البيانات الحساسة أو المتكررة.
-
-### أهميته
-يمنع العشوائية في بناء قاعدة البيانات، ويكشف مبكرًا العلاقات والبيانات الناقصة.
-
----
-
-## 07_SCREENS_AND_UI_STRUCTURE.md
-
-### الغرض
-تحديد الشاشات المطلوبة وهيكل الواجهة.
-
-### ماذا يحتوي؟
-- قائمة الشاشات.
-- وظيفة كل شاشة.
-- الحقول الأساسية.
-- الأزرار والإجراءات.
-- الفلاتر.
-- الجداول.
-- التنبيهات.
-- ملاحظات التصميم وتجربة المستخدم.
-
-### أهميته
-يمنع بناء واجهة غير مكتملة أو غير متوافقة مع العمليات والصلاحيات.
-
----
-
-## CONTENT_REQUIREMENTS.md — (مشروط — SCP-2026-08-15-016)
-
-### الغرض
-تثبيت **رسائل المحتوى** لكل شاشة/صفحة لمشاريع المحتوى (Website/Landing/Content-heavy) — ماذا يريد المالك أن يظهر فعلياً داخل كل صفحة وقسم، بمعزل عن التصميم البصري.
-
-### متى يُنشأ؟
-- **مشروط:** فقط عندما يكون Content Type = `User-Facing Content` / `Mixed` (من Discovery — Domain 4).
-- **التوقيت:** بعد `07_SCREENS_AND_UI_STRUCTURE.md` وقبل التصميم النهائي (28) وقبل Phase 5.
-- التطبيقات القياسية (Application Data فقط) **لا** تحتاجه — يكفي قسم خفيف داخل 07 إن لزم.
-
-### ماذا يحتوي؟
-لكل شاشة/صفحة (S1..Sn + المشتركة):
-- Purpose (الغرض)
-- Audience (الجمهور)
-- Primary Message (الرسالة الأساسية)
-- Required Content (المحتوى المطلوب ظهوره)
-- CTA (الدعوة للإجراء)
-- Forbidden (الممنوع/الحساس — من الخطوط الحمراء D-015)
-- Claims المسموحة (أرقام موثقة في مصادر الحقيقة فقط)
-- Content Priorities (الأولويات بين الرسائل)
-- Content Owner (المالك/المصدر)
-
-### أهميته
-يمنع المنظومة من افتراض المحتوى بدل المالك، ويعزل أي اعتراض على محتوى في شاشة واحدة بدل إعادة تصميم التطبيق كاملاً.
-
-### القالب
-`tera-system/runtime/TERA_RUNTIME_TEMPLATES_PREPARATION.md` — §41
-
----
-
-## 08_TECHNICAL_ARCHITECTURE.md
-
-### الغرض
-تثبيت القرارات التقنية الأساسية للمشروع.
-
-### ماذا يحتوي؟
-- لغة البرمجة.
-- Framework.
-- قاعدة البيانات.
-- نمط التطبيق: Web، API، Mobile، Desktop.
-- طريقة المصادقة.
-- بنية المشروع.
-- طريقة التعامل مع الملفات.
-- قواعد الأمان الأساسية.
-- بيئة التشغيل والنشر المتوقعة.
-
-### أهميته
-يمنع تضارب القرارات التقنية بين العملاء الفرعيين أثناء التنفيذ.
-
----
-
-## 09_IMPLEMENTATION_PLAN.md
-
-### الغرض
-تحويل التحليل إلى خطة تنفيذ مبدئية ضمن ملفات التحضير.
-
-### ماذا يحتوي؟
-- مراحل التنفيذ.
-- ترتيب بناء الموديولات.
-- المهام الرئيسية.
-- الاعتماديات بين المهام.
-- النسخة الأولى MVP.
-- ما يتم تنفيذه أولًا.
-- ما يتم تأجيله.
-- توزيع مبدئي للمهام على العملاء الفرعيين.
-
-### أهميته
-يمثل جسرًا بين التحضير والتخطيط التنفيذي، لكنه **ليس** خطة التنفيذ الرسمية النهائية.
-
-الخطط الرسمية للتنفيذ بعد اعتماد التحضير تكون داخل `project-control/`:
-
-```text
-PROJECT_MASTER_PLAN.md
-PROJECT_DETAILED_EXECUTION_PLAN.md
-EXECUTION_BATCH_PLAN.md
-```
-
----
-
-## 10_TESTING_AND_ACCEPTANCE.md
-
-### الغرض
-تحديد طريقة اختبار التطبيق ومعايير قبوله.
-
-### ماذا يحتوي؟
-- سيناريوهات الاختبار الأساسية.
-- اختبارات الصلاحيات.
-- اختبارات الإدخال.
-- اختبارات الحالات Workflows.
-- اختبارات التقارير.
-- اختبارات الأخطاء والاستثناءات.
-- معايير قبول كل موديول.
-- الأخطاء التي لا يسمح بتمريرها.
-
-### أهميته
-يقلل الأخطاء قبل التسليم، ويحول الاختبار من عمل عشوائي إلى عملية منظمة.
-
----
-
-## 11_DELIVERY_AND_HANDOVER.md
-
-### الغرض
-تجهيز التسليم النهائي للتطبيق.
-
-### ماذا يحتوي؟
-- قائمة ما سيتم تسليمه.
-- خطوات التشغيل.
-- بيانات الدخول التجريبية إن وجدت.
-- ملاحظات النشر.
-- قائمة الفحوصات النهائية.
-- الملفات المطلوبة للتسليم.
-- ملاحظات الدعم أو الصيانة.
-
-### أهميته
-يضمن أن نهاية المشروع واضحة، وأن التسليم لا يعتمد على ذاكرة المطور أو العميل تيرا.
-
----
-
-# ثانيًا: الملفات المشروطة Conditional Files
-
-هذه الملفات لا تُنشأ دائمًا، لكنها تصبح ضرورية إذا كانت طبيعة التطبيق تتطلبها.
-
----
-
-## 12_BUSINESS_RULES.md
-
-### الغرض
-توثيق قواعد العمل التي تتحكم في سلوك التطبيق.
-
-### ماذا يحتوي؟
-- شروط السماح أو المنع.
-- قواعد الاعتماد.
-- قواعد التعديل والحذف.
-- قواعد الاحتساب.
-- قواعد تغيير الحالة.
-- قواعد التحقق المرتبطة بالعمل.
-
-### أهميته
-ضروري في التطبيقات التي تحتوي على منطق عمل مهم مثل ERP، محاسبة، مخزون، موارد بشرية، أنظمة مالية، أو أنظمة موافقات.
-
----
-
-## 13_REPORTS_AND_DASHBOARDS.md
-
-### الغرض
-تحديد التقارير ولوحات المعلومات المطلوبة.
-
-### ماذا يحتوي؟
-- أسماء التقارير.
-- الغرض من كل تقرير.
-- الفلاتر.
-- الأعمدة.
-- التجميعات.
-- مؤشرات Dashboard.
-- صلاحيات عرض التقارير.
-- خيارات التصدير Excel / PDF.
-
-### أهميته
-مهم عندما تكون التقارير جزءًا أساسيًا من قيمة التطبيق، ولا يكفي دمجها داخل ملف الشاشات.
-
----
-
-## 14_INTEGRATIONS_AND_EXTERNAL_SERVICES.md
-
-### الغرض
-توثيق أي ربط مع أنظمة أو خدمات خارجية.
-
-### ماذا يحتوي؟
-- أسماء الخدمات الخارجية.
-- نوع التكامل.
-- اتجاه البيانات: إرسال، استقبال، أو الاثنين.
-- بيانات الربط المطلوبة.
-- نقاط API إن وجدت.
-- شروط الفشل وإعادة المحاولة.
-- حدود الخدمة الخارجية.
-
-### أهميته
-ضروري عند وجود تكامل مع دفع إلكتروني، رسائل، بريد، WhatsApp، ERP آخر، نظام محاسبي، Google Services، أو AI APIs.
-
----
-
-## 15_SECURITY_AND_ACCESS_CONTROL.md
-
-### الغرض
-تحديد الجوانب الأمنية التقنية للتطبيق.
-
-### ماذا يحتوي؟
-- Authentication.
-- Authorization.
-- إدارة الجلسات.
-- سياسة كلمات المرور.
-- حماية البيانات الحساسة.
-- منع الوصول غير المصرح.
-- صلاحيات API.
-- قواعد الوصول حسب الشركة أو الفرع أو القسم.
-
-### أهميته
-ضروري في التطبيقات متعددة المستخدمين، الأنظمة المالية، SaaS، ERP، أو أي تطبيق يحتوي على بيانات حساسة.
-
----
-
-## 16_AUDIT_LOG_AND_ACTIVITY_TRACKING.md
-
-### الغرض
-تحديد ما يجب تتبعه من أنشطة المستخدمين داخل النظام.
-
-### ماذا يحتوي؟
-- العمليات التي يجب تسجيلها.
-- المستخدم المنفذ.
-- التاريخ والوقت.
-- نوع العملية.
-- البيانات قبل وبعد التعديل.
-- عمليات الدخول والخروج.
-- الأحداث الحساسة.
-
-### أهميته
-ضروري عند وجود تعديلات مهمة، حذف، اعتماد، حركات مالية، صلاحيات، أو مسؤولية تشغيلية.
-
----
-
-## 17_NOTIFICATIONS_AND_ALERTS.md
-
-### الغرض
-تنظيم التنبيهات والإشعارات داخل التطبيق.
-
-### ماذا يحتوي؟
-- أنواع التنبيهات.
-- سبب إرسال التنبيه.
-- المستلمون.
-- طريقة الإرسال: داخل النظام، بريد، SMS، WhatsApp.
-- توقيت التنبيه.
-- نصوص التنبيهات.
-- حالات إيقاف أو تجاهل التنبيه.
-
-### أهميته
-مهم في تطبيقات الموافقات، التحصيل، المواعيد، المهام، المتابعة، وERP.
-
----
-
-## 18_IMPORT_EXPORT_DATA.md
-
-### الغرض
-تنظيم استيراد وتصدير البيانات.
-
-### ماذا يحتوي؟
-- أنواع الملفات المدعومة.
-- Excel import.
-- Excel export.
-- CSV.
-- PDF export.
-- قوالب الاستيراد.
-- قواعد التحقق من البيانات.
-- رسائل أخطاء الاستيراد.
-- طريقة معالجة البيانات المكررة أو غير الصحيحة.
-
-### أهميته
-ضروري في التطبيقات الإدارية والتجارية التي تعتمد على إدخال أو إخراج بيانات بكميات كبيرة.
-
----
-
-## 19_DATABASE_DESIGN.md
-
-### الغرض
-تحويل تصور البيانات إلى تصميم فعلي لقاعدة البيانات.
-
-### ماذا يحتوي؟
-- الجداول النهائية.
-- الحقول النهائية.
-- المفاتيح الأساسية.
-- المفاتيح الأجنبية.
-- العلاقات.
-- Indexes.
-- Constraints.
-- Naming conventions.
-- Seed data.
-
-### أهميته
-ضروري في المشاريع المتوسطة والكبيرة، خصوصًا عندما يكون نموذج البيانات معقدًا أو حساسًا.
-
----
-
-## 20_API_CONTRACTS.md
-
-### الغرض
-توثيق عقود API بين الواجهة والخلفية أو بين النظام والأنظمة الخارجية.
-
-### ماذا يحتوي؟
-- Endpoints.
-- Request structure.
-- Response structure.
-- Validation rules.
-- Error codes.
-- Status codes.
-- Authentication headers.
-- Pagination.
-- Filtering and sorting.
-
-### أهميته
-ضروري عند وجود Frontend وBackend منفصلين، تطبيق موبايل، تكامل خارجي، أو Microservices.
-
----
-
-## 21_VALIDATION_AND_ERROR_HANDLING.md
-
-### الغرض
-تحديد قواعد التحقق ورسائل الأخطاء.
-
-### ماذا يحتوي؟
-- الحقول المطلوبة.
-- أنواع البيانات.
-- الحدود الدنيا والعليا.
-- قواعد الإدخال.
-- رسائل الخطأ.
-- الأخطاء المتوقعة.
-- طريقة التعامل مع الأخطاء الفنية.
-- قواعد منع البيانات غير الصحيحة.
-
-### أهميته
-مهم جدًا في التطبيقات التي تحتوي على نماذج إدخال كثيرة أو بيانات حساسة.
-
----
-
-## 22_DEPLOYMENT_AND_ENVIRONMENTS.md
-
-### الغرض
-تنظيم بيئات التشغيل والنشر.
-
-### ماذا يحتوي؟
-- بيئة التطوير Development.
-- بيئة الاختبار Testing.
-- بيئة التجربة Staging.
-- بيئة الإنتاج Production.
-- متغيرات البيئة.
-- إعدادات السيرفر.
-- Domain و SSL.
-- خطوات النشر.
-- ملاحظات التحديثات.
-
-### أهميته
-ضروري لأي تطبيق سيتم تشغيله فعليًا على سيرفر أو Cloud أو لدى عميل.
-
----
-
-## 23_BACKUP_AND_RECOVERY.md
-
-### الغرض
-تحديد سياسة النسخ الاحتياطي والاسترجاع.
-
-### ماذا يحتوي؟
-- ما الذي سيتم نسخه.
-- تكرار النسخ الاحتياطي.
-- مكان حفظ النسخ.
-- مدة الاحتفاظ.
-- طريقة الاسترجاع.
-- اختبار الاسترجاع.
-- مسؤولية النسخ الاحتياطي.
-
-### أهميته
-ضروري في أي تطبيق يحتوي على بيانات مهمة. تجاهله في الأنظمة الإنتاجية خطر واضح.
-
----
-
-## 24_CLIENT_REVIEW_NOTES.md
-
-### الغرض
-تجميع ملاحظات العميل وقرارات المراجعة.
-
-### ماذا يحتوي؟
-- ملاحظات العميل.
-- قرارات الاجتماعات.
-- النقاط المقبولة.
-- النقاط المرفوضة.
-- النقاط المؤجلة.
-- الأسئلة المفتوحة.
-- تاريخ كل مراجعة.
-
-### أهميته
-مهم في المشاريع التي يوجد فيها عميل خارجي أو مراجعات متكررة، ويمنع الخلافات وسوء الفهم.
-
----
-
-## 25_CHANGE_REQUESTS.md
-
-### الغرض
-إدارة التعديلات التي تظهر بعد تثبيت النطاق.
-
-### ماذا يحتوي؟
-- وصف طلب التغيير.
-- سبب الطلب.
-- أثره على الوقت.
-- أثره على التكلفة.
-- أثره على النطاق.
-- أثره على التصميم أو قاعدة البيانات.
-- قرار القبول أو الرفض أو التأجيل.
-
-### أهميته
-ضروري في العمل التجاري. بدونه يتحول المشروع إلى تعديلات مفتوحة وغير مضبوطة.
-
----
-
-# ثالثًا: الملفات الثانوية Supporting Files
-
-هذه الملفات ليست أساسية في البداية، لكنها مفيدة في المشاريع الأكبر أو الأكثر تنظيمًا.
-
----
-
-## 26_RISKS_AND_ASSUMPTIONS.md
-
-### الغرض
-توثيق المخاطر والافتراضات المهمة.
-
-### ماذا يحتوي؟
-- المخاطر المتوقعة.
-- أثر كل خطر.
-- احتمالية حدوثه.
-- طريقة التعامل معه.
-- الافتراضات التي بُني عليها التحليل.
-- الأمور التي تحتاج تأكيدًا لاحقًا.
-
-### أهميته
-مفيد في المشاريع الكبيرة أو الغامضة، لكنه غير ضروري كمستند مستقل في التطبيقات الصغيرة.
-
----
-
-## 27_DECISIONS_LOG.md
-
-### الغرض
-توثيق القرارات المهمة أثناء المشروع.
-
-### ماذا يحتوي؟
-- القرار.
-- سبب القرار.
-- تاريخ القرار.
-- من طلبه أو وافق عليه.
-- البدائل التي تم رفضها.
-- أثر القرار على المشروع.
-
-### أهميته
-مهم عند تعدد الأطراف أو العملاء الفرعيين، ويمنع الرجوع المتكرر لنفس النقاش.
-
----
-
-## 28_UI_UX_GUIDELINES.md
-
-### الغرض
-تحديد القواعد التنفيذية النهائية للتصميم والستايل البصري قبل أي تخطيط أو تنفيذ Frontend.
-
-هذا الملف ليس مطلوبًا في مشاريع API/backend فقط، لكنه يصبح مطلوبًا عند وجود أي واجهة ذات ستايل بصري، أو عند استخدام Internal Kit، أو `getdesign.md`، أو صور/موقع/Figma/CSS/Design Tokens من العميل.
-
-### ماذا يحتوي؟
-- Design Source Decision: `INTERNAL_TERA_KIT` / `GETDESIGN_MD` / `FIGMA_DESIGN_FILE` / `USER_PROVIDED_REFERENCE` / `EXTERNAL_URL_ANALYSIS` / `HYBRID` / `NO_UI` / `N/A`.
-- Approved Design Direction.
-- Raw Design Sources داخل `project-preparation/design-source/`.
-- Client Branding Overrides.
-- Design Tokens.
-- Layout System.
-- Component Rules.
-- RTL/LTR Rules.
-- Responsive Rules.
-- Accessibility Rules.
-- Motion Rules.
-- Forbidden Styling.
-- Engineering Implementation Instructions.
-- UI Acceptance Checklist.
-- Open Design Gaps.
-
-### متى يُنشأ؟
-
-ينشأ هذا الملف إذا:
-
-- أعطى المستخدم ألوانًا أو تصميمًا أو هوية بصرية.
-- أعطى المستخدم CSS أو قالبًا أو Design Tokens.
-- أعطى المستخدم `getdesign.md` أو مرجعًا بصريًا خارجيًا.
-- احتاج التطبيق إلى واجهة موحدة قبل التنفيذ.
-- كان هناك أكثر من عميل أو دفعة تنفيذ ستعمل على الواجهة.
-- استخدم Tera أي Internal Kit من `tera-system/design-system/kits/`.
-
-### أهميته
-يمنع الستايل العشوائي، ويجعل التنفيذ ملتزمًا بمصدر تصميم واضح.
-
-لا يجوز لعميل التنفيذ اختراع ألوان أو spacing أو typography أو component styles أو layout patterns. إذا نقصت قاعدة تصميم، يرفع `Design Gap` بدل التخمين.
-
-المرجع النظامي:
-
-```text
-tera-system/design-system/
-```
-
----
-
-## 29_SAMPLE_DATA_AND_SEEDING.md
-
-### الغرض
-تجهيز بيانات تجريبية تساعد في التطوير والاختبار.
-
-### ماذا يحتوي؟
-- بيانات مستخدمين تجريبية.
-- بيانات مرجعية.
-- أمثلة معاملات.
-- حالات اختبار واقعية.
-- بيانات أولية Seed Data.
-
-### أهميته
-مفيد جدًا أثناء الاختبار والعرض التجريبي، خاصة في ERP والأنظمة الإدارية.
-
----
-
-## 30_USER_MANUAL_DRAFT.md
-
-### الغرض
-تجهيز مسودة دليل استخدام للتطبيق.
-
-### ماذا يحتوي؟
-- شرح الشاشات.
-- خطوات تنفيذ العمليات.
-- شرح الصلاحيات العامة.
-- ملاحظات الاستخدام.
-- الأسئلة المتكررة.
-
-### أهميته
-لا يُنشأ مبكرًا غالبًا، لكنه مهم قبل التسليم أو عند تدريب المستخدمين.
-
----
-
-## 31_MAINTENANCE_AND_SUPPORT.md
-
-### الغرض
-تحديد طريقة دعم التطبيق بعد التسليم.
-
-### ماذا يحتوي؟
-- أنواع الدعم.
-- مدة الدعم.
-- ما يشمله الدعم.
-- ما لا يشمله الدعم.
-- طريقة استقبال المشاكل.
-- أولوية الأخطاء.
-- آلية التحديثات.
-
-### أهميته
-مهم في المشاريع التجارية، ويمنع الخلط بين الدعم المجاني والتطوير الجديد.
-
----
-
-## 32_PERFORMANCE_REQUIREMENTS.md
-
-### الغرض
-تحديد متطلبات الأداء المتوقعة.
-
-### ماذا يحتوي؟
-- عدد المستخدمين المتوقع.
-- حجم البيانات المتوقع.
-- سرعة تحميل الشاشات.
-- سرعة التقارير.
-- العمليات الثقيلة.
-- حدود الأداء المقبولة.
-
-### أهميته
-مفيد في الأنظمة الكبيرة أو التي تحتوي على تقارير وبيانات كثيرة.
-
----
-
-## 33_MULTI_TENANCY_OR_COMPANY_STRUCTURE.md
-
-### الغرض
-تحديد طريقة دعم أكثر من شركة أو فرع أو عميل داخل نفس النظام.
-
-### ماذا يحتوي؟
-- هل النظام لشركة واحدة أم عدة شركات؟
-- الفروع.
-- الأقسام.
-- عزل البيانات.
-- صلاحيات الوصول حسب الشركة أو الفرع.
-- إعدادات كل شركة.
-
-### أهميته
-ضروري في SaaS وERP والأنظمة متعددة الشركات أو الفروع.
-
----
-
-## 34_COMPLIANCE_AND_LEGAL_NOTES.md
-
-### الغرض
-توثيق أي متطلبات قانونية أو تنظيمية.
-
-### ماذا يحتوي؟
-- شروط الخصوصية.
-- حماية البيانات.
-- المتطلبات القانونية الخاصة بالمجال.
-- الفواتير أو الضرائب إن وجدت.
-- الاحتفاظ بالسجلات.
-- التنبيهات القانونية المطلوبة.
-
-### أهميته
-مهم في التطبيقات المالية، الصحية، التعليمية، الحكومية، أو التي تحفظ بيانات حساسة.
-
----
-
-## 35_ROADMAP_AND_FUTURE_PHASES.md
-
-### الغرض
-تحديد ما بعد النسخة الأولى.
-
-### ماذا يحتوي؟
-- ميزات مستقبلية.
-- مراحل لاحقة.
-- تحسينات مؤجلة.
-- توسعات محتملة.
-- أولويات مستقبلية.
-
-### أهميته
-يساعد على ضبط التوقعات ومنع إدخال كل الأفكار في النسخة الأولى.
-
----
-
-# ملخص القرار العملي للعميل تيرا
-
-## عند بدء مشروع صغير
-ينشئ غالبًا:
-
-```text
-00_PROJECT_INPUTS.md
-01_PROJECT_BRIEF.md
-02_SCOPE_AND_BOUNDARIES.md
-03_MODULES_AND_FEATURES.md
-04_USERS_ROLES_PERMISSIONS.md
-05_BUSINESS_WORKFLOWS.md
-06_DATA_MODEL_PREPARATION.md
-07_SCREENS_AND_UI_STRUCTURE.md
-08_TECHNICAL_ARCHITECTURE.md
-09_IMPLEMENTATION_PLAN.md
-10_TESTING_AND_ACCEPTANCE.md
-11_DELIVERY_AND_HANDOVER.md
-```
-
-وقد يضيف:
-
-```text
-12_BUSINESS_RULES.md
-13_REPORTS_AND_DASHBOARDS.md
-22_DEPLOYMENT_AND_ENVIRONMENTS.md
-```
-
----
-
-## عند بدء مشروع متوسط
-ينشئ غالبًا الملفات الرئيسية، ويضيف حسب الحاجة:
-
-```text
-12_BUSINESS_RULES.md
-13_REPORTS_AND_DASHBOARDS.md
-14_INTEGRATIONS_AND_EXTERNAL_SERVICES.md
-15_SECURITY_AND_ACCESS_CONTROL.md
-16_AUDIT_LOG_AND_ACTIVITY_TRACKING.md
-17_NOTIFICATIONS_AND_ALERTS.md
-18_IMPORT_EXPORT_DATA.md
-21_VALIDATION_AND_ERROR_HANDLING.md
-22_DEPLOYMENT_AND_ENVIRONMENTS.md
-23_BACKUP_AND_RECOVERY.md
-24_CLIENT_REVIEW_NOTES.md
-25_CHANGE_REQUESTS.md
-```
-
----
-
-## عند بدء نظام كبير أو ERP أو SaaS
-يفحص الحاجة إلى جميع الملفات من:
-
-```text
-00_PROJECT_INPUTS.md
-إلى
-35_ROADMAP_AND_FUTURE_PHASES.md
-```
-
-لكن لا ينشئ أي ملف إلا إذا كان يخدم التحليل أو التنفيذ أو الاختبار أو التسليم.
-
----
-
-# قاعدة منع التضخيم
-
-على العميل تيرا الالتزام بالقاعدة التالية:
-
-> لا يتم إنشاء أي ملف فقط لأنه موجود في القائمة.
-> يتم إنشاء الملف فقط إذا كان غيابه سيؤدي إلى غموض، خطأ، إعادة عمل، ضعف أمان، سوء فهم، أو مشكلة في التسليم.
-
----
-
-# الصيغة النهائية لدور العميل تيرا في هذه المرحلة
-
-هذا الملف هو **كتالوج مرجعي** لملفات التحضير. لا يُنشئ تيرا الملفات مباشرة من هنا، بل:
-
-انظر `.opencode/agents/tera.md` القسم 11 للتسلسل العام للمراحل (7 مراحل).
-
-| المرحلة | ماذا يفعل تيرا |
-|---|---|
-| **2. Project Decision Formation** | يصنف حجم المشروع ويحدد الملفات المطلوبة مبدئياً في `TERA_PROJECT_DECISION.md` القسم 8 |
-| **بين TCEA و Phase 2 عند الحاجة** | يقرأ Tera الـ `APPLICATION_BLUEPRINT.md` فقط إذا كانت حالته `approved_for_preparation`، ولا يعامل `draft-seeds/` كـ baseline |
-| **3. Project Preparation Planning** | يقرأ الكتالوج، يصنف كل ملف (Required / Conditional / Deferred / Not Required)، يحدد الترتيب والمسؤول، وينتج `project-control/PREPARATION_PLAN.md` |
-| **4. Sub-Agent Generation & Preparation Delegation** | يولد العملاء الفرعيين المطلوبين ويفوّض إنشاء ملفات التحضير المخطط لها فقط |
-| **5. Execution Planning** | يحوّل ملفات التحضير المعتمدة إلى خطة تنفيذ رئيسية وتفصيلية ودفعات TASK-ID مع Pre-Execution Gate |
-| **6. Implementation** | ينفذ TASK-ID المعتمدة، يستلم Handback، يطبق Post-Execution Review، ثم يقبل أو يطلب إصلاح |
-| **7. Delivery, Handover & Closure** | يتحقق من جاهزية التسليم، القبول النهائي، Release Notes، Handover عند الحاجة، وتقرير إغلاق المشروع |
-
-**قاعدة منع التضخيم:**
-
-> لا يتم إنشاء أي ملف فقط لأنه موجود في القائمة.
-> يتم إنشاء الملف فقط إذا كان غيابه سيؤدي إلى غموض، خطأ، إعادة عمل، ضعف أمان، سوء فهم، أو مشكلة في التسليم.