@tera-system/core 0.1.0

package/core/tera-system/product-standards/maintenance-apps/BEST_PRACTICES_DOMAIN.md

@@ -0,0 +1,325 @@
+---
+document_type: product_standard_best_practices
+standard_id: TERA-STD-MNT-002
+product_name: "Tera Maintenance — منصة إدارة طلبات الصيانة"
+domain: Maintenance Management / Field Service Management (FSM) / Work Order Management (WOM)
+version: "1.0"
+date: "2026-07-07"
+language: "ar"
+direction: "rtl"
+status: "active — منشور كمعيار منظومة Tera"
+owner: "TeraSystem (Majed)"
+basis: "مبني على Domain Research (33 مصدراً عالمياً) + Domain Intelligence Report — وليس على أي عميل محدد"
+companion: "يرافق STANDARD_DEFINITION.md (ملف التعريف)"
+---
+
+# أفضل الممارسات القياسية — Tera Maintenance
+
+> 🔑 **هذا هو "دستور" المنتج.** كل ما يليه هو المعيار المعتمد من Tera لأنظمة صيانة الأجهزة.
+> يُعطى لأي عميل جديد لقراءته قبل النقاش — يخفف عبء العمل ويمنع إعادة اختراع العجلة.
+> **المصدر:** البحث المخصص (33 مصدراً) + Domain Intelligence Report — **وليس كلام أي عميل**.
+
+---
+
+## 1. معايير سير العمل (Workflow Standards)
+
+### T-WF-MNT-001 — دورة حياة الطلب (إلزامي ✅ Core)
+
+```
+المرحلة 1: الطلب (Request)
+    ↓
+المرحلة 2: الفرز والتقييم (Triage)
+    ↓
+المرحلة 3: التعيين (Assign)
+    ↓
+المرحلة 4: التنفيذ (Execute)
+    ↓
+المرحلة 5: الإغلاق (Close)
+    ↓
+المرحلة 6: التحليل (Analyze)
+```
+
+| المرحلة | الوصف | المسؤول |
+|:--------|:-------|:--------|
+| 1. الطلب | استقبال الطلب + تسجيل العميل والجهاز | استقبال |
+| 2. الفرز | تحديد الأولوية + تقييم الأهمية | استقبال/مدير |
+| 3. التعيين | اختيار الفني المناسب + تحديد الموعد | مدير |
+| 4. التنفيذ | الفني يشخّص + يسجّل + يطلب موافقة | فني |
+| 5. الإغلاق | تسجيل الدفع + تسليم الجهاز | استقبال/محاسب |
+| 6. التحليل | تقرير + قياس أداء | مدير |
+
+### T-WF-MNT-002 — إدارة الحالة (إلزامي ✅ Core)
+
+**الحالات المعيارية (8 حالات كحد أقصى):**
+
+```
+1. جديد (New)
+2. قيد المراجعة (Under Review)        ← الفرز والتقييم
+3. تم التخصيص (Assigned)              ← الفني معيّن
+4. قيد التنفيذ (In Progress)          ← الفني يشتغل
+5. بانتظار موافقة العميل (Pending Approval)
+6. معلق (On Hold)                     ← بانتظار قطعة/معلومة
+7. تم الإنجاز (Completed)             ← جاهز للتسليم
+8. مغلق (Closed)                      ← سُلّم + سُدِد
+```
+
+**القواعد:**
+- لا تزيد عن 8 حالات — كثرة الحالات تربك المستخدمين
+- كل تغيير حالة = سجل في `StatusHistory` (من، متى، من أي حالة إلى أي حالة)
+- إشعار تلقائي للأطراف المعنية (انظر §5)
+
+### T-WF-MNT-003 — موافقة العميل (إلزامي ✅ Core)
+
+```
+1. بعد الفحص → تسجيل التكلفة المقترحة
+2. حالة الطلب: "بانتظار موافقة العميل"
+3. تسجيل طريقة الموافقة: [واتساب / مكالمة / داخل الورشة]
+4. تسجيل: هل وافق؟ (نعم/لا) + من سجّل + متى
+5. إذا وافق → "قيد التنفيذ"
+6. إذا رفض → "مغلق" (أو إرجاع الجهاز)
+```
+
+**القاعدة الحاسمة:** لا يبدأ التنفيذ WITHOUT توثيق الموافقة. هذا يحمي المنظومة والعميل قانونياً.
+
+### T-WF-MNT-004 — نظام الأولويات (إلزامي ✅ Core)
+
+| الأولوية | اللون | المعنى | الترتيب في القائمة |
+|:--------|:------|:-------|:-------------------|
+| **عادي** (Normal) | 🟢 أخضر | طلب روتيني | الأخير |
+| **مهم** (Important) | 🟡 أصفر | يحتاج انتباه | وسط |
+| **طارئ** (Urgent) | 🔴 أحمر | عميل مستعجل / جهاز أساسي / صيف | **الأول** |
+
+**القاعدة:** الطلبات الطارئة تظهر أعلى القائمة دائماً.
+
+---
+
+## 2. معايير نموذج البيانات (Data Model Standards)
+
+### T-DM-MNT-001 — الكيانات الأساسية (إلزامي ✅ Core)
+
+```
+العميل (Customer)
+  ├── له عناوين متعددة
+  ├── له أجهزة (Asset)
+  ├── له طلبات (WorkOrder)
+  └── له مدفوعات
+
+الجهاز (Asset) — كيان مستقل مرتبط بالعميل
+  ├── نوع (DeviceType): ثلاجة/غسالة/مكيف/شاشة...
+  ├── ماركة (Brand)
+  ├── موديل (Model) — اختياري
+  ├── رقم سيريال (Serial) — اختياري
+  └── تاريخ صيانة (من الطلبات السابقة)
+
+طلب الصيانة (WorkOrder)
+  ├── مرتبط بعميل + جهاز
+  ├── مرتبط بفني
+  ├── له حالة (Status) + أولوية (Priority)
+  ├── له تكلفة (مقترحة + فعلية)
+  ├── له موافقة (طريقة + حالة + توقيت)
+  ├── له مدفوعات
+  └── له سجل حالة (StatusHistory)
+
+الفني (Technician)
+  ├── مرتبط بـ User
+  ├── له مهارات (Skills)
+  └── له طلبات مسندة
+
+المستخدم (User)
+  ├── له دور (Role): مدير/استقبال/فني/محاسب
+  └── مرتبط بفرع (Branch) — حتى لو فارغ
+
+الدفع (Payment)
+  └── مرتبط بطلب
+```
+
+### T-DM-MNT-002 — تصميم للتوسع (إلزامي ✅ Core)
+
+| المبدأ | التطبيق |
+|:-------|:--------|
+| **branch_id** | في كل جدول رئيسي — لتصفية البيانات حسب الفرع من اليوم الأول (حتى لو عميل بفرع واحد) |
+| **Audit Trail** | جدول `StatusHistory` لكل كيان رئيسي — يمنع الإنكار ويوفر تتبعاً |
+| **Soft Delete** | حقل `deleted_at` — لا حذف فيزيائي |
+| **JSON fields** | للحقول المتغيرة (مثل المهارات، التفاصيل الإضافية) — مرونة بدون تغيير Schema |
+| **Indexing** | على الحقول الأكثر بحثاً: `wo_number`, `phone`, `status`, `date` |
+| **العلاقات** | ماركة ← موديل ← قطعة غيار (Many-to-Many) — جاهز للتوسع لاحقاً |
+
+**ملاحظة:** جدول `SparePart` و`Supplier` و`Warehouse` و`ServiceContract` جاهزة من الآن (حتى لو فارغة) — لتجنب إعادة البناء عند التوسع.
+
+---
+
+## 3. معايير إدارة المخزون (Inventory Standards)
+
+### T-INV-MNT-001 — تصنيف قطع الغيار (قياسي ⚪ Standard — Phase 2)
+
+- **تصنيف ABC:** A (عالية القيمة، قليلة) / B (متوسطة) / C (رخيصة، كثيرة)
+- **Criticality Analysis:** حسب أهمية القطعة لاستمرارية الخدمة
+- **الربط:** قطعة الغيار ← أنواع الأجهزة/الموديلات (Many-to-Many)
+
+### T-INV-MNT-002 — إعادة الطلب التلقائي (متقدم 🔶 Advanced — Phase 2+)
+
+- **Reorder Point:** حد أدنى للمخزون عند الوصول له ← أمر شراء تلقائي
+- **Safety Stock:** مخزون أمان لمواجهة تقلبات الطلب
+- **Auto-Deduct:** عند إغلاق أمر عمل ← إنقاص الكمية المستخدمة آلياً
+- **Low Stock Alerts:** إشعار عند انخفاض الكمية
+
+---
+
+## 4. معايير التكامل (Integration Standards)
+
+### T-INT-MNT-001 — تكامل واتساب (قياسي ⚪ Standard — Phase 2)
+
+- **الأداة:** WhatsApp Business Cloud API (وليس واتساب العادي)
+- **الاستخدام:** إشعارات، عروض أسعار، موافقة (Interactive Template)، استقبال طلبات
+- **الأولوية:** قصوى في السوق العربي — العميل يتوقع واتساب كقناة أولى
+
+### T-INT-MNT-002 — تصميم API للتوسع (قياسي ⚪ Standard — من اليوم الأول)
+
+```
+- RESTful + JSON
+- OpenAPI/Swagger موثّق
+- Rate Limiting
+- Webhooks للأحداث (طلب جديد، تغيير حالة، دفع)
+- Versioning: /api/v1/, /api/v2/
+```
+
+**Endpoints الأساسية:**
+```
+GET/POST   /api/v1/customers
+GET/POST   /api/v1/work-orders
+PATCH      /api/v1/work-orders/{id}/status
+GET/POST   /api/v1/spare-parts/consume
+POST       /api/v1/payments
+GET        /api/v1/reports/kpi
+POST       /api/v1/notifications/send
+```
+
+---
+
+## 5. معايير الإشعارات (Notification Standards)
+
+### T-NOT-MNT-001 — إشعارات موجهة حسب الدور (إلزامي ✅ Core)
+
+| الدور | يستلم إشعار عند |
+|:-----|:----------------|
+| **فني** | إسناد طلب جديد + تغيير حالة طلبه |
+| **استقبال** | جهاز جاهز للتسليم + يحتاج تواصل مع عميل |
+| **مدير** | طلب متأخر + طلب طارئ + طلب بقي طويلاً بلا تحديث |
+| **محاسب** | طلب جاهز وعليه مبلغ/دفعة مستحقة |
+
+**القاعدة الذهبية:** فقط الأحداث التي **تحتاج تصرّفاً** من المستلم — لا إزعاج بكل حركة صغيرة.
+
+---
+
+## 6. معايير تجربة المستخدم (UX/UI Standards)
+
+### T-UX-MNT-001 — Mobile-First + Offline-First (إلزامي ✅ Core)
+
+- التصميم للجوال أولاً (الفنيون في الميدان)
+- العمل دون اتصال مع مزامنة لاحقة (مهم للورش والزيارات الميدانية)
+
+### T-UX-MNT-002 — دعم العربية الكامل (إلزامي ✅ Core)
+
+- RTL متكامل
+- خطوط تدعم العربية
+- دعم الأرقام (هندية/عربية)
+- تقويم هجري + ميلادي
+
+### T-UX-MNT-003 — مبادئ لكل دور
+
+| الدور | الأولوية في التصميم |
+|:-----|:-------------------|
+| **مدير** | لوحة تحكم سريعة + تقارير بيانية |
+| **استقبال** | جدولة Drag-and-Drop + تحويل سريع |
+| **فني** | 3-4 نقرات كحد أقصى لإنجاز المهمة + أزرار كبيرة |
+| **محاسب** | واجهة فواتير ومدفوعات واضحة |
+| **عميل** (عبر موظف) | تتبع بسيط برقم الطلب + رقم الهاتف |
+
+---
+
+## 7. معايير التقارير (Reporting Standards)
+
+### التقارير الأساسية (Level 1 — إلزامي ✅)
+
+| التقرير | المحتوى |
+|:--------|:--------|
+| **يومي** | عدد الطلبات الجديدة/المنجزة/قيد التنفيذ |
+| **أسبوعي** | ملخص المدير: جديد، منجز، متأخرات، إيراد، أكثر فني إنجازاً |
+| **شهري** | ملخص الإيرادات + فلترة حسب الفني |
+| **المتأخرات** | الطلبات التي تجاوزت المدة المتوقعة |
+
+### تقارير متقدمة (Level 2+ — Standard/Advanced)
+
+- **KPIs:** MTTR (متوسط وقت الإصلاح)، FTFR (نسبة الإصلاح من أول مرة)، PM/CM Ratio
+- **تكلفة الصيانة لكل أصل**
+- **رضا العملاء (CSAT)**
+
+---
+
+## 8. معايير البنية التحتية (Architecture Standards)
+
+### T-ARC-MNT-001 — تعدد الفروع (إلزامي ✅ Core)
+
+- كل جدول رئيسي يحمل `branch_id`
+- المدير يرى كل الفروع — الفني يرى فرعه فقط
+- لا تكلفة إضافية في النسخة الأولى — فقط جاهزية في DB
+
+### T-ARC-MNT-002 — الأمان والامتثال
+
+- تشفير HTTPS إلزامي
+- صلاحيات الأدوار تمنع الوصول غير المصرح به
+- **PDPL الأردني:** تشفير بيانات العملاء + احترام الخصوصية (استشارة قانونية عند الحاجة)
+
+---
+
+## 9. قواعد التخصيص (Customization Rules)
+
+عندما يطلب عميل انحرافاً عن هذا المعيار:
+
+| النوع | الإجراء |
+|:------|:--------|
+| **إضافة ميزة ضمن Level الحالي** | مسموح — تُضاف لملف العميل كـ "تخصيص" |
+| **تخفيض ميزة من المعيار** | مسموح — لكن يُوثّق كـ "نطاق مخفض" صراحةً |
+| **ميزة من Level أعلى** | تُعامل كـ Phase تالية أو Change Request |
+| **تغيير جوهري في Workflow** | يتطلب مراجعة Majed — لا يُعدّل المعيار نفسه |
+
+**القاعدة الذهبية:** المعيار لا يُكسر لرغبة عميل — بل يُوثّق الانحراف في ملف العميل.
+
+---
+
+## 10. ملخص المعايير (Quick Reference)
+
+| المعيار | الرمز | الحالة | المستوى |
+|:--------|:------|:------:|:------:|
+| دورة حياة الطلب (6 مراحل) | T-WF-MNT-001 | ✅ Core | L1 |
+| إدارة الحالة (8 حالات) | T-WF-MNT-002 | ✅ Core | L1 |
+| موافقة العميل | T-WF-MNT-003 | ✅ Core | L1 |
+| نظام الأولويات (3 مستويات) | T-WF-MNT-004 | ✅ Core | L1 |
+| الكيانات الأساسية | T-DM-MNT-001 | ✅ Core | L1 |
+| تصميم للتوسع | T-DM-MNT-002 | ✅ Core | L1 |
+| تصنيف قطع الغيار | T-INV-MNT-001 | ⚪ Standard | L2 |
+| إعادة الطلب التلقائي | T-INV-MNT-002 | 🔶 Advanced | L2+ |
+| تكامل واتساب | T-INT-MNT-001 | ⚪ Standard | L3 |
+| تصميم API للتوسع | T-INT-MNT-002 | ⚪ Standard | L1+ |
+| إشعارات موجهة | T-NOT-MNT-001 | ✅ Core | L1 |
+| Mobile-First + Offline | T-UX-MNT-001 | ✅ Core | L1 |
+| دعم العربية الكامل | T-UX-MNT-002 | ✅ Core | L1 |
+| تقارير أساسية | (§7) | ✅ Core | L1 |
+| تعدد الفروع | T-ARC-MNT-001 | ✅ Core | L1 |
+| الأمان والامتثال | T-ARC-MNT-002 | ✅ Core | L1 |
+
+---
+
+## 11. الأساس البحثي
+
+هذا المعيار مبني على:
+- **33 مصدراً عالمياً** (انظر `DOMAIN_RESEARCH_REPORT_MAINTENANCE_APPS.md`)
+- **تحليل DomainExpertAgent** (انظر `DOMAIN_INTELLIGENCE_REPORT_MANTENANCE.md`)
+- **معايير ISO:** ISO 55000 (إدارة الأصول)، ISO 14224 (تصنيف الأعطال)
+- **استراتيجية الأردن الرقمية 2026-2028**
+
+**تنويه حاسم:** محتوى هذا الملف ليس ناتجاً عن رغبة أي عميل محدد — بل عن أفضل الممارسات العالمية المثبتة. أي عميل جديد يقرأ هذا الملف كمرجع، ويخصص ما يشاء منه في ملفاته الخاصة.
+
+---
+
+> **تنويه:** هذا المعيار هو "دستور" المنتج. لا يُعدّل إلا عبر مراجعة رسمية من Majed وتحديث الإصدار.

