@tera-system/core 0.2.2 → 0.2.4

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/TeraArchitectureMap.md

@@ -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`, `tera-workshop/tools/tera-fetch.ps1`, `tera-workshop/tools/tera-release.ps1`, `tera-workshop/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`, `tools/tera-fetch.ps1`, `tools/tera-release.ps1`, `tools/tera-update.ps1`, `.tera/lock.json` داخل مستودعات العملاء |
 
 ## 3. Folder Roles
 
@@ -44,7 +44,7 @@ It is a map, not a policy source. Rules remain in the files listed in `TeraPolic
 | `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 |
+| `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 |
 

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/APPLICATION_PROPOSAL_TEMPLATE.html`.
+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`.
 
-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 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 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.
 

package/core/tera-system/TeraPolicyMap.md

@@ -47,7 +47,7 @@ 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/tasks/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/templates/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 (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 |
@@ -105,7 +105,7 @@ 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 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. |
 
 ## 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,4 @@ 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 ساعة |

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

@@ -20,11 +20,11 @@ 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 | نعم | نعم |
@@ -40,6 +40,7 @@ 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 وغيرها).
 
 ---
 

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

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

@@ -1,8 +1,8 @@
 # Tera Runtime Templates — Preparation & Blueprint Outputs
 
-These are the preparation-phase templates (Sections 35–41: TCEA outputs, ApplicationBlueprint outputs, and Content Requirements) split from TERA_RUNTIME_TEMPLATES.md via INSPECTION-2026-08-01 (INS-02).
+These are the preparation-phase templates (Sections 35–40: TCEA outputs and ApplicationBlueprint outputs) 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).
-Delivery templates: `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` (Sections 29–38).
+Delivery templates: `tera-system/runtime/TERA_RUNTIME_TEMPLATES_DELIVERY.md` (Sections 29–34).
 
 ---
 
@@ -46,6 +46,8 @@ It is produced by TCEA after completing the 13-domain discovery and before any s
 
 > **ملاحظة المجال 13:** يحتاج تغطية 3 جوانب داخلية على الأقل: (أ) معايير القبول والاختبارات, (ب) الميزانية وخطة الدفع, (ج) الضمان والصيانة.
 
+> **Non-Functional Depth (SCP-2026-08-29-001):** قبل إعلان Complete للمجالات 4/6/9/10، سجّل تغطية تفضيلات الزبون غير الوظيفية (مراجع بصرية، ألوان/نبرة، شكل العرض الرئيسي، حقول الشاشات، منطقة الاستضافة) في عمود "Reason if not Complete" أو في قسم ملاحظات التغطية — Partial + UNCERTAINTY_NOTICE إن لم تُجب.
+
 ## 3. Coverage Decision
 
 | Item | Value |

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

@@ -40,7 +40,7 @@ project-control/RELEASE_NOTES.md
 project-control/NEXT_VERSION_HANDOFF.md
 project-control/PROJECT_STATE.md
 project-control/TASK_REGISTRY.md
-project-control/tasks/TASK_TEMPLATE.md
+project-control/templates/TASK_TEMPLATE.md
 ```
 
 Rules:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tera-system/core",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "description": "Tera System OpenCode Plugin — governance core, 20 agents, 11 commands, distribution tools (personal edition)",
   "license": "SEE LICENSE IN LICENSE.md",
   "type": "module",
@@ -11,6 +11,7 @@
     "agents",
     "commands",
     "core",
+    "assets",
     "tools",
     "scripts",
     "MANIFEST.json",
@@ -20,6 +21,10 @@
     "LICENSE.md",
     "RELEASES.md"
   ],
+  "bin": {
+    "tera-restore": "scripts/install.js",
+    "tera-core-restore": "scripts/install.js"
+  },
   "scripts": {
     "postinstall": "node scripts/install.js"
   },

package/scripts/build.mjs

@@ -63,6 +63,7 @@ const checks = [
   ["agents", "agents"],
   ["commands", "commands"],
   ["core/tera-system", "coreFiles"],
+  ["assets", "assets"],
 ];
 let fail = false;
 for (const [dir, key] of checks) {
@@ -94,6 +95,7 @@ const groupHashes = {
   "core/tera-system": groupSha("core/tera-system"),
   tools: groupSha("tools"),
   "core/project-control": groupSha("core/project-control"),
+  assets: groupSha("assets"),
 };
 console.log("   group hashes:");
 for (const [g, h] of Object.entries(groupHashes)) console.log(`     ${g.padEnd(20)} ${h ?? "(n/a)"}`);

package/scripts/install.js

@@ -195,6 +195,10 @@ installGroup({ name: "agents", src: path.join(PKG_ROOT, "agents"), dest: path.jo
 installGroup({ name: "commands", src: path.join(PKG_ROOT, "commands"), dest: path.join(target, ".opencode", "commands") });
 installGroup({ name: "tera-system", src: path.join(PKG_ROOT, "core", "tera-system"), dest: path.join(target, "tera-system") });
 installGroup({ name: "tools", src: path.join(PKG_ROOT, "tools"), dest: path.join(target, "tools") });
+// Required assets (SCP-2026-08-29-002): pricing calculator + client templates.
+// Installs relative to target root so `project-control/...` and `tera-workshop/...`
+// land at the exact paths policies reference. Never skipped (unlike project-control skeleton).
+installGroup({ name: "assets", src: path.join(PKG_ROOT, "assets"), dest: target });
 installConfig();
 installProjectControl();