مصطلحات بوابة القرار

تعريفات قصيرة وقانونية لمصطلحات بوابة القرار.

Condition

عقدة ورقة في شجرة المتطلبات تشير إلى condition_id المحدد في ScenarioSpec. عند تقييمها، تبحث عن ConditionSpec، تستعلم عن فحص مزود الأدلة، تطبق المقارن، وتعيد نتيجة ثلاثية الحالة. يجب أن تكون معرفات الحالة مستقرة ووصفية (مثل ‘env_is_prod’، ‘after_freeze’).

ConditionSpec

يربط condition_id باستعلام الأدلة، والمقارن، والقيمة المتوقعة. يتم الإشارة إلى condition_id من قبل أوراق المتطلبات. عند التقييم، يقوم وقت التشغيل باستعلام المزود باستخدام EvidenceQuery (provider_id + check_id + params)، ويطبق المقارن على الأدلة، ويعيد true/false/unknown. يؤدي عدم وجود المتوقع (باستثناء exists/not_exists) إلى الحصول على unknown.

EvidenceAnchor

بيانات التعريف التي تربط الأدلة بمصدرها للتحقق غير المتصل. تحتوي على anchor_type و anchor_value المحددين من قبل المزود (مثل ‘receipt_id’، ‘log_offset’). تتيح المراسي مسارات التدقيق: عند وجود مرساة، يمكنك إعادة استعلام المزود (إذا كان لا يزال متاحًا) أو التحقق من اللقطات المؤرشفة. يتم تضمين المراسي في حزم التشغيل.

EvidenceContext

تم تمرير سياق وقت التشغيل إلى مزودي الأدلة أثناء الاستعلامات. يتضمن tenant_id و run_id و scenario_id و stage_id و trigger_id و trigger_time و correlation_id الاختياري لارتباط التدقيق. السياق هو بيانات وصفية فقط ولا يغير منطق الشرط.

EvidenceQuery

تم إرسال الطلب إلى مزود الأدلة. يحتوي على provider_id (أي مزود يجب الاستفسار عنه)، check_id (أي فحص لمزود يجب تنفيذه)، وparams (معاملات محددة للمزود). الاستعلام حتمي: نفس الاستعلام دائمًا يعيد نفس النتيجة عند وجود نفس الحالة الخارجية. يتم تسجيل الاستعلامات لأغراض التدقيق.

EvidenceRef

مرجع URI غير شفاف يشير إلى محتوى الأدلة المخزنة خارج وقت التشغيل. يسجل وقت التشغيل المرجع ولكنه لا يسترجعه أو يحله؛ يمكن للمراجعين الخارجيين استخدام URI لاسترجاع الأدلة حسب الحاجة.

EvidenceResult

استجابة من مزود الأدلة. تحتوي على قيمة الدليل (أو هاشه إذا تم حظر الكشف الخام)، evidence_hash من أجل النزاهة، رابط مرجعي للمصدر، وبيانات تعريف توقيع اختيارية. تقوم المقارنات بالتقييم بناءً على حقل القيمة. يتم التقاط النتائج في حزم التشغيل لإعادة التشغيل.

EvidenceValue

حمولة الأدلة الفعلية التي يعيدها المزود. يمكن أن تكون JSON (كائنات، مصفوفات، سلاسل نصية، أرقام، قيم منطقية، null) أو بايتات خام. يقوم المقارن بتفسير نوع القيمة: تتطلب المقارنات الرقمية أرقامًا، بينما تتطلب in_set أن تكون القيمة المتوقعة مصفوفة. تؤدي عدم تطابق الأنواع إلى نتائج غير معروفة.

GateOutcome

نتيجة الثلاث حالات لتقييم بوابة: صحيحة، خاطئة، أو غير معروفة. تعني “صحيحة” أن المتطلب قد تم تلبيته. تعني “خاطئة” أن الأدلة تتعارض مع المتطلب. تعني “غير معروفة” أن الأدلة مفقودة، أو أن المقارن لا يمكنه التقييم (عدم تطابق النوع)، أو أن المزود قد فشل. يمكن أن يتفرع التوجيه بناءً على أي نتيجة؛ فقط “صحيحة” تتقدم بالمراحل الخطية/الثابتة.

GateSpec

يحدد بوابة واحدة داخل مرحلة. تحتوي كل بوابة على معرف بوابة (gate_id) وشجرة متطلبات (تعبير RET). تمر البوابة فقط عندما يتم تقييم متطلباتها على أنه صحيح وفقًا لمنطق كليين الثلاثي. تفشل البوابات في حالة الإغلاق: الكاذب أو المجهول يمنع التقدم. يتم تقييم عدة بوابات في مرحلة معًا.

Provider

مصدر الأدلة (خادم MCP مدمج أو خارجي) الذي يجيب على فحوصات EvidenceQuery. يتم تكوين المزودين في decision-gate.toml ويتم اكتشافهم عبر عقود MCP.

RET

شجرة تقييم المتطلبات. جبر بولياني على نتائج ثلاثية الحالة يتكون من عقد And و Or و Not و RequireGroup و Condition. تجعل شجرات تقييم المتطلبات منطق البوابة واضحًا وقابلًا للتدقيق.

RequireGroup

مشغل نصاب N-of-M في شجرة المتطلبات. يحدد الحد الأدنى (min) من متطلبات الأطفال التي يجب أن تمر. يستخدم منطق ثلاثي الحالة: يُرجع true عندما يكون هناك على الأقل min من الأطفال صحيحين؛ يُرجع false عندما لا يمكن حتى لجميع المجهولين أن يصبحوا صحيحين الوصول إلى min؛ وإلا يُرجع unknown. يُستخدم للموافقة متعددة الأطراف، توقيعات العتبة، أو الفحوصات الزائدة.

Requirement

