@tera-system/core 0.1.0

package/core/tera-system/agent-helpers/application-blueprint-details.md

@@ -0,0 +1,177 @@
+# تطبيق: ApplicationBlueprintAgent — تفاصيل مرجعية
+
+> **ملف مساعد.** يُقرأ عند الحاجة — ليس ملفاً تشغيلياً أساسياً.
+> المصدر الرئيسي: `.opencode/agents/application-blueprint.md`
+
+---
+
+## 1. Depth Control Matrix — مصفوفة التحكم بالعمق
+
+### معايير التقييم
+
+| البعد | Low | Medium | High |
+|-------|-----|--------|------|
+| **Risk** | تقنية مألوفة، domain معروف، متطلبات واضحة | تقنية معروفة، domain جديد جزئياً | تقنية جديدة، تكامل معقد، بيانات حساسة |
+| **Uncertainty** | متطلبات واضحة بالكامل | متطلبات واضحة 70-80% | متطلبات غير واضحة، أقسام "TBD" |
+| **Complexity** | متجر، مدونة، CRUD بسيط | مقاولات، عقارات، لوجستيك | ERP, محاسبة, تصنيع, طب, قانون |
+
+### المصفوفة الكاملة
+
+| Risk | Uncertainty | Complexity | Depth Level | الأقسام الإلزامية |
+|------|-------------|------------|-------------|------------------|
+| Low | Low | Low | **Core Only** | 0-10 (الأساسية) |
+| Low | Low | Medium | **Standard** | 0-12 (الكاملة) |
+| Low | Medium | Low | **Core Only** | 0-10 (الأساسية) |
+| Low | Medium | Medium | **Standard** | 0-12 (الكاملة) |
+| Medium | Low | Low | **Standard** | 0-12 (زيادة Risk يرفع المستوى) |
+| High | * | * | **Full** | 0-15 (كاملة + C4 + ADR + Events) |
+| * | High | * | **Full** | 0-15 (كاملة + Open Questions مفصلة) |
+| * | * | High | **Full + Event Storming** | 0-15 + Event Storming مفصل |
+
+### تأثير Depth Level
+
+| المستوى | الأقسام | C4 Diagrams |
+|----------|---------|-------------|
+| **Core Only** | 11 قسماً (0-10) | اختياري — يُوصى به في حال وجود تكامل خارجي |
+| **Standard** | 13 قسماً (0-12 + ADR Seeds) | يُوصى به بشدة — تقدير المهندس |
+| **Full** | 15 قسماً (0-15) | مُوصى به بشدة — تقدير المهندس |
+
+**⚠️ قاعدة C4:** تقدير المهندس بعد Depth Assessment. القرار يُوثّق مع السبب.
+
+### تقييم سريع (للمشاريع الواضحة)
+
+إذا كان المشروع واضحاً تماماً من first glance (جميع الأبعاد تقييمها Low):
+- اختر **Core Only** مباشرة
+- سجّل السبب في Depth Assessment: "All dimensions Low — Core Only selected directly"
+- هذا يوفر 5-10 دقائق تقييم تفصيلي
+
+---
+
+## 2. ADR Seeds — بذور القرارات المعمارية
+
+### الهيكل الكامل لكل Seed
+
+| الحقل | الوصف | مثال |
+|-------|-------|------|
+| **Title** | عنوان يميّز القرار | "اختيار قاعدة بيانات" |
+| **Context** | السياق الذي أثار الحاجة | "النظام يحتاج تخزين مرن للبيانات غير المهيكلة" |
+| **Decision Candidate** | الخيار المقترح (مع خيارات بديلة) | "Primary: PostgreSQL مع JSONB. Alternatives: MongoDB, SQL Server" |
+| **Tradeoffs** | مقايضات معروفة | "PostgreSQL: +نضج, +SQL, -المرونة. MongoDB: +المرونة, -الاتساق" |
+| **Status** | `[ADR-Seed]` — ليس قراراً نهائياً | `[ADR-Seed]` |
+
+### متى لا توجد قرارات معمارية؟
+
+إذا كان المشروع صغيراً (Core Only) وليس هناك أي قرار معماري حقيقي:
+```
+1. Title: No significant architecture decisions identified yet
+   Context: Project scope is straightforward with standard patterns
+   Decision Candidate: Will emerge during formal preparation
+   Tradeoffs: N/A at this stage
+   Status: [ADR-Seed]
+```
+
+هذا أفضل من إجبار قرارات غير موجودة.
+
+---
+
+## 3. C4 Architecture Diagrams — النمذجة المعمارية
+
+### مستويات C4
+
+| المستوى | المحتوى | إلزامي في |
+|----------|---------|-----------|
+| **C1 — Context** | النظام في محيطه: المستخدمون الخارجيون، الأنظمة المتكاملة | Full |
+| **C2 — Container** | المكونات الكبيرة: Web, API, Database, Workers, Queues | Full |
+| **C3 — Component** | المكونات الداخلية (للمكونات الحرجة فقط) | اختياري |
+
+### مصدر الحقيقة
+
+```text
+مصدر الحقيقة هو ملف Structurizr DSL (.dsl) — نص version-controlled.
+الـ diagrams (PNG/SVG) هي مخرجات مشتقة تُولّد لاحقاً.
+```
+
+### قواعد كتابة DSL
+
+```structurizr
+workspace {
+    model {
+        // تعريف المستخدمين والأنظمة
+        user = person "مستخدم" "وصف"
+        system = softwareSystem "النظام" "وصف"
+
+        user -> system "يستخدم" "HTTP"
+
+        // تعريف الـ Containers
+        webApp = container "Web App" "تطبيق الواجهة" "React"
+        api = container "API" "واجهة الخدمات" "API"
+        db = container "Database" "قاعدة البيانات" "SQL"
+
+        system -> webApp "يحتوي"
+        webApp -> api "يستدعي" "HTTP/REST"
+        api -> db "يقرأ/يكتب" "EF Core"
+    }
+    views {
+        systemContext system "SystemContext" {
+            include *
+            autolayout
+        }
+        container system "Containers" {
+            include *
+            autolayout
+        }
+    }
+}
+```
+
+### توليد الـ Diagrams — الوضع الحالي
+
+**✅ MCP مُفعّل:** `colincoleman/structurizr-mcp` — مثبت في `structurizr-mcp/`.
+
+**الميزات المتاحة:**
+- قراءة/كتابة ملفات `.dsl` ✅ (دائماً متاح)
+- تصدير diagrams إلى SVG/PNG/Mermaid/PlantUML ✅ (يحتاج Docker قيد التشغيل)
+- التحقق من صحة DSL ✅ (يحتاج Docker)
+- معاينة النماذج عبر http://localhost:8081 ✅ (يحتاج Docker)
+
+**إذا لم يعمل MCP (Docker غير متاح):**
+الـ DSL النصي يكفي كمرجع معمارية كامل — الـ diagrams تُولّد لاحقاً عند تشغيل Docker.
+
+**لتشغيل حاوية Structurizr (من جذر المستودع):**
+```bash
+docker run -d --rm -p 8081:8080 -v "%CD%\architecture:/usr/local/structurizr" structurizr/structurizr local
+```
+> **ملاحظة:** المسار نسبي من جذر المستودع (يعمل على أي جهاز). بديل PowerShell: `-v "$PWD\architecture:/usr/local/structurizr"`
+> **ملاحظة:** المنفذ 8081 لأن 8080 مشغول بـ ERPNext. المعاينة عبر http://localhost:8081
+
+---
+
+## 4. Domain Events Map — خريطة أحداث المجال
+
+للمشاريع ذات `Domain Complexity ≥ High` أو `Uncertainty ≥ High`.
+
+### الهيكل
+
+#### Domain Events (الأحداث)
+| الحدث | المشغّل (Command) | الفاعل (Actor) | المصدر (Aggregate) |
+|-------|-------------------|----------------|-------------------|
+| "OrderPlaced" | PlaceOrderCommand | Customer | Order |
+| "PaymentReceived" | ProcessPaymentCommand | System | Payment |
+
+#### Commands (الأوامر)
+| الأمر | النتيجة | الـ Actor |
+|-------|---------|-----------|
+| PlaceOrderCommand | OrderPlaced | Customer |
+| ProcessPaymentCommand | PaymentReceived | System |
+
+#### Key Aggregates (الكيانات الرئيسية)
+| الكيان | الأحداث المرتبطة |
+|--------|------------------|
+| Order | OrderPlaced, OrderShipped, OrderCancelled |
+| Payment | PaymentReceived, PaymentFailed |
+
+### متى تستخدم Event Storming
+
+- **إلزامي**: Domain Complexity ≥ High في Depth Assessment
+- **اختياري**: المشاريع التي يظهر فيها أنماط أحداث معقدة أثناء blueprinting
+- **غير مطلوب**: Core Only أو Standard للمشاريع البسيطة غير المعقدة

