@tera-system/core 0.2.4 → 0.2.6

package/MANIFEST.json

@@ -1,6 +1,6 @@
 {
   "name": "@tera-system/core",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "description": "Build manifest for the Tera System OpenCode Plugin component.",
   "compatibleEnvironments": [
     "opencode"
@@ -12,15 +12,15 @@
     "coreFiles": 111,
     "tools": 7,
     "projectControlTemplates": 1,
-    "assets": 28
+    "assets": 29
   },
   "sha256": {
-    "agents": "0dbd18c2289ef40f0c1a24b6a85d42a4aa02be4228ed5060b4e471cd422943de",
+    "agents": "627368c85eb5ab840986b6e8a60b08977803b73c52c698662bc6cc68a1254b7c",
     "commands": "a2520ceef3a3f4e9cec2e4c070aeecd41a215ed12438f81d45111e6c801f9ec2",
-    "core/tera-system": "9d73d60f1b10460fb5e52ac2b80bd87fd224a6a63354d33268c2a8feb5a10805",
+    "core/tera-system": "527e36c620f68fe6c4c6056bd9345aca8f1c9eed7a028fe18d9b70c04dc1df51",
     "tools": "1f96a2de662c50c5c0a4c62d27ec583671c690163a0b35add036bfdd2b3a1f1a",
     "core/project-control": "cb979181d50e54c9b9b9173ffc890ca021bfaefe9678b1cad4a2f67ceac3dfdd",
-    "assets": "46e250f6540a6e59f171bc3b34e661185e7c1ad981bca6322bf242c2985651f8"
+    "assets": "8def8ca49522949e601a3bd325809d124c6135e4700e0b156d594f50f3886b7c"
   },
-  "builtAt": "2026-08-28"
+  "builtAt": "2026-08-29"
 }

package/RELEASES.md

@@ -4,6 +4,32 @@
 
 ---
 
+## 0.2.6 (2026-08-29)
+
+### نظام ترميز الخطابات الصادرة للزبون (SCP-2026-08-29-005)
+
+**الجديد:**
+- **صيغة رسمية موحدة:** `{كود-العميل}-{النوع}-{السنة}-{التسلسل}` (مثال: NPB-LET-2026-004) — عبر كل المشاريع والمستودعات.
+- **كود العميل من Majed فقط** — سجل مركزي `project-control/CLIENT_CODES.md` (المصدر الوحيد)، وحارس يرفع طلب كود لكل عميل جديد — الفريدية بنيوية (لا تكرار عبر المستودعات).
+- **أنواع وثائق رسمية** (قابلة للزيادة بقرار Majed): LET / CON / ADD / PAL / DOC / TPL.
+- **سجل خطابات العميل** `client-approval/LETTER_LOG.md` إلزامي — مصدر التسلسل المحلي، يُسجَّل قبل الإرسال.
+- القاعدة في تدفق TCEA (A.4) + TeraClientPolicy §9.6 + خريطة السياسات.
+
+---
+
+## 0.2.5 (2026-08-29)
+
+### ملكية السورس كود + سياسة التسعير (SCP-2026-08-29-004)
+
+**الجديد:**
+- **قاعدة ملكية السورس:** السورس كود حق ملكية Tera — لا يُسلَّم للزبون افتراضياً (TeraPricingPolicy §31 + TeraClientPolicy §9.5 + العقد §12).
+- **خيارا شراء:** L1 (Source Access — 40% من سعر المشروع) و L2 (ملكية داخلية — max(3×، 1,000 JOD)) عبر ملحق تعاقدي — وإعادة البيع مرفوضة افتراضياً (L3 = اتفاقية منفصلة بموافقة Majed).
+- **اكتشاف مبكر:** سؤال توقع السورس إلزامي في Domain 13 قبل التسعير (بنك الأسئلة QS.1–QS.4).
+- **نموذج جديد:** `tera-workshop/client-templates/contractual/SOURCE_CODE_PURCHASE_ADDENDUM_TEMPLATE.md` (assets 28→29).
+- **قوالب محدثة:** العقد §8/§12، الاقتباسان (DRAFT + QUOTATION)، تقرير الهاندوف، حزمة تسليم العميل، خريطتا السياسات والمعمارية، مساعد التسعير A.8.6.
+
+---
+
 ## 0.2.4 (2026-08-29)
 
 ### إصلاح فجوة التغليف: شحن الحاسبة + قوالب المراسلات (SCP-2026-08-29-002)

package/agents/tera-client-engagement.md

@@ -225,6 +225,8 @@ Majed يفتحك ← حوار استكشافي ← Websearch عن التطبيق
 ← **طبّق Budget-to-Scope Control Rule (B.2)** — صنّف كل ميزة حسب أولويتها وميزانية العميل
 ← **سجّل كل قرار في CLIENT_DECISION_LOG.md (C.5, B.5)** — بحالة Approved/Deferred/Conditional/Pending Approval
 ← **طبّق Final Scope Reconciliation Gate (B.3)** — وحّد حالة كل ميزة في FEATURE_LIST.md
+← **ملكية السورس (SCP-2026-08-29-004):** سؤال توقع السورس في Domain 13 إلزامي قبل التسعير — الافتراضي: السورس ملك Tera ولا يُسلَّم. إذا توقعه الزبون → قدّم L1/L2 كبند منفصل بموافقة Majed (TeraPricingPolicy §31) — وإعادة البيع مرفوضة افتراضياً
+← **ترميز الخطابات (SCP-2026-08-29-005):** لا تُرسل أي مراسلة رسمية للزبون دون رقم رسمي بصيغة `{كود-العميل}-{النوع}-{السنة}-{التسلسل}` — كود العميل من Majed حصراً (سجل CLIENT_CODES المركزي — لا يُخترع ولا يُستنتج)، والتسلسل من `client-approval/LETTER_LOG.md` المحلي — أنشئ السجل وسجّل كل خطاب قبل إرساله (الأنواع: LET/CON/ADD/PAL/DOC/TPL — راجع TeraClientPolicy §9.6)
 ← التحقق من Quotation Readiness Gate (B.4) قبل DRAFT_QUOTATION.md
 ← إنتاج DRAFT_QUOTATION.md (Level 2) ← Majed يراجع ويعتمد
 ← **تأكيد Workspace Plan مع Majed (المسار: clients/CLIENT-NAME/applications/APP-NAME/، الاسم الرسمي، الهيكل المتوقع — تخطيط فقط لا إنشاء مجلدات)**

package/assets/tera-workshop/client-templates/commercial/DRAFT_QUOTATION_TEMPLATE.md

@@ -64,10 +64,33 @@
 - [ ] اشتراكات خارجية (تراخيص، APIs، خدمات طرف ثالث)
 - [ ] تكاليف الاستضافة
 - [ ] تكاليف الدومين و SSL
+- [x] **السورس كود (ملك Tera — يُباع كخيار منفصل حسب TeraPricingPolicy §31)**
 - [ ] أخرى: _______
 
 ---
 