شجرة تقييم المتطلبات (RET) هي جبر بولي على نتائج ثلاثية الحالة. تتكون من عقد And و Or و Not و RequireGroup و Condition في شكل شجرة. يستخدم التقييم منطق كليين القوي: الخطأ يهيمن على And، والصحيح يهيمن على Or، والمجهول ينتشر. تمر البوابات فقط عندما يتم تقييم الجذر إلى صحيح. تجعل RETs منطق البوابة واضحًا وقابلًا للتدقيق وإعادة التشغيل.

سيناريوسبك

المواصفات الكاملة لعملية اتخاذ قرار حتمية. تحتوي على قائمة مرتبة من المراحل، وتعريفات الشروط، وسياسات/مخططات اختيارية. إن ScenarioSpec غير قابلة للتغيير بمجرد تسجيلها: يتم تجزئة شكلها القياسي بصيغة JSON لإنتاج spec_hash. نفس المواصفة + نفس الأدلة = نفس القرارات، دائمًا.

TimeoutPolicy

سياسة التحكم فيما يحدث عندما تنتهي مهلة مرحلة. الخيارات: ‘فشل’ تشير إلى أن التشغيل قد فشل بسبب انتهاء المهلة؛ ‘التقدم مع العلم’ يتقدم ويحدد علم انتهاء مهلة القرار؛ ‘فرع بديل’ يوجه باستخدام نتائج غير معروفة في قواعد الفروع. اختر بناءً على أهمية سير العمل واحتياجات التوجيه.

TriState

نتيجة تقييم الحالة الثلاثية: صحيحة، خاطئة، أو غير معروفة. تُستخدم بواسطة المقارنات وتقييم RET لتمثيل الأدلة المفقودة أو عدم تطابق النوع دون إيجاد إيجابيات كاذبة.

advance_to

السياسة التي تتحكم في كيفية تقدم التشغيل من المرحلة الحالية. أربعة أوضاع: ‘linear’ تتقدم إلى المرحلة التالية بالترتيب؛ ‘fixed’ تقفز إلى مرحلة مسماة؛ ‘branch’ توجه بناءً على نتائج البوابة (true/false/unknown كل منها يطابق next_stage_id)؛ ‘terminal’ تنهي التشغيل. وضع الفرع يمكّن سير العمل الشرطي.

allow_default

يسمح باستخدام مساحة الأسماء ‘default’ حرفياً (اختياري). يتطلب namespace.default_tenants. يجب أن تستخدم عمليات النشر في الإنتاج مساحات أسماء محددة لتجنب تصادمات بين المستأجرين.

allow_http

إعداد لكل مزود يسمح بروابط http:// لمزود الأدلة HTTP. الإعداد الافتراضي هو غير مفعل (HTTPS فقط). قم بتمكينه لنقاط الصحة الداخلية التي تفتقر إلى TLS. يفضل استخدام HTTPS لأي خدمات يمكن الوصول إليها عبر الشبكة.

allowinsecurehttp

يتيح استخدام عناوين URL http:// (غير TLS) لمزودي MCP على مستوى العالم. يجب تعطيله في الإنتاج. استخدمه فقط للتطوير المحلي أو الشبكات المعزولة. حركة مرور HTTP غير مشفرة وعرضة للاعتراض.

allow_logical

يسمح بتوقيتات منطقية في فحوصات الوقت بدلاً من الحاجة إلى unix_millis الحقيقي. يمكن تفعيله للاختبار والمحاكاة حيث تكون السيطرة على الوقت الحتمي مطلوبة. يجب تعطيله في الإنتاج بسبب قيود الوقت الحقيقي.

allow_raw

إعداد لكل مزود يسمح بالكشف عن الأدلة الخام. يتطلب أن تكون allow_raw_values صحيحة على مستوى عالمي. يتم تعيينه على المزودين الذين تكون أدلتهم آمنة للكشف (مثل، الطوابع الزمنية، حالة الصحة). يتم حذفه للمزودين الحساسين (الأسرار، بيانات الاعتماد).

allowrawvalues

إعداد عالمي يسمح بقيم الأدلة الخام في النتائج. عندما يكون غير صحيح، يقوم المزودون بإرجاع تجزئات بدلاً من القيم. قم بتمكينه فقط عندما تحتاج الأنظمة المستهلكة إلى محتوى الأدلة الفعلي. اجمعه مع require_provider_opt_in للتحكم المتعدد الطبقات.

allow_yaml

يسمح بتحليل YAML في مزود الأدلة JSON. YAML هو مجموعة فرعية من JSON مع بناء جملة إضافي. قم بتمكينه عندما تستخدم ملفات التكوين تنسيق YAML. قم بتعطيله للحد من استخدام JSON النقي للتحقق الأكثر صرامة.

allowed_comparators

قائمة السماح بالمقارنات الصالحة لهذا المخرج من الفحص.

allowed_hosts

قائمة السماح لأسماء المضيفين لطلبات الخروج لمزود HTTP. يُسمح فقط بعناوين URL التي تتطابق مع هذه المضيفين. يمنع SSRF: الاستعلامات إلى المضيفين غير المعتمدين تفشل مع خطأ أمني. مطلوب لمزودي HTTP في الإنتاج.

allowlist

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

anchor_types

سلاسل نوع المرساة التي قد تصدرها عملية التحقق من المزود.

audit_enabled

تمكين تسجيل تدقيق MCP المنظم. عندما يكون غير صحيح، يتم تجاهل أحداث التدقيق. الافتراضي هو صحيح للحفاظ على أدلة الأمان والامتثال.

audit_path

مسار نظام الملفات لسجلات تدقيق MCP (خطوط JSON). عند عدم تعيينه، تُكتب أحداث التدقيق إلى stderr.

bind

عنوان خادم MCP الذي يتم الربط به لنقل HTTP أو SSE. التنسيق: ‘host:port’ (على سبيل المثال، ‘127.0.0.1:8080’، ‘0.0.0.0:9000’). مطلوب عندما يكون نقل الخادم http/sse. استبعد عند استخدام stdio.

capabilities_path

