@tera-system/core 0.2.0 → 0.2.2

package/core/tera-system/agent-helpers/Tera_Project_Preparation_Files_Conditional.md

@@ -0,0 +1,597 @@
+# Tera Agent — Conditional & Supporting Preparation Files Guide
+
+> هذا الملف المساعد يحتوي الملفات المشروطة والثانوية والملخصات التشغيلية المنقولة من:
+> `tera-system/Tera_Project_Preparation_Files.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 عند الحاجة، وتقرير إغلاق المشروع |
+
+**قاعدة منع التضخيم:**
+
+> لا يتم إنشاء أي ملف فقط لأنه موجود في القائمة.
+> يتم إنشاء الملف فقط إذا كان غيابه سيؤدي إلى غموض، خطأ، إعادة عمل، ضعف أمان، سوء فهم، أو مشكلة في التسليم.

package/core/tera-system/engineering-governance/ENGINEERING_AGENT_RESPONSIBILITIES.md

@@ -197,7 +197,7 @@ DesignReviewer remains visual/design focused. It may report engineering-adjacent
 - layout patterns not following `28_UI_UX_GUIDELINES.md`;
 - UI implementation that makes future visual changes unnecessarily hard.
 
-DesignReviewer may build static HTML/CSS prototypes from design sources for visual review when Majed requests. Prototypes are for review only, not production code. Temporary files stored in `project-control/prototypes/` and deleted after approval.
+DesignReviewer (ناقد) is a Tera-managed review sub-agent (SCP-2026-08-28-001) with independent judgment. It reviews prototypes built by Coding Agents (TASK-PROTO-*) before they are shown to Majed/the client, and reviews implemented UI. It does not build prototypes. The Reviewer Invocation Neutrality Rule applies (no expected-results feeding); findings escalate directly to Majed (three shields).
 
 DesignReviewer must not become a general code architecture auditor.
 

package/core/tera-system/runtime/TERA_RUNTIME_PROTOCOLS.md

@@ -6,9 +6,9 @@ This file now contains **Section 19** (Project Knowledge Management Protocol) af
 
 | Split file | Sections | Lines |
 |---|---|---|
-| `TERA_RUNTIME_PROTOCOLS_CORE.md` | 1–11 (Core operational) | ~758 |
-| `TERA_RUNTIME_PROTOCOLS_CLIENT.md` | 12–18 (Client & Discovery) | ~356 |
-| `TERA_RUNTIME_PROTOCOLS.md` (this file) | 19 (Knowledge Management) | ~38 |
+| `TERA_RUNTIME_PROTOCOLS_CORE.md` | 1–11 (Core operational) | 799 |
+| `TERA_RUNTIME_PROTOCOLS_CLIENT.md` | 12–18 (Client & Discovery) | 355 |
+| `TERA_RUNTIME_PROTOCOLS.md` (this file) | 19 (Knowledge Management) | 50 |
 
 Update any reference that pointed to Sections 1–18 to the new files.
 

package/core/tera-system/runtime/TERA_RUNTIME_PROTOCOLS_CLIENT.md

@@ -165,7 +165,7 @@ Mandatory approval gates:
 | Flow Approval | The client confirms the main flows. |
 | Screen Approval | The client confirms screen list and purpose. |
 | Design Direction Approval | The client confirms style, tone, references, and constraints. |
-| Prototype Approval | The client confirms the prototype or the reason no prototype is needed. |
+| Prototype Approval | The client confirms the actual prototype via a formal approval letter. Mandatory for all applications; only a documented Majed waiver (WAIVED_BY_MAJED) can exempt it. |
 | Execution Authorization | The client authorizes implementation to start. |
 
 Client question rules:
@@ -203,8 +203,8 @@ Exit criteria before Build Mode:
 - Contacts exist.
 - Approval authority is documented or explicitly confirmed by the user.
 - Client approval package exists.
-- Scope, flows, screen map, design direction, acceptance criteria, and execution authorization are approved and recorded.
-- Only truly non-applicable package files, such as prototype notes for a no-prototype project, may be marked `Not applicable with reason`; approval gates required for execution must not be waived.
+- Scope, flows, screen map, design direction, prototype approval (via formal letter or WAIVED_BY_MAJED), acceptance criteria, and execution authorization are approved and recorded.
+- `08_PROTOTYPE_PLAN.md` is present and mandatory; it may not be marked `Not applicable with reason` except with a documented Majed waiver (WAIVED_BY_MAJED). Other truly non-applicable package files may be marked with a reason; approval gates required for execution must not be waived.
 - Pending decisions are documented and do not block the next phase.
 
 ---

package/core/tera-system/runtime/TERA_RUNTIME_TEMPLATES.md

@@ -604,7 +604,7 @@ Required files:
 - 05_USER_FLOWS.md: Present / Missing / Not applicable with reason
 - 06_SCREEN_MAP.md: Present / Missing / Not applicable with reason
 - 07_DESIGN_DIRECTION.md: Present / Missing / Not applicable with reason
-- 08_PROTOTYPE_PLAN.md: Present / Missing / Not applicable with reason
+- 08_PROTOTYPE_PLAN.md: Present / Missing / Not applicable ONLY with documented Majed waiver (WAIVED_BY_MAJED)
 - 09_ACCEPTANCE_CRITERIA.md: Present / Missing / Not applicable with reason
 - 10_CLIENT_APPROVAL_RECORD.md: Present / Missing
 - 11_CHANGE_CONTROL.md: Present / Missing
@@ -615,7 +615,7 @@ Approval gates:
 - Flow Approval: Approved / Pending / Needs Revision
 - Screen Approval: Approved / Pending / Needs Revision
 - Design Direction Approval: Approved / Pending / Needs Revision
-- Prototype Approval: Approved / Pending / Not Applicable / Needs Revision
+- Prototype Approval: Approved (formal letter) / Pending / Needs Revision / WAIVED_BY_MAJED
 - Execution Authorization: Approved / Pending / Blocked
 
 Build Mode allowed: Yes / No
@@ -818,11 +818,15 @@ Use these outlines when creating files under `clients/.../client-approval/`. Cli
 ```text
 # خطة البروتوتايب
 