package/core/tera-system/product-standards/maintenance-apps/STANDARD_DEFINITION.md

@@ -0,0 +1,142 @@
+---
+document_type: product_standard_definition
+standard_id: TERA-STD-MNT-001
+product_name: "Tera Maintenance — منصة إدارة طلبات الصيانة"
+domain: Maintenance Management / Field Service Management (FSM) / Work Order Management (WOM)
+version: "1.0"
+date: "2026-07-07"
+language: "ar"
+direction: "rtl"
+status: "active — منشور كمعيار منظومة Tera"
+owner: "TeraSystem (Majed)"
+basis: "مبني على Domain Research (33 مصدراً عالمياً) + Domain Intelligence Report — وليس على أي عميل محدد"
+applies_to: "أي عميل يطلب تطبيق إدارة طلبات صيانة للأجهزة المنزلية/الكهربائية/الإلكترونية"
+---
+
+# تعريف المنتج القياسي — Tera Maintenance
+
+> **هذا الملف هو "ملف التعريف" لمنتج Tera القياسي لتطبيقات صيانة الأجهزة.**
+> يُستخدم كنقطة انطلاق لأي عميل جديد — لا يُعاد اختراع العجلة في كل مشروع.
+> **المصدر المعتمد:** البحث المخصص (DomainResearchAgent + DomainExpertAgent) — لا علاقة له بأي عميل بعينه.
+
+---
+
+## 1. ما هو هذا التطبيق؟
+
+**Tera Maintenance** هو منصة برمجية لإدارة دورة حياة **طلبات صيانة الأجهزة** (المنزلية، الكهربائية، الإلكترونية). يغطي الاستقبال، التشخيص، الموافقة، التنفيذ، الدفع، والتسليم — مع متابعة الفنيين والتقارير.
+
+| البند | الوصف |
+|:------|:-------|
+| **الاسم القياسي** | Tera Maintenance — منصة إدارة طلبات الصيانة |
+| **النوع** | Web App متجاوب (Responsive) — يعمل على الكمبيوتر والجوال |
+| **اللغة** | العربية (RTL) أولاً |
+| **الجمهور المستهدف** | ورش ومؤسسات صيانة الأجهزة (من فني واحد إلى 30+) |
+| **نموذج التسليم** | MVP قابل للتوسع تدريجياً (انظر مصفوفة النضج §4) |
+
+---
+
+## 2. لمن هذا التطبيق؟ (Target Segments)
+
+| الشريحة | الوصف | المستوى الموصى |
+|:--------|:-------|:--------------:|
+| **محل صيانة صغير** | 1-5 موظفين، فني واحد إلى 3 | Level 1 (أساسي) |
+| **مؤسسة صيانة متوسطة** | 5-15 موظفاً، فنيون متعددون | Level 1 → 2 |
+| **شركة صيانة** | 10-30 موظفاً، فروع محتملة | Level 2 → 3 |
+| **مزود خدمة صناعية/ميداني** | تركيز على الميدان + عقود | Level 3 → 4 |
+
+**الشركات التي يخدمها:**
+- صيانة غسالات، ثلاجات، مكيفات، شاشات، أفران، أجهزة مطبخ
+- صيانة أجهزة إلكترونية خفيفة
+- أي "ورشة + زيارة منزلية" مختلطة
+
+**الشركات التي لا يخدمها (يحتاج تخصيص منفصل):**
+- صيانة السيارات (مجال مختلف — معياره المستقل لاحقاً)
+- صيانة الجوالات (معيار `mobile-repair-apps/` المستقل)
+- المصانع والصيانة الصناعية الثقيلة (يحتاج CMMS متقدم)
+
+---
+
+## 3. متى نستخدم هذا المعيار؟ (Trigger)
+
+استخدم ملف المعايير هذا عندما:
+
+- ✅ العميل يطلب "نظام إدارة طلبات صيانة" أو "نظام متابعة أجهزة"
+- ✅ العميل لديه ورشة أو فريق صيانة ويعاني من التسجيل اليدوي
+- ✅ العميل يريد متابعة الفنيين والطلبات والتقارير
+- ✅ العميل يفضّل WhatsApp/هاتف كقناة تواصل أساسية
+
+**لا تستخدم هذا المعيار عندما:**
+- ❌ العميل يطلب ERP أو محاسبة متكاملة (يحتاج نطاق أوسع)
+- ❌ العميل يطلب تطبيق جوال مستقل تماماً في النسخة الأولى (هذا معيار Phase 3 — يُنصح به كإضافة)
+- ❌ العميل في مجال خارج الصيانة (تجارة، تعليم، طبي...)
+
+---
+
+## 4. مصفوفة النضج (Maturity Levels)
+
+هذا هو القلب الاستراتيجي — كل عميل يبدأ من مستوى ويصعد حسب حجمه وطموحه.
+
+| المستوى | الاسم | الميزات الأساسية | الفئة المستهدفة |
+|:------:|:------|:----------------|:-----------------|
+| **Level 1** | أساسي | CRM + طلبات + حالات + فنيين + دفع + تقارير أساسية | محلات صغيرة (1-5) |
+| **Level 2** | قياسي | Level 1 + مخزون + تقارير KPIs + جدولة + عقود بسيطة | شركات صغيرة-متوسطة (5-15) |
+| **Level 3** | متقدم | Level 2 + واتساب API + GPS + Offline + عقود متكررة | شركات متوسطة (10-30) |
+| **Level 4** | ذكي | Level 3 + صيانة تنبؤية + AI + تكامل ERP | شركات كبيرة + صناعية |
+
+**الافتراض الافتراضي (Default):** يبدأ أي عميل جديد من **Level 1** ويتوسع لاحقاً.
+
+---
+
+## 5. العلاقة مع ملفات المنظومة الأخرى
+
+| الملف | العلاقة |
+|:------|:--------|
+| `BEST_PRACTICES_DOMAIN.md` (في هذا المجلد) | 🔑 **الدستور** — تفاصيل المعايير التقنية والتشغيلية |
+| `TeraPricingPolicy.md` | التسعير يُحسب عبر السياسة المعتمدة (حالياً v4.2) |
+| `TERA_AGENT_CONDUCT.md` | قواعد السلوك الإلزامية لكل عملاء المنظومة |
+| ملفات العميل الفعلي (`client-engagement/`) | تُبنى **فوق** هذا المعيار — المعيار هو الأساس، العميل يخصص |
+
+---
+
+## 6. كيف نتعامل مع عميل جديد؟ (Workflow للتسويق/المبيعات)
+
+```
+1. نعطي العميل ملف BEST_PRACTICES_DOMAIN.md لقراءته
+2. العميل يرى ما هو "مشمول افتراضياً" (لا يحتاج نقاش)
+3. العميل يحدد انحرافاته عن المعيار (مثلاً: "أريد تقرير X إضافي")
+4. نحن نسجل الانحرافات كـ Change Requests أو تخصيصات
+5. ننتقل مباشرة للتسعير (ليس من Zero)
+```
+
+**الوفر في الوقت:** ~70% من أسئلة Discovery تصبح غير ضرورية — العميل يقرأ المعيار أولاً.
+
+---
+
+## 7. الأساس البحثي (Research Basis)
+
+هذا التعريف مبني على:
+
+| المصدر | المحتوى |
+|:-------|:--------|
+| `DOMAIN_RESEARCH_REPORT_MAINTENANCE_APPS.md` | 33 مصدراً عالمياً (ISO, ServiceTitan, Housecall Pro, Zoho FSM, OxMaint, MAPCON...) |
+| `DOMAIN_INTELLIGENCE_REPORT_MANTENANCE.md` | تحليل وتصنيف + Tera Best Practices + Gap Analysis |
+| استراتيجية الأردن الرقمية 2026-2028 | السياق المحلي |
+| معايير ISO 55000 / ISO 14224 | المرجع الدولي لإدارة الأصول والأعطال |
+
+**ملاحظة حاسمة:** محتوى هذا الملف **ليس** ناتجاً عن رغبة أي عميل محدد — بل عن أفضل الممارسات العالمية المثبتة.
+
+---
+
+## 8. حالة المعيار
+
+| البند | القيمة |
+|:------|:-------|
+| الإصدار | 1.0 |
+| تاريخ الإصدار | 2026-07-07 |
+| الحالة | ✅ منشور ومنفعّل |
+| المراجعة القادمة | عند تنفيذ 3 مشاريع فعلية أو ظهور فجوة بحثية جديدة |
+| المالك | Majed (TeraSystem) |
+
+---
+
+> **تنويه:** هذا المعيار هو "دستور" المنتج. أي انحراف عنه في مشروع عميل يجب توثيقه صراحةً في ملفات العميل — لا يُعدّل هذا الملف إلا عبر مراجعة رسمية من Majed.

