pending_approval، يُـعلَّق استدعاء أداة
الوكيل بدلاً من إرساله — إنه الآن ينتظر إنساناً. هذه الصفحة للمراجِع: كيف
توافق على تعليقات استدعاء أداة الوكيل (أو ترفضها) من وحدة التحكم، وماذا
يُظهر لك الطابور، وكيف يمنع OrcaRouter مراجِعَين من الاصطدام على نفس القرار.
إنها نصف الحل من الإنسان في الحلقة. لـ لماذا يُعلَّق استدعاء وكيف يعيد الوكيل
المُعلَّق التقديم بعدها، انظر الأحكام و
مرجع الموافقات الأعمق. للحل من نظامك الخاص
بدلاً من وحدة التحكم، انظر
webhooks الموافقة.
1. دورة حياة الاستدعاء المُعلَّق، من مقعد المراجِع
استدعاء مُعلَّق حلقة قصيرة خارج النطاق. مهمتك هي الخطوة الوسطى:يُعلَّق الاستدعاء
تُحَل قاعدة إلى
pending_approval. يعيد الترحيل HTTP 400 برمز
firewall_approval_pending ومعرّف موافقة؛ لا يصل الاستدعاء إلى الأداة
أبداً. يبدأ الوكيل في الاستطلاع على ذلك المعرّف.حل تعليق محكوم بـ Developer+ — نفس بوابة تغذية أحداث جدار الحماية. الأدوار
الأدنى يمكنها قراءة سياسة جدار الحماية والإعدادات والأدوات المكتشفة، لكن أدوار
Developer-فما-فوق فقط يمكنها سرد طابور الموافقة أو موافقة/رفض استدعاء أداة
مُعلَّق. انظر
الأدوار والنطاق.
2. اسرد الطابور المُعلَّق
تبويب Approvals يقرأGET /api/workspace/firewall/approvals. بلا فلتر يعيد
طابور pending، الأقدم أولاً — فالاستدعاء الأطول انتظاراً يجلس في
الأعلى وتعمل على المتراكم بالترتيب.
state هو الفلتر الوحيد المهم. تتطابق القيم مع دورة حياة الموافقة:
state | الموافقات المُعادة |
|---|---|
pending (الافتراضي) | مُعلَّقة، بانتظار قرار — طابور عملك. |
approved | مُمرَّرة بالفعل. |
rejected | محجوبة بالفعل. |
3. اقرأ لماذا عُلِّق الاستدعاء
يحمل كل صف مدخلات القرار التي يحتاجها مراجِع — اسم الأداة (tool_name)،
وبصمة وسائط (args_hash، تجزئة SHA-256 لوسائط الاستدعاء المعيارية —
قيم الوسائط الخام لا تُخزَّن في الموافقة)، ومعرّف الطلب، وسطر أصل بلغة
بسيطة يسمّي السياسة، والقاعدة، والعبارة التي أُطلقت:
policy_name — أي سياسة علّقته
policy_name — أي سياسة علّقته
السياسة المسمّاة التي تنتمي إليها القاعدة المطابقة، مُحَلّة ضمن نطاق مساحة
العمل فلا يمكن أبداً لمعرّف قديم أن يُظهر اسم سياسة مستأجر آخر.
rule_label + matched_clause — السبب البشري
rule_label + matched_clause — السبب البشري
علامة القاعدة وواصف “لماذا” من سطر واحد — مثل
command contains rm -rf،
أو tool matches "http_fetch" لقاعدة glob فقط. هذا يُصيّر سطر “عُلِّق
لأن…” في الطابور.rule_changed — أصل يمكنك الوثوق به
rule_changed — أصل يمكنك الوثوق به
true عندما حُرِّرت القاعدة المطابقة عند أو بعد إنشاء هذه الموافقة.
عندها تُكبَت العلامة والعبارة الحية (قد لا تعكسان ما علّق الاستدعاء فعلاً)،
ويُظهر الطابور ملاحظة “القاعدة تغيّرت منذ ذلك الحين” بدلاً من أصل قديم.
اسم الأداة والوسائط — مدخلات القرار الحقيقية — تُعرَض دائماً.4. وافق أو ارفض
الحل يرسلPATCH /api/workspace/firewall/approvals/:id بـ decision بقيمة
approved أو rejected وreason اختياري. تفعل وحدة التحكم هذا لك عندما
تنقر الزر؛ الشكل:
approved← قد يمضي الاستدعاء المُعلَّق. إعادة تقديم الوكيل التالية، حاملةً ترويسة الموافقة أحادية الاستخدام، تُمرَّر مرة واحدة.rejected← يبقى الاستدعاء محجوباً. يرى الوكيل الرفض ويمكنه اختيار مسار آخر، أو سؤال المستخدم، أو التوقف.
decision يُتحقَّق منه مقابل المجموعة المغلقة {approved, rejected} — أي شيء
آخر يُرفض. يُسجَّل reason مع القرار ويُكتَب إلى سجل تدقيق جدار الحماية جنباً
إلى جنب مع الفاعل واسم الأداة ومعرّف الطلب.
كل حل يكتب صف تدقيق مساحة عمل يسمّي من قرّر، والقرار، والسبب. حلول وحدة
التحكم تسجّل الفاعل البشري؛ حلول webhook
تسجّل فاعلاً نظامياً. أصل الحل لا يُسقَط أبداً صامتاً.
5. أول-كاتب-يفوز: لا حل مزدوج
موافقة مُعلَّقة يمكن أن تُسبَق — مراجِعان في وحدة التحكم، أو نقرة وحدة تحكم و استدعاء webhook يصلان معاً. يحل OrcaRouter هذا بقاعدة أول-كاتب-يفوز واحدة:- القرار تحديث شرطي ذرّي يُطلق فقط بينما لا تزال الموافقة
pending. أول كاتب يفوز ويطبّق القرار. - كل كاتب لاحق يرصد “محلولة بالفعل” ويُعامَل كـ عملية عديمة الأثر تكرارياً — يحصل على HTTP 200 بالوثيقة المحلولة بالفعل، وليس خطأً.
resolved: true يعني أن استدعاءك طبّق القرار؛ وalready_resolved: true يعني
أن أحداً (أو webhook ما) وصل أولاً وأنت ترى نتيجته. في كلتا الحالتين يتصالح
الطابور إلى حالة متسقة واحدة.
6. مرور ملموس عبر الطابور
مساحة عمل باستقلالية متوازنة تعلّق استدعاءshell.exec لوكيل لأن قاعدة طابقت
command contains rm -rf. كمراجِع أنت:
- تفتح Approvals —
shell.execالمُعلَّق يجلس في أعلى قائمةpendingالأقدم-أولاً. - تقرأ الصف: الأداة
shell.exec، بصمةargs_hash، معرّف الطلب، وسطر “عُلِّق لأن…command contains rm -rf” (مُصيَّر من عبارة القاعدة المطابقة). لا علامةrule_changed، فالأصل حالي. - الهدف دليل مؤقت، فتـوافق بسبب.
- يعيد
PATCHالخاص بكresolved: true؛ استطلاع الوكيل التالي يرىapproved، يعيد التقديم بترويسته أحادية الاستخدام، ويعمل الأمر مرة واحدة بالضبط.
already_resolved: true بقراره —
لا ضرر، لا تشغيل مزدوج.
أين تذهب بعد ذلك
مرجع الموافقات
حلقة HITL الكاملة: التعليق، الاستطلاع، إعادة التقديم، والترويسة أحادية
الاستخدام.
webhooks الموافقة
احلل التعليقات من نظامك الخاص باستدعاء موقَّع بـ HMAC.
الأحكام
أين يقع pending_approval بين أحكام جدار الحماية الستة.
سجل الأحداث
أكّد النتيجة اللاحقة لاستدعاء محلول في التغذية.