-هل البروتوتايب مطلوب؟ نعم / لا
+هل البروتوتايب مطلوب؟ نعم (إلزامي — SCP-2026-08-28-001) / لا (فقط مع تجاوز Majed موثق WAIVED_BY_MAJED)
 سبب القرار:
-الشاشات أو التدفقات التي يجب تمثيلها:
+الشاشات أو التدفقات التي يجب تمثيلها (من 06_SCREEN_MAP.md):
+الموجات (للتطبيقات الكبيرة — الشاشات الحرجة أولاً):
 مستوى التفصيل: منخفض / متوسط / عالي
-الأداة المقترحة إن وجدت:
+فريق البناء: Coding Agents تحت Tera (ui-designer + engineering-agent-typescript) — TASK-PROTO-*
+المراجع: DesignReviewer (ناقد) — قبل عرضه على Majed/الزبون
+طريقة العرض: Majed أولاً ← الزبون عبر Majed ← خطاب اعتماد رسمي
+مسار الاعتماد: client-approval/PROTOTYPE_APPROVAL_LETTER + 10_CLIENT_APPROVAL_RECORD.md (Gate 6)
 معايير قبول البروتوتايب:
 حالة الاعتماد:
 ```
@@ -902,7 +906,7 @@ This file now contains **Sections 1–28** (Tera/TCEA core templates).
 
 | Split file | Sections | Lines |
 |---|---|---|
-| `TERA_RUNTIME_TEMPLATES_DELIVERY.md` | 29–34 (Execution, Delivery, Closure) | ~505 |
-| `TERA_RUNTIME_TEMPLATES_PREPARATION.md` | 35–40 (TCEA/Blueprint outputs) | ~344 |
+| `TERA_RUNTIME_TEMPLATES_DELIVERY.md` | 29–38 (Execution, Delivery, Closure, operational hardening) | 584 |
+| `TERA_RUNTIME_TEMPLATES_PREPARATION.md` | 35–41 (TCEA/Blueprint outputs, Content Requirements) | 376 |
 
 Update any reference that pointed to Sections 29+ to the new files.