عقد دمج بوابة القرار مع النواة الأساسية للأصول

نظرة عامة

هذا المستند هو العقد القياسي الجاهز للتنفيذ لدمج Decision Gate (DG) مع Asset Core (ASC). يحدد الحدود والسلطة ودلالات الأدلة اللازمة للحفاظ على الاستقلالية مع تمكين التداخل عالي الثقة.

نية التصميم: يظل DG طبقة تحكم مستقلة. يظل ASC ركيزة حالة عالمية مستقلة. التكامل اختياري وصريح.

الحدود غير القابلة للتفاوض

• لا ارتباط بين الأكواد: لا يرتبط DG بمكتبات ASC أو يشارك واجهات برمجة التطبيقات الداخلية.
• عدم وجود قيود على مسارات الكتابة (v1): يجب ألا يجلس DG على مسارات كتابة ASC.
• حدود الثقة المغلقة: يجب أن ترفض المساحات المفقودة أو غير المصرح بها.
• الحتمية أولاً: نفس المدخلات تؤدي إلى مخرجات متطابقة وحزم تشغيل.

سلطة النطاق

مصدر الحقيقة

• نشر متكامل: كتالوج مساحة أسماء ASC هو المرجع المعتمد.
• Standalone DG deployments: DG registry is authoritative. نشر DG المستقل: سجل DG هو السلطة المعتمدة. تم منع الإذن للمطورين عندما namespace.authority.mode = "assetcore_http".

قواعد التحقق

• DG must validate namespace_id for every namespace-scoped tool call, يجب على DG التحقق من namespace_id لكل استدعاء أداة محددة النطاق، بما في ذلك استعلامات الأدلة.
• مساحة اسم غير معروفة -> فشل مغلق.
• الكتالوج غير قابل للوصول -> فشل مغلق.

قواعد معرف الفضاء الاسمي

• DG تقبل فقط معرفات المساحة الرقمية (>= 1).
• التحقق من سلطة Asset Core مباشر؛ لا توجد جدول تحويل أو ترجمة.

مصفوفة المصادقة/RBAC

طبقة التكامل

لا يجب على DG تحليل رموز ASC أو مشاركة تفاصيل مصادقة ASC الداخلية. تتحقق طبقة التكامل الضيقة من مصادقة ASC وتقوم بإعادة توجيه سياق رئيسي الحد الأدنى:

• معرف_المستأجر
• principal_id
• الأدوار
• policy_class
• المجموعات

الوضع الافتراضي

الإعدادات الافتراضية للمصادقة محافظة: لا يوجد تأليف سيناريوهات أو كتابة في السجل ما لم يتم منحها صراحة في مصفوفة التعيين.

مصفوفة التعيين (افتراضي)

طبقة التكامل تقوم بربط أدوار ASC + فئة السياسة في قائمة السماح لأداة DG. هذا الربط هو فشل مغلق: الأدوار المفقودة أو غير المعروفة لا تمنح أي وصول.

مجموعات أدوات DG (مرجع):

• التأليف: scenario_define, schemas_register
• Run operations: scenario_start, scenario_trigger, scenario_next, تشغيل العمليات: scenario_start, scenario_trigger, scenario_next, scenario_submit, precheck
• Read-only: scenario_status, scenarios_list, schemas_list, schemas_get, providers_list, provider_contract_get, للقراءة فقط: scenario_status, scenarios_list, schemas_list, schemas_get, providers_list, provider_contract_get, provider_check_schema_get, evidence_query, decision_gate_docs_search
• تدقيق: runpack_export, runpack_verify

تعيين افتراضي (موصى به):

دور ASC	قيود فئة السياسة	مجموعات أدوات DG
TenantAdmin	لا شيء	تأليف + تنفيذ العمليات + قراءة فقط + تدقيق
NamespaceOwner	لا شيء	تأليف + تنفيذ العمليات + قراءة فقط + تدقيق
NamespaceAdmin	لا شيء	تأليف + تنفيذ العمليات + قراءة فقط + تدقيق
NamespaceWriter	لا شيء	تنفيذ العمليات + قراءة فقط + تدقيق (للتحقق فقط)
NamespaceReader	لا شيء	قراءة فقط + تدقيق (للتحقق فقط)
SchemaManager	فقط سكراتش، مشروع	تأليف (المخططات فقط) + قراءة فقط
AgentSandbox	فقط سكراتش	تنفيذ العمليات + قراءة فقط
NamespaceDeleteAdmin	لا شيء	قراءة فقط