+## 5.1 ملكية السورس كود (إلزامي — SCP-2026-08-29-004)
+
+> **السورس كود حق ملكية لمنظومة Tera ولا يُسلَّم ضمن هذا العرض.**
+> خيارات شراء السورس متاحة بطلب منفصل بقرار Majed — وفق `TeraPricingPolicy.md` §31.
+> **مهم:** سؤال توقع السورس في Domain 13 إلزامي قبل التسعير — سجّل النتيجة هنا.
+
+| توقع الزبون (من Discovery Domain 13) | القرار |
+|---|---|
+| لا يتوقع السورس / غير متأكد | يُغلق بسطر الافتراضي أعلاه — بلا سعر |
+| يتوقع السورس للصيانة | قدّم L1 (40%) كبند منفصل — بقرار Majed |
+| يتوقع السورس لملكية كاملة | قدّم L2 (max(3×، 1,000 JOD)) — بقرار Majed |
+| يطلب إعادة بيع/ترخيص | **رفض افتراضي + إحالة لـ Majed** (L3 — اتفاقية منفصلة) |
+
+| خيار السورس (داخلي — لا يُعرض للزبون كسعر مفتوح) | السعر | مطبق؟ |
+|---|---|---|
+| L0 — ترخيص تشغيلي (الافتراضي) | — | [x] افتراضي |
+| L1 — Source Access (صيانة داخلية) | 40% من سعر المشروع | [ ] |
+| L2 — ملكية كاملة (استخدام داخلي) | max(3× السعر، 1,000 JOD) | [ ] |
+| L3 — إعادة بيع تجاري | مرفوض افتراضياً — موافقة Majed الخاصة | [ ] |
+
+---
+
 ## 6. خطة الدفع المقترحة
 
 - [ ] 50% – 25% – 25% (Default)

package/assets/tera-workshop/client-templates/commercial/QUOTATION_TEMPLATE.md

@@ -99,6 +99,7 @@ status: TEMPLATE
 - رسوم بوابات الدفع
 - الاشتراكات الخارجية (تراخيص، APIs، خدمات طرف ثالث)
 - الاستضافة أو الدومين أو SSL (إلا إذا ذُكرت صراحة)
+- **السورس كود — ملك مقدم الخدمة ولا يُسلَّم ضمن هذا العرض؛ خيارات شراء متاحة بطلب منفصل**
 
 ---
 

package/assets/tera-workshop/client-templates/contractual/SOFTWARE_SERVICES_AGREEMENT_TEMPLATE.md

@@ -87,7 +87,8 @@ status: TEMPLATE
 - قيمة الخدمات وطريقة الدفع حسب عرض السعر المعتمد.
 - لا يبدأ العمل قبل استلام الدفعة المقدمة.
 - يحق لمقدم الخدمة إيقاف العمل مؤقتًا عند تأخر أي دفعة مستحقة.
-- لا يتم تسليم النسخة النهائية أو السورس أو الوصول الكامل إلا بعد تسوية الدفعات المستحقة، ما لم يتفق الطرفان خطيًا على خلاف ذلك.
+- لا يتم تسليم النسخة النهائية (التطبيق قيد التشغيل والوثائق المتفق عليها) إلا بعد تسوية الدفعات المستحقة، ما لم يتفق الطرفان خطيًا على خلاف ذلك.
+- **السورس كود لا يُسلَّم ضمن هذه الاتفاقية** إلا بموجب «ملحق شراء السورس» معتمد وبعد سداد كامل مقابل الملحق — راجع البند 12.
 
 ---
 
@@ -117,8 +118,10 @@ status: TEMPLATE
 
 ## 12. الملكية الفكرية والسورس
 
-- يتم تحديد ملكية السورس وحق الاستخدام في عرض السعر أو نطاق العمل.
-- ما لم ينص الاتفاق خلاف ذلك، يحتفظ مقدم الخدمة بحق استخدام المعرفة العامة والقوالب والمكونات العامة والخبرات غير الخاصة بالعميل.
+- **السورس كود حق ملكية لمقدم الخدمة (Tera) ولا ينتقل إلى العميل افتراضياً.** يحصل العميل على ترخيص استخدام تشغيلي للتطبيق ضمن أعماله فقط.
+- لا يُسلَّم السورس كود بأي شكل (مستودع، ملفات، نسخ، أرشيف) إلا بموجب «ملحق شراء السورس» معتمد يحدد مستوى الحقوق والمقابل وفق سياسة التسعير (§31 من TeraPricingPolicy) — ويتم نقل الوصول أو الملكية **بعد سداد كامل مقابل الملحق**.
+- **إعادة بيع السورس أو التطبيق أو ترخيصه للغير ممنوعة دائماً** في المستويات L1 وL2، ما لم يُنص صراحة على خلاف ذلك في اتفاقية ترخيص/امتياز منفصلة معتمدة خطياً من الطرف الأول.
+- يحتفظ مقدم الخدمة بملكية المعرفة العامة والقوالب والمكونات المشتركة (واجهات، أنماط هندسة، مكونات جاهزة) المستخدمة في التطبيق — ولا تشملها أي ملكية تُمنح للعميل بموجب ملحق شراء السورس.
 - لا تنتقل أي ملكية أو صلاحيات نهائية قبل سداد المستحقات المتفق عليها.
 
 ---

package/assets/tera-workshop/client-templates/contractual/SOURCE_CODE_PURCHASE_ADDENDUM_TEMPLATE.md