مسار نظام الملفات إلى عقد مزود JSON (عقد القدرة). يعلن العقد عن الفحوصات المدعومة، ومخططات المعلمات، وتوافق المقارنات. يتحقق وقت التشغيل من الاستعلامات مقابل العقد قبل الإرسال. وزع العقود جنبًا إلى جنب مع ثنائيات المزود.

check_id

معرف فحص المزود للتقييم داخل مزود. كل مزود يكشف عن فحوصات مسماة (مثل ‘get’ للبيئة، ‘after’ للوقت، ‘status’ لـ http). يحدد check_id ما يعيده المزود وما المعلمات التي يقبلها. راجع providers.json للحصول على الكتالوج الكامل للفحوصات لكل مزود.

checks

قائمة الفحوصات المقدمة من خلال عقد المزود.

المقارن

عامل المقارنة المطبق على الأدلة. المقارنات المدعومة: يساوي، لا يساوي، أكبر من، أكبر من أو يساوي، أقل من، أقل من أو يساوي، يحتوي على، في المجموعة، موجود، غير موجود. جميع المقارنات باستثناء موجود/غير موجود تتطلب قيمة متوقعة وتعيد حالة غير معروفة عند عدم تطابق النوع. تعيد المقارنات الرقمية حالة غير معروفة للأرقام غير الرقمية. يتجاهل موجود/غير موجود القيمة المتوقعة.

condition_id

معرف ثابت لحالة ضمن ScenarioSpec. يتم الإشارة إلى معرفات الحالة بواسطة أوراق المتطلبات ويجب أن تكون وصفية وثابتة (على سبيل المثال، ‘env_is_prod’).

conditions

قائمة إدخالات ConditionSpec في ScenarioSpec. كل شرط يربط فحص مزود بقواعد المقارنة والقيم المتوقعة لتقييم البوابة.

config_schema

مخطط JSON للتحقق من صحة إدخالات تكوين المزود.

contains

صحيح عندما تحتوي الأدلة (مصفوفة أو سلسلة) على القيمة المتوقعة.

content_hash

بيانات التجزئة لأي محتوى حمولة. تشمل خوارزمية التجزئة وقيمة التجزئة. تمكن من التحقق من سلامة الحزم، والتقديمات، والأدلة دون الحاجة إلى الوصول إلى المحتوى الخام. تُستخدم في جميع أنحاء runpacks.

نوع_المحتوى

نوع محتوى MIME المرتبط بقيمة دليل أو حمولة حزمة (على سبيل المثال، application/json). يُستخدم لفحوصات الكشف والتوافق.

content_types

أنواع محتوى MIME المسموح بها لقيم الأدلة أو فحوصات قواعد السياسة. تُستخدم في عقود المزودين وقواعد السياسة لتقييد تنسيقات الحمولة.

correlation_id

معرف يربط الطلبات والقرارات ذات الصلة عبر الأنظمة. قم بتمرير correlation_id مع المحفزات لتتبع تدفقات القرار من خلال السجلات، والقياسات، والخدمات الخارجية. يتم تمريره في EvidenceContext لتسجيل مزود الخدمة.

decisiongatedocs_search

يبحث في وثائق بوابة القرار للحصول على إرشادات وأفضل الممارسات. يعيد الأقسام مرتبة مع العناوين، بيانات دور المستخدم، والمتابعات المقترحة. استخدم هذا للإجابة على أسئلة المنتج أو السياسة دون مغادرة جلسة MCP.

decision_id

معرف فريد لقرار مسجل. يتم إنشاؤه عندما ينتج تقييم الزناد نتيجة ويرتبط بتسلسل القرار، trigger_id، و stage_id. تمكّن معرفات القرار من تتبع التدقيق وتصحيح الأخطاء.

deep_equals

المساواة الهيكلية العميقة لكائنات JSON والمصفوفات.

deepnotequals

عدم المساواة الهيكلية العميقة لكائنات JSON والمصفوفات.

افتراضي

يتم تطبيق تأثير السياسة الافتراضية عندما لا تتطابق أي قواعد. الافتراضي هو “رفض” لسلوك الفشل المغلق.

default_policy

سياسة الثقة الافتراضية لمزودي الأدلة. الخيارات: ‘audit’ أو ‘require_signature’ (مع قائمة المفاتيح). يمكن لمزودين فرديين تجاوز ذلك. ابدأ بـ ‘audit’ وقم بتشديد السياسة حسب الحاجة لكل مزود.

default_tenants

قائمة السماح لهويات المستأجرين المسموح لهم باستخدام مساحة الأسماء الحرفية ‘default’. مطلوبة عندما تكون allow_default صحيحة؛ القائمة الفارغة مرفوضة.

denylist

قائمة مفاتيح متغيرات البيئة التي يجب ألا يقرأها مزود البيئة أبدًا. تفشل الاستعلامات عن المفاتيح المرفوضة على الفور. استخدم قوائم الرفض للدفاع المتعدد: حظر المفاتيح الحساسة المعروفة (API_KEY، SECRET_*، إلخ) حتى لو تم الاستعلام عنها عن طريق الخطأ.

الوصف

ملخص قصير يصف سلوك المزود ونواياه.

الحتمية

تحقق من استقرار مخرجات المزود: حتمي، يعتمد على الوقت، أو خارجي.

dispatch_targets

وجهات يتم تسليم الحزم المنبعثة إليها. قم بتكوين الأهداف في run_config: agent، session، external، أو channel. تتيح الأهداف المتعددة التوزيع على أنظمة مختلفة.

effect

قواعد تأثير السياسة: ‘إذن’، ‘رفض’، أو ‘خطأ’ (فشل مغلق مع خطأ في السياسة).

المحرك

سياسة اختيار محرك الإرسال. الخيارات: ‘permit_all’، ‘deny_all’، أو ‘static’. استخدم ‘static’ لتطبيق التفويض القائم على القواعد. يمكن إضافة محركات إضافية عبر المحولات دون تغيير النواة.

entry_packets