package/core/tera-system/profiles/PROFILES_INDEX.md

@@ -0,0 +1,57 @@
+# Technology Profiles Index
+
+## Purpose
+
+Technology Profiles keep Tera Agent technically neutral at the system level.
+
+Tera must stay a generic project orchestrator. Technology-specific execution
+rules must come from the active profile, not from the core Tera system files.
+
+## Selection Order
+
+When Tera needs implementation rules, it determines the active profile in this order:
+
+1. Read `project-control/PROJECT_STATE.md`.
+2. If `Active Technology Profile` is defined there, use it.
+3. Otherwise review `project-inputs/02_TECHNICAL_CONTEXT.md`.
+4. Then derive or confirm it through `project-preparation/08_TECHNICAL_ARCHITECTURE.md`.
+5. If no matching profile exists, ask the user to confirm the stack or create a
+   draft profile from `tera-system/profiles/TEMPLATE.md` before execution.
+
+## Rules
+
+- Do not use rules from an inactive profile.
+- Do not mix rules from unrelated stacks.
+- Do not apply `nextjs-prisma` rules to `.NET Blazor + EF Core`.
+- Do not apply `dotnet-blazor-ef` rules to a Prisma-based project.
+
+## Relationship with Technical Context
+
+Technology Profile must not be selected from guesswork alone.
+
+Profile selection should be grounded in:
+
+1. `project-inputs/02_TECHNICAL_CONTEXT.md`
+2. `project-preparation/08_TECHNICAL_ARCHITECTURE.md`
+3. `project-control/PROJECT_STATE.md` when a live project uses it
+
+If the stack is still unclear, do not activate a final profile yet.
+
+## Current Profiles
+
+| Profile ID | Stack | Status | Notes |
+|---|---|---|---|
+| `nextjs-prisma` | Next.js + TypeScript + PostgreSQL + Prisma | Available | Use when the approved architecture matches this stack |
+| `dotnet-blazor-ef` | .NET Blazor + EF Core | Available | Ready for future .NET-oriented projects |
+| `effect-bun-opencode` | TypeScript + Effect TS + Bun + OpenCode-style monorepo | **Deprecated** | المشروع المصدر (TeraOpenCode/TeraAi) أُزيل 2026-08-15 — يحتفظ بمعرفة الـ stack للاستخدام المستقبلي |
+| `dotnet-wpf-sqlite` | C# (.NET 8) + WPF + CommunityToolkit.Mvvm + SQLite | ✅ **Approved** | WPF Desktop — معتمد من Majed (مشروع تجريبي سابق) |
+| `phaser-react-node` | Phaser 3 + React + Node.js + TypeScript + PostgreSQL + Zustand + TanStack Query + Zod + Vite + Vitest | ✅ **Approved** | Web Game 2D — معتمد من Majed (2026-07-29) |
+| `react-pwa` | React 18 + Vite + TypeScript + Tailwind CSS (RTL) + Zustand + idb (IndexedDB) + Fuse.js + vite-plugin-pwa | ✅ **Approved — Active** | PWA محلي عربي (Offline Standalone) — فعّل Majed (2026-08-01, PREP-D-016) |
+
+## Placeholder Candidates
+
+The following stacks may need profiles later, but are not created now:
+
+- Django + Django ORM
+- Laravel + Eloquent
+- Spring Boot + Hibernate