@@ -0,0 +1,100 @@
+---
+document_type: source_code_purchase_addendum
+template_version: v1.0
+category: contractual
+used_by: TeraClientEngagementAgent
+client_facing: true
+approval_required: Majed
+client_signature_required: true
+legal_review_required: true
+pricing_policy: tera-system/TeraPricingPolicy.md (§31)
+status: TEMPLATE
+---
+
+# ملحق شراء السورس كود — `[ADDENDUM_ID]`
+
+> **نوع الوثيقة:** ملحق تعاقدي لاتفاقية الخدمات البرمجية `[AGREEMENT_ID]`
+> **تنبيه:** قالب مسودة قانونية — لا يُستخدم رسمياً إلا بعد مراجعة قانونية واعتماد Majed.
+> **المرجع الحاكم:** `TeraPricingPolicy.md` §31 — ملكية السورس كود والتسليم.
+
+---
+
+## 1. الأطراف
+
+| الطرف | الاسم |
+|---|---|
+| مقدم الخدمة (Tera) | `[PROVIDER_NAME]` |
+| العميل | `[CLIENT_NAME]` |
+
+---
+
+## 2. مستوى شراء السورس (اختر واحداً)
+
+| المستوى | الحقوق | السعر |
+|---:|---|---|
+| **L1 — Source Access** | وصول السورس لصيانة/تعديل فريق العميل أو مورد معتمد | `[L1_PRICE]` JOD (40% من سعر المشروع) |
+| **L2 — ملكية كاملة (استخدام داخلي)** | كل L1 + تعديل وإعادة استخدام داخل أعمال العميل وفروعه | `[L2_PRICE]` JOD (max(3× سعر المشروع، 1,000 JOD)) |
+
+**المستوى المختار:** `[L1 / L2]` — بمبلغ **`[TOTAL_ADDENDUM]` JOD**
+
+---
+
+## 3. الحقوق الممنوحة
+
+- `[LEVEL_RIGHTS]` — حسب المستوى المختار في البند 2.
+
+---
+
+## 4. الممنوعات (سارية دائماً في L1 و L2)
+
+- ❌ إعادة بيع السورس أو التطبيق أو ترخيصه للغير بأي شكل.
+- ❌ النشر العام للمستودع أو رفع الكود على منصات عامة.
+- ❌ إعادة استخدام السورس في منتج/خدمة تُقدَّم للغير (خارج أعمال العميل وفروعه).
+- ❌ إزالة أو إخفاء علامات الملكية أو إشعارات الحقوق من الملفات.
+
+---
+
+## 5. المقابل المالي والدفع
+
+- قيمة الملحق: **`[TOTAL_ADDENDUM]` JOD** — تُدفع دفعة واحدة **قبل** تسليم الوصول/الملكية.
+- **لا يُسلَّم السورس كود أو يُنقل أي وصول قبل سداد 100% من مقابل هذا الملحق.**
+- تأخير السداد يوقف نقل الوصول دون اعتبار ذلك إخلالاً من مقدم الخدمة.
+
+---
+
+## 6. طريقة التسليم
+
+- عبر مستودع خاص (Private Repository) أو أرشيف مشفّر يُسلَّم بقناة آمنة.
+- لا يُنشر الكود على أي منصة عامة.
+- (L2) يُوقَّع على إقرار نقل الملكية بعد السداد الكامل.
+
+---
+
+## 7. بقاء ملكية مكونات Tera المشتركة
+
+- تبقى ملكية المكونات المشتركة (واجهات، أنماط هندسة، قوالب، مكونات جاهزة) **لمقدم الخدمة** ولا تشملها هذه الصفقة — ويُزيل مقدم الخدمة أي مكوّن مشترك مطلوب قبل التسليم أو يرخّصه للاستخدام ضمن التطبيق فقط.
+
+---
+
+## 8. الضمان
+
+- الضمان الوارد في الاتفاقية الأصلية (البند 11) يسري على التطبيق المُسلَّم — ولا يشمل تعديلات العميل اللاحقة على السورس.
+
+---
+
+## 9. إقرار طرفي الاتفاقية
+
+- يقرّ الطرفان بأن ملكية السورس تنتقل (أو يُمنح الوصول) وفق البند 2 فقط، وبأنهما اطّلعا على الممنوعات في البند 4 والتزما بها.
+
+---
+
+## 10. التوقيع
+
+| الطرف | الاسم | التوقيع / الإقرار | التاريخ |
+|---|---|---|---|
+| العميل | `[CLIENT_SIGNATORY]` | `[SIGN_CLIENT]` | `[DATE]` |
+| مقدم الخدمة | `[PROVIDER_SIGNATORY]` | `[SIGN_PROVIDER]` | `[DATE]` |
+
+---
+
+> **ملاحظات الاستخدام:** لا يُعرض هذا الملحق في العرض الأولي — يُقدَّم فقط عند طلب الزبون صراحة للسورس، وبعد موافقة Majed على المستوى والسعر.

package/assets/tera-workshop/client-templates/handover/HANDOVER_REPORT_TEMPLATE.md

@@ -44,6 +44,8 @@ status: TEMPLATE
 | 2 | `[DELIVERABLE_2]` | تم التسليم / معلق | `[D2_NOTES]` |
 | 3 | `[DELIVERABLE_3]` | تم التسليم / معلق | `[D3_NOTES]` |
 
+> **غير مُسلَّم ضمن هذه العملية (ملك Tera):** السورس كود بأي شكل — إلا بموجب «ملحق شراء السورس» معتمد (L1/L2 وفق TeraPricingPolicy §31) — وإعادة بيعه أو ترخيصه للغير ممنوعة دائماً.
+
 ---
 
 ## 4. البنود المعلقة

package/core/tera-system/TeraApplicationQuestionBank.md

@@ -350,6 +350,26 @@ Once all relevant domains have been covered and Tera has a complete picture, pro
 
 ---
 
+## الملكية والسورس كود — أسئلة إلزامية (SCP-2026-08-29-004)
+
+> تُطرح في **Domain 13 (Acceptance & Commercials)** قبل إغلاق Discovery وقبل أي تسعير.
+> المصدر الحاكم: `TeraPricingPolicy.md` §31 + `TeraClientPolicy.md` §9.5.
+
+- **QS.1:** هل يتوقع الزبون استلام السورس كود؟ (نعم / لا / غير متأكد)
+- **QS.2:** هل لدى الزبون سياسة داخلية تشترط امتلاك السورس؟
+- **QS.3:** (إذا نعم) لأي غرض أساساً؟ (صيانة داخلية / ملكية كاملة للاستخدام الداخلي / إعادة بيع أو ترخيص للغير)
+- **QS.4:** هل قبل الزبون سابقاً نماذج ترخيص تشغيل بدون سورس؟
+
+**قرار التوجيه:**
+| النتيجة | الإجراء |
+|---|---|
+| لا يتوقع / غير متأكد | سطر الافتراضي في العرض: "السورس غير مشمول" — بلا سعر |
+| يتوقع للصيانة | عرض L1 (40%) كبند منفصل — بقرار Majed |
+| يتوقع ملكية كاملة | عرض L2 (max(3×، 1,000 JOD)) — بقرار Majed |
+| يطلب إعادة بيع/ترخيص | **رفض افتراضي + إحالة لـ Majed** (اتفاقية منفصلة فقط) |
+
+---
+
 ## Usage Rules
 
 1. **Tera does not ask all questions.** Select the essential ones first, then deep-dive only in domains that need it.

package/core/tera-system/TeraArchitectureMap.md

@@ -16,7 +16,7 @@ It is a map, not a policy source. Rules remain in the files listed in `TeraPolic
 | Strategic advisory and decision support | Helps Majed evaluate whether a decision, project, fork, or direction is right before execution; advisory only, no approval or execution authority | `.opencode/agents/tera-strategic-advisor.md` |
 | Project intake | Captures raw idea, technical context, missing information, and readiness | `TeraProjectIntakePolicy.md`, `project-inputs/` |
 | Client engagement and approval | Manages client profile, contacts, approval package, and change control — the commercial truth layer | `TeraClient*.md`, `clients/`, `.opencode/agents/tera-client-engagement.md` |
-| Solution preparation (phases 1–4) | Owned by مُهندس (ApplicationBlueprintAgent). Converts confirmed handoff into blueprint, intake, project decision, preparation planning, delegation, cross-review, baseline, and Engineering Handoff Package | `.opencode/agents/application-blueprint.md`, `Tera_Project_Preparation_Files.md`, `agent-helpers/Tera_Project_Preparation_Files_Conditional.md`, `project-preparation/`, `runtime/TERA_SOLUTION_PREPARATION_*.md` |
+| Solution preparation (phases 1–4) | Owned by مُهندس (ApplicationBlueprintAgent). Converts confirmed handoff into blueprint, intake, project decision, preparation planning, delegation, cross-review, baseline, and Engineering Handoff Package | `.opencode/agents/application-blueprint.md`, `Tera_Project_Preparation_Files.md`, `project-preparation/`, `runtime/TERA_SOLUTION_PREPARATION_*.md` |
 | Design governance | Controls design source decisions, design tokens, component rules, internal kits, and UI acceptance | `tera-system/design-system/`, `project-preparation/28_UI_UX_GUIDELINES.md` |
 | Engineering handoff gate | Two-gate handoff between مُهندس and Tera: Solution Readiness Gate → Engineering Handoff Package → Engineering Intake Gate | `ENGINEERING_HANDOFF_PACKAGE.md`, `project-control/` |
 | Execution orchestration (phases 5–7) | Owned by TeraAgent (Engineering Delivery Lead). Execution planning, delegation to Coding/QA/Audit agents, Pre/Post gates, implementation, delivery, closure | `TeraPreExecutionGate.md`, `runtime/TERA_RUNTIME_*.md`, `project-control/` |
@@ -25,7 +25,7 @@ It is a map, not a policy source. Rules remain in the files listed in `TeraPolic
 | Sub-agent lifecycle | Defines, generates, narrows, activates, and reviews specialized agents | `TeraSubAgents.md`, `AGENT_GENERATION_TEMPLATE.md`, `generated-agents/` |
 | Delivery, handoff, and closure | Produces final delivery readiness, release notes, client handover material, acceptance records, and closure reports | `project-control/DELIVERY_READINESS_REPORT.md`, `project-control/PROJECT_CLOSURE_REPORT.md`, `clients/.../delivery/` |
 | Project implementation knowledge | Maintains concise current-state operational knowledge per screen/module/service | `project-knowledge/` داخل كل تطبيق |