تُصدر حزم الكشف عند دخول عملية إلى مرحلة. استخدم entry_packets لإصدار المعلومات في نقاط سير العمل المحددة: على سبيل المثال، كشف التكوين بعد الموافقة، إصدار أحداث التدقيق، أو تفعيل الأنظمة downstream. تتضمن الحزم الحمولة، schema_id، وvisibility_labels للتحكم في الوصول.

equals

صحيح عندما تتساوى الأدلة مع المتوقع (أرقام، سلاسل، قيم بوليانية، أو قيم JSON).

error_message

رسالة الخطأ للإبلاغ عنها عندما يكون التأثير ‘خطأ’. مطلوب لقواعد الخطأ.

evidence_anchor

حقل EvidenceResult يحتوي على بيانات التعريف الخاصة بالمرساة (anchor_type + anchor_value) المستخدمة لربط الأدلة بمصدرها للتحقق منها في وضع عدم الاتصال.

evidence_hash

SHA-256 هاش لقيمة دليل للتحقق من النزاهة. تم حسابه على الشكل القياسي لـ EvidenceValue. تتيح هاشات الأدلة التحقق دون الكشف عن القيم الخام: يمكن للمراجعين تأكيد تطابق الأدلة مع التوقعات حتى عندما يتم حظر الكشف عن القيم الخام.

استعلام_الأدلة

يستعلم عن مزود الأدلة مع تطبيق سياسة الإفصاح المكونة. يُرجع EvidenceResult الذي يحتوي على القيمة (أو الهاش)، بيانات التعريف الخاصة بالمرساة، والتوقيع الاختياري. استخدم هذا لتصحيح الأخطاء أو بناء بوابات مخصصة خارج تدفق السيناريو القياسي.

evidence_ref

حقل EvidenceResult يحتوي على مرجع URI خارجي لمحتوى الأدلة المخزنة خارج وقت التشغيل.

أمثلة

مثال على استدعاءات الفحص مع المعلمات والنتائج.

exists

صحيح عندما تكون قيمة الدليل موجودة. يتم تجاهل المتوقع.

المتوقع

قيمة الهدف مقارنةً بمخرجات الأدلة. يجب أن يتطابق النوع مع نوع الدليل: قيم JSON لـ equals/in_set، أرقام لـ greater_than، مصفوفات لـ in_set (يتطابق الدليل مع أي عنصر). إذا كانت القيمة المتوقعة مفقودة أو غير متطابقة، فإن المقارن يُرجع unknown (فشل مغلق). غير مطلوب لـ exists/not_exists.

forbid_labels

علامات الرؤية التي يجب ألا تكون موجودة لتطابق القاعدة.

forbidpolicytags

علامات السياسة التي يجب ألا تكون موجودة حتى يتطابق القاعدة.

نتيجة البوابة

نتيجة الثلاث حالات لتقييم بوابة: صحيحة، خاطئة، أو غير معروفة. تعني “صحيحة” أن المتطلب قد تم تلبيته. تعني “خاطئة” أن الأدلة تتعارض مع المتطلب. تعني “غير معروفة” أن الأدلة مفقودة، أو أن المقارن لا يمكنه التقييم (عدم تطابق النوع)، أو أن المزود قد فشل. يمكن أن يتفرع التوجيه بناءً على أي نتيجة؛ فقط “صحيحة” تتقدم بالمراحل الخطية/الثابتة.

gate_id

معرف لبوابة داخل مرحلة. يجب أن يكون فريدًا داخل المرحلة. يظهر في سجلات التشغيل، والقرارات، وتوجيه الفروع. استخدم أسماء وصفية تعكس ما تتحقق منه البوابة: ‘env_gate’، ‘time_gate’، ‘approval_gate’.

gates

قائمة GateSpecs التي تم تقييمها عند دخول عملية إلى مرحلة. يتم تقييم جميع البوابات معًا (دون استخدام الدائرة القصيرة). تحدد سياسة advance_to للمرحلة كيف تؤثر نتائج البوابات على التقدم. تتيح البوابات المتعددة إجراء فحوصات متوازية: على سبيل المثال، تحقق من قيود الوقت والموافقات قبل التقدم.

generated_at

تم تسجيل الطابع الزمني في بيان تشغيل الحزمة الذي يشير إلى متى تم إنشاء التصدير. يتم التعبير عنه كـ ISO 8601. مفيد لسجلات التدقيق وفحوصات الحداثة. لا يؤثر على نتيجة التحقق.

greater_than

صحيح عندما تكون الأدلة الرقمية أكبر من المتوقع.

greaterthanor_equal

صحيح عندما تكون الأدلة الرقمية أكبر من أو تساوي المتوقعة.

hash_algorithm

الخوارزمية المستخدمة لتجزئة الأدلة وقطع التشغيل. حالياً تستخدم SHA-256 حصرياً. يتم تسجيلها في البيانات الوصفية لضمان التوافق المستقبلي. لا تفترض وجود خوارزميات أخرى دون التحقق من هذا الحقل.

in_set

صحيح عندما تكون الأدلة موجودة في المصفوفة المتوقعة.

include_verification

علامة تشير إلى ما إذا كان يجب إصدار تقرير تحقق جنبًا إلى جنب مع تصدير runpack. عند تفعيلها، يقوم runpack_export أيضًا بتشغيل التحقق ويتضمن التقرير. مفيد للتحقق الفوري بعد التصدير.

issueentrypackets

علامة تتحكم فيما إذا كان scenario_start يصدر entry_packets للمرحلة الأولية. قم بتعيينها إلى false لتأجيل إصدار الحزم حتى يتم تشغيل الأول أو التالي. مفيد عندما تحتاج العمليات إلى إعداد قبل بدء الإفصاحات.

jsonpath

محدد JSONPath المستخدم من قبل مزود JSON لاستخراج القيم من الوثائق. تتبع الصياغة RFC 9535. أمثلة: ‘$.version’، ‘$.config.features[*].name’. تصبح القيمة المستخرجة دليلاً لتقييم المقارن.

less_than

صحيح عندما تكون الأدلة الرقمية أقل من المتوقع.

