@tera-system/core 0.1.0

package/core/tera-system/TERA_CONTINUOUS_IMPROVEMENT_POLICY.md

@@ -0,0 +1,111 @@
+<!-- © 2026 Majed Khaireddin (Alabasi1980). Tera System — Proprietary. All rights reserved. -->
+
+# TERA CONTINUOUS IMPROVEMENT POLICY
+
+## 1. الغرض
+
+هذه السياسة توجّه جميع العملاء الأساسيين في منظومة Tera إلى التزام **اليقظة النظامية** — أي ملاحظة الفجوات، الخلل، التضخم، أو فرص التحسين في المنظومة والإبلاغ عنها، بدلاً من تجاهلها أو اعتبارها خارج نطاق المسؤولية.
+
+---
+
+## 2. السياق
+
+هذه المؤسسة والمنظومة ما زالت في مرحلة تأسيس وتشغيل أولي، وهذا المشروع يُعد من أوائل المشاريع التجريبية/التشغيلية لدينا.
+
+لذلك، يُتوقع من كل عميل أثناء عمله أن يبقى متنبهاً لقابلية تحسين المنظومة نفسها، وليس فقط تنفيذ المهمة الموكلة إليه.
+
+---
+
+## 3. مجالات المراقبة — ما يجب أن ينتبه له العميل
+
+أثناء العمل على أي مرحلة أو مهمة، إذا لاحظ العميل أي مما يلي، يجب عليه عدم تجاهله:
+
+| المجال | أمثلة |
+|--------|-------|
+| نقص في الملف التعريفي أو التعليمات التشغيلية | دور العميل غير محدّد بدقة، تعليمات ناقصة |
+| خلل أو غموض في المنظومة أو آلية العمل | سياسة متناقضة، بروتوكول غير مكتمل |
+| أوامر أو قيود غير مناسبة لطبيعة الدور | العميل ممنوع من فعل شيء ضروري لأداء عمله |
+| خطوات أو أعمال غير ضرورية تسبب بطئاً أو تعطيلاً | تكرار في المهام، مراحل لا قيمة مضافة لها |
+| صلاحيات أو أدوات إضافية يحتاجها العميل | MCP، صلاحية قراءة/كتابة، أداة مفقودة |
+| مهام غير مناسبة للدور أو يجب نقلها لعميل آخر | تداخل مسؤوليات بين العملاء |
+| تحسينات مقترحة على طريقة العمل أو الملفات أو البروتوكولات | إعادة هيكلة، دمج ملفات، تبسيط إجراءات |
+| أي ملاحظة من شأنها تحسين جودة المؤسسة أو كفاءة العملاء أو تقليل الأخطاء والتضخم | — |
+
+---
+
+## 4. آلية الإبلاغ — ما يجبفعله العميل عند اكتشاف ملاحظة مهمة
+
+عند اكتشاف أي ملاحظة تستوفي معايير البند §3، على العميل القيام بالخطوات التالية:
+
+1. **إبلاغ Majed** بها بوضوح في ردّه.
+2. **توضيح أثرها** على العمل، إن وجد.
+3. **اقتراح حل عملي** مختصر إن أمكن.
+4. **تسجيلها** داخل ملف التطبيق التالي:
+   ```
+   project-control/AGENT_GAPS_LOG.md
+   ```
+
+### 4.1 صيغة التسجيل في AGENT_GAPS_LOG.md
+
+يجب أن تكون الملاحظة منظّمة بالشكل التالي:
+
+```md
+## GAP-[رقم تلقائي أو مؤقت] — [عنوان مختصر]
+
+- Date:
+- Agent:
+- Context:
+- Observation:
+- Impact:
+- Recommended Action:
+- Severity: Low / Medium / High
+- Status: Open
+```
+
+### 4.2 تنبيه مهم — لا تسجيل للتفاصيل الصغيرة
+
+لا يُستخدم هذا المسار لتسجيل ملاحظات عادية أو تفاصيل تنفيذية صغيرة.
+يُستخدم فقط للملاحظات التي تكشف:
+
+- خللاً
+- نقصاً
+- تضارباً
+- فرصة تحسين حقيقية
+- حاجة تطوير في المنظومة أو في دور العميل نفسه
+
+---
+
+## 5. استمرارية العمل
+
+على العميل أن **يستمر في تنفيذ مهمته الأساسية**، ولا يوقف العمل بسبب الملاحظة إلا إذا كان الخلل مؤثراً على:
+
+- سلامة القرار
+- جودة التنفيذ
+
+في هذه الحالة، على العميل إيقاف العمل مؤقتاً، إبلاغ Majed، وانتظار التوجيه.
+
+---
+
+## 6. العلاقة مع بقية المنظومة
+
+| الملف/الآلية | العلاقة بهذه السياسة |
+|--------------|----------------------|
+| `project-control/AGENT_GAPS_LOG.md` | الوجهة الرسمية لتسجيل الملاحظات |
+| `TeraSystemEvolutionAgent` | المسؤول عن مراجعة ومعالجة الإدخالات في AGENT_GAPS_LOG.md |
+| `TeraPreExecutionGate.md` §2.5 | التذكير التشغيلي بقراءة هذه السياسة قبل التنفيذ |
+| `TeraPolicyMap.md` | يوثق هذه السياسة كمصدر حقيقة رسمي |
+| `tera-system/AIS_PROTOCOL.md` | بروتوكول AIS — آلية تسجيل وتحسين استباقية (مكملة لـ GAPS) |
+| `project-control/AGENT_IMPROVEMENT_SUGGESTIONS.md` | السجل المركزي لاقتراحات AIS |
+| `TeraSystemEvolutionAgent` | المسؤول أيضاً عن معالجة اقتراحات AIS (مراجعة، تصنيف، تحويل لـ SCP) |
+
+---
+
+## 7. أحكام ختامية
+
+- هذه السياسة تخضع لنفس قواعد التطوير: أي تعديل عليها يحتاج `SYSTEM_CHANGE_PROPOSAL` وموافقة Majed.
+- لا يجوز لأي عميل تعديل هذه السياسة أو استخدامها كمبرر لتعديل صلاحياته دون المرور بـ `TeraSystemEvolutionAgent`.
+- هذه السياسة دائمة — وليست إعلاناً مؤقتاً.
+
+---
+
+> *"المنظومة تتحسن فقط عندما يلاحظ من يعمل فيها ما يحتاج تحسيناً."*

