أمثلة على بوابة القرار
تقوم Decision Gate بتحويل المنطق والأدلة والأبواب إلى سير عمل يمكن التحقق منه. كل سير عمل هنا مدعوم بالأدلة، مغلق عند الفشل، وقابل للتدقيق.
التحقق من مهام الوكيل
ما الذي يحله هذا
عندما يبلغ وكيل “تم”، تحتاج إلى أكثر من مجرد ادعاء - تحتاج إلى دليل. يوضح هذا المثال كيف تحول Decision Gate مخرجات الوكيل إلى نتيجة يمكن التحقق منها يمكنك قبولها دون مراجعة يدوية.
سير العمل
- يقوم الوكيل بأداء المهمة وإنتاج الأدلة
- يقوم بوابة القرار بتقييم الأدلة مقابل بوابة
- إذا اجتاز البوابة، يتم قبول المهمة وتدقيقها
مقتطف المواصفات (متطلبات البوابة)
{
"gate_id": "tests-passed",
"requirement": { "Condition": "tests_ok" }
}
تصاريح البوابة عندما تكون فشل الاختبارات = 0.
النقطة الرئيسية
هذا النمط يحول “منجز” إلى “منجز مع دليل”. ينطبق في أي مكان يمكن فيه التحقق من مخرجات الوكيل مقابل بيانات حقيقية—اختبارات، تقارير، تحويلات، أو فحوصات الامتثال. لم يعد الناتج مجرد ادعاء؛ بل هو قابل للتحقق. يمكن أن يقود هذا التحقق الحلقة نفسها—التكرار حتى تمر البوابة، أو التوقف عندما يظهر انتهاك.
بوابة جودة الإصدار
ما الذي يحله هذا
قبل أن تقوم بشحن تغيير، تحتاج إلى دليل يثبت أنه يلبي متطلبات الجودة والسلامة. يوضح هذا المثال كيف أن Decision Gate يمنع الإصدار ما لم يكن لدى كل فحص مطلوب دليل حقيقي.
سير العمل
- عملية الإصدار الخاصة بك تقوم بتشغيل الاختبارات، والتغطية، وفحوصات الأمان
- كل أداة تكتب ملف نتيجة بتنسيق JSON
- يقوم Decision Gate بتقييم جميع الشروط قبل الإصدار
مقتطف المواصفات (منطق AND)
{
"gate_id": "quality-checks",
"requirement": {
"And": [
{ "Condition": "tests_ok" },
{ "Condition": "coverage_ok" },
{ "Condition": "scan_ok" }
]
}
}
تصاريح البوابة عندما تفشل الاختبارات = 0 والتغطية ≥ 85% والثغرات الحرجة = 0.
النقطة الرئيسية
هذه بوابة إصدار تحول العديد من الإشارات إلى قرار واحد. نفس النمط ينطبق على أي عملية حيث يجب أن تتفق عدة فحوصات قبل اتخاذ إجراء - الجودة، السلامة، الامتثال، أو المخاطر. سواء تم تفعيل الإصدار بواسطة إنسان، أو خط أنابيب، أو وكيل، فإن البوابة تفرض نفس القاعدة: يمكنك الشحن فقط عندما تقول الأدلة إنه يمكنك ذلك.
موافقة الإنسان (نصاب)
ما الذي يحله هذا
بعض القرارات تتطلب موافقة بشرية، حتى عندما يقوم الوكلاء بمعظم العمل. يوضح هذا المثال كيفية طلب موافقتين من أصل ثلاث، دون الانتظار على الجميع.
سير العمل
- يقوم الوكيل بإعداد القرار ويطلب الموافقات
- يقدم المراجعون الموافقات كدليل
- يقوم بوابة القرار بتقييم منطق النصاب
- بمجرد وجود موافقتين، يتم تدقيق تصاريح البوابة والقرار
مقتطف المواصفات (RequireGroup)
{
"gate_id": "review-quorum",
"requirement": {
"RequireGroup": {
"min": 2,
"reqs": [
{ "Condition": "alice_approved" },
{ "Condition": "bob_approved" },
{ "Condition": "carol_approved" }
]
}
}
}
تصاريح البوابة عندما يوافق ما لا يقل عن 2 من 3 مراجعين.
النقطة الرئيسية
منطق النصاب يحول الموافقة البشرية إلى قاعدة يمكن للنظام فرضها. إنه يعمم على أي تدفق للموافقة—قانوني، أمني، مالي—حيث تحتاج إلى عتبات واضحة ومسار تدقيق. تصبح العملية موثوقة دون الحاجة إلى توافق بالإجماع.
تعلم المزيد
هذا يكمل المقدمة إلى Decision Gate. قارن الإصدارات في Decision Gate Features، أو انتقل مباشرة إلى الوثائق للحصول على المواصفات، الرياضيات، والضمانات.
- أساسيات بوابة القرار — المفاهيم الأساسية بلغة بسيطة
- تأليف السيناريو — تنسيق ScenarioSpec الكامل
- دليل منطق RET — AND/OR/NOT/RequireGroup
- التوثيق الكامل — تفاصيل المرجع والتنفيذ