lessthanor_equal

صحيح عندما تكون الأدلة الرقمية أقل من أو تساوي المتوقعة.

lexgreaterthan

مقارنة السلاسل المعجمية: صحيحة عندما يتم فرز الأدلة بعد المتوقع.

lexgreaterthanorequal

مقارنة السلاسل المعجمية: صحيحة عندما يتم فرز الأدلة بعد أو تساوي المتوقع.

lexlessthan

مقارنة السلاسل المعجمية: صحيحة عندما يتم فرز الأدلة قبل المتوقع.

lexlessthanorequal

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

logprecheckpayloads

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

منطقي

قيمة الطابع الزمني المنطقي المستخدمة للترتيب الحتمي عندما يكون الوقت الحقيقي غير متاح. يتم قبول الأعداد الصحيحة المقدمة من المتصلين (>= 0) فقط عندما يكون allow_logical مفعلًا. مفيد للاختبار والمحاكاة.

manifest

بيان الحزمة الذي يحتوي على بيانات وصفية وهاش لجميع العناصر. يسرد كل ملف في الحزمة مع هاش SHA-256 الخاص به، بالإضافة إلى طابع زمني للتوليد ومرجع spec_hash. تتحقق عملية التحقق من الهاشات المحسوبة مقابل البيان لاكتشاف التلاعب أو الملفات المفقودة.

manifest_name

تجاوز اسم الملف لبيان التشغيل. الافتراضي هو ‘manifest.json’. قم بتخصيصه عند تصدير عدة حزم تشغيل إلى نفس الدليل أو عند التكامل مع أنظمة تتوقع أسماء ملفات محددة.

manifest_path

مسار ملف البيان داخل دليل runpack. يُستخدم بواسطة runpack_verify لتحديد موقع البيان. عادةً ما يكون ‘manifest.json’ في جذر runpack. يقوم المدقق بقراءة هذا الملف أولاً لاكتشاف جميع العناصر الأخرى.

maxbodybytes

حجم جسم الطلب الأقصى بالبايتات لطلبات JSON-RPC. يمنع الأحمال الزائدة من استنفاد موارد الخادم. يتم رفض الطلبات التي تتجاوز هذا الحد قبل المعالجة. قم بتكوين الإعدادات بناءً على أحجام الأحمال المتوقعة.

max_bytes

الحجم الأقصى للملف بالبايتات الذي سيقوم موفر JSON بقراءته. يمنع استنفاد الموارد بسبب الملفات الكبيرة جدًا. تفشل الاستعلامات للملفات التي تتجاوز هذا الحد مع خطأ في التحقق. قم بتحديد الحجم بشكل مناسب لملفات التكوين الخاصة بك.

maxkeybytes

الحد الأقصى لطول البايت لمفاتيح متغيرات البيئة التي يستعلم عنها مزود البيئة. يمنع استنفاد الموارد الناتج عن أسماء المفاتيح غير الطبيعية. الافتراضي هو حد معقول. الاستعلامات التي تتجاوز هذا الحد تفشل مع خطأ في التحقق من الصحة.

maxresponsebytes

أقصى حجم لجسم استجابة HTTP الذي سيقرأه مزود HTTP. يمنع استنفاد الذاكرة من الاستجابات غير المحدودة. يتم تقصير أو رفض الاستجابات التي تتجاوز هذا الحجم. الحجم للاستجابات النموذجية لفحص الصحة أو API.

maxvaluebytes

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

الوضع

وضع تشغيل الخادم: ‘صارم’ (افتراضي) أو ‘dev_permissive’ القديم. يُفضل استخدام التبديل الصريح dev.permissive. يقوم dev-permissive بتخفيف الأدلة المؤكدة فقط ولا يسمح تلقائيًا بالنطاق الافتراضي.

name

اسم المزود القابل للقراءة البشرية المعروض في الوثائق وواجهات المستخدم.

not_equals

صحيح عندما لا تساوي الأدلة المتوقع.

not_exists

صحيح عندما تكون قيمة الدليل مفقودة. يتم تجاهل المتوقع.

notes

ملاحظات اختيارية حول سلوك المزود أو الحتمية.

on_timeout

سياسة مهلة المرحلة (TimeoutPolicy). موجودة دائمًا في StageSpec وتستخدم فقط عند تعيين المهلة؛ يتم تجاهلها عندما تكون المهلة فارغة. تدعم سلوكيات ‘فشل’، ‘التقدم مع العلم’، أو ‘فرع بديل’.

output_dir

دليل حيث يقوم runpack_export بكتابة حزمة التدقيق لتخزين نظام الملفات. اختياري عند تكوين تخزين runpack المُدار. تأكد من وجود أذونات الكتابة ومساحة كافية على القرص. قد يتم الكتابة فوق الملفات الموجودة.

تجاوزات

خريطة تجاوز حتمية لقيم البيئة أثناء الاختبار. المفاتيح في التجاوزات تحل محل عمليات البحث الحقيقية في البيئة، مما يضمن أدلة قابلة للتكرار. استخدمها في CI/CD حيث تختلف البيئة عبر العدائين.

packet_id

معرف لحزمة الإفصاح. يجب أن يكون فريدًا ضمن السيناريو. يُستخدم لتتبع الانبعاثات، والتصفية حسب نوع الحزمة، والتوافق مع dispatch_targets. يُشار إليه في entry_packets وdisclosure logs.

packet_ids

معرفات الحزم المسموح بها بموجب القاعدة.

params

تمرير معلمات محددة لمزود الخدمة إلى عملية الفحص. الهيكل يختلف حسب المزود: env.get يحتاج إلى {key}، time.after يحتاج إلى {timestamp}، http.status يحتاج إلى {url}. تؤدي المعلمات المطلوبة غير الصحيحة أو المفقودة إلى فشل المزود، مما ينتج عنه نتيجة غير معروفة.

params_required

سواء كان يجب تقديم EvidenceQuery.params لهذا الفحص.

params_schema

مخطط JSON لحمولات معلمات فحص المزود.

