system-prompts-and-models-of-ai-tools/docs/TIER1_TRUST_EXPANSION_PLAN_AR.md

version	owner	status	review_cadence	last_updated	related
1.0	Platform + Governance	canonical	مع كل توسع لمسارات external أو موصلات جديدة	2026-04-16	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)

---

المرحلة 1 — Endpoint Inventory

الهدف

قائمة شاملة لمسارات HTTP المعروضة من التطبيق.

أداة مقترحة (من جذر الريبو)

rg "@router\\.(get|post|put|delete|patch)" salesflow-saas/backend/app/api -n

(على Windows يمكن استخدام rg من ripgrep أو بحث المحرّر بنفس النمط.)

تصنيف أولي (مثال)

النوع	معنى تشغيلي	مثال نمطي
internal	قراءة/داخلية، أثر محدود	صحة، لوحات داخلية
external	أثر خارجي أو بيانات عميل	إرسال، توقيع، دفع
critical	أثر مالي/تنظيمي عالٍ	عروض حساسة، M&A عند التفعيل

---

المرحلة 2 — Classification (A / R / S)

لكل مسار حساس، عيّن وفق 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 ومسارات approval_center.py.

التوسيع = تطبيق نفس الأنماط على كل مسار صُنّف external/critical بعد المراجعة.

---

المرحلة 4 — Tool Verification

هدف

ربط نتيجة الأداة بما يُخزَّن في السجل/الدليل (حيث ينطبق 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 وtest_tier1_golden_path_partner.py).

---

المرحلة 7 — Policy Stress Test

سيناريوهات:

• محاولة override لسياسة.
• سياسة مفقودة أو role خاطئ.
• رمز منتهٍ / غير مصرّح.

المتوقع: رفض واضح + سجل تدقيق، لا سلوك صامت.

---

المرحلة 8 — Audit Proof

لكل إجراء حرج يجب أن يبقى أثر يمكن تسليمه للتدقيق:

• سجل موافقة.
• evidence pack (أو مرجع pack id).
• trace / correlation.
• إيصال أداة حيث ينطبق.

---

الخلاصة التنفيذية

هذا التوسع يكمّل قوائم جاهزية الإنتاج القياسية (اختبار، أمن، تدرج، استرجاع) عندما تُطبَّق على حدود الثقة لا على الواجهات فقط. (TechTarget)

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، تخزين مؤقت، طوابير، توسع أفقي) — يُفضّل مشروع منفصل بحدود زمنية ونطاق واضحين.

---

المراجع