تنفيذ فئة السياسة:

• If policy_class is prod, SchemaManager and AgentSandbox do not إذا كانت policy_class هي prod، فإن SchemaManager و AgentSandbox لا تمنح أي أذونات DG (حيث أن ASC قد قيدت هذه الأدوار بالفعل).
• غير معروف أو مفقود policy_class -> رفض.

ملاحظة التدقيق: runpack_verify آمن للسماح به بشكل واسع؛ يجب تقييد runpack_export لأدوار المسؤول/المالك ما لم يتم منحه بشكل صريح.

قائمة التحكم في الوصول للسجل (DG الداخلي)

يتم فرض الوصول إلى سجل المخطط بواسطة طبقة ACL داخلية في DG تعمل بعد قائمة الأدوات المسموح بها في طبقة التكامل. هذا منفصل عن عمد:

• تعيين RBAC (التكامل) يحدد الأدوات التي يمكن استدعاؤها.
• Registry ACL (DG) decides who may schemas_register/list/get per قائمة التحكم في الوصول للسجل (DG) تحدد من يمكنه schemas_register/list/get لكل مستأجر/مساحة اسم، باستخدام المبادئ وبيانات تعريف فئة السياسة.

الإعدادات الافتراضية لـ ACL المدمجة:

• اقرأ: NamespaceReader+ ضمن مساحة الأسماء.
• اكتب: NamespaceAdmin/TenantAdmin فقط.
• يمكن لـ SchemaManager الكتابة فقط عندما يكون policy_class غير إنتاجي.

يجب ألا تفترض تنفيذات التكامل أن قوائم الأدوات المسموح بها تعني إذن كتابة السجل؛ يجب أن تسمح كلا الطبقتين بالعملية.

دلائل الأدلة (ASC Canon)

يجب أن تتضمن جميع الأدلة المدعومة من ASC المرتكزات التالية:

• assetcore.namespace_id
• assetcore.commit_id
• assetcore.world_seq

ترقية اختيارية للمرساة:

• assetcore.chain_hash (عندما يقوم ASC بتمكين تجزئة السلسلة)

يجب التقاط هذه المراسي في حزم التشغيل واستخدامها في التحقق غير المتصل.

عقد مزود الأدلة

المدخلات المطلوبة

• namespace_id (DG)
• معرف مساحة الاسم (مُعَدل أو عددي)
• تحقق من المعلمات (container_id، class_id، إلخ)

المخرجات المطلوبة

• قيمة الدليل أو الهاش
• تجزئة الدليل (JSON القياسي)
• مرساة الأدلة (مرساة ASC المحددة أعلاه)
• نوع المحتوى
• فئة الحتمية (يجب أن تكون حتمية لقراءات ASC)

الحدود والإخفاقات

• مهلات صارمة؛ إعادة المحاولة فقط في حالة حدوث أخطاء في النقل.
• مهلة أو خطأ في المزود -> غير معروف (فشل مغلق).

معرفات الترابط

متطلبات شاملة

• يجب على DG تمرير معرف ارتباط العميل إلى استفسارات أدلة ASC.
• يجب على DG إصدار معرفات ارتباط الخادم في سجلات التدقيق و runpacks.
• يتم تسجيل معرفات الترابط وتوثيقها في نصوص الأدوات.

التطهير

معرفات الترابط المقدمة من العميل تعتبر غير آمنة ويتم التحقق منها بدقة عند الدخول. يتم رفض القيم غير الصالحة؛ فقط المعرفات المعقمة تنتقل إلى مزودي ASC. معرفات الترابط الصادرة من الخادم موجودة دائمًا لأغراض تدقيق السجلات.

التحقق من تشغيل الحزمة

يجب أن تؤكد عملية التحقق من Runpack:

• جميع إدخالات أدلة ASC تتضمن المراسي المطلوبة.
• قيم المراسي مُشكلة بشكل جيد وتطابق المخطط المتوقع.
• assetcore.chain_hash الاختياري موجود عند تكوينه كشرط مطلوب.

خارج النطاق (v1)

• التحكم في مسار الكتابة لـ ASC بواسطة DG.
• إنشاء مساحة اسم ASC من DG.
• تغيير حالة ASC عبر بوابة القرار.