حمولة

جسم محتوى حزمة أو تقديم أو حمولة مشغلة. مشفر كـ PacketPayload: json، bytes، أو content_ref خارجي (uri + content_hash، تشفير اختياري). يتم تجزئة الحمولة لضمان السلامة وقد يتم التحقق من صحتها وفقًا للمخطط قبل الإخراج.

permissive

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

permissiveexemptproviders

معرّفات مقدمي الخدمة المعفاة من تخفيفات الإذن التطويري (مثل مقدمي Asset Core).

permissive_scope

محدد نطاق متساهل للمطورين. حالياً ثابت على asserted_evidence_only للإصدار 1.

permissivettldays

اختياري TTL (أيام) لتحذيرات السماح بالتطوير. يستخدم mtime من الإعدادات لإصدار تحذيرات انتهاء الصلاحية عند تجاوز TTL.

permissive_warn

إصدار تحذيرات وأحداث تدقيق أمني عند تمكين أو انتهاء صلاحية dev-permissive.

policy_tags

تُطبق العلامات على العمليات، الشروط، أو الإفصاحات لتوجيه السياسات. تتيح العلامات سلوكًا شرطيًا: قواعد إفصاح مختلفة لكل بيئة، حدود معدلات محددة لكل مستأجر، أو فئات تدقيق. عرّف العلامات في ScenarioSpec وطبقها على العمليات، الشروط، الحزم، أو مهلات الوقت حسب الحاجة.

فحص مسبق

يقيم سيناريو مقابل البيانات المصرح بها دون تغيير حالة التشغيل. يتحقق من البيانات المصرح بها مقابل شكل مسجل ويعيد نتيجة القرار للمحاكاة. استخدم هذا كحلقة تكرار سريعة للوكلاء قبل تشغيل السيناريو المدقق scenario_next.

providercheckschema_get

يسترجع تفاصيل مخطط مستوى التحقق لمزود (مخطط المعلمات، مخطط النتائج، قوائم السماح للمقارنات، والأمثلة). استخدم هذا لتأليف النماذج أو إرشادات LLM دون تحميل العقد الكامل للمزود.

providercontractget

يسترجع JSON عقد المزود القياسي وهاشه لمزود معين. استخدم هذا لاكتشاف مخططات التحقق، قوائم السماح للمقارنات، والأمثلة. يتم التحكم في الكشف بواسطة سياسة التفويض ورؤية عقد المزود.

provider_id

معرف لمزود الأدلة المسجل في decision-gate.toml. يوفر المزودون الفحوصات: ‘time’ للطوابع الزمنية، ‘env’ لمتغيرات البيئة، ‘http’ لفحوصات الصحة، ‘json’ لاستعلامات الملفات. يمكن تسجيل المزودين المخصصين عبر تكوين MCP.

providers_list

قائمة بمزودي الأدلة المسجلين وملخص قدراتهم. تعيد معرفات المزودين، بيانات النقل، ورؤية محددة بالسياسة. استخدم هذا لاكتشاف المزودين المتاحين والفحوصات المدعومة.

سجل

غلاف لردود التقديم. يحتوي على submission_id، run_id، payload، content_type، content_hash، submitted_at، وcorrelation_id. تسجل السجلات أن العناصر قد تم تقديمها وتجزئتها للتدقيق.

request

غلاف لحمولات طلب الأداة. يُستخدم في رسائل بروتوكول MCP. يحتوي على اسم الأداة، والمعلمات، وبيانات الطلب الوصفية. الهيكل الداخلي؛ يتفاعل معظم المستخدمين عبر أدوات السيناريو_* ذات المستوى الأعلى.

require_labels

علامات الرؤية التي يجب أن تكون موجودة لكي يتطابق القاعدة.

requirepolicytags

علامات السياسة التي يجب أن تكون موجودة لكي يتطابق القاعدة.

requireprovideropt_in

يتطلب من المزودين الاشتراك صراحة في الكشف الخام عبر allow_raw في إعداداتهم. حتى إذا كانت allow_raw_values صحيحة على مستوى عالمي، فإن المزودين الذين لم يشتركوا يعودون بقيم هاش. دفاع متعدد الطبقات للأدلة الحساسة.

requirement

عبارة RET التي يجب أن يلبيها البوابة. يحتوي هذا الحقل على جذر شجرة المتطلبات (And/Or/Not/RequireGroup/Condition). تمر البوابة فقط عندما تقيم الشجرة بالكامل إلى true. صمم المتطلبات للتعامل مع النتائج غير المعروفة بشكل صريح عبر التفرع أو عتبات RequireGroup.

النتيجة

مثال على قيمة الناتج لاستدعاء الفحص.

result_schema

مخطط JSON لقيم مخرجات فحص المزود.

جذر

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

القواعد

قائمة مرتبة من قواعد السياسة. القاعدة الأولى التي تتطابق مع طلب الإرسال تفوز.

run_config

تكوين يتم توفيره عند بدء تشغيل عبر scenario_start. يتضمن tenant_id و run_id و scenario_id و dispatch_targets و policy_tags. تكوين التشغيل غير قابل للتغيير بعد البدء ويتم تسجيله في runpacks لضمان إمكانية التكرار.

run_id

معرف فريد يحدد تنفيذًا واحدًا لسيناريو. يتم إنشاؤه عند بدء السيناريو ويستخدم لجميع العمليات اللاحقة. تظهر معرفات التشغيل في حزم التشغيل، والقرارات، وسجلات التدقيق. احتفظ بمعرفات التشغيل للربط واستجابة الحوادث.

runstatestore

تكوين الخلفية للحفاظ على حالة التشغيل. تشمل الخيارات الذاكرة (للاختبار) أو SQLite. يحتفظ المتجر بتقدم التشغيل، تاريخ القرارات، والمحفزات المعلقة. قم بتكوين المتانة والاحتفاظ بناءً على احتياجات الامتثال.

runpack_dir

