@tera-system/core 0.1.0

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

@@ -0,0 +1,584 @@
+# Tera Runtime Templates — Delivery & Execution
+
+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–40).
+
+---
+
+## 29. Project Master Plan (Phase 5 — Output)
+
+This template is used for the first formal output of Phase 5 (Execution Planning).
+The generated file is saved to `project-control/PROJECT_MASTER_PLAN.md`.
+
+```markdown
+# PROJECT_MASTER_PLAN.md
+
+## 1. Plan Metadata
+
+| Item | Value |
+|---|---|
+| Project | [NAME] |
+| Version | 1.0 |
+| Status | Draft / Approved / Active |
+| Reference | `project-preparation/09_IMPLEMENTATION_PLAN.md` |
+
+## 1.1 Relationship to Preparation Plan
+
+| File | Role |
+|---|---|
+| `project-preparation/09_IMPLEMENTATION_PLAN.md` | Preliminary implementation plan produced during preparation |
+| `project-control/PROJECT_MASTER_PLAN.md` | Official execution roadmap after preparation approval |
+| `project-control/PROJECT_DETAILED_EXECUTION_PLAN.md` | Detailed traceable execution items |
+| `project-control/EXECUTION_BATCH_PLAN.md` | Next approved executable batch only |
+| `project-control/tasks/TASK-COD-XXX.md` | Actual executable unit |
+
+## 2. Execution Phases
+
+| Phase | Name | Objective | Roadmap Tier | Depends On | Status |
+|---|---|---|---|---|---|
+| 1 | [e.g. Technical Foundation] | [e.g. Scaffold project, init ORM, verify startup] | Core MVP / Foundation | — | Planned |
+| 2 | [e.g. Database Schema] | [e.g. Define models, create migration, seed] | Core MVP | Phase 1 | Planned |
+| 3 | [e.g. Core Feature] | [e.g. Main workflow implementation] | Core MVP / Extended MVP | Phase 1, 2 | Planned |
+| ... | ... | ... | ... | ... | ... |
+
+## 2.1 Formal Phased Roadmap
+
+| Roadmap Tier | Included Phases / Features | Explicitly Excluded / Later |
+|---|---|---|
+| Core MVP | ... | ... |
+| Extended MVP | ... | ... |
+| Phase 2 | ... | ... |
+| Later / Out of Scope | ... | ... |
+
+> **Rule:** No detailed execution planning or `TASK-COD-*` generation before this master plan, including the formal phased roadmap, is approved.
+
+## 3. Transition Conditions
+
+| From | To | Condition |
+|---|---|---|
+| Phase 1 | Phase 2 | Project starts, dev env works, ORM connects to DB |
+| Phase 2 | Phase 3 | Schema applied, seed data verified |
+| ... | ... | ... |
+
+## 4. Design Source Decisions
+
+| Phase / Batch | Design Source | Decided? |
+|---|---|---|
+| All UI phases | [INTERNAL_TERA_KIT / GETDESIGN_MD / FIGMA_DESIGN_FILE / USER_PROVIDED_REFERENCE / EXTERNAL_URL_ANALYSIS / HYBRID / NO_UI / N/A] | Yes / No |
+| Phase 3 (UI) | [source] | Yes / No |
+
+> **Rule:** No UI phase/batch without a Design Source Decision.
+
+## 5. Deferred Items
+
+| Item | Reason | Phase |
+|---|---|---|
+| ... | ... | ... |
+
+## 6. Approval
+
+- [ ] Submitted
+- [ ] Approved → Ready for Detailed Planning
+- [ ] Needs revision
+```
+
+---
+
+## 30. Detailed Execution Plan (Phase 5 — Output)
+
+This template breaks each phase into traceable execution items.
+The generated file is saved to `project-control/PROJECT_DETAILED_EXECUTION_PLAN.md`.
+
+```markdown
+# PROJECT_DETAILED_EXECUTION_PLAN.md
+
+## 1. Source Reference
+
+- Master Plan: `project-control/PROJECT_MASTER_PLAN.md`
+- Implementation Plan: `project-preparation/09_IMPLEMENTATION_PLAN.md`
+
+## 2. Phase Breakdown
+
+### Phase [N]: [Phase Name]
+
+| Item ID | Description | Linked TASK-ID | Depends On | Status | Notes |
+|---|---|---|---|---|---|
+| P1-01 | [e.g. Scaffold Next.js project] | TASK-COD-001 | — | Planned | |
+| P1-02 | [e.g. Init Prisma + connect to DB] | TASK-COD-002 | P1-01 | Planned | See profile: nextjs-prisma |
+| P2-01 | [e.g. Define User model] | TASK-COD-003 | P1-02 | Planned | |
+| P2-02 | [e.g. Create migration + apply] | TASK-COD-004 | P2-01 | Planned | |
+| ... | ... | ... | ... | ... | ... |
+
+### Item Status Legend
+
+| Status | Meaning |
+|---|---|
+| Planned | Defined, not yet assigned |
+| In Progress | Assigned to agent, being executed |
+| Completed | Executed and accepted |
+| Blocked | Cannot proceed without resolution |
+| Deferred | Moved to later phase |
+
+## 3. Approval
+
+- [ ] Submitted
+- [ ] Approved → Ready for batch planning
+- [ ] Needs revision
+```
+
+---
+
+## 31. Execution Batch Plan (Phase 5 — Output)
+
+This template defines the current approved batch only — not the full project.
+The generated file is saved to `project-control/EXECUTION_BATCH_PLAN.md`.
+
+```markdown
+# EXECUTION_BATCH_PLAN.md
+
+## 1. Batch Metadata
+
+| Item | Value |
+|---|---|
+| Batch | [Number / Name] |
+| Phase | [Phase from Master Plan] |
+| Status | Draft / Approved / In Progress / Completed |
+| Source Plan | `project-control/PROJECT_DETAILED_EXECUTION_PLAN.md` |
+
+## 2. Included Tasks
+
+| TASK-ID | Description | Assigned Agent | Allowed Write Targets | Pre-Execution Gate |
+|---|---|---|---|---|
+| TASK-COD-001 | [e.g. Scaffold project] | EngineeringAgent | `.` (project root) | PASS |
+| TASK-COD-002 | [e.g. Init ORM + DB] | EngineeringAgent | `prisma/schema.prisma`, `.env.example` | PASS |
+| ... | ... | ... | ... | ... |
+
+## 3. Not Included (Deferred to Later Batches)
+
+| Item | Reason | Expected Batch |
+|---|---|---|
+| Schema design | Depends on scaffold completion | Batch 2 |
+| UI components | No Design Source Decision yet | Batch 3 |
+
+## 4. Design Source Decision (for this batch)
+
+- [ ] INTERNAL_TERA_KIT
+- [ ] GETDESIGN_MD
+- [ ] FIGMA_DESIGN_FILE
+- [ ] USER_PROVIDED_REFERENCE
+- [ ] EXTERNAL_URL_ANALYSIS
+- [ ] HYBRID
+- [ ] NO_UI
+- [ ] N/A
+
+## 5. User Approval
+
+- [ ] Batch plan submitted
+- [ ] Approved → Begin execution (Phase 6)
+- [ ] Rejected → Revise
+- [ ] Blocked → Reason: ...
+
+---
+
+> **Rules:**
+> - No Implementation without Execution Plan.
+> - No UI Task without Design Source Decision.
+> - No UI Task without `28_UI_UX_GUIDELINES.md` when visual style matters.
+> - UI tasks must link `tera-system/design-system/UI_ACCEPTANCE_GATE.md`.
+> - No TASK-ID without Pre-Execution Gate PASS.
+> - No batch execution without user approval.
+```
+
+---
+
+## 32. Post-Execution Review (Phase 6 Review Template)
+
+This template is used inside `project-control/tasks/TASK-COD-XXX.md` after an agent handback and before any task acceptance or closure.
+
+```markdown
+## Post-Execution Review
+
+| Check | Result | Notes |
+|---|---|---|
+| TASK objective completed? | PASS / FAIL | ... |
+| Output matches approved scope? | PASS / FAIL | ... |
+| No files outside Allowed Write Targets? | PASS / FAIL | ... |
+| No forbidden files created? | PASS / FAIL | ... |
+| No unexpected libraries added? | PASS / FAIL | ... |
+| No secrets, tokens, passwords, or real `.env` values? | PASS / FAIL | ... |
+| Technology Profile respected? | PASS / FAIL | ... |
+| UI/UX rules respected if UI exists? | PASS / FAIL / N/A | ... |
+| UI Acceptance Gate passed if UI exists? | PASS / FAIL / N/A | ... |
+| Acceptance Criteria passed? | PASS / FAIL | ... |
+| CLI / tool side effects reviewed? | PASS / FAIL / N/A | ... |
+| Rollback needed? | Yes / No | ... |
+
+Gate Result:
+PASS / NEEDS_FIX / BLOCKED
+
+Final Tera Decision:
+Accepted / Needs Fix / Blocked / Rework Needed / Deferred / Cancelled / READY FOR OWNER ACCEPTANCE
+
+Owner Approval Required: Yes / No / N/A — (المصدر: Task Contract / Gate / Batch approval / قرار مالك مسجل — لا يُقرر ارتجالياً)
+Owner Approval Status: Pending / Approved / N/A
+(إذا Required = Yes وStatus = Pending → الحالة = READY FOR OWNER ACCEPTANCE — لا Accepted/Closed — SCP-2026-08-16-003)
+
+Required Record Updates:
+- [ ] `project-control/tasks/TASK-COD-XXX.md`
+- [ ] `project-control/TASK_REGISTRY.md`
+- [ ] `project-control/PROJECT_ACTIVITY_LOG.md`
+- [ ] `project-control/PROJECT_STATE.md`
+- [ ] `project-control/ISSUES_AND_GAPS.md` if needed
+- [ ] `project-control/DECISIONS_LOG.md` if owner approval recorded
+- [ ] `project-control/TERA_AUDIT_TRAIL.md` (AUD entry with Owner Approval Status)
+```
+
+---
+
+## 33. Compliance Record (Task Closure Governance Summary)
+
+هذا القسم يُضاف إلى `project-control/tasks/TASK-COD-XXX.md` كآخر قسم قبل الإغلاق (بعد `Post-Execution Review`).
+وهو المرجع المعتمد لـ Monitor للتحقق من مطابقة Handback + Git diff + القواعد.
+
+```markdown
+## Compliance Record
+
+| # | Check | Result | Verified By |
+|---|---|---|---|
+| 1 | Pre-Execution Gate: PASS documented in task file | PASS / N/A | Tera |
+| 2 | Allowed Write Targets respected | PASS / FAIL | Tera |
+| 3 | No secrets/tokens/passwords in outputs or logs | PASS / FAIL | Tera |
+| 4 | Design Source Decision documented (if UI exists) | PASS / N/A | Tera |
+| 5 | Post-Execution Review: PASS | PASS / FAIL | Tera |
+| 6 | PROJECT_ACTIVITY_LOG.md updated | PASS / FAIL | Tera |
+| 7 | Handback recorded in TASK-ID file | PASS / FAIL | Tera |
+| 8 | Git diff matches Handback description | PASS / FAIL / PENDING | Monitor\* |
+| 9 | CLI/commands documented (if any) | Done / N/A | Tera |
+| 10 | Owner Approval: إذا Required = Yes → الاعتماد الصريح مسجل (Task + DECISIONS_LOG + AUDIT_TRAIL) قبل CLOSED | PASS / N/A | Tera |
+| 11 | Cross-Record Consistency: لا تعارض حالة المهمة بين Task file / TASK_REGISTRY / PROJECT_STATE / DECISIONS_LOG / AUDIT_TRAIL | PASS / FAIL | Tera/Monitor |
+
+\* Item 8: Monitor يتحقق عند نشاطه. إذا لم يكن Monitor نشطاً، يوثق Tera الفحص الذاتي.
+\* Item 10–11: SCP-2026-08-16-003 — المرجع الحاكم: `TERA_RUNTIME_PROTOCOLS_CORE.md` §4.0/§4.0.1.
+
+Compliance Status: COMPLIANT / NON-COMPLIANT / PENDING_MONITOR_REVIEW
+```
+
+---
+
+## 34. UI/UX Guidelines Template (Design Governance Output)
+
+This template defines the required structure of `project-preparation/28_UI_UX_GUIDELINES.md`.
+
+Required sections:
+
+```markdown
+# 28_UI_UX_GUIDELINES.md
+
+## 1. Design Source Decision
+## 2. Approved Design Direction
+## 3. Raw Design Sources
+## 4. Client Branding Overrides
+## 5. Design Tokens
+## 6. Layout System
+## 7. Component Rules
+## 8. RTL/LTR Rules
+## 9. Responsive Rules
+## 10. Accessibility Rules
+## 11. Motion Rules
+## 12. Forbidden Styling
+## 13. Engineering Implementation Instructions
+## 14. UI Acceptance Checklist
+## 15. Figma Source Mapping (when FIGMA_DESIGN_FILE is active)
+## 16. Open Design Gaps
+```
+
+Rule:
+
+```text
+EngineeringAgent implements UI from this file first. Missing rules become Design Gaps, not guesses.
+```
+
+---
+
+## 35. Phase 7 Delivery, Handover & Closure Templates
+
+These templates are used after Phase 6 implementation is complete. Phase 7 does not execute code. Blocking findings return to Phase 6 as `TASK-COD-FIX-*`.
+
+### 35.1 Delivery Readiness Report
+
+Generated file: `project-control/DELIVERY_READINESS_REPORT.md`
+
+```markdown
+# DELIVERY_READINESS_REPORT.md
+
+## 1. Metadata
+
+| Field | Value |
+|---|---|
+| Project |  |
+| Phase | 7 — Delivery, Handover & Closure |
+| Date |  |
+| Prepared By | Tera / qa-agent / DevOpsAgent |
+| Status | Draft / Ready / Blocked |
+
+## 2. Entry Gate
+
+| Check | Result | Notes |
+|---|---|---|
+| All approved TASK-COD closed or deferred | PASS / FAIL |  |
+| Post-Execution Reviews complete | PASS / FAIL |  |
+| No undocumented Critical blockers | PASS / FAIL |  |
+| TASK_REGISTRY current | PASS / FAIL |  |
+| PROJECT_STATE current | PASS / FAIL |  |
+| ISSUES_AND_GAPS current | PASS / FAIL / N/A |  |
+
+## 3. Delivery Readiness
+
+| Area | Result | Notes |
+|---|---|---|
+| Core workflows | Ready / Not Ready |  |
+| Final QA / smoke | PASS / FAIL / N/A |  |
+| Regression review | PASS / FAIL / N/A |  |
+| Documentation | Ready / Needs Work |  |
+| Deployment readiness | Ready / Not Ready / N/A |  |
+| Security closure | PASS / FAIL / N/A |  |
+
+## 4. Blockers
+
+| Blocker | Severity | Required Action | Return to Phase 6? |
+|---|---|---|---|
+|  | Critical / High / Medium / Low |  | Yes / No |
+
+## 5. Result
+
+Delivery Readiness Status: READY / NEEDS_FIX / BLOCKED
+```
+
+### 35.2 Final Acceptance Checklist
+
+Generated file: `project-control/FINAL_ACCEPTANCE_CHECKLIST.md`
+
+```markdown
+# FINAL_ACCEPTANCE_CHECKLIST.md
+
+| Acceptance Area | Result | Evidence / Notes |
+|---|---|---|
+| Approved scope delivered | PASS / FAIL |  |
+| Deferred items documented | PASS / FAIL / N/A |  |
+| Open issues reviewed | PASS / FAIL |  |
+| User/client acceptance recorded | PASS / FAIL |  |
+| No hidden blockers | PASS / FAIL |  |
+| Handover package ready if client project | PASS / FAIL / N/A |  |
+
+Final Acceptance Status: ACCEPTED / NEEDS_FIX / BLOCKED
+```
+
+### 35.3 Release Notes
+
+Generated file: `project-control/RELEASE_NOTES.md`
+
+```markdown
+# RELEASE_NOTES.md
+
+## Version / Release
+
+- Release Name:
+- Date:
+- Scope:
+
+## Delivered
+
+- ...
+
+## Changed
+
+- ...
+
+## Fixed
+
+- ...
+
+## Deferred / Not Included
+
+- ...
+
+## Known Issues
+
+- ...
+```
+
+### 35.4 Post-Implementation Review
+
+Generated file: `project-control/POST_IMPLEMENTATION_REVIEW.md`
+
+```markdown
+# POST_IMPLEMENTATION_REVIEW.md
+
+## What Went Well
+- ...
+
+## What Was Difficult
+- ...
+
+## Scope / Quality Notes
+- ...
+
+## Process Improvements
+- ...
+
+## Follow-up Recommendations
+- ...
+```
+
+### 35.5 Project Closure Report
+
+Generated file: `project-control/PROJECT_CLOSURE_REPORT.md`
+
+```markdown
+# PROJECT_CLOSURE_REPORT.md
+
+## 1. Closure Metadata
+
+| Field | Value |
+|---|---|
+| Project |  |
+| Closure Date |  |
+| Closure Decision | Closed / Needs Final Fix / Deferred / Blocked |
+| Approved By | User / Client / Tera |
+
+## 2. Completion Summary
+
+- Delivered:
+- Deferred:
+- Out of Scope:
+
+## 3. Required Outputs
+
+| Output | Status | Notes |
+|---|---|---|
+| Delivery Readiness Report | Complete / N/A |  |
+| Final Acceptance Checklist | Complete / N/A |  |
+| Release Notes | Complete / N/A |  |
+| Client Handover Package | Complete / N/A |  |
+
+## 4. Open Issues / Deferred Items
+
+| Item | Status | Recommended Action |
+|---|---|---|
+|  | Deferred / Closed / Won't Fix |  |
+
+## 5. Final Decision
+
+Project Closure Status: CLOSED / BLOCKED / NEEDS_PHASE_6_FIX
+```
+
+### 35.6 Client Handover Package
+
+Generated file for external client projects:
+
+```text
+clients/CLIENT-[client-name-or-id]/applications/APP-[app-name-or-id]/delivery/CLIENT_HANDOVER_PACKAGE.md
+```
+
+```markdown
+# CLIENT_HANDOVER_PACKAGE.md
+
+## 1. تسليم المشروع
+
+- اسم العميل:
+- اسم التطبيق:
+- تاريخ التسليم:
+- نسخة التسليم:
+
+## 2. ما تم تسليمه
+
+- ...
+
+## 3. طريقة التشغيل / الوصول
+
+- لا تكتب أسرارًا أو كلمات مرور.
+- أشر فقط إلى أن البيانات الحساسة محفوظة كـ local environment secrets أو عبر قناة آمنة.
+
+## 4. العناصر المؤجلة أو غير المشمولة
+
+- ...
+
+## 5. القبول النهائي
+
+- Accepted / Needs Fix / Deferred
+- اسم صاحب الاعتماد:
+- التاريخ:
+```
+
+---
+
+## 36. Logging & Production Diagnosis Standards (GAP-006 — SCP-2026-08-16-005)
+
+تُطبَّق على كل تسليم يعمل في الإنتاج.
+
+### 35.1 Logging Standards
+
+| القاعدة | المعيار |
+|---|---|
+| المستويات | موحدة: `ERROR` (فشل يحتاج انتباهاً)، `WARN` (غير متوقع لكن قابل للاستمرار)، `INFO` (مراحل أعمال)، `DEBUG` (تشخيص — يُغلق في الإنتاج) |
+| السياق | كل سطر يشمل: اسم العملية/التدفق + معرّف الكيان/الطلب حيثما توفر |
+| البيانات الحساسة | **ممنوع** تسجيل: كلمات مرور، Tokens، بيانات شخصية — تُستبدل بمرجع مُقنّع |
+| اللغة | لغة واحدة متسقة حسب Baseline المشروع |
+
+### 35.2 Production Diagnosis — الخطوات الأولى
+
+عند الإبلاغ عن مشكلة إنتاجية، اتبع بالترتيب:
+
+1. اقرأ السجلات بالمستوى الصحيح (ERROR/WARN أولاً) مع سياق العملية.
+2. تحقق من حالة الخدمة/التبعيات (قاعدة بيانات، API خارجي، تخزين) قبل لمس الكود.
+3. أعد إنتاج الخطأ في بيئة معزولة (Staging/محلي بنفس قيم البيئة) عند الإمكان.
+4. وثّق السبب الجذري في تقرير المهمة/التسليم.
+
+---
+
+## 37. Performance Verification & Load Testing Guidance (GAP-007 — SCP-2026-08-16-006)
+
+### 36.1 Basic Performance Check — إلزامي عند التسليم
+
+| الفحص | الحد الأدنى |
+|---|---|
+| زمن استجابة المسارات الرئيسية | قياس + تسجيل متوسط/p95 للمسارات الأساسية |
+| استهلاك الذاكرة | مراقبة عملية ممثلة؛ تسجيل الذروة |
+| استهلاك المعالج | مراقبة عملية ممثلة؛ تسجيل الاستخدام |
+
+سجّل **أرقاماً حقيقية** في تقرير التسليم — لا ادعاءات بلا قياس.
+
+### 36.2 Load Testing — مشروط (المشاريع الحساسة للنمو فقط)
+
+- حدد سيناريو أساسياً: مستخدمون متزامنون، طلبات/ثانية، مدة.
+- استخدم أداة قياسية موثوقة؛ سجّل الإنتاجية ومعدل الأخطاء.
+- قرار القبول/الرفض بيد المالك/المدير — موثق.
+- غير مطلوب للمشاريع الصغيرة/الثابتة/الداخلية (تجنّب التضخم).
+
+---
+
+## 38. Backup & Disaster Recovery Guidance (GAP-008 — SCP-2026-08-16-007)
+
+تنطبق على التسليمات ذات البيانات (قاعدة بيانات، ملفات رفع، سجلات).
+
+### 37.1 Backup Basics
+
+| البند | الإرشاد |
+|---|---|
+| ما يُحمى | قاعدة البيانات، ملفات الرفع، الإعدادات/الحالة |
+| التكرار | يومي كحد أدنى للبيانات النشطة؛ أسبوعي للثابتة — حسب الحساسية |
+| التخزين | منفصل عن بيئة الإنتاج (قرص/منطقة مختلفة) |
+
+### 37.2 أهداف الاستعادة (RPO/RTO)
+
+- **RPO** (الحد الأقصى المقبول لفقدان البيانات): يُحدد صراحةً (مثال: ≤ 24 ساعة).
+- **RTO** (الحد الأقصى المقبول لزمن الاستعادة): يُحدد صراحةً (مثال: ≤ 4 ساعات).
+- يُتفق عليهما مع العميل ويُسجّلان في وثائق التسليم/القبول.
+
+### 37.3 اختبار استعادة دوري
+
+- اختبر استعادة من نسخة احتياطية في بيئة معزولة قبل الاعتماد على الخطة.
+- سجّل نتيجة الاختبار (تاريخ، نجاح/فشل) في وثائق التسليم.
+
+---