package/core/tera-system/profiles/TEMPLATE.md

@@ -0,0 +1,47 @@
+# Technology Profile: <profile-id>
+
+## 1. Profile Identity
+
+- Profile ID:
+- Language:
+- Framework:
+- Database:
+- ORM:
+- Package Manager / CLI:
+- Default Project Type:
+
+## 2. Applicability
+
+Describe when this profile should be used and what kind of projects it covers.
+
+## 3. Default Execution Order
+
+Provide the normal high-level implementation order for this stack.
+
+## 4. First Task Rule
+
+Define the safest first implementation task for this technology.
+
+## 5. Scaffold Rules
+
+List safe scaffold commands, important flags, and default scaffold restrictions.
+
+## 6. ORM / Database Rules
+
+Define the limits for schema, entities, migrations, apply commands, and database-side validation.
+
+## 7. CLI Side Effects
+
+List common commands that create files, install packages, modify config, create migrations, or change database state.
+
+## 8. Forbidden Defaults
+
+List what must not be created by default unless the task explicitly requires it.
+
+## 9. Pre-Execution Gate Additions
+
+List profile-specific checks that extend the general `TeraPreExecutionGate.md`.
+
+## 10. Acceptance Criteria Patterns
+
+List common acceptance expectations for this stack.

package/core/tera-system/profiles/dotnet-blazor-ef.md