دليل الجذر لحزمة التشغيل للتحقق. يقوم runpack_verify بقراءة البيان من هذا الموقع والتحقق من جميع العناصر المرجعية. أشر إلى الدليل الذي يحتوي على manifest.json.

runpack_export

يصدر حزمة تدقيق حتمية (runpack) تحتوي على مواصفات السيناريو، وجميع المحفزات، وتقييمات البوابات، والقرارات، وحزم الإفصاح. يتضمن البيان تجزئة SHA-256 لكل عنصر. تتيح حزم التشغيل التحقق غير المتصل: يمكن لأي شخص إعادة تشغيل منطق القرار وتأكيد نفس النتائج.

runpack_verify

يتحقق من بيان الحزمة والقطع الفنية في وضع عدم الاتصال. يتحقق من تطابق جميع التجزئات، وأن تسلسل القرارات متسق داخليًا، وأنه لا توجد قطع فنية مفقودة أو تم العبث بها. يُرجع تقرير تحقق. استخدم هذا لتدقيق الامتثال، مراجعة الحوادث، أو التحقق من بوابة CI/CD.

تحديد_السيناريو

يسجل ScenarioSpec مع وقت التشغيل ويعيد spec_hash القياسي الخاص به. يتحقق وقت التشغيل من بنية المواصفة، ويتأكد من وجود جميع الشروط والمزودين المشار إليهم، ويحسب تجزئة SHA-256 للصيغة القياسية بتنسيق JSON. قم بتخزين spec_hash للتدقيق: فهو يثبت أي مواصفة محددة تحكم عملية التشغيل.

scenario_id

معرف ثابت لسيناريو عبر دورة حياته: التسجيل، التشغيل، والتدقيق. اختر معرفات وصفية، ذات إصدارات (مثل، ‘deployment-gate-v2’). معرف السيناريو بالإضافة إلى تجزئة المواصفات معًا يحدد بالضبط أي تعريف سير عمل تم استخدامه.

scenario_ids

معرفات السيناريو المسموح بها بموجب القاعدة.

سيناريو_التالي

يقيم البوابات للمرحلة الحالية ويتقدم أو يحتفظ بالتشغيل. هذا هو المحرك الرئيسي لعمليات العمل التي يتحكم فيها الوكيل. يجب أن تكون جميع البوابات صحيحة للتقدم؛ وإلا فإن التشغيل يتوقف. تستخدم مراحل الفروع نتائج البوابات لاختيار next_stage_id بمجرد اجتياز البوابات. قد تقوم سياسات المهلة بتوليف النتائج لتوجيه الفروع البديلة. تعيد القرار والمرحلة الجديدة، مع مستويات ملاحظات اختيارية (ملخص، تتبع، دليل) عندما يسمح بذلك سياسة ملاحظات الخادم.

سيناريو_البداية

ينشئ حالة تشغيل جديدة لسيناريو مسجل. يبدأ التشغيل في المرحلة الأولى ويصدر اختيارياً entry_packets كإفصاحات. يعيد run_id الذي يحدد جميع العمليات اللاحقة. يبدأ التشغيل في الحالة النشطة مع تعيين stage_entered_at من started_at.

حالة السيناريو

يسترجع لقطة قراءة فقط من عملية دون تعديلها. يعيد current_stage_id، status، last_decision، issued_packet_ids، و safe_summary اختياري لعرض واجهة المستخدم. استخدم هذا للوحات المعلومات، والاستطلاع، وتصحيح الأخطاء. تستثني الاستجابة قيم الأدلة الخام.

سيناريو_تقديم

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

مشغل_السيناريو

يقدم حدث تحفيزي مع طابع زمني صريح ويقيم التنفيذ. على عكس scenario_next، تحمل المحفزات نوعًا وsource_id وبيانات وصفية اختيارية للتحقق من الوقت والتدقيق. يضمن trigger_id معالجة متكررة: المكالمات المتكررة بنفس trigger_id تعيد القرار المخزن.

قائمة السيناريوهات

قوائم السيناريوهات المسجلة لمستأجر واسم نطاق. تعيد معرفات السيناريو وهاش المواصفات لدعم الجرد والتدقيق.

schema_id

معرف لنموذج مرتبط بالحزم. تتحقق النماذج من بنية الحمولة قبل الإرسال. قم بتسجيل النماذج في مصفوفة النماذج الخاصة بـ ScenarioSpec. تشير الحزم إلى النماذج بواسطة schema_id لضمان سلامة النوع والتوثيق.

schema_ids

معرفات المخطط المسموح بها بموجب القاعدة.

schemas_get

يسترجع شكل بيانات محدد بواسطة schema_id والإصدار لمستأجر وnamespace. يفشل في حالة عدم وجود المخطط.

قائمة_المخططات

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

schemas_register

يسجل مخطط شكل البيانات لمستأجر وفضاء أسماء. المخططات غير قابلة للتغيير؛ إعادة تسجيل نفس النسخة تفشل. قم بتضمين created_at لتوثيق متى تم تأليف المخطط.

توقيع

بيانات التعريف الخاصة بالتوقيع التشفيري المرفقة بالأدلة. تحتوي على مخطط التوقيع (مثل، ed25519)، معرف المفتاح العام، وبايتات التوقيع. تمكن المزودين من إثبات صحة الأدلة. يمكن للمحققين التحقق من التوقيعات دون اتصال باستخدام مرجع المفتاح المثبت.

spec_hash

هاش SHA-256 القياسي لـ ScenarioSpec في شكل JSON حتمي. دائمًا ما تنتج مواصفات متطابقة المحتوى نفس الهاش بغض النظر عن ترتيب الحقول. قم بتخزين spec_hash عند بدء التشغيل: فهو يثبت بالضبط أي إصدار من المواصفات كان يحكم القرارات. ضروري للتدقيق والامتثال.

stageenteredat

تم تسجيل الطابع الزمني عند دخول التشغيل المرحلة الحالية. يُستخدم لتقييم مهلات المرحلة ولإعادة تشغيل التدقيق. يتم تعيينه عند scenario_start ويتم تحديثه عند التقدم.

