@tera-system/core 0.2.3 → 0.2.5

package/core/tera-system/AGENT_DEPENDENCY_MAP.md

@@ -14,14 +14,14 @@
 
 | Agent | يتم استدعاؤه بواسطة | يستدعي/يشير إلى | يقرأ من |
 |-------|-------------------|----------------|---------|
-| **tera.md** | — (Engineering Delivery Lead — phases 5–7 — SCP-118) | `ui-designer.md`, `engineering-agent.md`, `engineering-agent-typescript.md`, `engineering-agent-phaser.md`, `engineering-agent-dotnet.md`, `tera-software-designer.md`, `auditor.md`, `design-reviewer.md` (Tera-managed — SCP-2026-08-28-001) | `tera-system/runtime/TERA_RUNTIME_*.md`, `project-control/`, `ENGINEERING_HANDOFF_PACKAGE.md` |
+| **tera.md** | — (Engineering Delivery Lead — phases 5–7 — SCP-118) | `ui-designer.md`, `engineering-agent.md`, `engineering-agent-typescript.md`, `engineering-agent-phaser.md`, `engineering-agent-dotnet.md`, `tera-software-designer.md`, `auditor.md` | `tera-system/runtime/TERA_RUNTIME_*.md`, `project-control/`, `ENGINEERING_HANDOFF_PACKAGE.md` |
 | **ui-designer.md** | `tera.md`, `tera-system-evolution.md` (للأغراض النظامية) | `design-reviewer.md` (ناقد يراجعه)، `engineering-agent-typescript.md` (يسلّم له UI Spec) | `28_UI_UX_GUIDELINES.md`, `tera-system/design-system/*.md` |
 | **engineering-agent.md** | `tera.md` | `ui-designer.md` (مصمم يسبقه)، `tera-software-designer.md` (يسبقه للمهام المعقدة) | `TECHNICAL_SPECIFICATION.md`, `28_UI_UX_GUIDELINES.md` |
 | **engineering-agent-typescript.md** 🆕 | `tera.md` | `ui-designer.md` (يستلم منه UI Spec)، `engineering-agent-phaser.md` (يملك integration bridge معه) | `engineering-agent-core.md`, Active Technology Profile, `28_UI_UX_GUIDELINES.md` |
 | **engineering-agent-phaser.md** 🆕 | `tera.md` | `engineering-agent-typescript.md` (يملك bridge معه عبر Tera) | `engineering-agent-core.md`, Active Technology Profile, game design documents |
 | **engineering-agent-dotnet.md** | `tera.md` | — | `engineering-agent-core.md`, Active .NET Technology Profile |
 | **tera-software-designer.md** | `tera.md` | `engineering-agent.md` (ينفذ الـ Spec) | `project-preparation/*.md`, `28_UI_UX_GUIDELINES.md`, `PROJECT_RULES.md` |
-| **design-reviewer.md** | `tera.md` (Tera-managed — SCP-2026-08-28-001)؛ `tera-system-evolution.md` (للأغراض النظامية)؛ Majed مباشرة في أي وقت (درع الاستدعاء) | يراجع مخرجات `tera.md` (بروتوتايب TASK-PROTO-* وواجهات منفذة) — حكم مستقل + تصعيد مباشر لـ Majed (الدروع الثلاثة) | `28_UI_UX_GUIDELINES.md`, `tera-system/design-system/DESIGN_REVIEW_STANDARDS.md` |
+| **design-reviewer.md** | — (مستقل — يستدعيه Majed) | `TeraAgent`, `EngineeringAgent` (مراجعة مخرجاتهم) | `28_UI_UX_GUIDELINES.md`, `tera-system/design-system/DESIGN_REVIEW_STANDARDS.md` |
 | **tera-client-engagement.md** | — (مستقل — يستدعيه Majed) | `domain-research-agent.md`, `domain-expert-agent.md`, `production-erp-expert.md`, `application-blueprint.md` | `tera-system/client-helpers/*.md`, `tera-system/TeraPricingPolicy.md` |
 | **application-blueprint.md** | `tera-client-engagement.md` (handoff); — (Solution Preparation Authority — phases 1–4 — SCP-118) | `domain-research-agent.md`, `domain-expert-agent.md`, `production-erp-expert.md`, preparation agents, `qa-agent.md` (Planning Mode), `ui-designer.md` (Preparation Design Mode) | `tera-system/runtime/TERA_SOLUTION_PREPARATION_*.md`, `project-preparation/`, `client-engagement/` |
 | **domain-research-agent.md** | `tera-client-engagement.md`, `tera.md`, `application-blueprint.md`, `tera-system-evolution.md` | `domain-expert-agent.md` (يسلم له للتحليل) | — (بحث خارجي) |
