الاختبار العكسي للمسودة
- Dashboard
- CLI
محرر السياسة يعيد تشغيل مسودة ضد الاستدعاءات التي أجرتها أسطولك بالفعل، قبل نشرها.
- افتح المسودة في Admin → policy editor. يؤكد المحرر أنها تحلل كـ JavaScript.
- في backtest، اختر الوكلاء ونطاق الوقت الذي تريد إعادة تشغيله — كل الوكلاء و30d بشكل افتراضي — واترك آخر مرشح على everything ما لم تريد تضييقه.
-
اختر run backtest.

شغله ضد حدث تصفه
fp policies test يشغل ملف السياسة على جهازك ضد حدث اصطناعي ويتحقق من القرار. لا يتم نشر أي شيء ولا يصل أي شيء إلى Cloud:
--event و --tool و --command و --file. مرشح match الخاص بالسياسة نفسها ينطبق أيضاً، لذا فإن السياسة التي لا تغطي الحدث الذي وصفته تُرجع skipped بدلاً من قرار — عادة ما يكون علامة على أن match أضيق مما قصدت.
شغله على جهاز واحد
بعد ذلك، فرضه حقاً على جهازك الخاص، ضد وكيلك الخاص:اختبر ما ينكسر
التثبيت يرفض ملف مفقود، أو خطأ في بناء الجملة، أو استيراد لم يتم حله، أو استثناء على المستوى الأعلى، أو وحدة تتجاوز المهلة الزمنية أثناء التحميل — لذا أعد تشغيله بعد كل تغيير على الملف أو أي شيء يستورده. في وقت الفرض، يتم تسجيل نفس الملف المكسور و skipped بحيث تستمر كل سياسة أخرى في العمل: تعامل مع تحذير التحميل في سجلات الإنتاج كفرض مفقود. ملفات الاتفاقية يتم تحميلها بدون أمر التثبيت، لذا احتفظ بخطوةfailproofai policies --install --custom <file> صريحة في CI — هذا ما يفشل البناء على سياسة مكسورة.
ثم أطعمه ما يرسله الوكلاء فعلاً، ليس فقط الإدخال الذي تتوقعه: الحقول المفقودة، أسماء الأدوات البديلة مثل Write و Edit، مسارات Windows، إدخال مشوه. أرجع allow أو instruct أو deny متعمد على كل مسار، اجعل الدالة حتمية، واربط أي استدعاء خارجي برصيد زمني قصير.
ثم انشره وراقبه
يُظهر الاختبار العكسي ما كانت ستفعله السياسة لحركة المرور التي كانت لديك؛ لا يمكن أن يُظهر ما ستفعله حركة المرور التي لم تشهدها حتى الآن. اختر publish version في المحرر (أو شغلfp policies publish)، ثم نشّرها في وضع observe أولاً — يتم تسجيل أحكامها ولا يتم حظر أي شيء — وفرضها بمجرد أن تفصل مطابقاتها الإجراءات غير الآمنة عن الإجراءات الصحيحة.