-| Tera distribution and versioning | Builds releases and distributes Tera to client repositories in a versioned, verifiable way; clients derive updates from the origin repository (RepositoryUrl) via fetch + verified release packages (Tag + Manifest + SHA lockfile + updater tools); ownership contract separates Tera-managed from client-owned files | `tera-system/TERA_DISTRIBUTION_POLICY.md`, `tools/tera-fetch.ps1`, `tools/tera-release.ps1`, `tools/tera-update.ps1`, `.tera/lock.json` داخل مستودعات العملاء |
+| Tera distribution and versioning | Builds releases and distributes Tera to client repositories in a versioned, verifiable way; clients derive updates from the origin repository (RepositoryUrl) via fetch + verified release packages (Tag + Manifest + SHA lockfile + updater tools); ownership contract separates Tera-managed from client-owned files | `tera-system/TERA_DISTRIBUTION_POLICY.md`, `tera-workshop/tools/tera-fetch.ps1`, `tera-workshop/tools/tera-release.ps1`, `tera-workshop/tools/tera-update.ps1`, `.tera/lock.json` داخل مستودعات العملاء |
 
 ## 3. Folder Roles
 
@@ -41,10 +41,9 @@ It is a map, not a policy source. Rules remain in the files listed in `TeraPolic
 | `tera-system/design-system/` | System design governance, schemas, gates, internal kits | Project-specific design decisions |
 | `tera-system/profiles/` | Technology-specific execution rules | Generic project policy |
 | `tera-system/knowledge-base/` | Reusable domain knowledge references | Project-specific client facts |
-| `tera-system/product-standards/` | Reusable active product standards | Runtime policy, client-specific records, or application code |
 | `tera-system/engineering-helpers/` | Shared engineering reference files | Language-specific profiles |
 | `tera-workshop/` | System development and tooling files | Core policy or project files |
-| `tools/` | Official Tera updater tooling (tera-update.ps1 + batch updater) used to pin/upgrade Tera in client repositories | Client application code; replacing client-owned files |
+| `tera-workshop/tools/` | Official Tera updater tooling (tera-update.ps1 + batch updater) used to pin/upgrade Tera in client repositories | Client application code; replacing client-owned files |
 | `book/` | Comprehensive user-facing documentation and guides (Quick Start, Vision, Quality, Policies) | Runtime operational files; per-project records |
 | `architecture/` | Structurizr C4 workspace (`.dsl` source of truth + exported diagrams) | Application code; client project files |
 
@@ -67,7 +66,7 @@ Client / User Idea
 ```text
 Client Registration → Contacts → Application Intake
 → Client Questions through Majed → Discovery Coverage
-→ Client Approval Package → Approval Record → Prototype Approval (Gate 6 — Tera first task TASK-PROTO-* + formal letter) → Execution Authorization (Gate 7)
+→ Client Approval Package → Approval Record → Execution Authorization
 → TCEA Handoff to مُهندس
 → مُهندس: Blueprint + Phases 1–4 → Solution Baseline
 → Solution Readiness Gate → Engineering Handoff Package