package/core/tera-system/client-helpers/tera-client-engagement-discovery-domains.md

@@ -0,0 +1,99 @@
+---
+description: Canonical source for the 13 mandatory TCEA discovery domains — single source of truth for numbering, naming, aliases, coverage, and blocking rules.
+---
+
+# Discovery Domains — المجالات الـ 13 الرسمية للاكتشاف
+
+> هذا الملف هو **المصدر الوحيد المعتمد** لتعريف وترقيم مجالات Discovery الـ 13.
+> جميع الملفات الأخرى (Question Bank, Templates, Protocols) تشير إلى هذا الملف بدلاً من تعريف المجالات من جديد.
+>
+> **لا تقرأ هذا الملف افتراضياً.** اقرأه فقط عند بدء Discovery لعميل جديد، أو عند الشك في ترقيم أو اسم Domain معين.
+
+---
+
+## جدول المجالات الرسمي
+
+| # | الاسم الرسمي (Canonical) | الأسماء المقبولة (Aliases) | Minimum Coverage | يحجب التسعير؟ | يحجب الهاندوف؟ |
+|:-:|:-------------------------|:--------------------------|:----------------:|:-------------:|:--------------:|
+| 1 | Business & Goals | Business Context & Value, Administrative | Client profile, problem, goal, decision maker | لا | نعم |
+| 2 | Users, Roles & Access | Users & Roles, Functional | User types, roles hierarchy, permissions model | لا | نعم |
+| 3 | Process & Workflow | Workflow & Operations | Core business processes, approval flows, states | نعم | نعم |
+| 4 | Data & Content | Data & Content | Entities, relationships, data volume, file types + **Content Type (Application Data / User-Facing Content / Mixed)** — لمشاريع User-Facing Content/Mixed: استراتيجية المحتوى (التموضع/النبرة/Claims المسموحة/الخطوط الحمراء) مؤكدة من المالك | نعم | نعم |
+| 5 | Scope & MVP | Scope & MVP | In/out scope, priorities, phases | نعم | نعم |
+| 6 | Screens & UX | Screens & UX | Screen count, UI complexity, responsive needs | نعم | نعم |
+| 7 | Notifications Engine | Notifications Engine | Email, SMS, in-app, push, templates | لا | نعم |
+| 8 | Reports & Dashboards | Reports & Dashboards | Report types, charts, filters, export | نعم | نعم |
+| 9 | Design & Branding | Design & Branding | Brand guidelines, design source (Figma/etc), UI kit | لا | نعم |
+| 10 | Technical, Hosting & Compliance | Technical, Hosting & Compliance | Stack, hosting, domain, SSL, compliance needs | نعم | نعم |
+| 11 | Security & Audit | Security & Audit | Auth method, data sensitivity, audit trail | نعم | نعم |
+| 12 | Integrations & APIs | Integrations & APIs | Third-party APIs, webhooks, data sync | نعم | نعم |
+| 13 | Acceptance, Commercials & Warranty | Acceptance, Commercials & Warranty | Acceptance criteria, budget, payment plan, warranty, support terms | نعم | نعم |
+
+---
+
+## القواعد
+
+1. **هذا الترقيم هو المعتمد فقط.** لا يُستخدم ترقيم آخر في أي ملف من ملفات المنظومة.
+2. **جميع Domains الـ 13 إلزامية التغطية** في `DISCOVERY_COVERAGE_SUMMARY.md` — لكن عمق التغطية (Minimum Coverage) يختلف حسب حجم المشروع (صغير/متوسط/معقد/غامض).
+3. **Blocks Pricing = نعم** ← هذا المجال إذا كان `Missing` أو `Partial` دون حل يمنع إنتاج `DRAFT_QUOTATION.md` (Level 2).
+4. **Blocks Handoff = نعم** ← هذا المجال إذا كان `Missing` أو `Partial` دون حل يمنع PASS في B.7b (Final Handoff Package Gate).
+5. الأسماء المقبولة (Aliases) يمكن استخدامها في الأسئلة والحوارات مع Majed، لكن **الاسم الرسمي (Canonical)** يُستخدم في جميع الوثائق الرسمية (`DISCOVERY_COVERAGE_SUMMARY.md`, `DRAFT_QUOTATION.md`, `TERA_HANDOFF_PACKAGE.md`).
+6. **المجال 13 (Acceptance, Commercials & Warranty)** يتطلب تغطية 3 جوانب داخلية على الأقل: (أ) معايير القبول والاختبارات, (ب) الميزانية وخطة الدفع, (ج) الضمان والصيانة.
+7. **Content Type Rule (SCP-2026-08-15-016):** إذا كان Content Type = `User-Facing Content` أو `Mixed` (موقع/صفحة هبوط/تسويق/محتوى)، تُفعَّل **Content Confirmation Gate** في مرحلة التحضير (بعد `07_SCREENS_AND_UI_STRUCTURE.md` وقبل التصميم النهائي)، ويُشترط `CONTENT_REQUIREMENTS.md` معتمد من المالك في Solution Readiness Gate. التطبيقات القياسية (Application Data فقط) لا تُفعَّل — Anti-Bloat.
+
+---
+
+## علاقة هذا المصل بالملفات الأخرى
+
+| الملف | العلاقة |
+|-------|---------|
+| `TeraApplicationQuestionBank.md` | يستخدم هذا الترقيم كمرجع للأسئلة — راجع discovery-domains.md للترقيم المعتمد |
+| `TERA_RUNTIME_TEMPLATES.md §35` | Domain Coverage Matrix تستخدم هذا الترقيم والترتيب |
+| `TERA_RUNTIME_PROTOCOLS.md` (Smart Interview) | تستخدم أسماء المجالات من هذا المصدر |
+| `gates.md` (B.1 Discovery Coverage Gate) | تشير إلى "جميع Domains الـ 13" — تعريفها هنا |
+
+---
+
+## توجيهات Track A — تطوير تطبيق قائم `[Existing]`
+
+> استخدم هذه التوجيهات إذا كان المشروع **Track A** مع `Application Status = [Existing]` (تطوير تطبيق قائم، لا تطبيق جديد من الصفر).
+
+### Domain 10 (Technical, Hosting & Compliance) — أسئلة إضافية للتطبيقات القائمة
+
+في Discovery للتطبيقات القائمة، أضف هذه الأسئلة إلى Domain 10:
+
+| السؤال | الغرض |
+|--------|-------|
+| ما هي التقنيات المستخدمة حالياً؟ (لغة البرمجة، الإطار، قاعدة البيانات، الاستضافة) | فهم البيئة التقنية |
+| هل يوجد Tech Debt معروف؟ (مشاكل أداء، أخطاء متكررة، كود قديم) | تقييم الجهد الإضافي المطلوب |
+| هل يحتاج ترحيل بيانات (Data Migration)؟ ما حجمها؟ | تحديد تعقيد الترحيل |
+| هل توجد قيود تكامل (Integrations) مع أنظمة أخرى؟ | تحديد نطاق التكامل المطلوب |
+| هل التطبيق مُوثّق؟ (وثائق API، README، إلخ) | تقييم سهولة البدء |
+| هل يوجد نظام اختبارات (Test Suite)؟ | تقييم جودة الكود الحالي |
+
+### Handoff Note
+
+في `TERA_HANDOFF_PACKAGE.md` للتطبيقات القائمة، أضف بنداً يلخص:
+- التقنيات الحالية
+- Tech Debt Assessment
+- حالة قاعدة الكود (مُوثّقة، غير مُوثّقة، مختبرة)
+- قيود التكامل المعروفة
+
+---
+
+## توجيهات Track B — Product Implementation
+
+> عندما يكون المسار **Track B**، الـ 13 Domain تبقى إلزامية التغطية لكن الأسلوب يتغير: بدلاً من "ما هي احتياجاتك؟" تسأل "هل منتجنا يغطي احتياجاتك؟"
+
+### الفرق في الأسلوب بين Track A و Track B
+
+| الجانب | Track A (Custom) | Track B (Product) |
+|--------|:----------------:|:-----------------:|
+| نوع الأسئلة | استكشافية مفتوحة | استقصائية — "هل المنتج الحالي يغطي X؟" |
+| Narrative | "أخبرني عن مشكلتك لأبني حلاً" | "هذا منتجنا، كيف يلبي احتياجاتك؟" |
+| Scope | يبنى من الصفر | يُقيّم (Fit/Gap) بقدرات المنتج |
+| التسعير | Scorecard + حاسبة Excel | تراخيص + خدمات تنفيذ (راجع pricing.md) |
+
+### الإشارة لملف Fit-Gap
+
+في Track B، Discovery يتبعه مباشرة Fit-Gap Analysis مفصّلة في `protocols.md` (Fit-Gap Analysis Protocol). الـ 13 Domains هنا تمهيد للتحليل، وليس Scope نهائي كما في Track A.