@@ -0,0 +1,76 @@
+# Technology Profile: dotnet-blazor-ef
+
+## 1. Profile Identity
+
+- Profile ID: `dotnet-blazor-ef`
+- Language: C#
+- Framework: .NET Blazor
+- Database: SQL Server or approved project database
+- ORM: Entity Framework Core
+- Package Manager / CLI: dotnet CLI, NuGet
+- Default Project Type: Internal business application
+
+## 2. Applicability
+
+Use this profile when the approved architecture is based on .NET Blazor with EF Core.
+
+## 3. Default Execution Order
+
+1. Scaffold the Blazor project and solution structure.
+2. Add only the required base packages.
+3. Define entities and DbContext in separate approved tasks.
+4. Create migrations in a separate approved task.
+5. Apply database changes only in a dedicated database task.
+
+## 4. First Task Rule
+
+Safe first task:
+
+```text
+Scaffold .NET Blazor project + basic solution structure only
+```
+
+## 5. Scaffold Rules
+
+- Use `dotnet new blazor...` only for project scaffolding.
+- Keep the first task limited to project structure and minimum approved packages.
+
+## 6. ORM / Database Rules
+
+- Entities belong to a separate schema/domain task.
+- `DbContext` belongs to a clear database setup task.
+- Migrations belong to a separate migration task.
+- `dotnet ef database update` is forbidden unless the task is explicitly a database apply task.
+- Do not add Identity/Auth without explicit delegation.
+
+## 7. CLI Side Effects
+
+- `dotnet new blazor...` creates boilerplate files.
+- `dotnet add package` modifies `.csproj`.
+- `dotnet ef migrations add` creates migration files.
+- `dotnet ef database update` changes database state.
+
+## 8. Forbidden Defaults
+
+Do not add by default in the first implementation task:
+
+- Entities
+- `DbContext`
+- migrations
+- database update
+- Auth
+- custom UI styling
+- large services
+- repository layer without clear need
+
+## 9. Pre-Execution Gate Additions
+
+- Confirm scaffold task does not silently add Identity or extra hosting layers.
+- Confirm EF Core work is split from scaffold work unless the task explicitly combines them with approval.
+- Confirm database update commands are isolated.
+
+## 10. Acceptance Criteria Patterns
+
+- Basic Blazor project structure exists and builds.
+- No unapproved database changes were applied.
+- No unapproved auth or heavy infrastructure was added.