@@ -31,8 +31,7 @@
 | **tera-strategic-advisor.md** | — (مستقل — يستدعيه Majed فقط) | لا يستدعي عملاء ولا يديرهم؛ قد يوصي Majed بالرجوع إلى TeraAgent أو حارس أو غيرهم | ملفات وسياقات القرار فقط، مصادر خارجية عند الحاجة |
 | **auditor.md** | `tera.md`؛ و`monitor.md` فقط عند طلب Majed | يراجع مخرجات `tera.md`, `engineering-agent.md`؛ يحيل findings إلى `SecurityAgent`, `DesignReviewer`, `QAAndAcceptanceAgent`, أو `ProjectControlAgent` عبر الوكيل المستدعي | `project-control/*.md`, `project-control/audit-reports/`, `tera-system/engineering-governance/*.md`, الملفات المعدلة |
 | **monitor.md** | — (مستقل — يستدعيه Majed) | يراجع مخرجات `tera.md`, `engineering-agent.md`; قد يستدعي `auditor.md` فقط عندما يطلب Majed تحدي/تحقق جودة مستقل | `project-control/*.md`, `tera-system/*.md` |
-| **qa-agent.md** (الاسم المنطقي: QAAndAcceptanceAgent) | `tera.md` (يُفعّله Tera) | لا يستدعي عملاء آخرين | ملفات التحضير، ملفات المهمة، logs، مخرجات CLI، `project-control/test-reports/` |
-| **project-knowledge-agent.md** | `tera.md` (بعد قبول المهمة وعند تأثر شاشة/وحدة/خدمة) | لا يستدعي عملاء آخرين؛ غرضه تحديث المعرفة التشغيلية المقبولة | `tera-system/runtime/TERA_RUNTIME_PROTOCOLS.md` §19، حزمة المعرفة، الملفات المحددة؛ يكتب فقط `clients/**/applications/*/project-knowledge/**/*.md` |
+| **qa-agent.md** (الاسم المنطقي: QAAndAcceptanceAgent) | `tera.md` (يُفعّله Tera) | لا يستدعي عملاء آخرين | ملفات التحضير، ملفات المهمة، logs، مخرجات CLI، `project-control/test-reports/` |
 | **tera-business-transformation-consultant.md** | — (مستقل — يُستدعى من TCEA عبر Majed عند Track C) | `domain-research-agent.md`, `domain-expert-agent.md` (للبحث عن معايير الصناعة وأفضل الممارسات) | `tera-system/consulting-helpers/BTCA_METHODOLOGY_FRAMEWORK.md`, `BTCA_REPORT_TEMPLATES.md` |
 
 ---
@@ -69,40 +68,38 @@ ui-designer.md
 
 | الملف | الحجم (سطور) | الحالة / ملاحظات |
 |-------|-------------|-----------------|
-| `tera.md` | 538 | 🟢 < 700 — +18 (SCP-2026-08-28-001: Prototype First-Task + Intake check) |
-| `tera-system/TeraSubAgents.md` | 904 | 🟡 700–1000 — +49 (SCP-2026-08-28-001: تسجيل ناقد §5.7.2) — يحتاج دراسة تقسيم قريبة |
+| `tera.md` | 520 | 🟢 < 700 — +4 (SCP-2026-08-16-003: READY FOR OWNER ACCEPTANCE §12) |
+| `tera-system/TeraSubAgents.md` | 855 | 🟡 700–1000 — يحتاج دراسة تقسيم قريبة |
 | `tera-system/TeraHelperAgents.md` | 970 | 🟡 700–1000 — يحتاج دراسة تقسيم قريبة |