stage_id

معرف لمرحلة ضمن سيناريو. يجب أن يكون فريدًا ضمن ScenarioSpec. يتم الإشارة إليه بواسطة سياسات advance_to وأهداف الفروع. تظهر معرفات المرحلة في حالة التشغيل، والقرارات، وإصدارات entry_packet. استخدم أسماء وصفية: ‘الموافقة’، ‘التحقق’، ‘الإصدار’.

stage_ids

معرفات المرحلة المسموح بها بموجب القاعدة.

المراحل

قائمة مرتبة من مراحل القرار في ScenarioSpec. تحتوي كل مرحلة على بوابات للتقييم وسياسة advance_to. تتقدم العمليات عبر المراحل بشكل متسلسل ما لم تقم الفروع بإعادة توجيهها. تعزل المراحل المخاوف: قد تتحقق المراحل المبكرة من المتطلبات المسبقة، وتتحقق المراحل الوسطى من الشروط، وتفوض المراحل النهائية الإجراءات.

started_at

توقيت تم توفيره من قبل المتصل يحدد متى بدأت العملية. مطلوب عند scenario_start ويستخدم لحسابات التوقيت، stage_entered_at، وسجلات التدقيق. يُفضل استخدام توقيتات صريحة لإعادة التشغيل المحددة.

ثابت

تكوين سياسة الإرسال الثابت. ينطبق عندما تكون policy.engine = ‘static’.

الحالة

مؤشر الحالة الحالي للتشغيل أو التحقق. حالات التشغيل: ‘نشط’، ‘مكتمل’، ‘فشل’. حالات التحقق: ‘نجح’، ‘فشل’. تحقق من الحالة لتحديد الإجراءات التالية أو ظهور المشكلات.

storage_uri

موقع التخزين الاختياري الذي يتم إرجاعه بواسطة واجهات تخزين runpack المدارة (على سبيل المثال، s3://bucket/tenant/namespace/run/runpack.tar). يظهر فقط عندما يتم تكوين الخادم لتصدير runpacks إلى تخزين الكائنات.

submission_id

معرف لعنصر خارجي تم تقديمه عبر scenario_submit. يجب أن يكون فريدًا ضمن التشغيل. يمكّن من تقديمات غير متكررة: الاستدعاءات المتكررة بنفس الحمولة تعيد السجل الموجود، بينما تعيد الحمولات المتعارضة خطأ.

النظام

اسم النظام الخارجي لأهداف الإرسال.

target

معرف الهدف الخارجي لأهداف الإرسال.

target_id

معرف الهدف لمحددات الوكيل/الجلسة/القناة.

target_kind

نوع الهدف لمحدد صريح. الخيارات: ‘agent’، ‘session’، ‘external’، ‘channel’.

target_kinds

أنواع الأهداف المسموح بها بواسطة القاعدة. الخيارات: ‘agent’، ‘session’، ‘external’، ‘channel’.

targets

اختيار أهداف صريح لتفويض الإرسال.

tenant_id

معرف لعزل المستأجرين في نشرات متعددة المستأجرين. نطاقات التشغيل، تخزين الحالة، والسياسات. يتم فصل بيانات كل مستأجر بشكل منطقي. الافتراضي هو مستأجر واحد إذا لم يتم تحديده. مطلوب لأنماط SaaS والبنية التحتية المشتركة.

timeout

إعدادات مهلة المرحلة. تعيينها إلى TimeoutSpec تحتوي على timeout_ms و policy_tags، أو null لعدم وجود مهلة. تمنع المهلات العمليات من التوقف إلى أجل غير مسمى ويتم التعامل معها بواسطة on_timeout.

timeout_ms

مهلة بالمللي ثانية. تُستخدم لوقت المهلة في المراحل (TimeoutSpec) ولطلبات مزود HTTP. العمليات التي تتجاوز هذه المدة تفشل وفقًا للسياسة.

transport

بروتوكول نقل MCP للتواصل مع المزودين: ‘stdio’ لخطوط الأنابيب الفرعية، ‘http’ لـ JSON-RPC عبر HTTP، ‘sse’ للأحداث المرسلة من الخادم. اختر بناءً على النشر: stdio لمزودي الخدمة المحليين، http/sse للخدمات البعيدة. قم بتكوين ذلك في decision-gate.toml [[providers]].

trigger

تم تقديم حمولة الحدث عبر scenario_trigger لتقديم تشغيل. تحتوي على trigger_id، run_id، kind، time، source_id، حمولة اختيارية، وcorrelation_id. يتم تسجيل المحفزات لإعادة تشغيل التدقيق.

trigger_id

معرف يضمن معالجة الزناد بطريقة متكررة. المكالمات المتكررة بنفس trigger_id تعيد القرار المخزن دون إعادة التقييم. استخدم UUIDs أو معرفات مستمدة من الأحداث. هذا أمر حاسم لإعادة المحاولة بشكل آمن في الأنظمة الموزعة.

trigger_time

تاريخ ووقت تم توفيره من قبل المتصل من حدث الزناد المستخدم في فحوصات الوقت وEvidenceContext. يستخدم نوع Timestamp (unix_millis أو logical عند السماح بذلك) لتجنب قراءات الساعة الحائطية. يمكن للمراجعين إعادة تشغيل العمليات مع trigger_time المسجل.

unix_millis

توقيت Unix معبر عنه بالمللي ثانية منذ بداية العصر (1970-01-01 UTC). تنسيق قياسي لـ trigger_time وفحوصات الوقت. دقة المللي ثانية تمكن من جدولة دون الثانية. تحويل من ISO 8601: تحليل إلى Date، استدعاء getTime().

user_agent

سلسلة رأس User-Agent لطلبات مزود HTTP. الافتراضي هو معرف Decision Gate. قم بتخصيصه وفقًا لمتطلبات API، أو تحديد معدل الحد، أو لأغراض التصحيح. يظهر في سجلات الخدمات الخارجية.

visibility_labels

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