package/core/tera-system/TERA_DISTRIBUTION_POLICY.md

@@ -0,0 +1,291 @@
+<!-- © 2026 Majed Khaireddin (Alabasi1980). Tera System — Proprietary. All rights reserved. -->
+
+# TERA Distribution Policy — سياسة توزيع Tera على مستودعات العملاء
+
+## 1. الغرض
+
+تُعرّف هذه السياسة **الطريقة الرسمية** لتوزيع منظومة Tera (الملفات المُدارة تابعاً لـ Tera) على مستودعات العملاء، وترقية هذه المستودعات، وضمان:
+- تثبيت إصدار معروف (Version Pinning) — لا نسخ متفرقة ولا تتبع تلقائي للفروع
+- تحقق من سلامة الملفات (SHA256) قبل كل تثبيت
+- فصل ملكية واضح بين ملفات Tera وملفات العميل
+- مسار ترقية واسترجاع آمنين بأمر واحد
+
+> **مصدر الحقيقة:** هذه السياسة هي المرجع الوحيد لآلية التوزيع. الخرائط (Policy Map / Architecture Map) تشير إليها فقط.
+> **المصدر:** SCP-2026-08-15-009 — موافق عليه 2026-08-15 (تحديث SCP-007/SCP-008).
+
+---
+
+## 2. نموذج التوزيع
+
+```text
+TeraSystem الرئيسي (المستودع الأصلي — RepositoryUrl)
+  │  إصدار رسمي عبر Tag (tera-vX.Y.Z)
+  ▼
+tera-fetch.ps1 ← جلب من المستودع الأصلي (HTTPS/SSH موثق) + بناء حزمة متحققة
+  ▼
+Release Package (ملفات Tera-managed + SHA256SUMS + TERA_RELEASE_MANIFEST.json)
+  │
+  ▼
+تثبيت/ترقية آلي عبر tera-update.ps1 (-SourcePath أو -RepositoryUrl)
+  ▼
+مستودع عميل (Client repository)
+  ├── .opencode/        ← Tera-managed
+  ├── tera-system/      ← Tera-managed
+  ├── tera-workshop/    ← Tera-managed (اختياري للتوزيع)
+  ├── .tera/lock.json   ← Tera-managed (ملف القفل)
+  ├── .tera/backups/    ← نسخ استرجاع محلية غير موزعة
+  ├── project-control/  ← Client-owned
+  ├── project-preparation/ ← Client-owned
+  ├── project-inputs/   ← Client-owned
+  └── clients/ + كود التطبيق ← Client-owned
+```
+
+### 2.0 الاستمداد من المستودع الأصلي (نموذج الأصالة — الخيار ب)
+
+- **مرساة الثقة:** المستودع الأصلي الخاص (HTTPS/SSH موثق) هو المصدر الوحيد المعتمد للإصدارات.
+- **القناة:** HTTPS موثوق أو SSH — مصادقة على مستوى git؛ لا تتبع تلقائي لأي فرع.
+- **التثبيت:** الـ Lockfile يحفظ **Commit SHA كامل** للـ Tag — التحقق النهائي هو SHA، لا اسم الفرع.
+- **tera-fetch.ps1** يجلب الـ Tag من `RepositoryUrl` ويبني حزمة متحققة (Manifest + SHA256SUMS) قبل أي تثبيت.
+- **رفض الانتحال:** استبدال حزمة كاملة (ملفات + SUMS) لا يكفي — الـ Commit SHA في الـ Lockfile يجب أن يطابق Manifest المُجرى من الأصل.
+- لا توقيع GPG إلزامي حالياً (القرار ب)؛ يُعاد النظر عند فتح التوزيع العام خارج المستودع الخاص.
+
+### 2.1 قواعد الإصدار
+
+| القاعدة | الوصف |
+|---|---|
+| الترويس | كل إصدار رسمي = `git tag tera-vX.Y.Z` (مثلاً `tera-v2.5.0`) |
+| مرجع الإصدار | الـ Lockfile يحفظ **Commit SHA كامل** + Tag + Version — SHA هو الحقيقة، وليس الفرع |
+| القنوات | `stable` (افتراضي) / `beta` (اختياري) — تُسجَّل في الـ Lockfile |
+| التثبيت | كل عميل يُثبَّت على Tag محدد بوعي؛ عميل يبقى على `tera-v2.0.0` وآخر ينتقل لـ `tera-v2.5.0` |
+| المنع المطلق | **لا تتبع تلقائي لـ `main` أو `develop` في أي مستودع عميل** |
+
+### 2.2 Lockfile — `.tera/lock.json`
+
+في جذر كل مستودع عميل:
+
+```json
+{
+  "version": "2.5.0",
+  "tag": "tera-v2.5.0",
+  "commit": "FULL_COMMIT_SHA",
+  "channel": "stable",
+  "files": [
+    ".opencode/agents/example.md",
+    "tera-system/example.md",
+    "tera-workshop/example.ps1"
+  ]
+}
+```
+
+- **version:** رقم الإصدار (بدون بادئة tera-)
+- **tag:** الـ Tag الرسمي
+- **commit:** SHA الكامل للمرجع — هو مؤشر الحقيقة
+- **channel:** stable أو beta
+- **files:** قائمة الملفات المُدارة في الإصدار؛ تُستخدم لاكتشاف الملفات المحذوفة في الترقية
+
+عند غياب `lock.json` أو تلفه → **يتوقف التحديث**؛ التثبيت الأول وحده يُسمح به مع `-Initialize` صريح. لا يُفترض أي إصدار افتراضي.
+
+---
+
+## 3. عقد الملكية (Ownership Contract)
+
+| المسار داخل مستودع العميل | الملكية | التعامل |
+|---|---|---|
+| `.opencode/` | **Tera** | يستبدله المُحدِّث عند الترقية |
+| `tera-system/` | **Tera** | يستبدله المُحدِّث عند الترقية |
+| `tera-workshop/` (اختياري في التوزيع) | **Tera** | يُوزَّع فقط إذا كانت الحزمة تشمله |
+| `.tera/lock.json` | **Tera** | يكتبه المُحدِّث تلقائياً |
+| `.tera/backups/` | **Tera updater** | نسخ استرجاع محلية؛ لا تُضمَّن في الحزمة ولا في commit |
+| `project-control/` | العميل | لا يلمسه المُحدِّث أبداً |
+| `project-preparation/` | العميل | لا يلمسه المُحدِّث أبداً |
+| `project-inputs/` | العميل | لا يلمسه المُحدِّث أبداً |
+| `clients/`, كود التطبيق | العميل | لا يلمسه المُحدِّث أبداً |
+
+### 3.1 قواعد صارمة
+
+1. **المُحدِّث يرفض** أي استبدال لملف Tera-managed عُدّله العميل محلياً → يُبلَّغ بالتعارض ولا يُستبدل.
+2. **ممنوع** تعديل ملفات Tera-managed يدوياً داخل مستودع العميل. أي تحسين عام يبدأ من مستودع Tera الرئيسي ثم يُصدَّر كنسخة جديدة.
+3. حذف أي مجلد Tera-managed من مستودع العميل (مثل حذف `tera-system/`) يُعد تعديلاً محلياً → يمنع التحديث حتى يُعاد.
+
+---
+
+## 4. أدوات التوزيع
+
+| الأداة | المسار | الوظيفة |
+|---|---|---|
+| `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 |
+
+### 4.1 tera-fetch.ps1 — الجلب من المستودع الأصلي
+
+```powershell
+# عرض الإصدارات المتاحة في المستودع الأصلي
+pwsh .\tera-workshop\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 .\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"
+```
+
+**وضع Check:** يقارن الإصدار المثبت في `lock.json` بأحدث إصدار في الأصل، ويخبرك بما يلي:
+- أنت على أحدث إصدار ✅
+- يوجد إصدار أحدث + أمر الترقية الجاهز
+- لا تثبيت مسبق + أمر التثبيت الأول
+
+لا يُنشئ Check أي تعديل — قراءة فقط.
+
+### 4.1b الإشعار التلقائي — tera-watch.ps1 + tera-schedule.ps1
+
+تسجيل الإشعار التلقائي مرة واحدة لكل مستودع عميل:
+
+```powershell
+# تسجيل مهمة Windows Task Scheduler (عند تسجيل الدخول + كل 6 ساعات)
+pwsh .\tera-workshop\tools\tera-schedule.ps1 `
+  -RepositoryUrl "https://github.com/Alabasi1980/TeraSystem.git" `
+  -RepoPath "D:\My Projects\TeraWebsite"
+
+# إزالة المهمة
+pwsh .\tera-workshop\tools\tera-schedule.ps1 -Unregister
+```
+
+السلوك:
+- عند وجود إصدار أحدث → **Windows Toast** أصلي يظهر على سطح المكتب + ملف `.tera/update-status.json` يُحدَّث.
+- ملف الحالة قابل للقراءة من أي جلسة (بما فيها OpenCode) لمعرفة `updateAvailable`.
+- تشغيل يدوي لمرة واحدة: `pwsh .\tera-workshop\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 .\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"
+```
+
+### 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"
+```
+
+ينشئ الأمر حزمة مجلدية متحققة تحتوي على `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 .\tera-workshop\tools\tera-update.ps1 -Version tera-v2.5.0 -Channel stable -Mode Apply -Initialize -SourcePath "C:\TeraReleases\tera-v2.5.0"
+```
+
+### 4.4 سلوك المُحدِّث (سلسلة تحقق إلزامية)
+
+```text
+1. قراءة Manifest وSHA256SUMS — غيابهما أو نقصهما = إيقاف
+2. مطابقة version/tag/commit/channel والتحقق من كل hash قبل أي نسخ
+3. فحص lock.json؛ التالف/الناقص = إيقاف، والتثبيت الأول يحتاج -Initialize
+4. فرض Git وفحص التعديلات المحلية على ملفات Tera-managed
+5. منع المسارات المطلقة و.. وأي ملف خارج Tera-managed roots
+6. منع الكتابة عبر أي Reparse Point (symlink/junction) في مسار الوجهة
+7. مع -Initialize: رفض أي ملف/مجلد غير متتبع يتعارض مع ملفات الحزمة
+8. الفرق بين الحزمة والحالي → (جديد/مستبدل/كما هو/محذوف)
+9. [Plan] تقرير فقط — لا كتابة
+10. [Apply] backup → نسخ/حذف مضبوط → تحديث lock.json → staged diff check → commit
+11. عند الفشل: استرجاع من backup وتقرير واضح
+```
+
+### 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 .\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"
+```
+
+- يقبل ملف قائمة مستودعات (سطر لكل مسار) أو JSON بالشكل `{ "repositories": ["..."] }`
+- يستخدم SourcePath أو RepositoryUrl واحداً متحققاً لكل المستودعات
+- كل مستودع يستقبل Plan أولاً؛ فشل أي Plan يمنع كل Apply
+- Apply الدفعي ليس ذرّياً بين المستودعات؛ يُسجّل نجاح/فشل كل مستودع منفرداً
+
+---
+
+## 5. قائمة الإصدار الرسمي (Release Checklist)
+
+تُنفَّذ في مستودع Tera الرئيسي قبل نشر أي إصدار:
+
+```text
+1. التحقق أن SHA256SUMS ومحتوى الحزمة مطابقان للمرجع
+2. إنشاء Tag: git tag tera-vX.Y.Z (بدون رسالة عشوائية) ثم دفعه للمستودع الأصلي
+3. بناء الحزمة: tera-release.ps1 من الـ Tag (ملفات Tera-managed فقط)
+4. التحقق اليدوي: تثبيت تجريبي على مستودع وهمي (Plan ثم Apply)
+5. النشر ثم التسجيل في SYSTEM_EVOLUTION_LOG.md
+```
+
+**حماية الإصدار:** لا يُنشر Tag إلا بعد نجاح خطوة 5 (تثبيت تجريبي) — منع إصدار "مكسور" ينتشر للعملاء.
+
+---
+
+## 6. الترقية والاسترجاع
+
+### الترقية
+```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 .\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"
+```
+
+### الاسترجاع (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"
+```
+- الاسترجاع = تحديث إلى SHA سابق — نفس الآلية، بلا "مسار خاص"
+- ملفات العميل لا تتأثر إطلاقاً
+
+---
+
+## 7. العلاقة مع بقية المنظومة
+
+| الملف | العلاقة |
+|---|---|
+| `tera-system/TeraPolicyMap.md` | يوثّق هذه السياسة كمصدر حقيقة لموضوع التوزيع |
+| `tera-system/TeraArchitectureMap.md` | يوضّح طبقة التوزيع ودور `tera-workshop/tools/` |
+| `project-control/SYSTEM_EVOLUTION_LOG.md` | يسجّل كل إصدار/ترقية منفذة |
+| `tera-system/TOOLING_AND_MCP_POLICY.md` | السياسة الحاكمة للأدوات — المُحدِّث أداة رسمية ضمن `tera-workshop/tools/` |
+| `.gitattributes` | `cr-at-eol` — أساس سلامة `git diff --check` عند التحديث |
+
+---
+
+## 8. الحوكمة
+
+- تعديل هذه السياسة يحتاج `SYSTEM_CHANGE_PROPOSAL` وموافقة Majed.
+- تجاوز أي بوابة (SHA، التعارض المحلي، قائمة الإصدار) **ممنوع** حتى بأمر تنفيذي.
+- هذه السياسة دائمة — وليست إعلاناً مؤقتاً.
+
+---
+
+## 9. سجل الإصدارات (Release History)
+
+| الإصدار | التاريخ | القناة | أبرز المحتوى |
+|---|---|---|---|
+| `tera-v1.0.0` | 2026-08-15 | stable | أول إصدار رسمي موثق: آلية توزيع كاملة (release/fetch/update/batch)، تنظيف شامل، وإصلاحات Pilot (gitattributes، commit detection) |
+
+---
+
+> *"التوزيع بلا ترويس فوضى. الترويس بلا تحقق انتحال. التحقق بلا استرجاع رهان."*