package/core/tera-system/client-helpers/tera-client-engagement-gates.md

@@ -0,0 +1,258 @@
+---
+description: TCEA operational gates — B.1 through B.7b detailed definitions for quality control.
+---
+# TCEA Gates — ملف المساعد البوابات
+
+> **اقرأني فقط عندما:** تحتاج التحقق من شرط Gate قبل الانتقال بين Modes (A→B Discovery→Pricing, B→C Pricing→Handoff).
+>
+> **لا تقرأني:** في بداية Session أو أثناء Discovery الروتيني.
+>
+> **إظهار تأكيد القراءة:** فقط إذا كانت الجلسة Audit/Debug، أو طلب Majed ذلك صراحة، أو كان القرار عالي الأثر. مثال عند الحاجة فقط: "📖 قرأت gates.md — Gate [اسم البوابة] = [PASS/FAIL]"
+
+---
+
+## B.1 Discovery Coverage Gate — بوابة تغطية الاستكشاف
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Discovery Coverage Gate |
+| **الهدف** | ضمان أن جميع مجالات الاستكشاف الـ 13 قد غُطّيت بشكل كافٍ قبل الانتقال إلى تصنيف المشروع والتسعير المبدئي |
+| **المدخلات المطلوبة** | `DISCOVERY_COVERAGE_SUMMARY.md` (بعد تطبيق Self-Check Protocol A.6.1 على كل Domain) |
+| **شروط النجاح** | 1. جميع Domains الـ 13 مغطاة — إما `Complete` أو `Partial` مع `UNCERTAINTY_NOTICE`<br>2. كل Domain `Complete`: مصدر المعلومة واضح، Majed confirmed، والخطورة `Low` أو `Medium`<br>3. كل Domain `Partial`: `UNCERTAINTY_NOTICE` موجود ومرفوع لـ Majed<br>4. لا يوجد Domain بخطورة `High` بدون تأكيد Majed |
+| **شروط الإيقاف (Blocking Conditions)** | 1. Domain بخطورة `High` بدون تأكيد Majed ← توقف إجباري<br>2. Domain غير مغطى (لا `Complete` ولا `Partial`) ← توقف<br>3. `UNCERTAINTY_NOTICE` مرفوع ولم يحصل رد من Majed ← توقف |
+| **الإخراج الإلزامي** | `DISCOVERY_COVERAGE_SUMMARY.md` + قرار البوابة: **PASS/FAIL**. إذا كان FAIL، يُذكر السبب بوضوح: `Needs More Info` أو `Rejected`. |
+| **هل يمنع الانتقال؟** | **نعم** — لا يمكن تصنيف المشروع أو البدء بتحليل النطاق والتسعير قبل PASS |
+
+---
+
+## B.2 Budget-to-Scope Control Rule — قاعدة الموازنة بين النطاق والميزانية
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Budget-to-Scope Control Rule |
+| **الهدف** | مواءمة النطاق المقترح مع ميزانية العميل عبر تصنيف الميزات بالأولوية وحساب الجدوى المالية قبل التسعير |
+| **المدخلات المطلوبة** | `FEATURE_LIST.md` (الميزات), `CLIENT_INTAKE.md` (ميزانية العميل من Majed), `CLIENT_DECISION_LOG.md` (للتسجيل) |
+| **شروط النجاح** | 1. جميع الميزات مصنفة حسب الأولوية: P1 (Must-have), P2 (Should-have), P3 (Nice-to-have)<br>2. تكلفة P1 محسوبة تقديرياً وموثقة في `CLIENT_DECISION_LOG.md`<br>3. إذا P1 ≤ الميزانية → تم توزيع الباقي على P2/P3 مع توثيق<br>4. إذا P1 > الميزانية → تم رفع خيارات لـ Majed (تقليل النطاق / زيادة الميزانية / تقسيم مرحلي) وأخذ قرار موثق |
+| **شروط الإيقاف (Blocking Conditions)** | 1. ميزانية العميل غير معروفة ← توقف واسأل Majed صراحة<br>2. P1 غير مقدرة ← توقف<br>3. P1 > الميزانية ولم يتم توثيق قرار Majed ← توقف |
+| **الإخراج الإلزامي** | `CLIENT_DECISION_LOG.md` محدّث بتصنيف الأولويات + قرار توزيع الميزانية |
+| **هل يمنع الانتقال؟** | **نعم** — يمنع إنتاج `DRAFT_QUOTATION.md` قبل توثيق القرار |
+
+---
+
+## B.3 Final Scope Reconciliation Gate — بوابة توحيد النطاق النهائي
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Final Scope Reconciliation Gate |
+| **الهدف** | توحيد حالة جميع الميزات في `FEATURE_LIST.md` قبل التسعير، وضمان عدم وجود ميزات غير مصنّفة أو معلقة بدون قرار |
+| **المدخلات المطلوبة** | `FEATURE_LIST.md`, `CLIENT_DECISION_LOG.md` (قرارات الميزانية والتغيير), Budget-to-Scope documentation |
+| **شروط النجاح** | 1. كل ميزة في `FEATURE_LIST.md` لها حالة: `In Scope` / `Out of Scope` / `Deferred` / `Pending Decision`<br>2. كل ميزة `In Scope` لها أولوية: P1, P2, P3<br>3. لا توجد ميزة بحالة `Undefined` أو `Unclassified`<br>4. لا توجد ميزة `In Scope` تعتمد على ميزة `Deferred` أو `Pending Decision`<br>5. Budget-to-Scope (B.2) مطبّق وموثّق<br>6. **كل ميزة في `In Scope` تحمل وسماً من A.6.4 — ولا يجوز أن تكون `[Research Hint]` أو `[Assumption]` أو `[Unresolved]`** |
+| **شروط الإيقاف (Blocking Conditions)** | 1. أي ميزة بحالة `Undefined` ← توقف<br>2. ميزة `In Scope` بدون أولوية ← توقف<br>3. ميزة تعتمد على أخرى معلقة ← توقف<br>4. P1 > الميزانية بدون قرار Majed ← توقف<br>5. **أي ميزة `In Scope` موسومة بـ `[Research Hint]` أو `[Assumption]` أو `[Unresolved]` ← توقف — يجب ترقية الوسم إلى `[Confirmed by Majed]`** ← **MR1** |
+| **الإخراج الإلزامي** | `FEATURE_LIST.md` محدّثة ومكتملة (كل الميزات: حالة + أولوية + وسم A.6.4) + `CLIENT_DECISION_LOG.md` محدّث |
+| **هل يمنع الانتقال؟** | **نعم** — لا يمكن إنتاج `DRAFT_QUOTATION.md` قبل PASS |
+
+---
+
+## B.4 Quotation Readiness Gate — بوابة جاهزية التسعير
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Quotation Readiness Gate |
+| **الهدف** | التأكد من اكتمال جميع متطلبات التسعير قبل إنتاج `DRAFT_QUOTATION.md` (Level 2) — منع القفز إلى التسعير دون اكتمال الأساسيات |
+| **المدخلات المطلوبة** | `CLIENT_INTAKE.md`, `DISCOVERY_COVERAGE_SUMMARY.md` (مع قرار البوابة), `FEATURE_LIST.md` (بعد Reconciliation — جميع العناصر موسومة بـ `[Confirmed by Majed]`), `CLIENT_DECISION_LOG.md`, قائمة TeraPricingPolicy.md §2 (10 بنود تسعيرية), `TeraPricingCalculator.xlsx` (للجاهزية) |
+| **شروط النجاح** | 1. Understanding Summary confirmed by Majed<br>2. Discovery Coverage Gate = PASS (B.1)<br>3. Final Scope Reconciliation Gate = PASS (B.3)<br>4. Budget-to-Scope Control Rule documented (B.2)<br>5. معلومات التسعير الأساسية كاملة (حسب TeraPricingPolicy.md §2 — 10 بنود)<br>6. جميع الافتراضات عالية الخطورة (High-risk) محلولة أو موثقة وواضحة لـ Majed ← **MR2**<br>7. **جميع عناصر النطاق والتسعير موسومة بـ `[Confirmed by Majed]` — لا `[Research Hint]` ولا `[Assumption]` ولا `[Unresolved]`** ← **MR1** |
+| **شروط الإيقاف (Blocking Conditions)** | 1. Understanding Summary غير مؤكد أو لم يؤكده Majed ← توقف<br>2. Discovery Coverage Gate ≠ PASS ← توقف<br>3. Final Scope Reconciliation Gate ≠ PASS ← توقف<br>4. Budget-to-Scope غير موثق ← توقف<br>5. أي معلومة تسعيرية أساسية ناقصة (من TeraPricingPolicy.md §2) ← توقف<br>6. أي افتراض High-risk غير محسوم ← توقف ← **MR2**<br>7. **أي عنصر تسعير مبني على `[Research Hint]` أو `[Assumption]` ← توقف — يجب ترقية الوسم إلى `[Confirmed by Majed]`** ← **MR1** |
+| **الإخراج الإلزامي** | تقرير **PASS/FAIL** + قائمة **Blocking Gaps** (الفجوات المانعة) إذا كان FAIL |
+| **هل يمنع الانتقال؟** | **نعم** — لا يمكن إنتاج `DRAFT_QUOTATION.md` قبل PASS |
+
+---
+
+## B.5 CLIENT_DECISION_LOG.md — سجل قرارات العميل
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | CLIENT_DECISION_LOG.md |
+| **الهدف** | توثيق كل قرار يُتخذ أثناء دورة حياة العميل — تغييرات النطاق، تعديلات السعر، تحولات الأولوية — في سجل واحد قابل للتتبع |
+| **المدخلات المطلوبة** | القرارات الصادرة عن Majed أو العميل خلال كل مرحلة من تدفق العمل |
+| **شروط النجاح** | 1. كل إدخال يحتوي على: Decision ID \| Date \| Topic \| Decision \| Rationale \| Status \| Source<br>2. جميع القرارات مسجلة فور حدوثها — لا تأجيل<br>3. قبل Tera Handoff: كل الإدخالات بحالة `Approved` أو `Deferred` — صفر `Pending Approval` |
+| **الحالات المسموحة** | `Approved` (تم الاعتماد) \| `Deferred` (أُجّل) \| `Conditional` (معلق على شرط) \| `Pending Approval` (بانتظار الاعتماد) |
+| **شروط الإيقاف (Blocking Conditions)** | 1. أي إدخال بحالة `Pending Approval` عند Tera Handoff ← يمنع PASS في B.7a (Handoff Draft Readiness) و B.7b (Final Handoff Package) ← **MR3**<br>2. قرار تغيير نطاق أو سعر غير موثق ← يعتبر مخالفة |
+| **الإخراج الإلزامي** | `CLIENT_DECISION_LOG.md` محدّث باستمرار |
+| **هل يمنع الانتقال؟** | **نعم** — بشكل غير مباشر: يمنع Tera Handoff إذا بقي أي إدخال `Pending Approval` |
+
+---
+
+## B.6a Source Approval Consistency — فحص اتساق المصادر (قبل الحزمة)
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Source Approval Consistency Check |
+| **الهدف** | التأكد من أن جميع وثائق المصدر جاهزة ومعتمدة **قبل** صياغة `TERA_HANDOFF_PACKAGE.md` — لا يُذكر الحزمة لأنها لم تُنتج بعد |
+| **المدخلات المطلوبة** | `CLIENT_INTAKE.md`, `SCOPE_SUMMARY.md`, `FEATURE_LIST.md`, `DRAFT_QUOTATION.md`, `CLIENT_DECISION_LOG.md`, `CHANGE_REQUEST_LOG.md`, `CLIENT_BRIEF.md` |
+| **شروط النجاح** | 1. **لا مستندات عالقة:** لا يوجد مستند `Draft` يجب أن يكون `Approved`<br>2. **القرارات محسومة:** CLIENT_DECISION_LOG.md: 0 `Pending Approval`<br>3. **اتساق النطاق:** SCOPE_SUMMARY.md متطابق مع FEATURE_LIST.md — لا ميزات يتيمة<br>4. **اتساق السعر:** DRAFT_QUOTATION.md متوافق مع النطاق والميزات الموثقة<br>5. **حسم طلبات التغيير:** جميع CHANGE_REQUEST_LOG.md محسومة (Approved/Rejected/Deferred) |
+| **شروط الإيقاف (Blocking Conditions)** | 1. أي مستند مصدر بحالة `Draft` ويتطلب `Approved` ← توقف<br>2. أي قرار بحالة `Pending Approval` ← توقف<br>3. SCOPE_SUMMARY.md لا يتطابق مع FEATURE_LIST.md ← توقف<br>4. CHANGE_REQUEST غير محسوم ← توقف |
+| **الإخراج الإلزامي** | تقرير **PASS/FAIL** مع قائمة الاختبارات الراسبة. عند PASS فقط يُسمح بصياغة `TERA_HANDOFF_PACKAGE.md` كمسودة أولية |
+| **هل يمنع الانتقال؟** | **نعم** — يمنع إنتاج مسودة `TERA_HANDOFF_PACKAGE.md` |
+
+## B.6b Package Approval Consistency — فحص اتساق الحزمة (بعد الحزمة)
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Package Approval Consistency Check |
+| **الهدف** | التأكد من أن حالة `TERA_HANDOFF_PACKAGE.md` متسقة مع مصادرها — لا يمكن أن تكون الحزمة `Approved` إذا كان أي مصدر لا يزال `Draft` أو `Pending Approval` |
+| **المدخلات المطلوبة** | `TERA_HANDOFF_PACKAGE.md`, `CLIENT_INTAKE.md`, `SCOPE_SUMMARY.md`, `FEATURE_LIST.md`, `DRAFT_QUOTATION.md`, `CLIENT_DECISION_LOG.md`, `CHANGE_REQUEST_LOG.md` |
+| **شروط النجاح** | 1. **اتساق الحالة:** TERA_HANDOFF_PACKAGE.md تأخذ أقل حالة من جميع المصادر — إذا أي مصدر `Draft` أو `Pending`، فالحزمة لا يمكن أن تكون `Approved`<br>2. **جميع المصادر معتمدة:** لا يوجد مصدر بحالة `Draft` يتطلب `Approved` |
+| **شروط الإيقاف (Blocking Conditions)** | 1. TERA_HANDOFF_PACKAGE.md بحالة أعلى من أقل مصدر (مثلاً الحزمة `Approved` وأحد المصادر `Draft`) ← توقف |
+| **الإخراج الإلزامي** | تقرير **PASS/FAIL**. عند PASS فقط يمكن إعلان `TERA_HANDOFF_PACKAGE.md` كـ `Approved` وجاهزة للتسليم |
+| **هل يمنع الانتقال؟** | **نعم** — يمنع تسليم `TERA_HANDOFF_PACKAGE.md` النهائية |
+
+---
+
+## B.7a Handoff Draft Readiness Gate — بوابة جاهزية مسودة الهاندوف
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Handoff Draft Readiness Gate |
+| **الهدف** | التأكد من اكتمال جميع المتطلبات المسبقة للهاندوف **قبل** صياغة `TERA_HANDOFF_PACKAGE.md` — منع إنتاج حزمة على أساس غير مكتمل |
+| **المدخلات المطلوبة** | `CLIENT_INTAKE.md`, `SCOPE_SUMMARY.md`, `FEATURE_LIST.md`, `DRAFT_QUOTATION.md`, `CLIENT_DECISION_LOG.md`, `CHANGE_REQUEST_LOG.md`, `CLIENT_BRIEF.md` |
+| **شروط النجاح** | 1. Source Approval Consistency = PASS (B.6a)<br>2. Quotation Readiness Gate = PASS (B.4)<br>3. Final Scope Reconciliation = PASS (B.3)<br>4. Budget-to-Scope documented (B.2)<br>5. CLIENT_DECISION_LOG.md: صفر `Pending Approval` ← **MR3**<br>6. Quotation معتمد من Majed (Level 2 Approved)<br>7. جميع CHANGE_REQUEST_LOG.md محسومة<br>8. Workspace Plan confirmed by Majed (المسار المتوقع: `clients/CLIENT-NAME/applications/APP-NAME/`، الاسم الرسمي، والهيكل المتوقع) — تخطيط فقط لا إنشاء مجلدات |
+| **شروط الإيقاف (Blocking Conditions)** | 1. Source Approval Consistency = FAIL ← توقف<br>2. أي قرار `Pending Approval` ← توقف ← **MR3**<br>3. Level 2 Quotation غير معتمد من Majed ← توقف<br>4. CHANGE_REQUEST غير محسوم ← توقف<br>5. Workspace Plan غير مؤكد من Majed ← توقف |
+| **الإخراج الإلزامي** | تقرير **PASS/FAIL** + قائمة **Blocking Gaps** عند FAIL. عند PASS: يُسمح بإنتاج `TERA_HANDOFF_PACKAGE.md` كمسودة أولية |
+| **هل يمنع الانتقال؟** | **نعم** — لا يمكن إنتاج `TERA_HANDOFF_PACKAGE.md` قبل PASS |
+
+---
+
+## B.7b Final Handoff Package Gate — بوابة الحزمة النهائية للهاندوف
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Final Handoff Package Gate |
+| **الهدف** | التأكد من أن `TERA_HANDOFF_PACKAGE.md` نفسها مكتملة ومتسقة وجاهزة للتسليم إلى ApplicationBlueprintAgent (مُهندس) — SCP-2026-07-28-118: مُهندس هو المستلم الإلزامي؛ TeraAgent يستلم لاحقاً من مُهندس |
+| **المدخلات المطلوبة** | `TERA_HANDOFF_PACKAGE.md`, `CLIENT_INTAKE.md`, `SCOPE_SUMMARY.md`, `FEATURE_LIST.md`, `DRAFT_QUOTATION.md`, `CLIENT_DECISION_LOG.md`, `CHANGE_REQUEST_LOG.md`, Workspace Plan المعتمد من Majed (تخطيط فقط — لا إنشاء مجلدات) |
+| **شروط النجاح** | 1. `TERA_HANDOFF_PACKAGE.md` تحتوي على جميع الوثائق الأساسية: CLIENT_BRIEF أو SCOPE_SUMMARY + FEATURE_LIST + DRAFT_QUOTATION + CLIENT_DECISION_LOG + CHANGE_REQUEST_LOG<br>2. **جميع العناصر في حزمة الهاندوف موسومة بـ `[Confirmed by Majed]` — لا `[Research Hint]` ولا `[Assumption]` ولا `[Unresolved]`** ← **MR1**<br>3. الحزمة متسقة مع المصادر (CLIENT_INTAKE.md, SCOPE_SUMMARY.md, FEATURE_LIST.md, DRAFT_QUOTATION.md)<br>4. جميع إدخالات CLIENT_DECISION_LOG.md منعكسة في الحزمة<br>5. Package Approval Consistency = PASS (B.6b)<br>6. **Final Consistency Check = PASS** (SCP-2026-08-15-010):<br>   (أ) **عدّاد القرارات:** العدد المذكور في CLIENT_INTAKE / DISCOVERY_COVERAGE_SUMMARY / TERA_HANDOFF_PACKAGE يطابق آخر `D-###` فعلي في CLIENT_DECISION_LOG.md<br>   (ب) **تصنيف النطاق:** لا متطلب `Required`/`Must` في القرارات مصنف كـ `◉ Optional` في قائمة الميزات — كل Required → `✅ Included \| Essential`<br>   (ج) **بقايا المصطلحات:** لا صيغ/أسماء قديمة بعد أي Normalization (فحص الأنماط)<br>   (د) **المراجع:** كل `D-###` مُشار إليه في الحزمة موجود فعلياً في CLIENT_DECISION_LOG.md<br>   *الأوامر شبه الآلية:* انظر قسم "Final Consistency Check Commands" أدناه |
+| **شروط الإيقاف (Blocking Conditions)** | 1. أي وثيقة أساسية ناقصة من `TERA_HANDOFF_PACKAGE.md` ← توقف<br>2. **أي عنصر موسوم بـ `[Research Hint]` أو `[Assumption]` أو `[Unresolved]` داخل الحزمة ← توقف — يجب أن يكون `[Confirmed by Majed]`** ← **MR1**<br>3. عدم اتساق بين الحزمة والمصادر ← توقف<br>4. Package Approval Consistency = FAIL (B.6b) ← توقف<br>5. **Final Consistency Check = FAIL ← توقف — لا تُرفع TERA_HANDOFF_PACKAGE.md إلى Approved قبل التصحيح** (SCP-2026-08-15-010) |
+| **الإخراج الإلزامي** | تقرير **PASS/FAIL** + قائمة **Blocking Gaps** عند FAIL. عند PASS: `TERA_HANDOFF_PACKAGE.md` جاهز للتسليم إلى ApplicationBlueprintAgent |
+| **هل يمنع الانتقال؟** | **نعم** — لا يمكن تسليم الحزمة إلى ApplicationBlueprintAgent أو TeraAgent قبل PASS |
+
+---
+
+## B.7c Final Consistency Check Commands — أوامر الفحص شبه الآلي (SCP-2026-08-15-010)
+
+> **مبدأ التصميم:** الفحص أوامر قابلة للتشغيل تنتج نتيجة `PASS/FAIL` — لا يُحوَّل إلى Checklist يدوي طويل على TCEA.
+> تُشغَّل على ملفات الحزمة قبل رفع `TERA_HANDOFF_PACKAGE.md` إلى `Approved` (ضمن B.7b شرط 6).
+
+```powershell
+# (أ) عدّاد القرارات: عدد أسطر "| D-" في السجل — قارنه بالأرقام المذكورة في الملفات الثلاثة
+(Select-String -Path CLIENT_DECISION_LOG.md -Pattern '^\| D-\d+').Count
+Select-String -Path CLIENT_INTAKE.md, DISCOVERY_COVERAGE_SUMMARY.md, TERA_HANDOFF_PACKAGE.md -Pattern '\d+ قرار'
+
+# (ب) تصنيف النطاق: أي سطر Optional في قائمة الميزات — تحقق أن صاحبه ليس Required في القرارات
+Select-String -Path TERA_HANDOFF_PACKAGE.md -Pattern '◉ Optional'
+
+# (ج) بقايا المصطلحات: أنماط الأسماء/الصيغ القديمة بعد Normalization
+Select-String -Path CLIENT_INTAKE.md, CLIENT_DECISION_LOG.md, TERA_HANDOFF_PACKAGE.md -Pattern '<أنماط الأسماء القديمة>'
+
+# (د) المراجع: كل D-### في الحزمة — تحقق وجودها في السجل
+Select-String -Path TERA_HANDOFF_PACKAGE.md -Pattern 'D-\d{3}' | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique
+```
+
+**القاعدة:** كل فحص يعيد `PASS` عند عدم وجود مشكلة، و`FAIL` عند وجودها (مع سطر النتيجة في `TERA_RUNTIME_TEMPLATES_PREPARATION.md §36 — §11`).
+
+---
+
+## Workspace Verification — التحقق من مساحة العمل
+
+> هذا فحص خفيف بعد إنشاء المجلدات — ليس بوابة انتقال بين Modes، ولا يحتاج PASS/FAIL رسمي.
+
+| البند | التفاصيل |
+|-------|----------|
+| **التوقيت** | بعد إنشاء مساحة العمل فعلياً (بعد PASS B.7b + موافقة Majed) |
+| **الهدف** | التأكد من أن هيكل المجلدات قد أُنشئ بشكل صحيح وفق Workspace Plan، قبل وضع الملفات والتسليم |
+| **قائمة التحقق** | 1. المجلد الرئيسي `clients/CLIENT-NAME/` موجود<br>2. المجلد `applications/APP-NAME/` موجود<br>3. المجلد `client-engagement/` موجود داخل APPLICATION<br>4. جميع المسارات تطابق Workspace Plan المعتمد من Majed |
+| **عند الفشل** | أعلم Majed وأعد إنشاء الهيكل المفقود — هذا الفحص لا يمنع التسليم، لكن الهيكل الناقص يُبلغ عنه |
+
+---
+
+## 🅱️ Track B Gates — بوابات مسار المنتجات الجاهزة
+
+> هذه البوابات خاصة بـ **Track B (Product Implementation)** فقط. لكل مرحلة من B1 إلى B6 بوابة تمنع الانتقال إلى المرحلة التالية قبل PASS.
+>
+> **ملاحظة:** B4–B6 يديرها TeraAgent تقنياً — لكن TCEA يراقب جودة التنسيق والتسليم من جانب الزبون.
+
+---
+
+### PB.1 Product Discovery Gate — بوابة اكتشاف المنتج
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Product Discovery Gate |
+| **الهدف** | ضمان اكتمال فهم احتياجات الزبون الأساسية واستلام معلومات المنتج من Majed قبل الانتقال إلى Fit-Gap Analysis |
+| **المدخلات المطلوبة** | `PRODUCT_DISCOVERY_SUMMARY.md`, `PRODUCT_DEMO_SCRIPT.md`, كتالوج المنتج من Majed |
+| **شروط النجاح** | 1. PRODUCT_DISCOVERY_SUMMARY.md يحتوي: اسم العميل، المنتج المستهدف، الاحتياجات الأساسية، الميزانية الأولية<br>2. PRODUCT_DEMO_SCRIPT.md جاهز<br>3. معلومات المنتج مستلمة من Majed (اسم، Feature Matrix، Pricing)<br>4. الـ Demo قُدّم للزبون (أو مجدول) |
+| **شروط الإيقاف (Blocking Conditions)** | 1. لم يستلم TCEA معلومات المنتج من Majed ← توقف — اسأل Majed<br>2. PRODUCT_DISCOVERY_SUMMARY.md غير مكتمل ← توقف<br>3. Product Demo لم يُقدّم ← تنبيه (لا يمنع، لكن يُفضّل إكماله) |
+| **الإخراج الإلزامي** | **PASS/FAIL** — عند PASS: الانتقال إلى Phase B2 (Fit-Gap) |
+
+---
+
+### PB.2 Fit-Gap Coverage Gate — بوابة تغطية تحليل الفجوة
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Fit-Gap Coverage Gate |
+| **الهدف** | ضمان اكتمال Fit-Gap Analysis لكل متطلبات الزبون قبل الانتقال إلى Solution Blueprint والتسعير |
+| **المدخلات المطلوبة** | `FIT_GAP_MATRIX.md`, `RICEFW_INVENTORY.md`, `PRODUCT_DISCOVERY_SUMMARY.md` |
+| **شروط النجاح** | 1. FIT_GAP_MATRIX.md يغطي جميع المتطلبات الأساسية (Must-have كحد أدنى)<br>2. كل مطلب مصنف: Fit / Gap-Config / Gap-Custom / Process Change<br>3. كل Gap-Custom له Business Case مبدئي<br>4. MoSCoW أولويات محددة لجميع المتطلبات<br>5. RICEFW_INVENTORY.md يحتوي كل Gap-Custom |
+| **شروط الإيقاف (Blocking Conditions)** | 1. أي Must-have غير مصنّف ← توقف<br>2. Gap-Custom بدون Business Case ← توقف |
+| **الإخراج الإلزامي** | **PASS/FAIL** — عند PASS: الانتقال إلى Phase B3 (Solution Blueprint & Pricing) |
+
+---
+
+### PB.3 Solution Blueprint Gate — بوابة التصميم والتسعير
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Solution Blueprint Gate |
+| **الهدف** | ضمان اكتمال التصميم والتسعير قبل Handoff إلى TeraAgent للتنفيذ التقني |
+| **المدخلات المطلوبة** | `SOLUTION_BLUEPRINT.md`, `PRODUCT_QUOTATION.md`, `FIT_GAP_MATRIX.md` |
+| **شروط النجاح** | 1. SOLUTION_BLUEPRINT.md يحتوي: To-Be Business Process, Data Migration Plan, Integration Architecture<br>2. PRODUCT_QUOTATION.md جاهزة ومعتمدة من Majed<br>3. جميع Gap-Custum في RICEFW_INVENTORY.md مسعّرة<br>4. PRODUCT_IMPLEMENTATION_HANDOFF.md مسودة أولية جاهزة |
+| **شروط الإيقاف (Blocking Conditions)** | 1. PRODUCT_QUOTATION.md غير معتمدة من Majed ← توقف<br>2. SOLUTION_BLUEPRINT.md لا يغطي جميع Gap-Custom المعتمدة ← توقف |
+| **الإخراج الإلزامي** | **PASS/FAIL** + PRODUCT_IMPLEMENTATION_HANDOFF.md. عند PASS: Handoff إلى TeraAgent |
+
+---
+
+### PB.4 Configuration Readiness Gate — بوابة جاهزية التكوين
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Configuration Readiness Gate |
+| **الهدف** | ضمان اكتمال التكوين والاختبار قبل الانتقال إلى Go-Live ⚡ TeraAgent مسؤول عنها تقنياً |
+| **المدخلات المطلوبة** | `CONFIG_WORKBOOK.md`, `DATA_MIGRATION_PLAN.md`, تقارير اختبار (Unit + Integration) |
+| **شروط النجاح** | 1. CONFIG_WORKBOOK.md — جميع التكوينات مطبّقة وموثّقة<br>2. DATA_MIGRATION_PLAN.md — خطة ترحيل معتمدة<br>3. اختبارات الوحدة والتكامل — PASS (من TeraAgent)<br>4. TCEA يؤكد: لا توجد مشاكل معلقة من جانب الزبون |
+| **شروط الإيقاف (Blocking Conditions)** | 1. CONFIG_WORKBOOK.md غير مكتمل ← توقف<br>2. اختبارات FAIL معلقة ← توقف<br>3. الزبون لم يؤكد استعدادية البيانات للترحيل ← تنبيه |
+| **الإخراج الإلزامي** | **PASS/FAIL** — ⚡ يُنفذ بواسطة TeraAgent، TCEA يتحقق من تنسيق الزبون |
+
+---
+
+### PB.5 Go-Live Readiness Gate — بوابة جاهزية الإطلاق
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Go-Live Readiness Gate |
+| **الهدف** | ضمان اكتمال التدريب وترحيل البيانات وUAT قبل الإطلاق الفعلي |
+| **المدخلات المطلوبة** | `TRAINING_PLAN.md`, `CUTOVER_PLAN.md`, تقرير UAT (من الزبون) |
+| **شروط النجاح** | 1. TRAINING_PLAN.md — المستخدمون مدربون<br>2. CUTOVER_PLAN.md — خطة الانتقال معتمدة من Majed والزبون<br>3. UAT معتمد من الزبون (Acceptance Signed)<br>4. Data Migration — Mock Migration PASS |
+| **شروط الإيقاف (Blocking Conditions)** | 1. UAT غير معتمد ← توقف<br>2. المستخدمون غير مدربين ← توقف<br>3. Mock Migration FAIL ← توقف |
+| **الإخراج الإلزامي** | **PASS/FAIL** — عند PASS: الإذن بالإطلاق (Go-Live) |
+
+---
+
+### PB.6 Hypercare Handoff Gate — بوابة إنهاء الدعم المكثف
+
+| البند | التفاصيل |
+|-------|----------|
+| **الاسم** | Hypercare Handoff Gate |
+| **الهدف** | ضمان استقرار النظام بعد الإطلاق قبل تسليمه نهائياً للفريق التشغيلي أو إغلاق المشروع |
+| **المدخلات المطلوبة** | `ISSUE_LOG.md`, `HANDOVER_DOCUMENT.md`, Post-Implementation Review |
+| **شروط النجاح** | 1. ISSUE_LOG.md — لا توجد مشاكل Critical/High مفتوحة<br>2. HANDOVER_DOCUMENT.md — يحتوي: كلمة السر، عناوين الخوادم، جهات الاتصال، إجراءات الصيانة الأساسية<br>3. Post-Implementation Review — أُجريت مع الزبون ووثّقت<br>4. TCEA يؤكد: الزبون راضٍ ولا توجد مشاكل معلقة |
+| **شروط الإيقاف (Blocking Conditions)** | 1. مشاكل Critical/High مفتوحة ← توقف<br>2. HANDOVER_DOCUMENT.md غير مكتمل ← توقف |
+| **الإخراج الإلزامي** | **PASS/FAIL** — عند PASS: إغلاق المشروع أو الانتقال إلى دعم عادي (Retainer) |