-| `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md` | 912 | 🟡 700–1000 — +4 (SCP-2026-08-28-001: قوالب البروتوتايب) — تقسيم مكتمل سابقاً (INS-02) |
-| `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` | 584 | 🟢 < 700 — §§29–38 بعد إضافة إرشادات Logging/Performance/Backup |
-| `tera-system/runtime/TERA_RUNTIME_TEMPLATES_PREPARATION.md` | 376 | 🟢 < 700 — §§35–41 بعد إضافة Content Requirements |
+| `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md` | 908 | 🟡 700–1000 — +5 (SCP-2026-08-16-001: ملاحظة تفويض المدققين §2) — تقسيم مكتمل سابقاً (INS-02) |
+| `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` | 514 | 🟢 < 700 — +9 (SCP-2026-08-16-003: §32 Owner Approval fields + §33 items 10–11) |
+| `tera-system/runtime/TERA_RUNTIME_TEMPLATES_PREPARATION.md` | 344 | 🟢 < 700 — جديد INS-02 (§35–40) |
 | `tera-system/runtime/TERA_RUNTIME_PROTOCOLS.md` | 50 | 🟢 < 700 — §19 فقط (Knowledge Management) بعد تقسيم INS-02 continuation |
 | `tera-system/runtime/TERA_RUNTIME_PROTOCOLS_CORE.md` | 799 | 🟡 700–1000 — +31 (SCP-2026-08-16-003: Owner Approval Gate + Cross-Record Consistency §4) — قريب من الحد — مراقبة |
-| `tera-system/runtime/TERA_RUNTIME_PROTOCOLS_CLIENT.md` | 355 | 🟢 < 700 — +1 (SCP-2026-08-28-001: Gate 6 إلزامية + شروط خروج) |
+| `tera-system/runtime/TERA_RUNTIME_PROTOCOLS_CLIENT.md` | 356 | 🟢 < 700 — جديد INS-02 (§12–18) |
 | `tera-system/runtime/TERA_RUNTIME_CHECKLISTS.md` | 646 | 🟢 < 700 — +1 (SCP-2026-08-16-003: Phase 6 بند 8) |
