mirror of
https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools.git
synced 2026-06-18 07:19:35 +00:00
1ceeea9004
Complete Tier-1 closure follow-through by wiring docs governance gates, RC release readiness checks, source-of-truth enforcement, executive weekly contract surface, and go-live severity notes. Add full go-live revenue execution documentation set (production activation, real production playbook, trust expansion, first 3 clients, live deployment, and automated revenue engine) and register all canonical paths. Made-with: Cursor
154 lines
5.9 KiB
Markdown
154 lines
5.9 KiB
Markdown
---
|
||
version: "1.0"
|
||
owner: "Platform + Governance"
|
||
status: "canonical"
|
||
review_cadence: "مع كل توسع لمسارات external أو موصلات جديدة"
|
||
last_updated: "2026-04-16"
|
||
related:
|
||
- "governance/approval-policy.md"
|
||
- "trust/ledger-vs-tool-verification.md"
|
||
- "TIER1_PRODUCTION_ACTIVATION_PROGRAM_AR.md"
|
||
---
|
||
|
||
# Trust Expansion Plan (تغطية شاملة للثقة)
|
||
|
||
هدف البرنامج: أن تصبح المسارات الحساسة **policy-enforced** و**evidence-backed** بشكل يمكن تدقيقه، دون «تضخيم تعقيدي» يعطل التسليم.
|
||
|
||
> الأنظمة لا تفشل لغياب الذكاء فقط؛ تفشل بغياب **enforcement**، وتنفيذ ضعيف، أو ملاحظة ضعيفة. ([Seisan][2])
|
||
|
||
---
|
||
|
||
## المرحلة 1 — Endpoint Inventory
|
||
|
||
### الهدف
|
||
|
||
قائمة **شاملة** لمسارات HTTP المعروضة من التطبيق.
|
||
|
||
### أداة مقترحة (من جذر الريبو)
|
||
|
||
```bash
|
||
rg "@router\\.(get|post|put|delete|patch)" salesflow-saas/backend/app/api -n
|
||
```
|
||
|
||
(على Windows يمكن استخدام `rg` من [ripgrep](https://github.com/BurntSushi/ripgrep) أو بحث المحرّر بنفس النمط.)
|
||
|
||
### تصنيف أولي (مثال)
|
||
|
||
| النوع | معنى تشغيلي | مثال نمطي |
|
||
|--------|-------------|-----------|
|
||
| internal | قراءة/داخلية، أثر محدود | صحة، لوحات داخلية |
|
||
| external | أثر خارجي أو بيانات عميل | إرسال، توقيع، دفع |
|
||
| critical | أثر مالي/تنظيمي عالٍ | عروض حساسة، M&A عند التفعيل |
|
||
|
||
---
|
||
|
||
## المرحلة 2 — Classification (A / R / S)
|
||
|
||
لكل مسار **حساس**، عيّن وفق [`governance/approval-policy.md`](governance/approval-policy.md):
|
||
|
||
* `approval_class` (A0–A4 أو ما يعادلها في عقودكم)
|
||
* `reversibility` (R0–R3)
|
||
* `sensitivity` (S0–S3)
|
||
|
||
سجّل النتيجة في جدول (داخل الريبو أو أداة إدارة) مع **مالك** وتاريخ المراجعة.
|
||
|
||
---
|
||
|
||
## المرحلة 3 — Enforcement Layer
|
||
|
||
### مبدأ
|
||
|
||
على الحدود `external_*` (أو ما يعادلها في الكود):
|
||
|
||
* طلب موافقة / حزمة قرار حيث السياسة تقتضي.
|
||
* evidence pack حيث السياسة تقتضي.
|
||
* `correlation_id` / `trace_id` حيث السياسة تقتضي.
|
||
|
||
### في الكود اليوم
|
||
|
||
مرجع التنفيذ: [`decision_plane_contracts.py`](../salesflow-saas/backend/app/services/core_os/decision_plane_contracts.py) ومسارات [`approval_center.py`](../salesflow-saas/backend/app/api/v1/approval_center.py).
|
||
|
||
التوسيع = **تطبيق نفس الأنماط** على كل مسار صُنّف external/critical بعد المراجعة.
|
||
|
||
---
|
||
|
||
## المرحلة 4 — Tool Verification
|
||
|
||
### هدف
|
||
|
||
ربط نتيجة الأداة بما يُخزَّن في السجل/الدليل (حيث ينطبق [`trust/ledger-vs-tool-verification.md`](trust/ledger-vs-tool-verification.md)).
|
||
|
||
### حقول مفاهيمية (هدف تصميمي)
|
||
|
||
* `intended_action` / `actual_action` / `result` / `side_effects` / معرّف تكاملي (hash أو proof id) حيث تدعم المنصة.
|
||
|
||
---
|
||
|
||
## المرحلة 5 — Contradiction Engine (تغطية منطقية)
|
||
|
||
### مقارنات يجب أن تبقى قابلة للمراجعة
|
||
|
||
| المصدر | مقابل |
|
||
|--------|--------|
|
||
| memo / قرار | ما نُفِّذ فعليًا |
|
||
| نتيجة أداة | حالة DB أو سجل |
|
||
| موافقة | إجراء تم على المسار |
|
||
|
||
**API مرجعي:** `POST /api/v1/contradictions/` (مع evidence عند severity حرجة — انظر الاختبارات الحالية).
|
||
|
||
---
|
||
|
||
## المرحلة 6 — Coverage Test (هدف أتمتة)
|
||
|
||
### حالة الريبو
|
||
|
||
* اختبار شامّل باسم `test_trust_enforcement_all_routes.py` **غير موجود بعد** كـ«100% endpoints» — يُستهدف تدريجيًا (ابدأ بالمسارات `external_*` والمسار الذهبي).
|
||
|
||
### حتى ذلك الحين
|
||
|
||
* وسّع `pytest` على المسارات التي تلمس `external_*` والـ Class B (مثل [`test_proposals_saudi_send_validation.py`](../salesflow-saas/backend/tests/test_proposals_saudi_send_validation.py) و[`test_tier1_golden_path_partner.py`](../salesflow-saas/backend/tests/test_tier1_golden_path_partner.py)).
|
||
|
||
---
|
||
|
||
## المرحلة 7 — Policy Stress Test
|
||
|
||
سيناريوهات:
|
||
|
||
* محاولة override لسياسة.
|
||
* سياسة مفقودة أو role خاطئ.
|
||
* رمز منتهٍ / غير مصرّح.
|
||
|
||
المتوقع: **رفض واضح** + سجل تدقيق، لا سلوك صامت.
|
||
|
||
---
|
||
|
||
## المرحلة 8 — Audit Proof
|
||
|
||
لكل إجراء حرج يجب أن يبقى أثر يمكن تسليمه للتدقيق:
|
||
|
||
* سجل موافقة.
|
||
* evidence pack (أو مرجع pack id).
|
||
* trace / correlation.
|
||
* إيصال أداة حيث ينطبق.
|
||
|
||
---
|
||
|
||
## الخلاصة التنفيذية
|
||
|
||
هذا التوسع يكمّل قوائم جاهزية الإنتاج القياسية (اختبار، أمن، تدرج، استرجاع) عندما تُطبَّق على **حدود الثقة** لا على الواجهات فقط. ([TechTarget][1])
|
||
|
||
1. Golden path run (حسب الـ runbook).
|
||
2. Chaos على الحالات الحرجة.
|
||
3. Executive validation.
|
||
4. توسع Trust مسارًا مسارًا (جدول + A/R/S + enforcement).
|
||
5. Canary ثم full rollout مع rollback جاهز.
|
||
|
||
**توسيع لاحق (اختياري):** أتمتة PR (رفض تلقائي عند مخالفة governance)، أو **Full Backend Hardening** (DB، تخزين مؤقت، طوابير، توسع أفقي) — يُفضّل مشروع منفصل بحدود زمنية ونطاق واضحين.
|
||
|
||
---
|
||
|
||
## المراجع
|
||
|
||
[1]: https://www.techtarget.com/searchsoftwarequality/tip/A-production-readiness-checklist-for-software-development "A production readiness checklist for software development | TechTarget"
|
||
[2]: https://seisan.com/enterprise-app-readiness/ "Enterprise App Readiness | Seisan"
|