@@ -75,6 +74,8 @@ Client Registration → Contacts → Application Intake
 → Change Control for later requests
 ```
 
+**ملكية المخرجات (SCP-2026-08-29-004):** السورس كود ملك Tera ولا يُسلَّم للزبون افتراضياً — يُسلَّم التطبيق قيد التشغيل + الوثائق. خيارا L1/L2 (TeraPricingPolicy §31) عبر ملحق تعاقدي؛ إعادة البيع مرفوضة افتراضياً.
+
 ## 6. Runtime Design Principle
 
 All core runtime agents must pass the conduct gate in `tera-system/TERA_AGENT_CONDUCT.md`.

package/core/tera-system/TeraClientPolicy.md

@@ -100,9 +100,9 @@ Tera must not treat approval from a contact as final unless that contact has doc
 
 ### Client Discovery Output — Application Proposal
 
-After the Client Discovery + Smart Interview process completes (see `TERA_RUNTIME_PROTOCOLS_CLIENT.md` Section 18), the designated agent (TCEA for external clients, مُهندس for internal projects — SCP-2026-07-28-118) generates a **professional client-facing Application Proposal** as an HTML page using `tera-workshop/client-templates/commercial/APPLICATION_PROPOSAL_TEMPLATE.md`.
+After the Client Discovery + Smart Interview process completes (see `TERA_RUNTIME_PROTOCOLS_CLIENT.md` Section 18), the designated agent (TCEA for external clients, مُهندس for internal projects — SCP-2026-07-28-118) generates a **professional client-facing Application Proposal** as an HTML page using `tera-workshop/APPLICATION_PROPOSAL_TEMPLATE.html`.
 
-The proposal captures: understanding, users & roles, scope (MVP + out-of-scope), requirements by domain, assumptions, and proposed roadmap. Generated from `tera-workshop/client-templates/commercial/APPLICATION_PROPOSAL_TEMPLATE.md`.
+The proposal captures: understanding, users & roles, scope (MVP + out-of-scope), requirements by domain, assumptions, and proposed roadmap. Generated from `tera-workshop/APPLICATION_PROPOSAL_TEMPLATE.html`.
 
 The proposal is saved under `clients/.../client-approval/` and **must be approved by the client** before formal preparation begins. The approved proposal becomes the official scope reference for all subsequent gates.
 
@@ -203,7 +203,7 @@ The default mandatory package is:
 - `10_CLIENT_APPROVAL_RECORD.md`
 - `11_CHANGE_CONTROL.md`
 
-If a file is not applicable to a very small project, Tera must still create an explicit section in `10_CLIENT_APPROVAL_RECORD.md` explaining why it is not applicable and what replaced it. Exception: `08_PROTOTYPE_PLAN.md` may not be marked not applicable except with a documented Majed waiver (WAIVED_BY_MAJED) — the prototype is mandatory for all applications (SCP-2026-08-28-001).
+If a file is not applicable to a very small project, Tera must still create an explicit section in `10_CLIENT_APPROVAL_RECORD.md` explaining why it is not applicable and what replaced it.
 
 ### Approval Gates
 
@@ -214,35 +214,9 @@ If a file is not applicable to a very small project, Tera must still create an e
 | Gate 3: Flow Approval | The client confirms the main user and business flows. |
 | Gate 4: Screen Approval | The client confirms the screen list and screen purposes. |
 | Gate 5: Design Direction Approval | The client confirms visual direction, tone, and references. |
-| Gate 6: Prototype Approval | The client confirms the actual prototype (built and reviewed) via a formal approval letter. Mandatory for all applications. Exception: documented Majed waiver (WAIVED_BY_MAJED). |
+| Gate 6: Prototype Approval | The client confirms the prototype or prototype plan when applicable. |
 | Gate 7: Execution Authorization | The client authorizes moving into implementation. |
 
-### Prototype Mandate (SCP-2026-08-28-001)
-
-```text
-1. Every application — external or internal — requires an approved prototype before
-   real implementation. The only exception is a documented Majed waiver
-   (WAIVED_BY_MAJED) recorded in 10_CLIENT_APPROVAL_RECORD.md with a reason.
-   No agent may override this gate.
-2. The prototype is built by Coding Agents under Tera as the FIRST execution task
-   (TASK-PROTO-*), isolated under project-control/prototypes/ — non-production,
-   deleted or archived after approval. DesignReviewer (ناقد) reviews it before
-   it is shown to Majed and the client (Maker/Checker pattern).
-3. Coverage: all screens listed in 06_SCREEN_MAP.md. Large applications use waves
-   (critical transaction/input screens first); reducing waves is a Majed decision only.
-4. Approval evidence: a formal Prototype Approval Letter (see
-   tera-workshop/client-templates/contractual/PROTOTYPE_APPROVAL_LETTER_TEMPLATE.md)
-   confirming the screens/fields/flows as prototyped, and acknowledging that any
-   later impactful change = priced Change Request on the client's responsibility.
-   The letter is the Gate 6 evidence; without it (or a Majed waiver) the prototype
-   is not approved.
-5. The prototype must trace strictly to the approved baseline
-   (07_SCREENS_AND_UI_STRUCTURE.md) — it validates and surfaces gaps; it does not
-   invent requirements. Objections within approved scope = free design iteration
-   (baseline update via مُهندس when needed). Expansion beyond approved scope =
-   priced Change Request (MR4).
-```
-
 ### Approval Record
 
 `10_CLIENT_APPROVAL_RECORD.md` must document:
@@ -379,6 +353,73 @@ Client-facing content must protect clarity, scope, and trust.
 
 ---
 
+## 9.5 ملكية السورس كود (SCP-2026-08-29-004)
+
+```text
+السورس كود حق ملكية Tera — لا يُسلَّم للزبون افتراضياً في أي مشروع.
+التسعير والعروض والعقود والتسليم لا تفترض أن السورس للزبون.
+```
+
+- **الافتراضي:** العميل يحصل على ترخيص استخدام تشغيلي للتطبيق فقط. السورس لا يُسلَّم بأي شكل.
+- **عند اشتراط الزبون للسورس:** يُعرض خيارا L1 (Source Access — 40% من سعر المشروع) أو L2 (ملكية داخلية — max(3×، 1,000 JOD)) وفق `TeraPricingPolicy.md` §31 — عبر «ملحق شراء السورس» معتمد، وبنقل الوصول بعد سداد 100%.
+- **إعادة بيع السورس أو التطبيق أو ترخيصه للغير: مرفوضة افتراضياً** — تُعالج فقط باتفاقية ترخيص/امتياز منفصلة بموافقة Majed الخاصة.
+- مكونات Tera المشتركة (واجهات، أنماط هندسة، قوالب) تبقى ملك Tera في كل الأحوال.
+- سؤال توقع السورس إلزامي في Discovery (Domain 13) قبل أي تسعير — راجع بنك الأسئلة.
+
+---
+
+## 9.6 ترميز الخطابات والوثائق الصادرة للزبون (SCP-2026-08-29-005)
+
+```text
+المبدأ: لا تُرسل أي مراسلة رسمية للزبون دون رقم رسمي فريد — الترميز موحّد
+عبر كل المشاريع والمستودعات، وغير قابل للتكرار بين أي زبونين.
+```
+
+### الصيغة الرسمية
+
+```text
+{كود-العميل}-{نوع-الوثيقة}-{السنة}-{التسلسل}
+مثال:  NPB-LET-2026-004
+```
+
+| المكوّن | المصدر | القاعدة |
+|---|---|---|
+| **كود-العميل** (مثل NPB) | **Majed فقط** — عبر طلب يرفعه حارس من السجل المركزي `project-control/CLIENT_CODES.md` | يُخصص مرة واحدة ولا يُعاد استخدامه أبداً — يضمن الفريدية عبر المستودعات |
+| **نوع-الوثيقة** | التصنيف الرسمي أدناه | ثابت — يُضاف نوع جديد بقرار Majed |
+| **السنة** | سنة الإصدار | 4 أرقام |
+| **التسلسل** | سجل خطابات العميل `client-approval/LETTER_LOG.md` | عداد تصاعدي لكل (نوع + سنة) داخل نفس العميل — يبدأ من 001 |
+
+### أنواع الوثائق الرسمية (قابلة للزيادة)
+
+| الرمز | النوع | أمثلة |
+|:---:|---|---|
+| **LET** | خطاب / مراسلة رسمية | عرض السعر، اعتماد النطاق، الاعتماد التجاري، إشعارات (ملكية سورس وغيرها) |
+| **CON** | عقد / اتفاقية | اتفاقية خدمات برمجية، نطاق عمل (SOW)، ميثاق مشروع، NDA |
+| **ADD** | ملحق تعاقدي | ملحق شراء سورس، ملحق ملكية/دفع |
+| **PAL** | خطاب اعتماد بروتوتايب | اعتماد البروتوتايب |
+| **DOC** | وثيقة معلومات | ملخص اجتماع/فهم، نطاق تفصيلي، ملخص تجاري |
+| **TPL** | نموذج / استمارة | طلب تغيير، تقرير حالة |
+
+> **إضافة نوع جديد:** بقرار Majed فقط (عبر حارس) — لا يضيفه عميل المنظومة من تلقاء نفسه.
+
+### سجل خطابات العميل — `client-approval/LETTER_LOG.md` (إلزامي لكل عميل)
+
+| العمود | المعنى |
+|---|---|
+| رقم الخطاب | `{كود}-{نوع}-{سنة}-{تسلسل}` |
+| التاريخ | تاريخ الإصدار |
+| النوع | من التصنيف الرسمي |
+| المرجع/الملف | مسار/اسم ملف الخطاب |
+| الحالة | أُرسل / بانتظار رد / معتمد / ملغي |
+
+**قواعد:**
+1. يُنشأ `LETTER_LOG.md` عند أول خطاب لكل عميل ويُحدَّث قبل إرسال أي خطاب.
+2. التسلسل = آخر رقم من نفس (النوع + السنة) + 1.
+3. أي خطاب بلا رقم رسمي = مخالفة — لا يُرسل.
+4. كود العميل لا يُستنتج ولا يُخترع — يُؤخذ من Majed حصراً.
+
+---
+
 ## 10. Relationship to Internal Tera Files
 
 Client files are official relationship and approval records.

package/core/tera-system/TeraPolicyMap.md

@@ -38,7 +38,7 @@ Project files record project-specific decisions.
 | TCEA commercial value discovery (MR6) | `.opencode/agents/tera-client-engagement.md` (A.6.0 MR6) | `.opencode/agents/tera.md` | 6th Master Rule: TCEA must actively discover value-added opportunities — propose as options, not commitments. |
 | TCEA value-added proposals protocol | `tera-system/client-helpers/tera-client-engagement-protocols.md` (A.6.10) | Not applicable | Detailed protocol for commercial proposals: types, rules, template, connection to Future-Proof Discovery. |
 | Solution preparation (phases 1–4) | `.opencode/agents/application-blueprint.md` | `.opencode/agents/tera.md` (reference only) | Owned by مُهندس. Covers blueprint, intake, project decision, preparation planning, delegation, cross-review, baseline, and Engineering Handoff. SCP-2026-07-28-118. |
-| Preparation file catalog | `tera-system/Tera_Project_Preparation_Files.md` + `tera-system/agent-helpers/Tera_Project_Preparation_Files_Conditional.md` | `TERA_PROJECT_DECISION.md` | Main guide/index plus on-demand companion for conditional and supporting files. Owned by مُهندس during preparation. |
+| Preparation file catalog | `tera-system/Tera_Project_Preparation_Files.md` | `TERA_PROJECT_DECISION.md` | Comprehensive preparation files **Guide** (catalog + per-file purpose/questions/outputs) owned by مُهندس during preparation. Classified as reference Guide — not split (2026-08-01). |
 | Project decision template | `tera-system/TERA_PROJECT_DECISION.md` + `tera-system/runtime/TERA_SOLUTION_PREPARATION_TEMPLATES.md` §1 | Not applicable | Owned by مُهندس. 13-section structure. |
 | 7-phase Tera workflow | `.opencode/agents/tera.md` §11 (phases 5–7) + `.opencode/agents/application-blueprint.md` (phases 1–4) | Runtime files as referenced | Phases 1–4: مُهندس. Phases 5–7: Tera. SCP-2026-07-28-118. |
 | Phase 3 preparation planning output | `tera-system/runtime/TERA_SOLUTION_PREPARATION_TEMPLATES.md` §2 | `.opencode/agents/application-blueprint.md` | Produces `PREPARATION_PLAN.md`; owned by مُهندس. |
@@ -47,9 +47,9 @@ Project files record project-specific decisions.
 | Solution preparation templates | `tera-system/runtime/TERA_SOLUTION_PREPARATION_TEMPLATES.md` | `.opencode/agents/application-blueprint.md` | Phase 1–4 output templates for مُهندس. SCP-2026-07-28-118. |
 | Engineering handoff | `project-control/ENGINEERING_HANDOFF_PACKAGE.md` (produced by مُهندس, consumed by Tera) | `.opencode/agents/tera.md` §6 | Two-gate handoff: Solution Readiness → Engineering Intake. |
 | Phase 5 execution planning outputs | `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` Sections 29-31 | `.opencode/agents/tera.md`, `TERA_RUNTIME_CHECKLISTS.md`, `TeraPreExecutionGate.md` | Produces `PROJECT_MASTER_PLAN.md`, `PROJECT_DETAILED_EXECUTION_PLAN.md`, and `EXECUTION_BATCH_PLAN.md`. Split notice INS-02: Sections 29-31 moved to DELIVERY file. |
-| Phase 6 post-execution review template | `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` Section 32 | `TASK_TEMPLATE.md`, `TeraPreExecutionGate.md`, `TERA_RUNTIME_CHECKLISTS.md` | Used inside `TASK-COD-*` before final acceptance or closure. Note: `TASK_TEMPLATE.md` lives at `project-control/templates/TASK_TEMPLATE.md` (clarified INS-07, 2026-08-01). Split notice INS-02: Section 32 moved to DELIVERY file. |
+| Phase 6 post-execution review template | `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` Section 32 | `TASK_TEMPLATE.md`, `TeraPreExecutionGate.md`, `TERA_RUNTIME_CHECKLISTS.md` | Used inside `TASK-COD-*` before final acceptance or closure. Note: `TASK_TEMPLATE.md` lives at `project-control/tasks/TASK_TEMPLATE.md` (clarified INS-07, 2026-08-01). Split notice INS-02: Section 32 moved to DELIVERY file. |
 | Phase 7 delivery, handover, and closure | `.opencode/agents/tera.md` Section 5 + `TERA_RUNTIME_TEMPLATES_DELIVERY.md` Section 35 | `.opencode/agents/tera.md`, `TERA_RUNTIME_CHECKLISTS.md`, `TERA_RUNTIME_PROTOCOLS.md` | Project closure is separate from last TASK-COD closure. Phase 7 does not execute code. Split notice INS-02: Section 34 moved to DELIVERY file. |
-| Sub-agent registry (core) | `tera-system/TeraSubAgents.md` | `.opencode/agents/tera.md` | Core agents (Engineering, QA, Auditor, Software Designer, DesignReviewer) — 904 lines 🟡 |
+| Sub-agent registry (core) | `tera-system/TeraSubAgents.md` | `.opencode/agents/tera.md` | Core agents (Engineering, QA, Auditor, Software Designer) — 769 lines 🟢 |
 | Sub-agent registry (helpers) | `tera-system/TeraHelperAgents.md` | `.opencode/agents/tera.md` | Helper agents (Security, DevOps, Domain, ERP, etc.) — 964 lines 🟢 — split from TeraSubAgents.md via SCP-2026-07-26 |
 | Agent generation template | `tera-system/AGENT_GENERATION_TEMPLATE.md` | `TERA_RUNTIME_PROTOCOLS_CORE.md` | Draft agents use this source. |
 | Pre/Post execution gates | `tera-system/TeraPreExecutionGate.md` | `.opencode/agents/tera.md`, `TERA_RUNTIME_PROTOCOLS_CORE.md` | Gate details stay in the policy file. |
@@ -61,8 +61,7 @@ Project files record project-specific decisions.
 | Runtime checklists | `tera-system/runtime/TERA_RUNTIME_CHECKLISTS.md` | `.opencode/agents/tera.md` | Checklists stay outside runtime. |
 | MVP classification | `tera-system/runtime/MVP_DEFINITION_PROTOCOL.md` | `.opencode/agents/tera.md` | Runtime references when to load it. |
 | Technology profiles | `tera-system/profiles/` | `.opencode/agents/tera.md` | Stack-specific rules stay in profiles. |
-| Design governance layer | `tera-system/design-system/` | `.opencode/agents/tera.md`, `TERA_RUNTIME_CHECKLISTS.md`, `TERA_RUNTIME_PROTOCOLS_CORE.md` | Governs Design Source Decision, DESIGN.md integration, internal kits, design tokens, component rules, and UI Acceptance Gate. DesignReviewer (ناقد) = Tera-managed review sub-agent (SCP-2026-08-28-001) with three shields (neutrality / direct escalation / dual invocation). |
-| Prototype mandate | `tera-system/TeraClientPolicy.md` (Prototype Mandate — SCP-2026-08-28-001) | `TERA_RUNTIME_TEMPLATES.md` (08_PROTOTYPE_PLAN.md), `TERA_RUNTIME_PROTOCOLS_CLIENT.md`, `TeraPreExecutionGate.md` (#23) | Gate 6 mandatory for all applications; waiver = documented `WAIVED_BY_MAJED` only. Builder: Coding Agents under Tera (TASK-PROTO-*); reviewer: DesignReviewer (ناقد); evidence: formal Prototype Approval Letter. |
+| Design governance layer | `tera-system/design-system/` | `.opencode/agents/tera.md`, `TERA_RUNTIME_CHECKLISTS.md`, `TERA_RUNTIME_PROTOCOLS_CORE.md` | Governs Design Source Decision, DESIGN.md integration, internal kits, design tokens, component rules, and UI Acceptance Gate. |
 | Monitor audit framework | `.opencode/agents/monitor.md` | `ENGINEERING_AGENT_RESPONSIBILITIES.md` | Governs the 7 immutable audit rules, reference hierarchy, plan rejection authority, and cumulative audit for plan-compliance checking. |
 | Auditor audit framework | `.opencode/agents/auditor.md` | `ENGINEERING_AGENT_RESPONSIBILITIES.md` | Governs Auditor as a Tera-managed quality gate sub-agent, including diff-first scope, evidence model, QUAUD reporting, and authorized invocation by Tera/Monitor. |
 | Quality gate thresholds | `tera-system/engineering-governance/QUALITY_GATE_THRESHOLDS.md` | `.opencode/agents/auditor.md`, `.opencode/agents/tera.md` | Compact reference for Auditor rule classes, evidence requirements, P1/P2 checks, and default heuristics. |
@@ -105,8 +104,9 @@ Project files record project-specific decisions.
 | Business Transformation Consultant (BTCA) | `.opencode/agents/tera-business-transformation-consultant.md` | `tera-system/consulting-helpers/BTCA_METHODOLOGY_FRAMEWORK.md`, `BTCA_REPORT_TEMPLATES.md` | عميل مستقل للاستشارات الإدارية والتنظيمية غير البرمجية — Track C. SCP-2026-07-29-002. |
 | BTCA — Methodology Framework | `tera-system/consulting-helpers/BTCA_METHODOLOGY_FRAMEWORK.md` | `.opencode/agents/tera-business-transformation-consultant.md` | إطار المنهجية: تصنيف الأدلة الخماسي، مراحل العمل، دليل المقابلات، هيكل التقرير النهائي. |
 | BTCA — Report Templates | `tera-system/consulting-helpers/BTCA_REPORT_TEMPLATES.md` | `.opencode/agents/tera-business-transformation-consultant.md` | قوالب التقارير العشرة الأساسية + التقرير التنفيذي. |
-| Tera distribution (versioned) | `tera-system/TERA_DISTRIBUTION_POLICY.md` | `.tera/lock.json` في مستودعات العملاء | توزيع Tera المُروّس على مستودعات العملاء: استمداد من المستودع الأصلي (`tera-fetch.ps1` + RepositoryUrl)، إصدارات (Tag+SHA)، عقد ملكية، أدوات `tools/`. SCP-2026-08-15-009. |
-| Tera product standards — Maintenance | `tera-system/product-standards/maintenance-apps/STANDARD_DEFINITION.md` + `BEST_PRACTICES_DOMAIN.md` | Not applicable | Active reusable product standards for Maintenance/FSM/WOM; content remains in the standards files. |
+| Tera distribution (versioned) | `tera-system/TERA_DISTRIBUTION_POLICY.md` | `.tera/lock.json` في مستودعات العملاء | توزيع Tera المُروّس على مستودعات العملاء: استمداد من المستودع الأصلي (`tera-fetch.ps1` + RepositoryUrl)، إصدارات (Tag+SHA)، عقد ملكية، أدوات `tera-workshop/tools/`. SCP-2026-08-15-009. |
+| Source code ownership & pricing | `tera-system/TeraPricingPolicy.md` (§31) + `tera-system/TeraClientPolicy.md` (§9.5) | `tera-workshop/client-templates/contractual/SOURCE_CODE_PURCHASE_ADDENDUM_TEMPLATE.md`، `SOFTWARE_SERVICES_AGREEMENT` §12 | ملكية السورس افتراضياً لـ Tera (لا يُسلَّم للزبون) + خيارا L1 (40%) / L2 (max(3×، 1,000 JOD)) عبر ملحق تعاقدي + L3 (إعادة بيع) مرفوض افتراضياً. SCP-2026-08-29-004. |
+| Client letter numbering | `tera-system/TeraClientPolicy.md` (§9.6) + `project-control/CLIENT_CODES.md` | `client-approval/LETTER_LOG.md` في مستودع العميل | ترميز موحد `{كود-العميل}-{النوع}-{السنة}-{التسلسل}` — كود العميل يخصّصه Majed فقط (سجل مركزي) — الأنواع LET/CON/ADD/PAL/DOC/TPL (قابلة للزيادة). SCP-2026-08-29-005. |
 
 ## 4. Duplication Policy
 

package/core/tera-system/TeraPricingPolicy.md

@@ -690,3 +690,45 @@ max(Final Scorecard Price, 100 JOD, Minimum Profitable Price)
 | 6 | الحد الأعلى للتخفيض الخاص | 15% |
 | 7 | إعادة مراجعة Anchor Points | بعد اختبار 3 - 5 مشاريع فعلية |
 | 8 | الحد الأدنى لتقدير الساعات (Minimum Hours for Direct Pricing) | 40 ساعة |
+| 9 | نسبة سعر السورس L1 (Source Access) | 40% من سعر المشروع |
+| 10 | مضاعف سعر السورس L2 (ملكية كاملة للاستخدام الداخلي) | 3× سعر المشروع — بحد أدنى 1,000 JOD |
+
+---
+
+## 31. ملكية السورس كود والتسليم (SCP-2026-08-29-004)
+
+> **المصدر الحاكم:** هذا القسم + `TeraClientPolicy.md` + عقد `SOFTWARE_SERVICES_AGREEMENT` §12 — مصدر الحقيقة الوحيد لموضوع ملكية السورس.
+
+### 31.1 المبدأ الحاكم
+
+```text
+السورس كود التطبيقات حق ملكية لمنظومة Tera — ولا يُسلَّم للزبون افتراضياً أبداً.
+التسعير والوثائق والعقود والتسليم لا تفترض أن السورس كود للزبون نهائياً.
+```
+
+### 31.2 المخرجات الافتراضية (ما يُسلَّم في السعر الأساسي)
+
+| يُسلَّم | لا يُسلَّم |
+|---|---|
+| التطبيق قيد التشغيل (استضافة Tera أو خادم العميل) | السورس كود بأي شكل (مستودع، ملفات، نسخ، أرشيف) |
+| النشر والإعداد والتوثيق ودليل الاستخدام | مكونات Tera المشتركة (teranoo-ui، أنماط الهندسة، القوالب) |
+| التدريب | بيانات/إعدادات داخلية خاصة بـ Tera |
+| الضمان والصيانة (§22) | |
+
+### 31.3 خيارات شراء السورس — تُقدَّم عند طلب الزبون فقط
+
+| المستوى | الحقوق الممنوحة | الممنوعات | السعر |
+|:---:|---|---|---|
+| **L0 — الافتراضي** | ترخيص استخدام تشغيلي للتطبيق ضمن أعمال العميل | السورس بأي شكل | ضمن سعر المشروع |
+| **L1 — Source Access** | وصول السورس لصيانة/تعديل فريق العميل أو مورد معتمد | إعادة بيع، ترخيص للغير، استخدام في منتج آخر، نشر عام للمستودع | **40% من سعر المشروع** |
+| **L2 — ملكية كاملة (استخدام داخلي)** | كل L1 + تعديل وإعادة استخدام داخل أعمال العميل وفروعه | إعادة بيع/ترخيص التطبيق كمنتج للغير | **max(3× سعر المشروع، 1,000 JOD)** |
+| **L3 — إعادة البيع/الترخيص التجاري** | — | — | **ليست بند سعر:** رفض افتراضي + اتفاقية ترخيص/امتياز منفصلة بموافقة Majed الخاصة فقط |
+
+### 31.4 قواعد تشغيلية إلزامية
+
+1. **سؤال توقع السورس إلزامي في Domain 13 قبل أي تسعير** (راجع بنك الأسئلة + discovery-domains.md) — لا يُسعَّر مشروع قبل معرفة توقع الزبون.
+2. **العرض الرسمي للزبون:** يُعلن "السورس كود غير مشمول — خيارات متاحة بطلب منفصل" **دون أسعار مفتوحة**. الأسعار الداخلية (الجدول أعلاه) تظهر في DRAFT فقط وقرار عرضها لـ Majed.
+3. **أي تسليم سورس (L1/L2) يمر عبر «ملحق شراء السورس»** المعتمد — يحدد المستوى والحقوق والممنوعات، ويتم نقل الوصول/الملكية **بعد سداد 100% من مقابل الملحق**.
+4. **إعادة البيع ممنوعة دائماً** في L1 وL2. L3 لا يُعرض ولا يُناقش تسويقياً.
+5. مكونات Tera المشتركة تبقى ملك Tera في كل الأحوال ولا تشملها أي ملكية تُمنح.
+6. عند توقع الزبون للسورس: يُرفع الخيار لـ Majed مع التوصية قبل إدراجه في الاقتباس — لا يُسعَّر السورس تلقائياً.

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

@@ -27,7 +27,7 @@ description: Canonical source for the 13 mandatory TCEA discovery domains — si
 | 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 | نعم | نعم |
+| 13 | Acceptance, Commercials & Warranty | Acceptance, Commercials & Warranty | Acceptance criteria, budget, payment plan, warranty, support terms + **توقع السورس كود (نعم/لا/غير متأكد) والغرض** — راجع TeraPricingPolicy §31 | نعم | نعم |
 
 ---
 
@@ -41,6 +41,7 @@ description: Canonical source for the 13 mandatory TCEA discovery domains — si
 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.
 8. **Non-Functional Depth Rule (SCP-2026-08-29-001):** بنود العمق غير الوظيفي — تفضيلات الزبون في التصميم والمحتوى والشاشات والتقنية (مراجع بصرية، ألوان/نبرة، شكل العرض الرئيسي، حقول الشاشات، منطقة الاستضافة) — إلزامية التغطية قبل إعلان `Complete` للمجالات 6/9/10 (و4 حسب Content Type Rule أعلاه)، بعمق متناسب مع حجم المشروع (نفس مبدأ A.4). إذا لم يجب الزبون أو لم تتوفر المعلومة → `Partial` + `UNCERTAINTY_NOTICE` — لا يجوز `Complete`. الأسئلة المرجعية في `TeraApplicationQuestionBank.md` (Q5.2/Q5.3/Q5.7/Q5.15/Q4.12/Q7.1 وغيرها).
+9. **Source Ownership Rule (SCP-2026-08-29-004):** توقع السورس كود يُسأل في Domain 13 قبل أي تسعير. **الافتراضي: السورس ملك Tera ولا يُسلَّم.** عند توقع الزبون للسورس → يُعرض خيارا L1/L2 (TeraPricingPolicy §31) كبند منفصل بقرار Majed — وإعادة البيع/الترخيص للغير مرفوضة افتراضياً (L3 = اتفاقية منفصلة بموافقة Majed الخاصة).
 
 ---
 

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

@@ -133,6 +133,18 @@ description: TCEA pricing workflow, tools, reference sources, and client documen
 | دليل التدريب | `project-control/TRAINING_GUIDE_TCEA.md` | مرجع تدريب فقط — لا يُقرأ افتراضياً. يُستدعى فقط عند تحذير Proportion Check |
 | مثال تطبيقي | (يُنشأ عند أول عميل فعلي — أُزيل مثال العملاء التجريبيين 2026-08-15) | عند الحاجة يُنشأ مثال Scorecard تطبيقي جديد |
 
+### A.8.6 ملكية السورس كود (SCP-2026-08-29-004)
+
+| البند | القاعدة |
+|-------|--------|
+| **الافتراضي** | السورس ملك Tera — لا يُسلَّم للزبون. العرض يعلن "غير مشمول" دون أسعار مفتوحة. |
+| **L1 — Source Access** | وصول للصيانة الداخلية = **40% من سعر المشروع** |
+| **L2 — ملكية كاملة (داخلي)** | **max(3× سعر المشروع، 1,000 JOD)** |
+| **L3 — إعادة بيع** | مرفوض افتراضياً — اتفاقية منفصلة بموافقة Majed الخاصة |
+| **قبل التسعير** | سؤال توقع السورس في Domain 13 إلزامي (بنك الأسئلة QS.1–QS.4) |
+| **التسليم** | عبر «ملحق شراء السورس» — بعد سداد 100% — إعادة البيع ممنوعة دائماً |
+| **المرجع** | `TeraPricingPolicy.md` §31 + `TeraClientPolicy.md` §9.5 |
+
 ---
 
 ## C.1 الملفات التي تديرها

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

@@ -1,8 +1,8 @@
 # Tera Runtime Templates — Delivery & Execution
 
-These are the execution, delivery, closure, and operational-hardening templates (Sections 29–38) split from TERA_RUNTIME_TEMPLATES.md via INSPECTION-2026-08-01 (INS-02).
+These are the execution, delivery, and closure templates (Sections 29–34) split from TERA_RUNTIME_TEMPLATES.md via INSPECTION-2026-08-01 (INS-02).
 Main file: `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md` (Sections 1–28).
-Preparation-phase templates: `tera-system/runtime/TERA_RUNTIME_TEMPLATES_PREPARATION.md` (Sections 35–41).
+Preparation-phase templates: `tera-system/runtime/TERA_RUNTIME_TEMPLATES_PREPARATION.md` (Sections 35–40).
 
 ---
 
@@ -493,8 +493,11 @@ clients/CLIENT-[client-name-or-id]/applications/APP-[app-name-or-id]/delivery/CL
 
 ## 2. ما تم تسليمه
 
+- التطبيق قيد التشغيل (رابط/بيئة النشر) + التوثيق + التدريب (حسب النطاق)
 - ...
 
+> **غير مُسلَّم (ملك Tera — SCP-2026-08-29-004):** السورس كود بأي شكل، إلا بموجب ملحق شراء سورس معتمد (L1/L2 — TeraPricingPolicy §31). إعادة البيع/الترخيص للغير ممنوعة دائماً.
+
 ## 3. طريقة التشغيل / الوصول
 
 - لا تكتب أسرارًا أو كلمات مرور.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tera-system/core",
-  "version": "0.2.4",
-  "description": "Tera System OpenCode Plugin — governance core, 20 agents, 11 commands, distribution tools (personal edition)",
+  "version": "0.2.6",
+  "description": "Tera System OpenCode Plugin أ¢â‚¬â€‌ governance core, 20 agents, 11 commands, distribution tools (personal edition)",
   "license": "SEE LICENSE IN LICENSE.md",
   "type": "module",
   "engines": {
@@ -40,3 +40,4 @@
     "access": "public"
   }
 }
+