-| `tera-system/TeraPreExecutionGate.md` | 819 | 🟡 700–1000 — +1 (SCP-2026-08-28-001: بند #23 اعتماد البروتوتايب) |
-| `tera-client-engagement.md` | 891 | 🟡 700–1000 — توسعة Dual-Track عبر SCP-2026-07-29-001 |
+| `tera-system/TeraPreExecutionGate.md` | 818 | 🟡 700–1000 — +18 (SCP-2026-08-16-003: Owner Approval Gate + Checklist 33–35) |
+| `tera-client-engagement.md` | 892 | 🟡 700–1000 — توسعة Dual-Track عبر SCP-2026-07-29-001 + سطر Non-Functional Depth A.4 (SCP-2026-08-29-001) |
 | `auditor.md` | 665 | 🟢 < 700 — +22 (SCP-2026-08-16-001: Independent Scope Discovery §6.1) |
 | `qa-agent.md` | 498 | 🟢 < 700 — +23 (SCP-2026-08-16-001: Independent Discovery §3.1 + NOT VERIFIED) |
-| `tera-system-evolution.md` | 759 | 🟡 700–1000 — قريب من الحد — يحتاج مراقبة |
-| `.opencode/agents/project-knowledge-agent.md` | 271 | 🟢 < 700 — Project Knowledge post-acceptance agent |
+| `tera-system-evolution.md` | 754 | 🟡 700–1000 — قريب من الحد — يحتاج مراقبة |
 | `tera-strategic-advisor.md` | 325 | 🟢 < 700 |
 | `engineering-agent-typescript.md` | 300 | 🟢 < 700 |
 | `engineering-agent-phaser.md` | 275 | 🟢 < 700 |
 | `monitor.md` | 395 | 🟢 < 700 — +117 (SCP-2026-08-16-004: تصنيف + Lifecycle + Quick/Full + Snapshot + قوالب) — يقرأ/يكتب `MONITOR_STATE.md` |
-| `application-blueprint.md` | 409 | 🟢 < 700 — +2 (SCP-2026-08-28-001: شرط Prototype في §9 + §10) |
-| `design-reviewer.md` | 387 | 🟢 < 700 — SCP-2026-08-28-001: Tera-managed review sub-agent + Prototype Review Protocol |
+| `application-blueprint.md` | 407 | 🟢 < 700 — SCP-118 compact redesign + SCP-2026-08-15-016 (شرط Content في §9) |
 | `tera-system/engineering-helpers/engineering-agent-core.md` | 171 | 🟢 — ملف مشارك |
 | `tera-system/client-helpers/tera-client-engagement-protocols.md` | 692 | 🟢 < 700 — +3 بروتوكولات Track B |
 | `tera-system/client-helpers/tera-client-engagement-pricing.md` | 341 | 🟢 < 700 — +Product Pricing Models |
 | `tera-system/client-helpers/tera-client-engagement-gates.md` | 258 | 🟢 < 700 — +6 بوابات Track B + B.7c Final Consistency (SCP-014) |
-| `tera-system/client-helpers/tera-client-engagement-discovery-domains.md` | 99 | 🟢 < 700 — +Existing App + Track B |
-| `tera-system/runtime/TERA_SOLUTION_PREPARATION_PROTOCOL.md` | 335 | 🟢 < 700 — ملف SCP-118 |
+| `tera-system/client-helpers/tera-client-engagement-discovery-domains.md` | 100 | 🟢 < 700 — +Existing App + Track B + Non-Functional Depth Rule #8 (SCP-2026-08-29-001) |
+| `tera-system/runtime/TERA_SOLUTION_PREPARATION_PROTOCOL.md` | 279 | 🟢 < 700 — ملف SCP-118 |
 | `tera-system/runtime/TERA_SOLUTION_PREPARATION_TEMPLATES.md` | 397 | 🟢 < 700 — ملف SCP-118 |
 | `.opencode/agents/tera-business-transformation-consultant.md` | 290 | 🟢 < 700 — عميل SCP-2026-07-29-002 |
 | `tera-system/consulting-helpers/BTCA_METHODOLOGY_FRAMEWORK.md` | 195 | 🟢 < 700 — منهجية الأدلة ومراحل العمل |
 | `tera-system/consulting-helpers/BTCA_REPORT_TEMPLATES.md` | 266 | 🟢 < 700 — قوالب التقارير العشرة |
 
-**ملاحظة (تحديث 2026-08-28 — SCP-2026-08-28-003):** تمت مزامنة الأحجام مع القياس الحالي. الملفات 🔴 (>1000) تحتاج تقسيمًا إلزاميًا؛ الملفات 🟡 (700–1000) قيد المراقبة.
+**ملاحظة (تحديث 2026-08-01 — INS-01):** تمت إعادة حساب جميع الأحجام الفعلية وتصحيح الجدول. الملفات 🔴 (>1000) تحتاج خطط تقسيم (انظر INS-02). الملفات 🟡 (700–1000) قيد المراقبة.
 
 ---
 
@@ -112,9 +109,9 @@ ui-designer.md
 
 | الملف | الحجم | خطة التقسيم المقترحة | الحالة |
 |-------|-------|---------------------|--------|
-| `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md` | 912 | **✅ تم التقسيم:** §29–38 → `TERA_RUNTIME_TEMPLATES_DELIVERY.md` (584)، §35–41 → `TERA_RUNTIME_TEMPLATES_PREPARATION.md` (376) | ✅ **مكتمل** |
-| `tera-system/runtime/TERA_RUNTIME_PROTOCOLS.md` | 50 | **✅ تم التقسيم:** §1–11 → `TERA_RUNTIME_PROTOCOLS_CORE.md` (799)، §12–18 → `TERA_RUNTIME_PROTOCOLS_CLIENT.md` (355)، الرئيسي يحتفظ بـ §19 | ✅ **مكتمل** |
-| `tera-system/Tera_Project_Preparation_Files.md` | 464 | **✅ تم التقسيم:** المحتوى الأساسي بقي هنا، والتفاصيل المشروطة/الثانوية انتقلت إلى `tera-system/agent-helpers/Tera_Project_Preparation_Files_Conditional.md` (597) | ✅ **مكتمل** |
+| `tera-system/runtime/TERA_RUNTIME_TEMPLATES.md` | 903 | **✅ تم التقسيم (2026-08-01):** §29–34 → `TERA_RUNTIME_TEMPLATES_DELIVERY.md` (505)، §35–40 → `TERA_RUNTIME_TEMPLATES_PREPARATION.md` (344) | ✅ **مكتمل** |
+| `tera-system/runtime/TERA_RUNTIME_PROTOCOLS.md` | 50 | **✅ تم التقسيم (2026-08-01):** §1–11 → `TERA_RUNTIME_PROTOCOLS_CORE.md` (758)، §12–18 → `TERA_RUNTIME_PROTOCOLS_CLIENT.md` (356)، الرئيسي يحتفظ بـ §19 | ✅ **مكتمل** |
+| `tera-system/Tera_Project_Preparation_Files.md` | 1,015 | **قرار (2026-08-01):** لا تقسيم — هو "Guide" مرجعي متماسك (26 قالباً مدمجاً). يُوثَّق في الخرائط كـ Guide وليس Catalog. | 🟡 **لا يُقسَّم — توثيق فقط** |
 
-**القاعدة:** أي تقسيم فعلي يُنفَّذ عبر SCP منفصل بعد موافقة Majed.
-**الحالة:** تقسيم TERA_RUNTIME_TEMPLATES وTERA_RUNTIME_PROTOCOLS ودليل Preparation Files مكتمل بعد SCP-2026-08-28-003.
+**القاعدة:** أي تقسيم فعلي يُنفَّذ عبر SCP منفصل بعد موافقة Majed — لا يُقسَّم هنا تلقائياً.
+**الأولوية:** TERA_RUNTIME_TEMPLATES ✅ مكتمل — التالي: PROTOCOLS، ثم Preparation_Files.

package/core/tera-system/TERA_DISTRIBUTION_POLICY.md

@@ -113,22 +113,22 @@ Release Package (ملفات Tera-managed + SHA256SUMS + TERA_RELEASE_MANIFEST.js
 
 | الأداة | المسار | الوظيفة |
 |---|---|---|
-| `tera-fetch.ps1` | `tera-workshop/tools/` | جلب الإصدارات من المستودع الأصلي (List) + بناء حزمة متحققة (Fetch) |
-| `tera-update.ps1` | `tera-workshop/tools/` | تحديث مستودع عميل **واحد** — وضعا Plan و Apply |
-| `update-client-repositories.ps1` | `tera-workshop/tools/` | تحديث **دفعات** من المستودعات — وضعا Plan و Apply |
-| `tera-release.ps1` | `tera-workshop/tools/` | بناء حزمة إصدار متحقق منها من Tag + Manifest + SHA256SUMS |
+| `tera-fetch.ps1` | `tools/` | جلب الإصدارات من المستودع الأصلي (List) + بناء حزمة متحققة (Fetch) |
+| `tera-update.ps1` | `tools/` | تحديث مستودع عميل **واحد** — وضعا Plan و Apply |
+| `update-client-repositories.ps1` | `tools/` | تحديث **دفعات** من المستودعات — وضعا Plan و Apply |
+| `tera-release.ps1` | `tools/` | بناء حزمة إصدار متحقق منها من Tag + Manifest + SHA256SUMS |
 
 ### 4.1 tera-fetch.ps1 — الجلب من المستودع الأصلي
 
 ```powershell
 # عرض الإصدارات المتاحة في المستودع الأصلي
-pwsh .\tera-workshop\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -List
+pwsh .\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -List
 
 # فحص: هل يوجد إصدار أحدث من المثبت حالياً؟ (قراءة فقط — لا يعدّل شيئاً)
-pwsh .\tera-workshop\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -Check -RepoPath "D:\My Projects\TeraWebsite"
+pwsh .\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -Check -RepoPath "D:\My Projects\TeraWebsite"
 
 # بناء حزمة إصدار موثقة من المستودع الأصلي
-pwsh .\tera-workshop\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -Version tera-v2.5.0 -Channel stable -OutPath "C:\TeraReleases\tera-v2.5.0"
+pwsh .\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -Version tera-v2.5.0 -Channel stable -OutPath "C:\TeraReleases\tera-v2.5.0"
 ```
 
 **وضع Check:** يقارن الإصدار المثبت في `lock.json` بأحدث إصدار في الأصل، ويخبرك بما يلي:
@@ -144,47 +144,47 @@ pwsh .\tera-workshop\tools\tera-fetch.ps1 -RepositoryUrl "https://github.com/Ala
 
 ```powershell
 # تسجيل مهمة Windows Task Scheduler (عند تسجيل الدخول + كل 6 ساعات)
-pwsh .\tera-workshop\tools\tera-schedule.ps1 `
+pwsh .\tools\tera-schedule.ps1 `
   -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem.git" `
   -RepoPath "D:\My Projects\TeraWebsite"
 
 # إزالة المهمة
-pwsh .\tera-workshop\tools\tera-schedule.ps1 -Unregister
+pwsh .\tools\tera-schedule.ps1 -Unregister
 ```
 
 السلوك:
 - عند وجود إصدار أحدث → **Windows Toast** أصلي يظهر على سطح المكتب + ملف `.tera/update-status.json` يُحدَّث.
 - ملف الحالة قابل للقراءة من أي جلسة (بما فيها OpenCode) لمعرفة `updateAvailable`.
-- تشغيل يدوي لمرة واحدة: `pwsh .\tera-workshop\tools\tera-watch.ps1 -RepositoryUrl "..." -RepoPath "..." -Once`
+- تشغيل يدوي لمرة واحدة: `pwsh .\tools\tera-watch.ps1 -RepositoryUrl "..." -RepoPath "..." -Once`
 - رموز الخروج: 0 = محدّث، 2 = يوجد تحديث، 1 = خطأ.
 
 ### 4.2 tera-update.ps1 — أوامر
 
 ```powershell
 # فحص جاف من حزمة محلية
-pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0"
+pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0"
 
 # فحص جاف مباشرة من المستودع الأصلي (استمداد حي)
-pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
+pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
 
 # التنفيذ الفعلي من المستودع الأصلي
-pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
+pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
 ```
 
 ### 4.3 tera-release.ps1 — بناء الإصدار
 
 ```powershell
-pwsh .\tera-workshop\tools\tera-release.ps1 -Version 2.5.0 -Tag tera-v2.5.0 -Channel stable -OutputPath "C:\TeraReleases\tera-v2.5.0"
+pwsh .\tools\tera-release.ps1 -Version 2.5.0 -Tag tera-v2.5.0 -Channel stable -OutputPath "C:\TeraReleases\tera-v2.5.0"
 ```
 
 ينشئ الأمر حزمة مجلدية متحققة تحتوي على `TERA_RELEASE_MANIFEST.json` و`SHA256SUMS` من محتوى الـ Tag نفسه (لا من working tree). يرفض تعارض Version/Tag.
 
 مسارات إضافية:
 ```powershell
-pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepoPath "C:\clients\CLIENT-X\APP-Y" -SourcePath "C:\TeraReleases\tera-v2.5.0"
+pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepoPath "C:\clients\CLIENT-X\APP-Y" -SourcePath "C:\TeraReleases\tera-v2.5.0"
 
 # التثبيت الأول يحتاج تصريحاً صريحاً
-pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -Initialize -SourcePath "C:\TeraReleases\tera-v2.5.0"
+pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -Initialize -SourcePath "C:\TeraReleases\tera-v2.5.0"
 ```
 
 ### 4.4 سلوك المُحدِّث (سلسلة تحقق إلزامية)
@@ -206,11 +206,11 @@ pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable
 ### 4.5 update-client-repositories.ps1 — الدفعات
 
 ```powershell
-pwsh .\tera-workshop\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0" -ReposFile "C:\Tera\client-repositories.txt"
-pwsh .\tera-workshop\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.5.0" -ReposFile "C:\Tera\client-repositories.txt"
+pwsh .\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0" -ReposFile "C:\Tera\client-repositories.txt"
+pwsh .\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.5.0" -ReposFile "C:\Tera\client-repositories.txt"
 
 # دفعات مباشرة من المستودع الأصلي
-pwsh .\tera-workshop\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -ReposFile "C:\Tera\client-repositories.txt"
+pwsh .\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem" -ReposFile "C:\Tera\client-repositories.txt"
 ```
 
 - يقبل ملف قائمة مستودعات (سطر لكل مسار) أو JSON بالشكل `{ "repositories": ["..."] }`
@@ -241,19 +241,19 @@ pwsh .\tera-workshop\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -
 ### الترقية
 ```powershell
    # من حزمة محلية
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0"
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.5.0"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.5.0"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.5.0"
 
    # مباشرة من المستودع الأصلي
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Plan -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem"
 ```
 
 ### الاسترجاع (Rollback)
 ```powershell
 # العودة إلى إصدار سابق مثبت:
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.0.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.0.0"
-   pwsh .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.0.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.0.0"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.0.0 -Channel stable -Mode Plan -SourcePath "C:\TeraReleases\tera-v2.0.0"
+   pwsh .\tools\tera-update.ps1 -Version tera-v2.0.0 -Channel stable -Mode Apply -SourcePath "C:\TeraReleases\tera-v2.0.0"
 ```
 - الاسترجاع = تحديث إلى SHA سابق — نفس الآلية، بلا "مسار خاص"
 - ملفات العميل لا تتأثر إطلاقاً
@@ -265,9 +265,9 @@ pwsh .\tera-workshop\tools\update-client-repositories.ps1 -Version tera-v2.5.0 -
 | الملف | العلاقة |
 |---|---|
 | `tera-system/TeraPolicyMap.md` | يوثّق هذه السياسة كمصدر حقيقة لموضوع التوزيع |
-| `tera-system/TeraArchitectureMap.md` | يوضّح طبقة التوزيع ودور `tera-workshop/tools/` |
+| `tera-system/TeraArchitectureMap.md` | يوضّح طبقة التوزيع ودور `tools/` |
 | `project-control/SYSTEM_EVOLUTION_LOG.md` | يسجّل كل إصدار/ترقية منفذة |
-| `tera-system/TOOLING_AND_MCP_POLICY.md` | السياسة الحاكمة للأدوات — المُحدِّث أداة رسمية ضمن `tera-workshop/tools/` |
+| `tera-system/TOOLING_AND_MCP_POLICY.md` | السياسة الحاكمة للأدوات — المُحدِّث أداة رسمية ضمن `tools/` |
 | `.gitattributes` | `cr-at-eol` — أساس سلامة `git diff --check` عند التحديث |
 
 ---

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/` |
@@ -41,7 +41,6 @@ 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 |
 | `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 |
@@ -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

@@ -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,21 @@ 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) قبل أي تسعير — راجع بنك الأسئلة.
+
+---
+
 ## 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 مُهندس. |
@@ -49,7 +49,7 @@ Project files record project-specific decisions.
 | 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/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,8 @@ 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)، عقد ملكية، أدوات `tera-workshop/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. |
 
 ## 4. Duplication Policy
 

package/core/tera-system/TeraPricingPolicy.md

@@ -429,6 +429,22 @@ Minimum Profitable Price = Estimated Hours × Internal Hourly Rate
 
 إذا كانت تقديرات الساعات أقل من الواقع المتوقع، يتم اعتماد تقدير الساعات الأعلى لا رقم الـ Scorecard فقط.
 
+### قاعدة توثيق تقدير الساعات (SCP-2026-08-29-002)
+
+1. **تقدير الساعات إلزامي قبل اعتماد أي سعر — لا يجوز الاعتماد والساعات غير مدخلة (صفر) أو غير موثقة.**
+2. **الحد الأدنى لتقدير الساعات للتسعير المباشر = 40 ساعة.** أي تقدير أقل يستدعي مراجعة إلزامية أو تحويلاً لتحليل مدفوع (§20).
+3. يُفضَّل توثيق التقدير عبر **مصفوفة ساعات موزعة** (واجهات / منطق / بيانات / تكاملات / اختبار / نشر / توثيق) — النطاقات الإرشادية أدناه **دليل وليست التزاماً**، تُضبط حسب النطاق الفعلي. الحاسبة v4.3 تتضمن ورقة `HoursEstimator` لهذا الغرض.
+
+| عنصر التقدير | صغير (ساعة) | متوسط (ساعة) | كبير (ساعة) |
+|---|:---:|:---:|:---:|
+| واجهات وشاشات (UI) | 15–25 | 30–50 | 60–100 |
+| منطق الأعمال | 10–20 | 25–45 | 50–90 |
+| قاعدة البيانات | 5–10 | 12–25 | 30–60 |
+| التكاملات | 0–5 | 8–20 | 25–60 |
+| الاختبار والجودة QA | 5–10 | 12–25 | 30–60 |
+| النشر والاستضافة | 2–5 | 5–10 | 10–20 |
+| التوثيق والتدريب | 2–5 | 5–15 | 15–30 |
+
 ---
 
 ## 18. الحد الأدنى المطلق
@@ -590,6 +606,7 @@ Minimum Engagement Fee = 100 JOD
 11. أي مشروع مستعجل يخضع لـ Rush Premium.
 12. أي مشروع متوسط 41% - 60% لا يُسعّر مباشرة إلا إذا كان النطاق مكتوبًا وثابتًا.
 13. لا يتم تسليم النسخة النهائية قبل تسوية الدفعات المستحقة.
+14. لا يُعتمد أي سعر والساعات غير مدخلة (صفر) أو أقل من الحد الأدنى (40 ساعة) — راجع §17 (SCP-2026-08-29-002).
 
 ---
 
@@ -672,3 +689,46 @@ max(Final Scorecard Price, 100 JOD, Minimum Profitable Price)
 | 5 | الحد الأعلى للتخفيض العادي | 10% |
 | 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

@@ -20,14 +20,14 @@ description: Canonical source for the 13 mandatory TCEA discovery domains — si
 | 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 | نعم | نعم |
+| 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 | نعم | نعم |
+| 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 | نعم | نعم |
+| 13 | Acceptance, Commercials & Warranty | Acceptance, Commercials & Warranty | Acceptance criteria, budget, payment plan, warranty, support terms + **توقع السورس كود (نعم/لا/غير متأكد) والغرض** — راجع TeraPricingPolicy §31 | نعم | نعم |
 
 ---
 
@@ -40,6 +40,8 @@ description: Canonical source for the 13 mandatory TCEA discovery domains — si
 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.
+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.md

@@ -863,7 +863,7 @@ Use these outlines when creating files under `clients/.../client-approval/`. Cli
 
 This is not a text template but an **HTML document**. The proposal is generated as a self-contained HTML page with embedded CSS for professional presentation, RTL support, and print optimization.
 
-Reference file: `tera-workshop/APPLICATION_PROPOSAL_TEMPLATE.html`
+Reference file: `tera-workshop/client-templates/commercial/APPLICATION_PROPOSAL_TEMPLATE.md`
 
 After the Client Discovery + Smart Interview process completes, Tera populates the template with:
 - Application name, date, client name