diff --git a/docs/ar/admin/keys-and-permissions.mdx b/docs/ar/admin/keys-and-permissions.mdx index 1a402c6f6..6c067bb02 100644 --- a/docs/ar/admin/keys-and-permissions.mdx +++ b/docs/ar/admin/keys-and-permissions.mdx @@ -1,74 +1,54 @@ --- title: "المفاتيح والأذونات" -description: "أنشئ مفاتيح API ذات نطاق محدد للآلات والأتمتة والمشغّلين." +description: "إنشاء بيانات اعتماد للأفراد والأتمتة والآلات." icon: "key-round" --- -تنتمي مفاتيح API إلى منظمة وتحمل أذونات صريحة. استخدم مفاتيح منفصلة لاستيعاب الوكلاء، وتسليم السياسات، والمقيّمين، وأتمتة CI، والبرامج الإدارية. +استخدم مفتاحًا منفصلًا لكل شخص أو آلة أو مهمة أتمتة. امنح فقط الأذونات التي تحتاجها. ## إنشاء وتدوير مفتاح - - - 1. انتقل إلى **Administration → Keys**، اختر **new key**، وأدخل اسم حمل العمل. - 2. اختر مجموعة أذونات واضبط الأذونات الفردية فقط عندما تكون مجموعة الإعدادات المسبقة غير كافية. - 3. أنشئ المفتاح وانسخ سرّه لمرة واحدة فوراً. - 4. افتح المفتاح لاحقاً لتحديث المنح أو تعطيله أو إعادة توليد السرّ. +استخدم **Admin → Keys**، أو واجهة سطر الأوامر للسحابة: - درج الإنشاء هو حيث تختار أضيق المنح المطلوبة بواسطة حمل العمل. +```bash +fp keys list +fp keys create "audit automation" --add audits:read +fp keys disable "audit automation" +``` - ![درج مفتاح API الجديد مع إعدادات الأذونات المسبقة والمنح الفردية.](/images/dashboard/key-create.png) +احفظ السر عند إنشاؤه؛ لن يتم عرضه مرة أخرى. قم بالتدوير بإنشاء بديل وتحديث المستهلك ثم تعطيل المفتاح القديم. - بعد الإنشاء، تعرض صفحة المفاتيح البيانات الوصفية الدائمة وإجراءات الإدارة. لن يتم عرض السرّ لمرة واحدة مرة أخرى. +## مفاتيح الآلات - ![صفحة مفاتيح API توضح أذونات المفتاح ووقت الإنشاء وإجراءات إعادة التوليد والتعطيل.](/images/dashboard/api-keys.png) +يربط مفتاح الآلة الخدمة المحلية بالسحابة: - استخدم هذه القائمة لمراجعة المنح بشكل منتظم وتعطيل المفاتيح التي لا تعود مرتبطة بحمل عمل نشط. - - - ```bash - fp keys create production-agents \ - --add events:add \ - --add policies:pull - fp keys show production-agents - fp keys update production-agents --add events:read - fp keys regenerate production-agents --yes - fp keys disable production-agents - ``` +```bash +export FAILPROOFAI_CLOUD_TOKEN="" +failproofai config +``` - أعد توجيه أو احصر مخرجات الإنشاء/إعادة التوليد بشكل آمن؛ يتم إرجاع السرّ مرة واحدة فقط. - - +قد تحتاج الآلة المتصلة إلى قدرتين: -الأذونان المطلوبان بواسطة آلة Failproof AI متصلة مستقلان: +- `policies:pull` لاستقبال السياسات المدارة من السحابة. +- `events:add` لإرسال القرارات والجلسات. -- `events:add` يرسل الأحداث وبيانات الجلسة. -- `policies:pull` يسترجع نشرات السياسات المعيّنة. +تقارير الحالة تقدم هذه بشكل منفصل لأن أحدهما قد يعمل بينما الآخر لا يعمل. -يتم عرض أسرار المفاتيح عند إنشاؤها أو إعادة توليدها. قم بتخزينها في مدير الأسرار وأدرها دون إعادة استخدام بيانات اعتماد المشغّل التفاعلية. +## الأذونات الشائعة -## كتالوج الأذونات - -| المجال | الأذونات | +| الإذن | السماح به | | --- | --- | -| الأحداث | `events:add`, `events:read` | -| المفاتيح | `keys:create`, `keys:read`, `keys:disable`, `keys:regenerate`; `keys:update` متاح فقط للجلسات البشرية | -| المستخدمون | `users:create`, `users:read`, `users:update`, `users:delete` | -| التقييمات | `evaluations:read`, `evaluations:trigger` | -| لوحات المعلومات | `dashboards:read`, `dashboards:write`, `dashboards:delete` | -| الاستعلامات | `queries:read`, `queries:write`, `queries:delete`, `queries:run` | -| المساعد | `agent:use` | -| الإعدادات | `settings:read`, `settings:write` | -| التنبيهات | `alerts:read`, `alerts:write` | -| المشاكل | `issues:read`, `issues:create`, `issues:close` | -| عمليات التدقيق | `audits:read`, `audits:write` | -| السياسات | `policies:read`, `policies:write`, `policies:pull` | -| الاستخدام | `usage:read` | - -`orgs:admin` محفوظ لمشغّل النموذج ولا يمكن منحه لمفتاح منظمة أو عضو عادي. تقبل الرموز المتقاعدة `incidents:*` و `alerts:ack` من أجل التوافقية وتُعاد معايرتها إلى أذونات `issues:*` الحالية. +| `events:add` | إرسال الأحداث | +| `events:read` | قراءة الأحداث والأخطاء | +| `evaluations:read` | قراءة الجلسات والتقييمات | +| `audits:read` / `audits:write` | مراجعة أو إدارة التدقيقات | +| `policies:read` / `policies:write` | مراجعة أو نشر السياسات | +| `policies:pull` | سحب تعيينات سياسات الآلة | +| `keys:create` / `keys:disable` | إنشاء أو تعطيل المفاتيح | +| `orgs:admin` | إدارة المنظمة على مستوى المثيل؛ غير قابلة للتعيين لمفتاح تنظيمي | -مجموعات الأذونات المدمجة هي `read-only` و `standard` و `admin`. تضيف `standard` تفعيل التقييم وتنفيذ الاستعلامات والرد على المشاكل واستخدام المساعد إلى أذونات القراءة. يزيل إنشاء المفتاح المنح الخاصة بالبشر فقط حتى عندما تحتوي مجموعة الأذونات عليها. +تتطلب بعض أوامر `fp fleet` و `fp guardrails` الإدارية جلسة مستخدم موقعة بدلاً من مفتاح API. يشير نص المساعدة فيها إلى ذلك قبل تقديم طلب. - يمكن لمفاتيح النطاق على مستوى النموذج تحديد منظمة باستخدام رأس `X-AgentEye-Org`. قم بتعيينها بشكل صريح على نشرات متعددة المنظمات؛ قد يؤدي الحذف إلى تحديد المنظمة الافتراضية. + لا تعد استخدام بيانات اعتماد الاستيعاب مثل `AGENTEYE_KEY` أو `AGENTEYE_API_KEY` كـ `FP_API_KEY`. فهي تخدم أنظمة وأذونات مختلفة. \ No newline at end of file diff --git a/docs/ar/admin/overview.mdx b/docs/ar/admin/overview.mdx index 8bfcd1d87..76e9481d8 100644 --- a/docs/ar/admin/overview.mdx +++ b/docs/ar/admin/overview.mdx @@ -1,22 +1,30 @@ --- title: "الإدارة" -description: "تشغيل الوصول والاستخدام والمنظمات والأمان دون دمجها في سير عمل الموثوقية." +description: "تشغيل وصول Cloud والعضوية والإعدادات والاستهلاك دون دمجها في سير عمل الموثوقية." icon: "settings-2" --- -تحتوي الإدارة على عناصر التحكم اللازمة لتشغيل Failproof AI عبر فريق. يمكن لمعظم المستخدمين البقاء في الجلسات والتدقيق والسياسات؛ يستخدم المسؤولون هذا القسم لإدارة الوصول وحدود التشغيل. +الإدارة هي نصف Failproof AI في Cloud. المؤسسات والأعضاء ومفاتيح API وإعدادات المؤسسة والاستهلاك المقاس — كل هذا يتطلب اتصال Cloud. + + + يعمل Failproof AI أيضاً بدون حساب على الإطلاق. آلة محلية تفرض السياسة، وتحتفظ بسجل الجلسة على القرص، وتخدم لوحة المعلومات المحلية على `localhost:8020`، وتشغل `failproofai audit` دون إرسال أي شيء في أي مكان. اطلع على تكوين الآلة في [machine configuration](/ar/reference/events-and-configuration#machine-configuration) لمفاتيح `collector` المحلية. تخطَّ بقية هذا القسم إذا لم تكن تستخدم Cloud. + + +## حيث تقع الأدوات - - استخدم قسم **Admin** في الشريط الجانبي للسحابة للوصول إلى **محرر السياسات** و**الإنفاذ** و**الاستخدام** و**المفاتيح** و**المستخدمين** و**الإعدادات**. يشير العنصر المقفل إلى أن حسابك يفتقد إلى صلاحية القراءة. + + مجموعة **admin** في شريط الجانب Cloud تحتوي على **محرر السياسة** و**الإنفاذ** و**الاستخدام** و**المفاتيح** و**المستخدمون** و**الإعدادات**. - ![قسم الإدارة في الشريط الجانبي للسحابة يعرض محرر السياسات والإنفاذ والاستخدام والمفاتيح والمستخدمين والإعدادات.](/images/dashboard/admin-navigation.png) + ![مجموعة admin في شريط جانب Cloud يحتوي على محرر السياسة والإنفاذ والاستخدام والمفاتيح والمستخدمين والإعدادات.](/images/dashboard/admin-navigation.png) - + + ثبّت Cloud CLI كأداة منفصلة، ثم قم بتسجيل الدخول: + ```bash + uv tool install fp-cloud-cli + fp login fp whoami - fp orgs current - fp orgs perms fp usage ``` @@ -24,17 +32,43 @@ icon: "settings-2" +## إنسان مسجل دخول أو مفتاح API + +يعمل `fp` في أحد وضعي المصادقة، والفاصل يحدد الأوامر التي تعمل. الأمر الذي لا يمكن لمفتاح API تنفيذه يرفض قبل فتح الاتصال ويسمي السبب، بدلاً من ترك 401 أو 403 يحل محله. + +| الأمر | مفتاح API | الإذن | +| --- | --- | --- | +| `fp whoami` | نعم | لا شيء | +| `fp usage` | نعم | `usage:read` | +| `fp keys list` / `show` | نعم | `keys:read` | +| `fp keys create` | نعم | `keys:create` | +| `fp keys disable` | نعم | `keys:disable` | +| `fp keys regenerate` | نعم | `keys:regenerate` | +| `fp keys update` | لا | `keys:update`، الذي لا يمكن لأي مفتاح أن يحتفظ به | +| `fp users list` / `show` | نعم | `users:read` | +| `fp users create` | نعم | `users:create` | +| `fp users update` | نعم | `users:update` | +| `fp users disable` / `enable` | نعم | `users:delete` | +| `fp settings list` / `schema` | نعم | `settings:read` | +| `fp settings set` | نعم | `settings:write` | +| `fp orgs list` / `switch` / `current` / `perms` | لا | جلسة مسجلة دخول فقط | + +`fp usage` هو الأمر الذي يجب إعطاؤه لسكريبت إعداد التقارير: يعمل دون مراقبة تحت مفتاح ويحتاج فقط `usage:read`. + - - فحص نوافذ الفوترة واستهلاك المنظمة. - - - منح الآلات والأتمتة الصلاحيات المطلوبة فقط. + + أنشئ بيانات اعتماد الآلة، وامنح كل عملية فقط الأذونات التي تحتاجها. - - إدارة العضوية والإعدادات الافتراضية وحدود المنظمة. + + أدِر العضوية، واحتفظ بنطاق بيانات كل مؤسسة وإجراءاتها. - تكوين إعدادات التشغيل ومعالجة البيانات وأمان النشر. + عيّن قيم تسجيل الدخول والتنبيهات، وحدد بيانات الوكيل التي تغادر الآلة. + + + اقرأ ما قاست المؤسسة خلال نافذتها الحالية من 30 يوماً. + + + انظر الآلات المسجلة والكيفية التي تُحدَّد بها وما تفرضه. \ No newline at end of file diff --git a/docs/ar/admin/settings-and-security.mdx b/docs/ar/admin/settings-and-security.mdx index b8c121dcd..40abbcc67 100644 --- a/docs/ar/admin/settings-and-security.mdx +++ b/docs/ar/admin/settings-and-security.mdx @@ -1,68 +1,38 @@ --- +--- title: "الإعدادات والأمان" -description: "قم بتكوين الإعدادات التشغيلية واتخذ قرارات مدروسة حول بيانات الوكيل." -icon: "lock-keyhole" +description: "التحكم في إعدادات المؤسسة الافتراضية ومعالجة البيانات بيانات الاعتماد للآلة." +icon: "shield" --- -استخدم الإعدادات للقيم التشغيلية الخاصة بالنشر وتجاوزات نافذة سياق النموذج. افحص مخطط الإعدادات قبل تغيير قيمة من خلال واجهة برمجية التطبيقات أو واجهة سطر الأوامر. - -## تغيير إعداد المؤسسة - - - - 1. انتقل إلى **Administration → Settings**، وابحث عن مجموعة الإعدادات، واقرأ وصفها والمصدر الحالي. - 2. غيّر القيمة واحفظها. - 3. بالنسبة لنوافذ سياق النموذج، أضف أو حدّث تجاوز النموذج وأكّد الحد الفعلي. - 4. أعد التحقق من الجلسات والمقاييس التي تعتمد على القيمة المتغيرة. - - ![صفحة الإعدادات تعرض إعدادات مصادقة المؤسسة والإعدادات التشغيلية.](/images/dashboard/settings.png) - - - ```bash - fp settings list - fp settings schema - fp settings set --value - fp settings set alerts.email_default_recipients \ - --json-value '["oncall@example.com"]' - ``` +إعدادات المؤسسة تؤثر على الجميع في منظمة Cloud تلك. غيّرها من **Admin → settings** أو باستخدام `fp settings`. - شغّل `fp settings set --help` للحصول على نوع القيمة وأعلام التأكيد المستخدمة بواسطة واجهة سطر الأوامر المثبتة. - - +```bash +fp settings list +fp settings set +``` -## خيارات معالجة البيانات +## معالجة البيانات -يؤدي توصيل Failproof AI CLI إلى إرسال النصوص الكاملة بشكل افتراضي لأن التتبعات والتدقيقات تعتمد على محتواها. استخدم `--no-transcripts` عندما يجب أن تبقى المطالبات أو محتويات الملفات أو إدخال الطرفية محلية؛ يمكن لا يزال الإبلاغ عن نشاط الخطاف وقرارات السياسة. +الآلة المتصلة ترسل قرارات السياسة والنسخ الكاملة من جلسات العمل بشكل افتراضي. لإرسال القرارات فقط، اضبط `collector.sessions` على `false` في ملف `~/.failproofai/config.json` الخاص بالآلة بعد الاتصال. علم الإعداد الحالي `--no-transcripts` لا ينطبق على هذا الإعداد. -يتم تخزين بيانات اعتماد الإدخال المحلي بشكل منفصل عن إعدادات خادم غير سرية ويتم كتابتها بأذونات مقيدة. يجب بالتالي إدارة مفاتيح واجهة برمجية التطبيقات كأسرار الإنتاج. +يتم حذف بيانات الاعتماد على الآلة قبل التحميل، لكن إزالة الالتباس هي الحد الأدنى للأمان وليست بديلاً عن التحكم بالوصول. -## مرجع إعداد المؤسسة +الاستخدام المحلي فقط لا يتطلب حساباً. تاريخ الجلسة والتدقيق يبقى على الآلة، ما عدا التدقيق المحلي المجدول الذي يرسل هوية الآلة وملخص محدود بعد أن توافق عليه. يمكن تعطيل قياس الاستخدام المجهول للـ CLI باستخدام `FAILPROOFAI_TELEMETRY_DISABLED=1`. -جميع الإعدادات القابلة للتحرير في لوحة المعلومات لها نطاق تنظيمي. يبقى السلوك على مستوى النشر الكامل كتكوين بيئة الخادم. +## بيانات الاعتماد -| المفتاح | الافتراضي | الغرض | -| --- | --- | --- | -| `allowed_sign_ins` | `[]` | قيّد الأعضاء الحاليين إلى رسائل بريد إلكترونية دقيقة أو `*@domain`؛ القائمة الفارغة تعني عدم وجود تقييد إضافي. | -| `session_ttl_secs` | `86400` | مدة جلسة لوحة المعلومات؛ النطاق المقبول من 60 ثانية إلى 30 يومًا. | -| `otp_ttl_secs` | `600` | مدة OTP والرابط السحري؛ النطاق المقبول هو 60–1800 ثانية. | -| `alerts.email_default_recipients` | `[]` | المستلمون الافتراضيون عندما لا تتجاوز قناة البريد الإلكترونية للتنبيهات عنهم. | -| `alerts.slack_default_webhook` | فارغ | عنوان URL ويب هوك Slack الافتراضي. | -| `alerts.webhook_default_url` | فارغ | عنوان URL ويب هوك JSON عام افتراضي. | -| `alerts.webhook_signing_secret` | فارغ | مفتاح HMAC-SHA256 المستخدم لرأس `X-AgentEye-Signature`؛ القراءات مخفية. | -| `alerts.enabled_channels` | البريد الإلكترونية، Slack، ويب هوك | أنواع القنوات على مستوى المنظمة التي قد ترسل قواعد التنبيهات. | -| `default_user_permissions` | `standard` | مجموعة الأذونات المسماة المحددة مسبقًا للدعوات الجديدة. | +رموز الآلة مخزنة تحت `~/.failproofai/` برأذونات تابعة للمالك فقط. لا يتم كتابتها في تعريف الخدمة. -`allowed_sign_ins` هو مرشح، وليس منح: يجب أن يكون الشخص بالفعل عضوًا في المنظمة. استخدم قائمة فارغة للسماح لكل عضو؛ القيمة المكررة `*` مرفوضة. يجب أن تستخدم عناوين URL للتنبيهات HTTPS باستثناء عناوين التطوير loopback. +استخدم مفاتيح منفصلة للأشخاص والأتمتة والآلات. أعطِ كل واحدة الأذونات التي تحتاجها فقط، وأدرها عند تغيير الملكية، وألغِ إذنها عندما تتقاعد الآلة أو سير العمل. -## قائمة التحقق من الأمان +## قائمة التحقق -- استخدم HTTPS للاتصالات السحابية. -- حصّر المفاتيح على أصغر مجموعة أذونات. -- افصل بين بيئات الإنتاج وغير الإنتاج. -- راجع إعدادات التقاط والتحرير النصي قبل النشر. -- دقّق التغييرات في المستخدمين والمفاتيح والمنظمة. -- اختبر متطلبات النسخة الاحتياطية والاحتفاظ واستجابة الحوادث للنشر الخاص بك. +- اطلب أضيق أذونات مفيدة. +- اضبط `collector.sessions` على `false` حيث لا تكون محتويات كاملة ضرورية. +- راجع من يمكنه نشر السياسات الملزمة. +- اختبر السياسات في وضع المراقبة قبل التطبيق. +- اجعل تسميات الآلة واضحة ومعرّفات الآلة مستقرة. +- شغّل `failproofai config --status` بعد تغيير إعدادات الاتصال. - - إيقاف تشغيل التقاط النصي يغيّر ما يمكن للتدقيقات والتحقيقات أن تثبته. سجّل القرار والقيود المتوقعة منه. - \ No newline at end of file +انظر [المفاتيح والأذونات](/ar/admin/keys-and-permissions) للحصول على كتالوج الأذونات. \ No newline at end of file diff --git a/docs/ar/admin/usage.mdx b/docs/ar/admin/usage.mdx index bde9fa61c..9492b39d6 100644 --- a/docs/ar/admin/usage.mdx +++ b/docs/ar/admin/usage.mdx @@ -1,38 +1,78 @@ --- --- title: "الاستخدام" -description: "فحص استهلاك المؤسسة ونافذة الفواتير النشطة." +description: "فحص استهلاك المؤسسة للنافذة الحالية المدتها 30 يوماً." icon: "chart-no-axes-combined" --- -يعرض الاستخدام استهلاك المؤسسة الحالية ونوافذ الفواتير الخاصة بها. استخدمه لفهم كيفية تأثير نشر الإنتاج وحجم النصوص والتقييمات وتكرار التدقيق على خطتك. +يعرض الاستخدام ما قامت المؤسسة الحالية بقياسه خلال نافذة مدتها 30 يوماً. النافذة ثابتة ومرتبطة بكل مؤسسة، والاستخدام للقراءة فقط: لا ينطبق ولا يعرض أي حدود أو حصص أو عتبات خطة. كلا الواجهتين تشير إلى ذلك — لوحة سطر الأوامر تطبع "استخدام للقراءة فقط، لا توجد حدود مطبقة". ## مراجعة الاستخدام - - 1. انتقل إلى **الإدارة → الاستخدام**. - 2. تأكد من المؤسسة ونافذة القياس. - 3. راجع الاستيعاب والجلسات والتقييمات والمقاييس والتدقيقات والنتائج والتنبيهات والمستخدمين والمفاتيح. - 4. قارن عمل التدقيق الذي تم بدؤه واكتماله عندما يبدو استخدام التدقيق غير متوقع. + + 1. انتقل إلى **admin → usage**. + 2. أكّد المؤسسة والنافذة الزمنية — يعرض الرأس بداية ونهاية النافذة واليوم فيها والوقت المنقضي. + 3. اقرأ كتلة البطل: الأحداث المدرجة والجلسات والوكلاء والبيئات. + 4. اقرأ خطوط الأنابيب الاثنين: التقييمات (مع النقاط والمقاييس) والتدقيقات (مع المشاكل والتنبيهات)، كل منها يعرض الحالات المكتملة مقابل الحالات المبدوءة. + 5. اقرأ كتل مساحة العمل والوصول: الاستعلامات المحفوظة والبيانات والتنبيهات والمشاكل الفريدة والأعضاء ومفاتيح API. - ![صفحة الاستخدام تعرض نافذة القياس والأحداث المستقبلة وخطوط أنابيب التقييم والتدقيق وموارد مساحة العمل والأعضاء ومفاتيح واجهة برمجة التطبيقات.](/images/dashboard/usage-overview.png) + الأرقام مخزنة في الذاكرة المؤقتة وليست مباشرة. استخدم التحكم في التحديث في الأعلى يميناً بعد إجراء تتوقع أن ترى تأثيره. + + ![صفحة الاستخدام تعرض النافذة الزمنية والأحداث المستقطة وخطوط أنابيب التقييم والتدقيق وموارد مساحة العمل والأعضاء ومفاتيح API.](/images/dashboard/usage-overview.png) - + ```bash fp usage fp --json usage fp --org reliability-team --json usage ``` + + يحتاج `fp usage` إلى `usage:read` ويعمل تحت مفتاح API، مما يجعله الأمر المناسب لـ cron التقارير. + + مع `--json` يعيد استجابة لوحة البيانات دون تغيير: `org_id` و `billing_anchor` و `window` و `usage` و `calculated_at` و `stale_after`. `calculated_at` و `stale_after` هما كيفية معرفة قدم الرقم. + + لا يأخذ `fp usage` أي أعلام خاصة به — فقط `--json` و `--org` العامة. يقارير النافذة الحالية فقط وليس شيء قبلها، لذا احتفظ بسجلك الخاص بتشغيله بجدول زمني وتخزين حمولة `--json` بدلاً من توقع الاستعلام عن نافذة سابقة لاحقاً. + + ```bash + fp --json usage | jq '.usage.events_ingested' + ``` -## التحقيق في التغيير +### مفاتيح المقاييس + +كل شيء تحت `usage` في حمولة JSON، لذا يمكن لبرنامج نصي أن يسمي حقلاً بدلاً من تحليل لوحة. + +| المجموعة | المفاتيح | +| --- | --- | +| بيانات المراقبة | `events_ingested` و `sessions` و `agents` و `environments` | +| التقييمات | `evaluation_runs` و `evaluation_finishes` و `evaluations` و `metrics` | +| التدقيقات | `audit_runs` و `audit_finishes` و `issues_created` و `alerts_created` | +| مساحة العمل | `queries_created` و `dashboards_created` | +| الوصول | `users_active` و `users_created` و `keys_active` و `keys_created` | + +تقارير كل خط أنابيب العد المبدوء والمكتمل بشكل منفصل، لذا فإن الفجوة بين `audit_runs` و `audit_finishes` تعني عملاً بدأ ولم ينته — يستحق التحقق قبل أن تقرأ أي شيء في عدد المشاكل تحته. + +## التحقق من التغيير + +يتم تحديد حجم البيانات المدرجة لكل آلة وليس بشكل مركزي. ابدأ من المؤسسة والنافذة، ثم تابع ما تغير على الآلات التي تقدم البيانات إليها. + +| السبب | مكان التحقق | ما يجب تغييره | +| --- | --- | --- | +| آلة تقوم بإرسال نصوص الجلسة | `collector.sessions` في `~/.failproofai/config.json` لتلك الآلة | اضبطها على `false` لإرسال القرارات فقط | +| يتم إرسال نشاط الخطاف بالكامل | `collector.hooks_verbosity` في نفس الملف | `decisions` يسمح بالتجميع كل دقيقة؛ `off` يوقف أحداث الخطاف تماماً | +| تمت إضافة موقع التقاط جديد | `failproofai harness list` | أزله باستخدام `failproofai harness remove-path ` | +| تم إعادة إرسال السجل | عمليات `failproofai backfill` للآلة | تقوم بإعادة الإرسال بإزالة التكرار على تجزئة المحتوى والانهيار في الصفوف الموجودة بالفعل، لذا لا تعد مزدوجة | +| بدأت تكامل جديد في الإبلاغ | عدد `agents` و `environments` وقائمة الجلسات | حدد نطاق إعدادات المجمع للآلة الجديدة قبل طرحها | -1. تأكد من المؤسسة ونافذة النشاط. -2. قارن الزيادة مع حجم الجلسات حسب البيئة. -3. تحقق مما إذا بدأت عملية دمج جديدة في إرسال النصوص. -4. راجع تغييرات التقييم وتكرار التدقيق. -5. قارن مقابل الحدود على خطة التسعير الحالية. +الاستخدام لا يقارن شيئاً مقابل خطة. افعل ذلك خارج المنتج. -تعيد واجهة سطر الأوامر نفس الملخص للسكريبتات. \ No newline at end of file + + + إعدادات التعامل مع البيانات لكل آلة خلف هذه الأرقام. + + + سطح `fp` الكامل، بما في ذلك التثبيت والدخول. + + \ No newline at end of file diff --git a/docs/ar/admin/users-and-organizations.mdx b/docs/ar/admin/users-and-organizations.mdx index 0ce50af87..188d3f215 100644 --- a/docs/ar/admin/users-and-organizations.mdx +++ b/docs/ar/admin/users-and-organizations.mdx @@ -1,21 +1,16 @@ --- -title: "المستخدمون والمؤسسات" -description: "التحكم في العضوية والحفاظ على نطاق بيانات وإجراءات كل مؤسسة." +title: "المستخدمون والمنظمات" +description: "تحكم في العضويات واحفظ بيانات وإجراءات كل منظمة في نطاق محدد." icon: "users" --- -تعزل المؤسسات الجلسات والتقييمات والتدقيقات والمشاكل والتنبيهات والاستعلامات لوحات المعلومات والمستخدمين والمفاتيح. تأكد من المؤسسة النشطة قبل تغيير الموارد الإدارية. +تعزل المنظمات الجلسات والتقييمات والتدقيقات والمشاكل والتنبيهات والاستعلامات وجداول المعلومات والمستخدمين والمفاتيح. تأكد من المنظمة النشطة قبل تغيير أي مورد إداري. -## إدارة الأعضاء والمؤسسات +## اختيار المنظمة - - 1. استخدم محول المؤسسة في أعلى الشريط الجانبي للسحابة لتبديل المؤسسات. - 2. انتقل إلى **Administration → Users** للبحث عن الأعضاء أو التصفية حسب حالة النشاط والدور. - 3. حدد **new user**، وأدخل البريد الإلكتروني، واختر مجموعة أذونات، وعدّل الاستثناءات إذا لزم الأمر. - 4. افتح مستخدماً لاحقاً لتحديث المنح أو تعطيل تسجيل الدخول أو إعادة تفعيل الحساب. - - ![صفحة Users تعرض عناوين بريد الأعضاء ومجموعات الأذونات وعناصر التحكم في التحرير والتعطيل.](/images/dashboard/users.png) + + استخدم محدد المنظمة في أعلى شريط الجانب في السحابة. كل ما يليه — بما في ذلك كل صفحة في **admin** — يقرأ ويكتب إلى هذه المنظمة. ```bash @@ -23,22 +18,62 @@ icon: "users" fp orgs switch reliability-team fp orgs current fp orgs perms + ``` + + `fp orgs switch` بدون معرف يفتح منتقي أسهم يبدأ من منظمتك الحالية؛ التشغيل غير التفاعلي يعود إلى طلب مرقم، وتحت `--json` يلزم معرف. يستمر الاختيار إلى `~/.failproofai/fpcli/cli-auth.json`، لذا تُرسل الأوامر اللاحقة المستأجر النشط. تجاوزه لأمر واحد باستخدام `--org ` أو `FP_ORG`. + + + + + كل أمر `fp orgs` يحتاج إلى شخص موقع ويرفض تحت مفتاح API، لأن عضوية المنظمة تنتمي إلى شخص والمفتاح يعمل بالفعل لمنظمة واحدة. أوامر `fp users` أدناه تعمل بكلا الطريقتين. + + +## إدارة الأعضاء + + + + 1. انتقل إلى **admin → users** وابحث عن الأعضاء حسب البريد الإلكتروني، أو ضيّق القائمة باستخدام شرائح الفلتر `protected` و `admin` و `standard` و `read-only`. + 2. اختر **new user**، أدخل البريد الإلكتروني، اختر مجموعة الأذونات، وأضبط التجاوزات الخاصة بكل عضو إذا لزم الأمر. + 3. افتح عضواً لاحقاً لتغيير الأذونات أو تعطيل تسجيل الدخول أو إعادة تفعيل الحساب. + ![صفحة المستخدمين مع صندوق البحث بالبريد الإلكتروني وشرائح الفلتر وبطاقة عضو توضح أذوناته مجمعة حسب المورد.](/images/dashboard/users.png) + + شرائح الأذونات في هذا الإطار أسبق من إعادة تسمية `incidents:*` إلى `issues:*`؛ قائمة [الأذونات الشائعة](/ar/admin/keys-and-permissions#common-permissions) محدثة. + + + ```bash + fp users list + fp users list --active-only fp users create engineer@example.com --permission-set standard fp users show engineer@example.com fp users update engineer@example.com --add audits:write fp users disable engineer@example.com fp users enable engineer@example.com ``` + + يتم توجيه الأعضاء بالبريد الإلكتروني وحلهم بعدم الحساسية لحالة الأحرف، لذا `fp users show Alice.Chen@Example.com` و `fp users create alice.chen@example.com` يشيران إلى نفس الشخص. -يمكن للمسؤولين إنشاء وتحديث وتعطيل وإعادة تفعيل المستخدمين، ثم تعيين مجموعة الأذونات المناسبة لدورهم. يستخدم API عملية حذف للتعطيل، لكنها لا تزيل الحساب أو سجل عضويته. +### الأذونات وما يحتاجه كل فعل + +تستخدم أذونات الأعضاء نفس الحساب مثل المفاتيح: الأذونات الفعلية هي `(set ∪ added) − removed`، و `--add` / `--remove` تأخذ رموز `slug:action.action` المختصرة حيث تتسع الإجراءات المنقوطة. انظر [المفاتيح والأذونات](/ar/admin/keys-and-permissions). + +| الفعل | الأذونة | ملاحظات | +| --- | --- | --- | +| `fp users list` / `show` | `users:read` | `--active-only` يخفي الأعضاء المعطلين. | +| `fp users create` | `users:create` | `--permission-set` يعين الدور؛ `--add` / `--remove` يطبقان تجاوزات. | +| `fp users update` | `users:update` | `--permission-set` **يستبدل** تجاوزات العضو الخاصة به؛ `--add` / `--remove` وحدهما متزايدان مقابل أذوناته الحالية. | +| `fp users disable` / `enable` | `users:delete` | كلاهما، بما في ذلك التفعيل — منح هذا بشكل مقصود. | + +يرفض التعطيل حالتين بشكل مباشر، كخطأ Forbidden وليس رسالة تحقق: لا يمكن تعطيل عضو **protected**، ولا يمكنك تعطيل حسابك الخاص. تعطيل عضو معطل بالفعل، أو تفعيل عضو نشط بالفعل، هو عدم تدخل هادئ. تستخدم API عملية حذف للتعطيل، لكنها لا تزيل الحساب أو سجل العضوية. + +تحكم إعدادات منظمتين في العضوية: `default_user_permissions` يحدد مجموعة الأذونات للدعوة الجديدة، و `allowed_sign_ins` يتحكم في العناوين التي يمكنها تلقي رمز تسجيل دخول. أدرها من [صفحة الإعدادات](/ar/admin/settings-and-security). - يؤدي تعطيل مستخدم إلى منع هذه الهوية من تسجيل الدخول إلى كل مؤسسة، وليس فقط المؤسسة المحددة حالياً. يستعيد إعادة التفعيل تسجيل الدخول العام وأذونات العضو في هذه المؤسسة. + تعطيل مستخدم يمنع هذه الهوية من تسجيل الدخول إلى كل منظمة، وليس فقط المنظمة المحددة حالياً. إعادة التفعيل تستعيد تسجيل الدخول العام وأذونات العضو في هذه المنظمة. - أعطِ حسابات الخدمة أسماء وصفية مرتبطة بعبء العمل والمالك. تجنب مشاركة المفاتيح بين المؤسسات أو بين الأشخاص والآلات. + أعط حسابات الخدمة أسماء وصفية مرتبطة بسير عمل والمالك. لا تشارك مفتاحاً بين المنظمات، أو بين شخص وآلة. \ No newline at end of file diff --git a/docs/ar/audits/alerts.mdx b/docs/ar/audits/alerts.mdx index 1442287d5..f0eacd434 100644 --- a/docs/ar/audits/alerts.mdx +++ b/docs/ar/audits/alerts.mdx @@ -1,63 +1,104 @@ --- --- title: "التنبيهات" -description: "كتشف تكرار الحادثة وأرسلها إلى المستجيبين المناسبين." +description: "كشف التكرار وتوجيه المشكلة إلى المستجيبين المناسبين." icon: "bell-ring" --- -تراقب التنبيهات حالة قابلة للقياس وتنشئ حادثة عندما تنطلق. استخدمها عندما يجب أن ينتج عن الفشل استجابة في الوقت المناسب، بغض النظر عما إذا كانت السياسة يمكنها حجبه أم لا. +يراقب التنبيه حالة قابلة للقياس ويفتح مشكلة عند تفعيله. استخدمه عندما يجب أن ينتج عن الفشل استجابة فورية، سواء كانت السياسة قادرة على حجبه أم لا. ## إنشاء واختبار تنبيه - 1. انتقل إلى **Analyze → Alerts** واختر **new alert**. يمكنك أيضًا البدء من رمز الجرس على خطأ تمثيلي. + 1. انتقل إلى **Analyze → Alerts** واختر **new alert**. يمكنك أيضًا البدء من أيقونة الجرس على خطأ تمثيلي. 2. أدخل الاسم والخطورة ونوع المشغل والشرط وفترة التقييم وعدد الانتهاكات والنافذة والقنوات. - 3. احفظ التنبيه وافتح صفحة التفاصيل الخاصة به وقم بتشغيل **test**. - 4. انتقل إلى **Analyze → Issues** للقبول والتعيين والنقاش والاشتراك والتحقق من الحوادث التي أنشأها التنبيه. + 3. احفظ التنبيه وافتح صفحة التفاصيل الخاصة به وشغّل **test**. + 4. انتقل إلى **Analyze → Issues** للإقرار والتعيين والمناقشة والاشتراك في المشاكل التي يفتحها التنبيه وحلها. - يحدد الجزء الأول من النموذج التنبيه والإشارة التي يجب أن تشغله. + يحدد الجزء الأول من النموذج التنبيه والإشارة التي يجب أن تفعله. - ![الجزء الأول من نموذج التنبيه الجديد مع اسمه وتفاصيله وحالة التفعيل ونوع المشغل.](/images/dashboard/alert-new-trigger.png) + ![الجزء الأول من نموذج new-alert مع اسمه وحالته المفعلة ونوع المشغل.](/images/dashboard/alert-new-trigger.png) - يتحكم الجزء الثاني في مدة استمرار الحالة وعدد مرات تقييمها وحيث يتم إرسال الإخطارات. + يتحكم الجزء الثاني في المدة التي يجب أن يستمر الشرط فيها، وعدد مرات تقييمه، وأين يتم إرسال الإخطارات. - ![الجزء الثاني من نموذج التنبيه الجديد مع منطق الانتهاك والجدول والخطورة وقنوات التسليم وإجراء الإنشاء.](/images/dashboard/alert-new-routing.png) + ![الجزء الثاني من نموذج new-alert مع منطق الانتهاك والجدول والخطورة وقنوات التسليم وإجراء الإنشاء.](/images/dashboard/alert-new-routing.png) - بعد الحفظ، استخدم قائمة التنبيهات للتأكد من تفعيل القاعدة وأن مشغلها ونافذتها وخطورتها وقنواتها تطابق ما كنت تقصده. + بعد الحفظ، استخدم قائمة التنبيهات للتأكد من تفعيل القاعدة وأن المشغل والنافذة والخطورة والقنوات تطابق ما قصدته. تُظهر البطاقة التي تحتوي على مشاكل مفتوحة العدد؛ تحذف البطاقة بدون مشاكل هذا السطر تمامًا، لذا غيابها لا يخبرك بشيء. لقراءة الرقم لكل قاعدة بما في ذلك الأصفار، استخدم `fp alerts show `، والذي يطبعها دائمًا. - ![صفحة التنبيهات تعرض قواعس التنبيهات مع مشغلاتها وفترات التقييم والقنوات والخطورة.](/images/dashboard/alerts.png) - - اختبر التنبيه قبل الاعتماد عليه للاستجابة الإنتاجية. + ![صفحة التنبيهات تعرض قواعس التنبيهات مع المشغلات ونوافذ التقييم والقنوات والخطورة.](/images/dashboard/alerts.png) - + ```bash fp alerts create high-errors \ --trigger-kind metric_threshold \ --severity warning \ - --trigger-spec '{"metric":"error_count","op":">","value":50,"window_secs":900}' + --trigger-spec '{"metric":"error_count","op":">","value":50,"window_secs":900}' \ + --eval-interval-secs 300 \ + --min-breaches 2 \ + --eval-window 3 fp alerts show high-errors fp alerts test high-errors fp alerts update high-errors --severity critical --yes ``` - استخدم `fp alerts list` لمراجعة القواعد و `fp alerts delete ` لحذف واحدة. + تبدأ التنبيهات الجديدة **مفعلة**، ويتم رفض تضارب الأسماء قبل إنشاء أي شيء. + + يستبدل `fp alerts update` التعريف الكامل من جانب الخادم، لذا يقرأ CLI التنبيه ويضع أعلامك فوقه — يحتاج التحديث الذي يحتوي على أعلام فقط على `alerts:read` **بالإضافة إلى** `alerts:write`، ويؤكد إلا إذا مررت `--yes`. + + استخدم `fp alerts list` لمراجعة القواعد و `fp alerts delete ` لإزالة واحدة. يعاين الحذف القاعدة — بما في ذلك عدد المشاكل المفتوحة — ويؤكد قبل التصرف، لأنه لا يمكن التراجع عنه. + + الحذف ليس الطريقة لتسكيت قاعدة مزعجة. `DELETE /alerts/{id}` يتسلسل: كل مشكلة فتحتها التنبيهات تذهب معها، تأخذ تعليقاتها والمشتركين وسجل النشاط. صندوق تأكيد CLI يعبر عن هذا بأن المشاكل المفتوحة يتم "حذفها بدون مالك"؛ عقد API هو حذف متسلسل، لذا تعامل مع السجل على أنه ذهب. لإيقاف تشغيل قاعدة والاحتفاظ بما سجلته، قم بإيقاف تشغيلها بدلاً من ذلك — نموذج التنبيهات على لوحة التحكم يحتوي على تبديل مفعّل، و لا يكشف `fp alerts create` و `fp alerts update` عن علم `--enabled`، لذا فإن مسار CLI هو `fp alerts update --file` مع تعريف كامل يحمل `enabled: false`. - اطلع على مرجع [`fp alerts`](/ar/reference/cloud-cli#alerts) للحصول على مجموعة أوامر التنبيه الكاملة. + راجع [مرجع `fp alerts`](/ar/reference/cloud-cli#alerts) للحصول على مجموعة أوامر التنبيهات الكاملة. -يمكن أن تكون شروط التنبيه مبنية على الأخطاء أو درجات التقييم أو تركيبات التقييم أو SQL مخصص. أضف المستقبلين واختبر القاعدة وافتح الحادثة الناتجة للقبول والتعيين والتعليق والاشتراك والتحقق منها. + + **test** يسلم إخطارات حقيقية. يرسل إلى قنوات البريد الإلكتروني و Slack والـ webhook الحقيقية للتنبيه ويفتح مشكلة اصطناعية، لذا يمكن أن ينبه من هو في الخدمة. يؤكد أولاً على محطة طرفية تفاعلية؛ `--yes` و `--json` و stdin المعاد توجيهه جميعًا يتخطون هذا الموجه. يبلغ الخادم أيضًا عن النجاح بمجرد التوزيع، لذا فإن الاختبار الأخضر يثبت أن الرسالة غادرت، وليس أنها وصلت. + + +## حدد المشغل + +هناك خمسة أنواع مشغلات: + +| `--trigger-kind` | يتفعل عندما | +| --- | --- | +| `metric_threshold` | تتجاوز مقياس حد معين — الأخطاء أو زمن الاستجابة أو التكلفة أو أي شيء آخر يمكنك قياسه. | +| `per_event` | يصل حدث مطابق واحد. | +| `evaluation_score` | تتجاوز درجة المقيّم حد معين. | +| `eval_compound` | يتم دمج عدة شروط درجات، مثل فشل اثنين من ثلاث درجات. | +| `custom_sql` | تُرجع استعلام تكتبه انتهاكًا. | -## تصميم التنبيه الجيد +يذهب الشرط نفسه إلى `--trigger-spec`، مشكل للنوع الذي اخترته. + +## ضبط أرقام التقييم + +تطلب نموذج لوحة التحكم و CLI نفس القيم الأربع. + +| الإعداد | العلم | القيم المقبولة | +| --- | --- | --- | +| الخطورة | `--severity` | `info`, `warning`, `critical` | +| فترة التقييم | `--eval-interval-secs` | 30–86,400 ثانية | +| عدد الانتهاكات | `--min-breaches` | واحد على الأقل، وليس أبدًا أكثر من النافذة | +| نافذة التقييم | `--eval-window` | واحد على الأقل، محسوبة بـ **intervals**، وليس بالثواني | + +لذا فإن `--eval-interval-secs 300 --min-breaches 2 --eval-window 3` يعني "قيّم كل خمس دقائق، وتفعّل عندما يكون اثنان من آخر ثلاث تقييمات قد انتهكا". + +## تصميم التنبيهات الجيدة - سمّ الحالة وسير العمل المتأثر. -- حدد البيئة بشكل صريح. -- عيّن نافذة وحد يتجنب الاستجابة لحدث واحد غير ضار. -- أضف رابطًا أو استعلامًا يقود المستجيبين إلى الجلسات. +- حدد البيئة بوضوح. +- ضع نافذة وحد يتجنب الرد على حدث واحد ضار. +- أضف ارتباط أو استعلام يوجه المستجيبين إلى الجلسات. - عيّن مالكًا قبل تفعيل القاعدة. +- تحقق من `fp alerts show ` من عدد المشاكل المفتوحة قبل إضافة قاعدة أخرى للأعراض نفسها. تطبع بطاقة لوحة التحكم هذا السطر فقط عندما يكون العدد غير صفر. - بعد حل نتيجة التدقيق، أضف تنبيهًا عندما قد يحدث نفس الفشل مرة أخرى خارج تغطية السياسة. - \ No newline at end of file + بعد حل نتيجة تدقيق، أضف تنبيهًا عندما يمكن أن يحدث نفس الفشل خارج تغطية السياسة. + + + + الإقرار والتعيين والتعليق والاشتراك والحل — سير العمل الذي ينزل فيه كل تنبيه متفعل. + \ No newline at end of file diff --git a/docs/ar/audits/cadence.mdx b/docs/ar/audits/cadence.mdx index 1b468c8a0..b97c6ddb0 100644 --- a/docs/ar/audits/cadence.mdx +++ b/docs/ar/audits/cadence.mdx @@ -1,27 +1,29 @@ --- -title: "تكرار التدقيق" +title: "دورة التدقيق" description: "اختر متى يتم تشغيل التدقيقات المتكررة وكمية البيانات التي تراجعها." icon: "calendar-clock" --- -استخدم التدقيقات المتكررة لأنماط الأعطال التي يمكن أن تعود مع تغير الوكلاء والمطالبات والأدوات والنماذج. +استخدم التدقيقات المتكررة لأنماط الفشل التي قد تظهر مجددًا مع تغير الوكلاء والمحفزات والأدوات والنماذج. -## غيّر الجدول الزمني +## تغيير الجدول الزمني 1. انتقل إلى **Analyze → Audits** وافتح التدقيق. - 2. افتح إعداداته وغيّر حالة التفعيل أو الفترة الزمنية أو إرساء التوقيت العالمي أو وضع النافذة أو المراجعة للخلف. - 3. احفظ التدقيق وأكّد وقت التشغيل التالي على بطاقة التدقيق. - 4. استخدم **run now** مرة واحدة بعد تغيير النطاق أو السياق الرئيسي. + 2. اختر **edit settings** وغيّر الدورة والنافذة والحساسية أو عدد النتائج في كل تشغيل. + 3. احفظ التدقيق وأكّد وقت التشغيل التالي في رأس التدقيق. + 4. توقف واستأنف الجدول الزمني من نفس الرأس، بجانب **run now**. + 5. استخدم **run now** مرة واحدة بعد تغيير كبير في النطاق أو السياق. - ![محرر التدقيق يعرض التكرار ونافذة الكسح والنطاق وإعدادات التحليل والسياق وقنوات الإخطار.](/images/dashboard/audit-edit.png) + ![رأس تدقيق يعرض حالة الإيقاف المؤقت والنتائج المفتوحة والتشغيل الأخير والتشغيل التالي ونافذة المسح والحساسية وعناصر التحكم run now و edit settings و resume.](/images/dashboard/audit-detail.png) ```bash fp audits edit checkout-reliability \ --schedule-interval-secs 86400 \ --schedule-anchor 2026-08-15T09:00:00Z \ + --window-mode since_last \ --lookback-window-secs 86400 \ --yes @@ -29,21 +31,50 @@ icon: "calendar-clock" fp audits edit checkout-reliability --enabled --yes ``` - انظر إلى [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لحدود الجدول الزمني وسلوك النافذة وجميع أوامر التدقيق. + يطلب `fp audits edit` تأكيدًا قبل تغيير أي شيء، ولهذا يمرر كل مثال هنا `--yes`. يستبدل الخادم التعريف بالكامل في كل تحرير، لذا تعيد CLI إرسال التدقيق الحالي مع تطبيق التغييرات — يحتاج التحرير الذي يتضمن الأعلام فقط إلى `audits:read` **وكذلك** `audits:write`. حدّد نطاق مفتاح CI لكليهما. + + انظر [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لحدود الجدول الزمني وسلوك النافذة وجميع أوامر التدقيق. -اختر التكرار بناءً على سرعة وتكلفة المخاطرة: +## حدا الجدول الزمني + +كل التوصيات أدناه يجب أن تناسب داخل هذه الحدود. النطاقات من الخادم، و`fp` يعكسها على الجانب الضيف، لذا القيمة خارج أحدها تخرج 2 محليًا بدلاً من أن تكلف جولة 422. + +| الحقل | العلم | النطاق | الافتراضي | +| --- | --- | --- | --- | +| فترة الجدول الزمني | `--schedule-interval-secs` | 3,600–604,800 ثانية (ساعة واحدة إلى 7 أيام) | 86,400 (يومي) | +| نافذة الاسترجاع | `--lookback-window-secs` | 3,600–7,776,000 ثانية (ساعة واحدة إلى 90 يومًا) | 604,800 (7 أيام) | + +سبعة أيام هي الحد الأقصى للدورة. لا يوجد تدقيق شهري في Cloud. -| نمط المخاطرة | التكرار الأولي | +## اختر دورة + +اختر من سرعة وتكلفة المخاطر: + +| نمط المخاطر | دورة البداية | | --- | --- | -| إجراء الإنتاج عالي التأثير | يومي | -| انحدار سير العمل أو النموذج | أسبوعي | -| مراجعة الحوكمة أو الوصول | شهري | -| تحقيق إصدار لمرة واحدة | تشغيل مرة واحدة | +| إجراء الإنتاج عالي التأثير | يومي، أو كل ساعة أثناء توجيه تغيير محفوف بالمخاطر | +| تراجع سير العمل أو النموذج | أسبوعي | +| مراجعة الحوكمة أو الوصول | أسبوعي — أطول فترة متاحة | + +وازن نافذة الاسترجاع مع الدورة حتى لا تترك التشغيلات فجوات ولا تفحص مجموعة سكانية كبيرة بلا داع بشكل متكرر. + +لا يوجد تدقيق لمرة واحدة؛ كل تدقيق يحمل فترة جدول زمني. للتحقيق من الإصدار، أنشئه مفعلاً، اترك التشغيل الأول ينطلق — يتم وضع التشغيل الأول في الطابور فورًا عند الإنشاء، بغض النظر عن الهدف — ثم أوقفه مؤقتًا باستخدام `fp audits edit --disabled --yes`. أعد التفعيل قبل استخدام **run now**: التدقيق المعطل ليس لديه صف قائمة انتظار، والتشغيل اليدوي عليه سيتم رفضه برمز 409. + +## وضع النافذة والهدف + +يقرر `--window-mode` نافذة كل تشغيل يقوم بمسحها: + +| الوضع | السلوك | +| --- | --- | +| `since_last` | المتابعة من نهاية النافذة المحللة بالكامل الأخيرة، لذا يترك التشغيل المتخطى بدون فجوة. | +| `fixed` | أعد فحص `lookback_window_secs` المتجدد في كل تشغيل، مهما كان ما غطاه التشغيل الأخير. | + +`--schedule-anchor` يثبت المرحلة بدلاً من التكرار: تهبط التشغيلات على `anchor + N × interval`. أغفله والهدف الافتراضي هو 09:00 UTC التالي؛ يتم رفض هدف أكثر من 365 يومًا. يدخل تغيير الفترة أو الهدف حيز التنفيذ في إعادة الجدولة التالية، وليس في التشغيل المصفوف بالفعل، والتشغيل الفاشل لا يحرك الهدف. -قم بمواءمة نافذة المراجعة للخلف مع التكرار بحيث لا تترك التشغيلات فجوات ولا تفحص مجموعة سكانية كبيرة بلا داع بشكل متكرر. بعد تغيير هدف التدقيق أو سياقه، قم بتشغيله يدويًا مرة واحدة قبل الاعتماد على النتيجة المجدولة التالية. +بعد تغيير هدف التدقيق أو سياقه، قم بتشغيله يدويًا مرة واحدة قبل الاعتماد على النتيجة المجدولة التالية. - يتم تكوين التدقيقات المجدولة المحلية على الجهاز وتفحص سجل الوكيل المحلي. جداول التدقيق السحابية تعمل على جلسات السحابة. تعامل مع نتائجها وملكيتها بشكل منفصل. + هذه الصفحة تتعلق بجداول تدقيق Cloud، التي تعمل على جلسات Cloud. التدقيق المحلي لديه مؤقت خاص به: `failproofai audit --schedule [days]` يأخذ 1–90 يومًا والافتراضي 7، ويمسح تاريخ الوكيل على تلك الآلة الواحدة، وهو السطح الوحيد مع خيار شهري. النتائج والملكية منفصلة عن أي شيء هنا — انظر [Audit local agent history](/ar/audits/local-audit). \ No newline at end of file diff --git a/docs/ar/audits/findings-and-issues.mdx b/docs/ar/audits/findings-and-issues.mdx index ae002177a..b04bb857a 100644 --- a/docs/ar/audits/findings-and-issues.mdx +++ b/docs/ar/audits/findings-and-issues.mdx @@ -1,94 +1,137 @@ --- --- title: "النتائج والمشاكل" -description: "حول أدلة التدقيق إلى عمل معالجة مملوك وقابل للتتبع." +description: "حوّل أدلة التدقيق إلى عمل إصلاح مملوك وقابل للتتبع." icon: "clipboard-check" --- -النتيجة هي البيان المدعوم بالأدلة من التدقيق حول فشل ما. المشكلة هي سير العمل الدائم للرد عليها. +النتيجة هي البيان المدعوم بالأدلة من التدقيق حول فشل ما. المشكلة هي سير العمل الدائم للاستجابة لها. -## فرز وإسناد العمل +يستخدم الكائنان مفردات مختلفة، وهما يقفان بجانب بعضهما البعض، لذا يستحق الأمر توضيح الفرق بينهما أولاً: + +| | النتيجة | المشكلة | +| --- | --- | --- | +| الحالات | `open`, `recurring`, `resolved`, `dismissed`, `muted` | `firing`, `acknowledged`, `resolved` | +| علم التصفية | `--status` | `--state` | +| المعرّف | معرّف النتيجة | معرّف المشكلة | +| الإدراج الافتراضي | المجموعة النشطة: مفتوحة وحالات متكررة | الأحدث مفتوحة أولاً | + +## فرز العمل وإسناده - - 1. افتح **تحليل → التدقيقات**، اختر جولة مكتملة، ثم حدد نتيجة لفحص تحليلها والتوصية والجلسات واستعلامات الأدلة. - 2. أقرّ أو أسند أو ارفض أو أسكت أو حل أو أعد فتح النتيجة بعد التحقق من أدلتها. - 3. انتقل إلى **تحليل → المشاكل** وصفّ صندوق الوارد الدائم حسب الحالة أو الخطورة أو المسؤول. - 4. افتح المشكلة لإسنادها وإضافة تعليقات أو مشتركين، وحلّها بعد التحقق من الإصلاح. + + 1. افتح **Analyze → Audits**، واختر عملية اكتملت، ثم حدد نتيجة للفحص تفصيلاً تحليلها وتوصياتها والجلسات واستعلامات الأدلة. + 2. اعترف بالنتيجة، أو أسندها، أو أرفضها، أو أكتمها، أو حلها، أو أعد فتحها بعد التحقق من أدلتها. + 3. انتقل إلى **Analyze → Issues** وصفّ صندوق الوارد الدائم حسب الحالة أو الخطورة أو المسؤول. + 4. افتح المشكلة لإسنادها وإضافة تعليقات أو مشتركين، ثم حلها بعد التحقق من الإصلاح. - ابدأ بملخص النتيجة. تأكد من أن وصف الفشل والاستجابة الموصى بها والخطورة والترتيب تتفق مع الجلسات التي توقعت أن يفحصها التدقيق. + ابدأ بملخص النتيجة. تأكد من أن وصف الفشل والاستجابة الموصى بها والخطورة والترتيب تتطابق مع الجلسات التي توقعت أن يفحصها التدقيق. - ![نتيجة تدقيق تعرض الخطورة وعدد الحدوث وتحليل السبب الجذري والإجراء الموصى به وعوامل الترتيب والأدلة.](/images/dashboard/audit-finding.png) + ![نتيجة تدقيق مع الخطورة وعدد الحالات والتحليل الجذري والإجراء الموصى به وعوامل الترتيب والأدلة.](/images/dashboard/audit-finding.png) - بعد ذلك، افتح جلسة متأثرة بدلاً من الاعتماد على الملخص وحده. يجب أن يظهر التتبع المرتبط الحدث الدقيق والحمل الذي يدعمان النتيجة. + بعد ذلك، افتح جلسة متأثرة بدلاً من القرار من الملخص وحده. يجب أن يُظهر التتبع المرتبط الحدث الدقيق والحمل الفعلي الذي يدعم النتيجة. - ![جلسة مرتبطة من نتيجة تدقيق، مفتوحة في الخطأ ذي الصلة مع بيانات وصفية الحدث والحمل الخام.](/images/dashboard/audit-linked-session.png) + ![جلسة مرتبطة من نتيجة تدقيق، مفتوحة في الخطأ ذي الصلة مع بيانات الحدث والحمل الخام.](/images/dashboard/audit-linked-session.png) - بعد التحقق من الأدلة، استخدم المشاكل لإعطاء الاستجابة مالكاً وتتبعها بشكل مستقل عن جولات التدقيق المستقبلية. + بعد التحقق من الأدلة، استخدم المشاكل لإعطاء الاستجابة مالكاً وتتبعها بشكل مستقل عن عمليات التدقيق المستقبلية. - ![صندوق الوارد للمشاكل يظهر العمل النشط والمقرّ والمحلول مع الخطورة والملكية.](/images/dashboard/incidents.png) + ![صندوق وارد المشاكل يوضح العمل الفعال والمعترف به والمحلول مع الخطورة والملكية.](/images/dashboard/incidents.png) - افتح المشكلة لتسجيل ملاحظات التحقيق وإخطار المشتركين والحفاظ على سجل الاستجابة. حلّها فقط بعد نشر المعالجة والتحقق منها. + افتح المشكلة لتسجيل ملاحظات التحقيق وإخطار المشتركين والحفاظ على سجل الاستجابة. حلها فقط بعد نشر التصحيح والتحقق منه. - ![عرض تفاصيل المشكلة مع مصدرها وأدلة الانتهاك والمسؤولين والمشتركين والخط الزمني والتعليقات.](/images/dashboard/incident-detail.png) + ![عرض تفاصيل المشكلة مع مصدرها وأدلة الاختراق والمسؤولين والمشتركين والجدول الزمني والتعليقات.](/images/dashboard/incident-detail.png) - + ```bash fp audits findings --audit checkout-reliability --status open fp audits finding fp audits ack --reason "owner assigned" fp audits assign --to engineer@example.com + fp audits mute --reason "expected in staging" --yes + fp audits dismiss --reason "false positive" --yes + fp audits resolve --yes + fp audits reopen - fp issues list + fp issues list --state firing fp issues show + fp issues ack fp issues assign --assignee engineer@example.com fp issues comment-add --body "policy is in observe mode" fp issues resolve --yes ``` - استخدم `fp issues subscribe ` و `fp issues unsubscribe ` و `fp issues subscribers ` لإدارة المراقبين. + `mute` و `dismiss` و `resolve` تخفي أو تغلق نتيجة، لذا يتم تأكيد كل منها أولاً — مرر `--yes` في البرامج النصية. `ack` و `reopen` و `assign` قيود حجزي قابلة للعكس وتعمل فوراً. `ack` و `mute` و `dismiss` تأخذ `--reason`، وتستحق التمرير: يتم الاحتفاظ بها كملاحظات دائمة على النتيجة، وليس مكتوبة في سجل ومنسية. `resolve` و `reopen` و `assign` لا تأخذ سبباً. + + الإسناد يعمل بشكل مختلف على كل كائن. `fp audits assign` يتطلب `--to ` ويعيّن مالكاً واحداً؛ إعادة تشغيله تعيد الإسناد. `fp issues assign` يأخذ `--assignee` قابل للتكرار و**يستبدل** القائمة بأكملها، لذا حذفها يمسح كل مسؤول. + + استخدم `fp issues comment-list ` و `fp issues count --state firing` و `fp issues subscribe`/`unsubscribe`/`subscribers ` لبقية سطح المشكلة. - انظر [مرجع Cloud CLI للتدقيق والمشاكل](/ar/reference/cloud-cli#audits) لنتائج التدقيق و [`fp issues`](/ar/reference/cloud-cli#issues) لإدارة المشاكل. + اطّلع على [مرجع Cloud CLI للتدقيق والمشاكل](/ar/reference/cloud-cli#audits) لنتائج التدقيق و [`fp issues`](/ar/reference/cloud-cli#issues) لإدارة المشاكل. ## مراجعة نتيجة -تأكد من أنها تحتوي على: +يقرر حقلان ما يجب فعله بها قبل أي شيء آخر. + +**`kind`** يفصل بين `failure` (حدث خطأ ما) و `policy` انتهاك (قاعدة تم كسرها) و `improvement` (يمكن أداء العمل بشكل أفضل). يتم عرضه كشارة على النتيجة. نتيجة `policy` هي التي يمكن لسياسة ما إغلاقها؛ الاثنان الآخران يحتاجان عادة إلى تغيير سير عمل أو تنبيه أو تدخل بشري. + +**`priority`** درجة من 0–1، تُحسب مرة أخرى لكل عملية، وهي الترتيب الذي يتم فيه فرز صف النتائج. تقسمها صفحة النتيجة تحت **لماذا تحتل هذا الترتيب**، كقيمة × وزن: + +| العامل | الوزن | +| --- | --- | +| التغطية | 0.30 | +| الخطورة | 0.25 | +| الحجم | 0.25 | +| حداثة العهد | 0.20 | + +ثم تأكد من أن النتيجة تحتوي على: -- وضع فشل مستقر، وليس فقط عنوان لمرة واحدة +- نمط فشل ثابت، وليس فقط عنوان لحالة واحدة - الخطورة والتأثير التشغيلي -- معرّفات الجلسة المتأثرة أو الاستعلامات الداعمة +- معرّفات الجلسات المتأثرة أو الاستعلامات الداعمة - سياق كافٍ لإعادة إنتاج السلوك - استجابة مقترحة تتطابق مع الأدلة +لإعادة إنتاج نتيجة، اسحبها بالكامل: `fp --json audits finding ` يُرجع السجل الكامل مع `evidence` و `evidence_queries` و `scope` دون تعديل، وهذا هو التحليل الذي تم تشغيله فعلاً. `--json` خيار عام، لذا يأتي قبل الأمر. + ## استخدم مشكلة لإدارة الاستجابة -أنشئ أو ربط مشكلة عندما تحتاج النتيجة إلى إسناد أو نقاش أو تغييرات في الحالة أو تعليقات أو مشتركين. يمكن للمشاكل أن تمثل أيضاً حوادث التنبيهات والمشاكل المبلّغ عنها يدويّاً، وهذا هو السبب في أنها توجد تحت استجابة التدقيق وليس في الملاحة الأساسية. +أنشئ أو ربط مشكلة عندما تحتاج النتيجة إلى إسناد أو نقاش أو تغييرات حالة أو تعليقات أو مشتركين. يسجل `source` المشكلة مصدرها — `audit` أو `alert` أو `manual` — وهذا السبب في أن لوحة التحكم تعطي المشاكل عرضها الخاص **Issues** بدلاً من دمجها تحت تدقيق. + +الاشتراك جزئياً تلقائي. يتم الاشتراك للأشخاص عندما يعترفون بمشكلة أو يعلقون عليها أو يتم إسنادهم إليها أو يفتحونها — `fp issues subscribers` يسرد المشتركين النشطين فقط، لذا فهو ليس مجرد قائمة الاشتراكات اليدوية. يُرسل تعليق بريداً إلكترونياً لكل مشترك نشط، والتعليق يحتاج فقط إلى `issues:read`، لذا لن يكون المراجع القراءة فقط ملاحظاً صامتاً. -حل المشكلة عند نشر المعالجة والتحقق منها. حل النتيجة عندما يتم معالجة وضع الفشل لمجموعة التدقيق. قد تختلف هذه اللحظات. +حل المشكلة عندما يتم نشر التصحيح والتحقق منه. حل النتيجة عندما تتم معالجة نمط الفشل لمجموعة التدقيق. قد تختلف هذه اللحظات. ## حوّل مشكلة إلى مسودة سياسة - - 1. افتح المشكلة وتحقق من نتيجتها والجلسات المُستشهد بها والسبب الجذري والتوصية. - 2. حدد **إنشاء سياسة** وراجع نتيجة الأهلية والنية الفرض المقترحة. نتيجة **لا توجد سياسة** تعني أن السلوك قد يتطلب تنبيهاً أو تغييراً في سير العمل أو استجابة بشرية بدلاً من ذلك. - 3. حدد **اكتب هذه السياسة**، ثم راجع واختبر المصدر المُنشأ في **الإدارة → محرر السياسة** قبل تحديد **نشر الإصدار**. استخدم **افتح المحرر على أي حال** عندما تختلف مع فحص الأهلية. - 4. انتقل إلى **الإدارة → الفرض**، ونشّر الإصدار في وضع **مراقبة** والتحقق من قراراته تحت **مراقبة → السياسة** قبل فرضها. + + 1. افتح المشكلة وتحقق من نتيجتها والجلسات المذكورة والسبب الجذري والتوصية. + 2. حدد **generate policy** واستعرض نتيجة التأهل والنية الإنفاذية المقترحة. تعني نتيجة **no policy** أن السلوك قد يتطلب تنبيهاً أو تغيير سير عمل أو استجابة بشرية بدلاً من ذلك. + 3. حدد **write this policy**، ثم استعرض واختبر المصدر المُنتج في **Admin → policy editor** قبل تحديد **publish version**. استخدم **open the editor anyway** عندما تختلف مع فحص التأهل. + 4. انتقل إلى **Admin → enforcement**، ونشّر الإصدار في نمط **observe**، والتحقق من قراراته تحت **Observe → policy** قبل إنفاذه. - عنوان المشكلة ووصف النتيجة والسبب الجذري والتوصية ونية الأهلية تساعد في تكوين المسودة. لا شيء يتم نشره أو نشره تلقائيّاً. + يساعد عنوان المشكلة ووصف النتيجة والسبب الجذري والتوصية ونية التأهل في تأليف المسودة. لا يتم نشر أو نشر أي شيء تلقائياً. - - استخدم واجهة سطر الأوامر للتحقق من الأدلة قبل فتح المشكلة في لوحة المعلومات: + + استخدم CLI للفحص من الأدلة قبل فتح المشكلة في لوحة التحكم: ```bash fp issues show - fp audits finding + fp --json audits finding fp events --session-id --full --all ``` - أهلية السياسة ونشر Cloud ونشر الأسطول هي سير عمل لوحة المعلومات. استخدم `failproofai policies --install --custom ` عندما تريد التحقق من صحة مصدر السياسة المعادل محليّاً أولاً. + لوحة التحكم مسار واحد؛ CLI مسار آخر. `fp policies compose ""` تصيغ سياسة، `fp policies publish ./policy.mjs` تضرب إصدار (النشر لا ينشر أي شيء)، و `fp fleet deploy --add :observe` تضعها على جهاز في الظل. لاحقة `:observe` مطلوبة — `--add ` المجردة تنفذ فوراً. اقرأ ما كانت ستفعله مع `fp guardrails summary --since 24h`، ثم ارقَ مع `--add :enforce`. + + لمحاولة مصدر سياسة معادل على جهازك الخاص أولاً، وجّه CLI المحلي للملف: + + ```bash + failproofai policies -i -c ./checkout-policies.js + ``` + + ملف ينتهي اسمه بـ `policies.js` أو `policies.mjs` أو `policies.ts`، مُسقط في `.failproofai/policies/` في المشروع أو تحت `~/`، يتم تحميله عند كل حدث hook بدون أي أعلام على الإطلاق. diff --git a/docs/ar/audits/local-audit.mdx b/docs/ar/audits/local-audit.mdx index 882697fef..ac23fac8d 100644 --- a/docs/ar/audits/local-audit.mdx +++ b/docs/ar/audits/local-audit.mdx @@ -1,74 +1,57 @@ --- +--- title: "تدقيق سجل الوكيل المحلي" -description: "امسح سجلات CLI للوكيل المدعومة دون الاتصال بالإنترنت وراجع السلوك المحفوف بالمخاطر أو الهدر محليًا." +description: "مسح سجل الوكيل على هذا الجهاز بحثاً عن سلوك محفوف بالمخاطر أو مهدر." icon: "laptop-minimal-check" --- -استخدم التدقيق المحلي لمراجعة فورية وخاصة قبل توصيل جهاز بـ Failproof AI Cloud. يقوم بمسح سجلات الوكيل المخزنة بالفعل على جهازك، وتشغيل نشاط الأداة من خلال السياسات المدمجة، وفتح لوحة نتائج محلية. - -## تشغيل تدقيق تفاعلي +يقرأ التدقيق المحلي سجل الوكيل الموجود بالفعل على هذا الجهاز ويفتح النتائج في `http://localhost:8020/audit`. لا يتطلب حساباً. - - - يبدأ التدقيق المحلي من سطر الأوامر لأنه يجب أن يكتشف السجلات على الجهاز الحالي. قم بتشغيل `failproofai audit`؛ بعد المسح، يبدأ Failproof AI لوحة المعلومات المرفقة ويفتح **http://localhost:8020/audit**. +```bash +failproofai audit +``` - في عرض التدقيق، راجع عدد الجلسات واستدعاءات الأداة والمشاريع والنتائج المتعلقة بالسياسة. ابدأ بالنتائج المتكررة، ثم افحص المشروع المتأثر وسجل الوكيل قبل تفعيل الإنفاذ. +يغطي المسح السجل من جميع أجهزة التشغيل المدعومة التي يجدها. يعيد تشغيل كتالوج السياسات المدمج المكون من 39 سياسة في هذا الإصدار؛ لا يتم تضمين الحزم المثبتة والسياسات المخصصة. - لوحة معلومات التدقيق المحلية منفصلة عن **Analyze → Audits** في Failproof AI Cloud. التدققيقات المحلية تبقى على الجهاز ولا تتطلب حسابًا أو اتصالاً بالشبكة. - - - ```bash - npm install -g failproofai - failproofai audit - ``` +## قراءة النتيجة - الأمر يجري مسحًا كاملاً لكل سجل مدعوم يجده. الأمر الحالي لا يقبل عوامل تصفية مثل `--since` أو `--cli` أو `--project` أو `--port` أو `--no-open`. +ابدأ بالنتائج الأكثر تكراراً، ثم افتح الجلسة المتأثرة قبل تفعيل الفرض. - اترك العملية قيد التشغيل أثناء استخدام لوحة المعلومات المحلية. اضغط على Ctrl+C عند الانتهاء. - - +ثلاثة حدود مهمة: -محولات التدقيق الحالية يمكنها قراءة السجلات من Claude Code و Codex و GitHub Copilot CLI و Cursor و OpenCode و Pi و Hermes و OpenClaw و Factory و Devin و Antigravity و Goose. يتم مسح السجلات المتاحة محليًا فقط. +- يعيد التدقيق بناء أحداث الأدوات، وليس `Stop`، لذلك سياسات `require-*-before-stop` لا تظهر. +- ثمانية فحوصات "Audit-only" تحدد الأنماط المهدرة دون وجود سياسة مطابقة دقيقة. +- يتم تخطي `warn-repeated-tool-calls` لأن إعادة تشغيله ستعدّل الحالة على جانب النسخ. -## جدولة التدققيقات المحلية المتكررة +للحصول على نتيجة قابلة للفرض، استخدم أمر السياسة الموضح في النتيجة. افحص [دعم فرض جهاز التشغيل](/ar/reference/harnesses#enforcement-capability) قبل الاعتماد عليه. - - - افتح **Settings** في لوحة المعلومات المحلية، وفعّل التدققيقات المجدولة، واختر الفاصل الزمني، وعيّن عنوان البريد الإلكتروني الذي يجب أن يستقبل النتائج. تحدّث لوحة المعلومات وسطر الأوامر نفس إعدادات الجهاز. - - - فعّل تدقيقًا أسبوعيًا وأرسل النتائج إلى العنوان المحدد: +تعيش النتيجة المخزنة مؤقتاً في `~/.failproofai/audit/dashboard.json` وتنتهي صلاحيتها بعد سبعة أيام. - ```bash - failproofai audit --schedule 7 --email reliability@example.com - failproofai audit --status - ``` +## جدولة المسح - يقبل الفاصل الزمني 1-90 يومًا ويعود إلى 7 عند إغفاله. يوقع عليك الإعداد الأول عند الحاجة؛ يوفر `--email` عنوان التقرير دون طلب. +```bash +failproofai audit --schedule 7 +failproofai audit --status +failproofai audit --no-schedule +``` - أوقف الجدول دون حذف سجل التدقيق المحلي: +يقبل الفاصل الزمني 1–90 يوماً وافتراضياً 7. تتطلب الجدولة لأول مرة تسجيل دخول تفاعلي. يجب أن تكون خدمة الخلفية قيد التشغيل. - ```bash - failproofai audit --no-schedule - ``` - - +### ما يترك الجهاز -يشغّل الخادم عمليات المسح المجدولة في الخلفية، وينعش النتيجة المخزنة مؤقتًا المستخدمة من قبل لوحة المعلومات المحلية، ويرسل التقرير المُعد. استخدم `failproofai audit` عندما تريد تشغيل مسح تفاعلي فورًا. +لا يرسل التدقيق التفاعلي أي نتائج. قياس المسافة البادئة المجهول لواجهة سطر الأوامر مفعّل بشكل افتراضي؛ عطّله باستخدام `FAILPROOFAI_TELEMETRY_DISABLED=1`. -## الانتقال من الأدلة المحلية إلى عمليات Cloud +بعد اختيارك للجدولة، يرسل كل مسح مجدول معرّف الجهاز والتسمية والنظام الأساسي ونافذة المسح. إذا تم العثور على أنماط ضارة، فإنه يرسل أيضاً ملخصاً محدوداً يتضمن العدد والطوابع الزمنية وحتى ثلاثة أمثلة معدلة. لا ترسل المسحات النظيفة أي نتائج وبلا بريد إلكتروني. -التدقيق المحلي أساس سريع. وصّل الجهاز بـ Failproof AI Cloud عندما تحتاج إلى تتبعات مشتركة أو تدققيقات سكانية متكررة أو نتائج ومشاكل أو تنبيهات أو نشر السياسات على مستوى المنظمة أو صحة الأسطول. + + نتائج التدقيق هي أدلة للمراجعة، وليست إثباتاً بأن كل إجراء مميز غير آمن. تحقق من الجلسة قبل تحويل النتيجة إلى فرض محظور. + - - حدد هدفًا متكررًا وسكانًا ونافذة أدلة وقنوات الاستجابة. + + قم بتشغيل التدقيقات المشتركة المتكررة عبر الوكلاء والأجهزة. - - تحقق محليًا وانشر بشكل مقصود وأطلق النشر على مجموعة جهاز ضيقة أولاً. + + أضف السياسات المراجعة بعد تأكيد النتيجة. - - - - مخرجات التدقيق أدلة للمراجعة، وليست دليلاً على أن كل إجراء معلم غير آمن. أكد السياق قبل تحويل النتيجة إلى إنفاذ حجب. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/ar/audits/overview.mdx b/docs/ar/audits/overview.mdx index 953324399..7dd9e5879 100644 --- a/docs/ar/audits/overview.mdx +++ b/docs/ar/audits/overview.mdx @@ -1,56 +1,64 @@ --- -title: "التدقيقات" -description: "راجع مجموعة محددة من الجلسات للبحث عن الأخطاء التي لن تكشفها آثار البيانات وحدها." +title: "التدقيق" +description: "ابحث عن تشغيل الوكلاء للعثور على الإخفاقات المتكررة والسلوكيات المخاطرة والجهود المهدرة." icon: "scan-search" --- -يقوم التدقيق بالبحث في مجموعة مختارة من الجلسات عن هدف فشل محدد. يجمع بين أدلة التتبع ونتائج التقييم وضربات السياسة والسياق المرجعي لإنتاج نتائج يمكنك التصرف بناءً عليها. +يقوم التدقيق بمراجعة عمليات تشغيل الوكيل العديدة مقابل هدف محدد ويعيد نتائج مدعومة بالأدلة.
-انظر كيف ينتقل التدقيق من تشغيل مجدول إلى أخطاء مدعومة بأدلة يمكنك إصلاحها. +## محلي أو سحابي -## فتح التدقيقات +| | تدقيق محلي | تدقيق سحابي | +| --- | --- | --- | +| الأمر | `failproofai audit` | `fp audits` | +| القراءة من | سجل الوكيل على هذا الجهاز | الجلسات في منظمتك السحابية | +| ينتج | نتائج محلية على `localhost:8020/audit` | النتائج والمشاكل والتنبيهات المشتركة | +| يتطلب | لا يوجد حساب | اتصال سحابي ومفتاح API | - - - انتقل إلى **تحليل → التدقيقات**. تعرض الصفحة حالة الجدولة والنتائج المفتوحة والتشغيل الأخير والتشغيل التالي والتكرار وما إذا كان للتدقيق صفحات ملخص أو مرجعية. حدد بطاقة للإعدادات وسجل التشغيل؛ حدد **تدقيق جديد** لإنشاء واحد. +استخدم التدقيق المحلي لمراجعة سريعة لجهاز واحد. استخدم السحابة عندما تحتاج فريق إلى تدقيق متكرر عبر الوكلاء والأجهزة. - ![صفحة التدقيقات تعرض التدقيقات المتكررة مع جدولها والحساسية وحالة التشغيل.](/images/dashboard/audits.png) - - - ```bash - fp audits list - fp audits list --enabled-only --show-id - fp audits show - fp audits findings --status open --limit 20 - ``` - - +## الأسئلة التي يمكن للتدقيق الإجابة عليها -استخدم التدقيق عندما تحتاج للإجابة على سؤال على مستوى المجموعة مثل: +- أين يتوقف الوكلاء دون التصعيد؟ +- أي أعطال الأدوات تؤدي إلى إعادة محاولات غير فعالة؟ +- هل يقوم الوكلاء بالوصول إلى البيانات خارج سير العمل المقصود؟ +- ما الذي تغير بعد تحديث النموذج أو الموجه أو الأداة؟ -- أين يتخلى الوكلاء عن المهام دون تصعيد؟ -- أي أخطاء في الأدوات تؤدي إلى إعادة محاولات غير فعالة؟ -- هل يصل الوكلاء إلى البيانات خارج سير العمل المقصود؟ -- ما الذي تغير بعد إصدار نموذج أو موجه أو أداة؟ +## فتح تدقيقات السحابة -## تدفق استجابة التدقيق +انتقل إلى **Analyze → Audits**، أو استخدم: + +```bash +fp audits list +fp audits show +fp audits findings --status open --limit 20 +``` + +تستخدم أوامر التدقيق اسم التدقيق أو معرفه الكامل. تُستشهد بالنتائج من خلال معرفها الخاص. + +## من النتيجة إلى الوقاية ```text Session → Audit → Finding → Issue → Policy - ↘ Alert for recurrence + ↘ Alert ``` -يجب أن تسمي النتيجة نمط الفشل وتشير إلى الأدلة. تملك المشكلة الإصلاح. تمنع السياسة نمط إجراء معروف؛ تكتشف التنبيهات التكرار عندما لا يكون الحد من الأضرار ممكناً أو يحتاج إلى مراقبة. +تشير النتيجة إلى الأدلة. تمتلك المشكلة الرد. تمنع السياسة نمط إجراء معروف؛ التنبيه يراقب تكرار الحدوث. + +لا يجب أن تصبح كل نتيجة سياسة. تصف نتيجة `policy` قاعدة قابلة للتطبيق. قد تحتاج `failure` أو `improvement` إلى سير عمل أو موجه أو نموذج أو تغيير أداة بدلاً من ذلك. - - - حدد الهدف والمجموعة والسياق المرجعي قبل التشغيل الأول. + + + امسح السجل المحلي بدون حساب. + + + اختر الهدف والجلسات والجدول الزمني. - - اذكر ما يجب على كل وكيل إنتاجه وما يجب ألا يفعله أبداً. + + فرز الأدلة وتعيين رد. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/ar/audits/recipes.mdx b/docs/ar/audits/recipes.mdx index aba63e3e4..e7603ca06 100644 --- a/docs/ar/audits/recipes.mdx +++ b/docs/ar/audits/recipes.mdx @@ -1,54 +1,94 @@ --- +--- title: "وصفات التدقيق" -description: "أهداف البداية للتحقيقات الشائعة لأعطال الوكيل." +description: "أهداف ابتدائية للتحقيقات الشائعة لحالات فشل الوكيل." icon: "book-open-check" --- -استخدم هذه كأهداف بداية، ثم أضف وكيلك وبيئتك وسير العمل المتوقع. +استخدم هذه كأهداف ابتدائية، ثم أضف وكيلك وبيئتك وسير العمل المتوقع. - انتقل إلى **Analyze → Audits → New audit**، انسخ إحدى الوصفات في الوصف أو الملخص، ثم أضف البيئة والوكيل والفترة الزمنية ورابط المراجع ذات الصلة. أنشئ التدقيق وتفحص التشغيل الأول قبل جدولته. + انتقل إلى **Analyze → Audits → New audit**. سطر الوصفة من هذه الصفحة هو **الوصف** — ما تتوقع أن يكتشفه هذا التدقيق. قواعد سير العمل التي تجعل الهدف قابلاً للحكم عليه تذهب في **ملخصك**، في بطاقة **ما يعرفه**: خلفية يقرأها النموذج قبل أن ينظر إلى حدث واحد، محدود بـ 8,192 حرف، مضافة إلى ما يبحث عنه التدقيق بالفعل. الملخص ليس أبداً بديلاً للهدف وليس أبداً دليلاً على النتيجة. - يحول نموذج التدقيق الجديد الوصفة إلى فحص فشل قابل للتنفيذ بإضافة النطاق والسياق والإيقاع والإخطارات. + بعد ذلك حدد النطاق في **ما يقرأه**، لأن نصف هذه الوصفات هي ضوضاء بدونه. البيئات والوكلاء يضيقان المجموعة؛ **الأخطاء المراد تجاهلها** تسرد أنواع الأخطاء التي تتوقعها وتتعامل معها بالتصميم، لذا تتوقف عن حساب الفشل. يأخذ أسماء أنواع الأخطاء فقط، وهو ما يمنع وصفة حلقة إعادة المحاولة من الفيضان. - ![نموذج التدقيق الجديد المكون بهدف مركز وجدول زمني ونطاق الوكيل والبيئة والسياق وقنوات الإخطار.](/images/dashboard/audit-new.png) + يحول نموذج التدقيق الجديد الوصفة إلى فحص فشل قابل للتنفيذ بإضافة النطاق والسياق والتكرار والإخطارات. - بعد الإنشاء، تأكد من ظهور التدقيق في القائمة بالحالة والجدول الزمني المتوقع قبل الاعتماد على التشغيلات المتكررة. + ![نموذج التدقيق الجديد المكون بهدف مركز، وجدول زمني، ونطاق الوكيل والبيئة، والسياق وقنوات الإخطار.](/images/dashboard/audit-new.png) - ![صفحة التدقيقات حيث تظهر وصفة التدقيق الخاصة بسير العمل بعد الإنشاء.](/images/dashboard/audits.png) + بعد الإنشاء، تأكد من ظهور التدقيق في القائمة بالحالة والجدول الزمني المتوقع قبل الاعتماد على الأشواط المتكررة. - افتح التشغيل الأول وقم بتحسين الوصفة إذا كانت نتائجها أوسع أو أضيق من نمط الفشل المقصود. + افتح الشوط الأول وحسّن الوصفة إذا كانت نتائجها أوسع أو أضيق من وضع الفشل المقصود. احفظ الوصفة كملف نصي وأرفقها أثناء الإنشاء: ```bash fp audits create retry-loop-review \ + --description "Find agents that repeat a failing tool call without changing anything" \ --scope '{"environments":["production"]}' \ + --ignore-error-type RateLimitRetried \ --text-file ./retry-loop-audit.txt \ --schedule-interval-secs 86400 ``` + + `--text` و`--text-file` هما طريقتان لإرسال نفس الملخص؛ مرّر واحد، وليس كليهما. أضف صفحات مرجعية باستخدام `--url`، حتى خمسة، `https://` عام فقط. أرسل كل شيء مع طلب الإنشاء: التدقيق الممكن الجديد يستحق فوراً، لذا قد يفتقد السياق المكتوب في استدعاء ثان الشوط الأول. +## احكم على الوصفة، وليس فقط على الصيغة + +يحرك إعدادان النتيجة أكثر من الصيغة. **الحساسية** (`low`، `medium`، `high`، الافتراضي `medium`) تحدد مدى رغبة الشوط في تحديد نمط؛ **النتائج لكل شوط** (`--top-k`، الافتراضي 50) يحد من عدد ما يحتفظ به. ارفع الحساسية لسؤال حيث يكلف الخطأ أكثر من الإيجابية الخاطئة، واخفضها لنمط الحجم الذي سيملأ الطابور بطريقة أخرى. كل وصفة أدناه تسمي نقطة انطلاق — غيرها بعد قراءة الشوط الأول، وليس قبله. + +التخلي عن المهمة والتصعيد البشري المفقود هما أحكام ضد ما كان يجب أن يفعله الوكيل، وليس ضد خطأ أثاره. اكتب أولاً [سياق الوكيل](/ar/audits/agent-contracts) لهذا الوكيل، أو لن يكون للتحليل معيار للحكم بناءً عليه. + - - ابحث عن الجلسات التي يكرر فيها الوكيل نفس استدعاء الأداة الفاشلة دون تغيير الإدخال أو اختيار أداة بديلة أو التصعيد إلى شخص ما. + + ابحث عن جلسات حيث يكرر الوكيل استدعاء الأداة الفاشلة ذاتها بدون تغيير الإدخال، أو اختيار أداة بديلة، أو التصعيد إلى إنسان. + + ابدأ بـ `medium`، وأدرج أنواع الأخطاء التي تعيد محاولتها بهدف تحت **الأخطاء المراد تجاهلها**. - - ابحث عن الجلسات التي لا تطابق فيها الأداة المختارة المهمة المذكورة، أو حيث يخالف إدخال الأداة الشروط المسبقة المطلوبة لسير العمل. + + ابحث عن جلسات حيث الأداة المختارة لا تتطابق مع المهمة المذكورة، أو حيث إدخال الأداة ينتهك الشروط المسبقة المطلوبة لسير العمل. + + ابدأ بـ `medium`. ضع الشروط المسبقة نفسها في الملخص؛ بدونها ليس للتحليل قاعدة للتحقق منها. - - ابحث عن الجلسات التي تقرأ أو تكتب أو تنقل بيانات حساسة خارج المسارات والخدمات المعتمدة لهذا الوكيل. + + ابحث عن جلسات تقرأ أو تكتب أو تنقل بيانات حساسة خارج المسارات والخدمات المعتمدة لهذا الوكيل. + + ابدأ بـ `high`. الخطأ المفقود يكلف أكثر من إيجابية خاطئة ترفضها مرة واحدة. - ابحث عن الجلسات التي تنتهي بدون النتيجة المطلوبة أو خطأ واضح أو تسليم صريح لشخص ما. + ابحث عن جلسات تنتهي بدون النتيجة المطلوبة، أو خطأ واضح، أو تسليم صريح إلى إنسان. + + ابدأ بـ `medium`، واكتب قسم **تمام عندما** للوكيل أولاً — هذه الوصفة هي حكم ضده. - - ابحث عن الجلسات التي تتجاوز فيها مدة النموذج أو الأداة أو الإجمالية الميزانية المتوقعة، وحدد نمط الحدث المسؤول. + + ابحث عن جلسات يتجاوز فيها النموذج أو الأداة أو المدة الإجمالية الميزانية المتوقعة، وحدد نمط الحدث المسؤول. + + ابدأ بـ `low` وارفعها إذا كان الشوط الأول رقيقاً. الميزانيات تنتمي للملخص، وأي نوع خطأ يثيره مسار بطيء بالتصميم ينتمي **للأخطاء المراد تجاهلها**. - - ابحث عن الجلسات التي تطلبت فيها الثقة أو الفشل المتكرر أو التوجيه السياساتي قرار بشري لكن الوكيل استمر بشكل مستقل. + + ابحث عن جلسات حيث الثقة، أو الفشل المتكرر، أو إرشادات السياسة تتطلب قرار بشري لكن الوكيل استمر بشكل مستقل. + + ابدأ بـ `high`، وحدد قاعدة التصعيد في قسم **يجب ألا** للوكيل لذا يصنف التحليل بناءً عليه. - \ No newline at end of file + + +## احصل على إجابة أولى قبل إنشاء أي شيء + +عدة من هذه الأنماط لديها بالفعل كواشف دون اتصال في التدقيق المحلي، الذي يقرأ سجلات الوكيل على آلتك الخاصة ولا يحتاج إلى حساب: + +| الكاشف | النمط الذي يحسبه | +| --- | --- | +| `sleep-polling-loop` | `sleep` طويلة، أو حلقة استقصاء `while … sleep … done` | +| `reread-after-edit` | قراءة ملف عدّله الوكيل للتو أو كتبه | +| `find-from-root` | `find` ضد `/` أو دليل عالي المستوى آخر | +| `redundant-cd-cwd` | `cd` في الدليل الذي يكون فيه الصدفة بالفعل | +| `prefer-edit-over-read-cat` | `cat`، `head`، `tail`، `less`، أو `more` على ملف مصدر واحد | +| `prefer-edit-over-sed-awk` | تحريرات موضعية عبر `sed -i` أو `awk … > file` | +| `prefer-write-over-heredoc` | محتوى متعدد الأسطر مكتوب عبر heredoc أو `echo > file` | +| `git-commit-no-verify` | `git commit --no-verify`، تخطي الخطاطيف | + +هذه الكواشف تحسب؛ لا تحجب، وليس أحدها يقيس التكلفة أو الكمون. شغّل `failproofai audit` لترى أي أنماط صدفة مسرفة وخطرة ينتجها وكلاؤك بالفعل قبل أن تدفع لتدقيق Cloud على نفس الأساس — انظر [التدقيق المحلي لسجل الوكيل](/ar/audits/local-audit). \ No newline at end of file diff --git a/docs/ar/audits/run.mdx b/docs/ar/audits/run.mdx index bc0253a86..8e55c2f56 100644 --- a/docs/ar/audits/run.mdx +++ b/docs/ar/audits/run.mdx @@ -1,24 +1,23 @@ --- ---- -title: "تشغيل المراجعة والتحقق منها" -description: "قم بتشغيل المراجعة والتحقق من نطاقها وفحص النتائج الناتجة." +title: "تشغيل ومراجعة التدقيق" +description: "قم بتشغيل التدقيق والتحقق من نطاق تغطيته وفحص النتائج الناتجة." icon: "play" --- -قم بتشغيل المراجعة بعد أن تصبح أهدافها والمجموعة السكانية محددة بدرجة كافية بحيث يعرف مشغل آخر ما يبدو عليه الاكتشاف الصحيح. +قم بتشغيل التدقيق بعد أن يصبح الهدف والمجموعة المستهدفة محددة بدرجة كافية بحيث يعرف أي مشغل آخر كيف تبدو النتيجة الصحيحة. -## تشغيلها والتحقق منها +## تشغيل وفحص التدقيق - - 1. انتقل إلى **تحليل → المراجعات**، افتح المراجعة، وحدد **تشغيل الآن**. ستعني الاستجابة المصفوفة أن بواسطة الموزع سيبدأها قريباً. - 2. افتح التشغيل الجديد لمراجعة حالته والنافذة الزمنية والمدة وعدد النتائج والتقرير. + + 1. انتقل إلى **Analyze → Audits** وافتح التدقيق ثم حدد **run now**. تعني الرسالة المصفوفة أن المُرسِل سيبدأ التشغيل قريباً. + 2. افتح التشغيل الجديد لمراجعة حالته والنافذة ومدته وعدد النتائج والتقرير. 3. حدد جلسة الأدلة لفتح التتبع الدقيق. - 4. عد إلى صفحة المراجعة لتحرير الإعدادات أو تعطيل الجدول أو فحص التشغيلات القديمة. + 4. عُد إلى صفحة التدقيق لتعديل الإعدادات أو تعطيل الجدول أو فحص التشغيلات الأقدم. - ![صفحة تفاصيل المراجعة مع النتائج المفتوحة وحالة آخر وتالي تشغيل ونافذة الكسح والسياق والتحكم بالتشغيل الآن والنتائج المرتبة.](/images/dashboard/audit-detail.png) + ![صفحة تفاصيل التدقيق تعرض النتائج المفتوحة وحالة التشغيل الأخير والتالي ونافذة المسح والسياق والتحكم في تشغيل فوري والنتائج المصنفة.](/images/dashboard/audit-detail.png) - + ```bash fp audits run checkout-reliability fp audits runs checkout-reliability --limit 10 @@ -26,41 +25,82 @@ icon: "play" fp audits findings --audit checkout-reliability ``` - انظر إلى [مرجع `fp audits`](/ar/reference/cloud-cli#audits) لسجل التشغيل والنتائج وأوامر التصنيف. + `fp audits run` يصف التدقيق في قائمة الانتظار؛ لا ينتظر اكتماله. تابعه بـ `fp audits runs ` واقرأ النتائج بعد انتهاء التشغيل. لا تعيد `--limit` أكثر من 50 تشغيل أخير مهما طلبت. + + يعمل الفرز على معرّف النتيجة وليس على التدقيق: + + ```bash + fp audits finding + fp audits ack --reason "owner assigned" + fp audits assign --to engineer@example.com + fp audits mute --reason "expected in staging" --yes + fp audits dismiss --reason "false positive" --yes + fp audits resolve --yes + fp audits reopen + ``` + + `mute` و `dismiss` و `resolve` تؤكد قبل التنفيذ، لذا مرّر `--yes` في السكريبتات. `ack` و `assign` و `reopen` تعمل فوراً. + + راجع مرجع [`fp audits`](/ar/reference/cloud-cli#audits) لأوامر سجل التشغيل والنتائج والفرز. +قد يتم رفض **run now**. التشغيل الذي يعمل بالفعل والتدقيق المعطّل كلاهما يرد `409`، مع السبب في حقل `error` في الاستجابة؛ التدقيق الذي لا يوجد أو التابع لمنظمة أخرى يرد `404`. + +| السبب | المعنى | الحل | +| --- | --- | --- | +| التدقيق غير معروف | التدقيق غير موجود أو يتبع منظمة أخرى. | أكد الاسم باستخدام `fp audits list`. | +| التدقيق معطّل | للتدقيق المعطّل لا توجد صفوف في قائمة الانتظار. التدقيق المتوقف مؤقتاً يعرض تحكماً في **run now**. | استأنفه أولاً أو استخدم `fp audits edit --enabled --yes`. | +| تشغيل قيد التنفيذ بالفعل | تشغيل واحد في كل مرة لكل تدقيق؛ يجب أن ينتهي التشغيل الحالي قبل وضع آخر في قائمة الانتظار. | تحقق منه باستخدام `fp audits runs `. | + ## قبل التشغيل - تأكد من وجود جلسات في نافذة الوقت المحددة. - تحقق من مرشحات البيئة والوكيل. -- تحقق من أن السياق المرجعي حالي. -- تأكد من أن الهدف يصف نمط فشل وليس استنتاج مطلوب. +- تحقق من تحديث سياق المرجع. كل تشغيل يعيد قراءة صفحات التدقيق ويعود إلى النسخة المخزنة عندما لا يتمكن من الوصول إلى إحداها، لذا تستمر الصفحة المنقولة أو المحذوفة في تقديم نص قديم حتى تصلح عنوان URL. +- تأكد من أن الهدف يصف نمط فشل وليس استنتاجاً مرغوباً. ## مراجعة التشغيل -ابدأ بحالة التشغيل وتغطية الجلسة وما إذا كان تحليل النموذج قد تم تشغيله. ثم افحص شدة كل نتيجة ووصفها وجلسات الأدلة والاستعلامات الداعمة والمسار الموصى به للوقاية. +تفتح صفحة تفاصيل التدقيق بخمس بطاقات: **النتائج المفتوحة** في انتظار الفرز و **آخر تشغيل** و **التشغيل التالي** و **النافذة** (إلى متى يعود كل تشغيل) و **الحساسية** (مدى سرعة الفحص عن النمط: `low` أو `medium` أو `high`). حد النتائج على الأكثر N في التشغيل هو إعداد منفصل، نتائج لكل تشغيل (`--top-k`، الافتراضي 50). تجيب هذه الخمس على سؤال التغطية بسرعة أكبر من فتح التشغيل. + +ثم افحص شدة كل نتيجة ووصفها وجلسات الأدلة والاستعلامات الداعمة ومسار الوقاية المقترح. يتم ترتيب النتائج بنقاط **الأولوية** بين 0 و 1، ومصنفة لكل تشغيل، وكل نتيجة تعرض العوامل الأربعة الموزونة: + +| عامل التصنيف | الوزن | +| --- | --- | +| التغطية | 0.30 | +| الحجم | 0.25 | +| الشدة | 0.25 | +| الحداثة | 0.20 | -استخدم حالة النتيجة للإقرار أو الكتم أو الرفض أو الحل أو إعادة الفتح أو تعيين العمل. احفظ الأدلة حتى عند رفض النتيجة؛ فهي توضح سبب اتخاذ القرار. +النتيجة في إحدى الحالات الخمس بالضبط: `open` أو `recurring` أو `resolved` أو `dismissed` أو `muted`. استعلام `findings` بدون تصفية الحالة يعيد المجموعة المباشرة — `open` بالإضافة إلى `recurring`. النتيجة التي تكتمها أو تغضّ الطرف عنها أو تحلّها تترك تلك المجموعة؛ `ack` و `assign` لا يغيران الحالة، لذا تبقى النتيجة في قائمة الانتظار — مخفضة الأولوية أو مملوكة وليست محذوفة. اطلب حالة صراحة لترى الحالات التي غادرت. + +استخدم حالة النتيجة للإقرار أو الكتم أو الغض أو الحل أو إعادة الفتح أو تعيين العمل. احتفظ بالأدلة حتى عندما يتم غض الطرف عن النتيجة؛ فهي تشرح السبب. يغطي [النتائج والمشاكل](/ar/audits/findings-and-issues) ما يفعله كل فعل بالتشغيلات المستقبلية. ## تفسير التشغيل الفارغ أو المتأخر -| حالة التشغيل | ما تعنيه | ما يجب فعله | +| حالة التشغيل | المعنى | الحل | | --- | --- | --- | -| تم تشغيل التحليل وأنتج صفر نتائج | الأدلة المختارة لم تدعم نتيجة في الحساسية المكونة. | تأكد من أن النطاق يحتوي على جلسات تمثيلية، ثم اعتبر النتيجة سليمة ما لم يكن الهدف أو السياق غير واضح جداً. | -| تم تخطي تحليل النموذج أو فشل | يكتمل التشغيل بصفر نتائج، لكنه لم يقم بالتحقيق الوكيل. المسح الحتمي للبيانات الاعتماد والمعلومات الشخصية لا يزال يبلغ عن عدد التطابقات في إحصائيات التشغيل ولكنه لا ينشئ نتائج. | أصلح خدمة التحليل أو الإعدادات وأعد التشغيل. لا تفسر النتيجة الفارغة كدليل على أن المجموعة السكانية سليمة. | -| تحليل النموذج معطل | يكتمل التشغيل بنجاح مع صفر نتائج. المسح الحتمي لا يحل محل تحليل النموذج ولا يفتح نتائج. | فعّل تحليل النموذج أو عطّل المراجعة بدلاً من الاعتماد على مراجعة لا يمكنها إنتاج نتائج. | -| لا توجد سعة تحليل متاحة فوراً | تبقى المراجعة في طابور الانتظار وتعيد المحاولة بدلاً من تخطي المجموعة السكانية. | انتظر السعة أو وزع نقاط اثبات المراجعة. يجب على المشغلين ذاتي الاستضافة توسيع نطاق نسخ وكيل المراجعة والسعة المطابقة للموزع. | -| السعة تبقى غير متاحة لنافذة إعادة المحاولة | يستسلم التشغيل مع صفر نتائج ويرسل إخطار فشل عند توفر تسليم البريد الإلكتروني. | تحقق مما إذا كانت أسطول المراجعة مشبعاً أو يعيد تشغيله بشكل متكرر. | +| انتهى التحليل وأسفر عن صفر نتيجة | الأدلة المحددة لم تدعم النتيجة عند حساسية التكوين. | تأكد من أن النطاق يحتوي على جلسات تمثيلية، ثم اعتبر النتيجة صحيحة ما لم يكن الهدف أو السياق غامضاً جداً. | +| تم تخطي تحليل النموذج أو فشل | التشغيل ينتهي بصفر نتيجة لكنه لم يجرِ التحقيق المستند إلى الوكيل. المسح الحتمي بدون بيانات اعتماد وPII لا يزال يبلغ عن تطابقات في إحصائيات التشغيل لكنه لا ينشئ نتائج. | أصلح خدمة التحليل أو التكوين وأعد التشغيل. لا تفسّر النتيجة الفارغة على أنها دليل على أن المجموعة صحيحة. | +| تحليل النموذج معطّل | التشغيل ينجح بصفر نتيجة. المسح الحتمي لا يحل محل تحليل النموذج ولا ينفتح على نتائج. | فعّل تحليل النموذج أو عطّل التدقيق بدلاً من الاعتماد على تدقيق لا يستطيع إنتاج نتائج. | +| لا توجد سعة تحليل متاحة فوراً | التدقيق يبقى في قائمة الانتظار ويعيد المحاولة بدلاً من تخطي المجموعة. | انتظر السعة أو انشر نقاط تثبيت التدقيق. يجب على مشغلي الخوادم المحلية توسيع نسخ الوكيل وسعة المُرسِل المطابقة. | +| تبقى السعة غير متاحة لنافذة إعادة المحاولة | التشغيل يستسلم بصفر نتيجة ويرسل إشعار فشل عند توفر تسليم البريد الإلكتروني. | تحقق مما إذا كان أسطول التدقيق مشبعاً أو يعيد التشغيل بشكل متكرر. | + +الصفوف الثلاث الأخيرة تصف سلوك خادم Cloud API وموزّعه. على Cloud المُدار هذا من مسؤولية Failproof AI؛ على نشر محلي الخوادم فهو من مسؤوليتك. + +عندما لا يعمل التحليل، تحافظ عمليات التدقيق `since_last` على النافذة غير المحللة مفتوحة للتشغيل الناجح التالي. لا يتم سحب النتائج الموجودة لأن التحليل المتخطى ليس دليلاً على اختفاء الفشل. + +## فهم الإشعارات -عندما لا يتم تشغيل التحليل، تحافظ مراجعات `since_last` على تلك النافذة غير المحللة مفتوحة للتشغيل الناجح التالي. لا يتم إزالة النتائج الموجودة لأن التحليل المتخطى ليس دليلاً على اختفاء الفشل. +التشغيل الناجح يبلغ فقط عندما يجد شيئاً **جديداً**. الصمت من تدقيق صحي هو الحالة الطبيعية وليس علامة على أن لا شيء عمل — تحقق من **آخر تشغيل** على صفحة التدقيق أو استخدم `fp audits runs ` لترى أنه عمل. التدقيق الذي لا توجد قنوات مختارة له يحفظ النتائج ولا يبلغ أحداً. -## فهم إخطارات الفشل +التشغيل الفاشل أو خطوة تحليل النموذج الفاشلة تستخدم متلقي البريد الإلكتروني للتدقيق. إذا لم يكن للتدقيق قناة بريد إلكتروني، يعود Failproof AI إلى إعداد `alerts.email_default_recipients` للمنظمة لذا حتى التدقيق المعطّل بصمت له مسار تصعيد. -يستخدم التشغيل الفاشل أو خطوة تحليل النموذج الفاشلة مستقبلي البريد الإلكتروني للمراجعة. إذا لم تكن للمراجعة قناة بريد إلكتروني، فإن Failproof AI ترجع إلى إعداد `alerts.email_default_recipients` للمنظمة بحيث تظل المراجعة المكسورة بصمت لديها مسار تصعيد. يجب تمكين البريد الإلكتروني للمنظمة وتكوين SMTP. وإلا فسيتم تسجيل الفشل ولكن لا يمكن إرسال بريد إلكتروني. فشل التشغيل لا يحرك نقطة الجدول الثابتة للمراجعة. +يجب تفعيل البريد الإلكتروني للمنظمة وتكوين SMTP. وإلا فسيتم تسجيل الخطأ لكن لا يمكن تسليم أي بريد إلكتروني. فشل التشغيل لا يحرك رابط الجدول الثابت للتدقيق. -كل تشغيل يخزن أيضاً السياق الدقيق [للوكيل](/ar/audits/agent-contracts) المستخدم لكل وكيل كلقطة عقد. لا تغير التعديلات اللاحقة معيار الأدلة المسجل مع تشغيل سابق. +كل تشغيل أيضاً يحفظ [السياق الدقيق للوكيل](/ar/audits/agent-contracts) المستخدم لكل وكيل كلقطة عقد. التعديلات اللاحقة لا تغير معيار الأدلة المسجل مع التشغيل الأقدم. - لا تقم بنشر سياسة حجب مباشرة من نتيجة غير مؤكدة. افتح الآثار المذكورة وتأكد من أن القاعدة تفصل السلوك غير الآمن عن العمل المشروع. + لا تنشر سياسة حجب مباشرة من نتيجة غير تم التحقق منها. افتح الآثار المذكورة وتأكد من أن القاعدة تفصل بين السلوك غير الآمن والعمل المشروع. \ No newline at end of file diff --git a/docs/ar/audits/setup.mdx b/docs/ar/audits/setup.mdx index ef014effa..e274e1ffb 100644 --- a/docs/ar/audits/setup.mdx +++ b/docs/ar/audits/setup.mdx @@ -1,24 +1,26 @@ --- ---- title: "إعداد تدقيق" -description: "تحديد هدف التدقيق، وملء الجلسة، وسياق الأدلة." +description: "تحديد هدف التدقيق وملء الجلسة وسياق الأدلة." icon: "sliders-horizontal" --- -تبدأ جودة التدقيق من نطاقه. الطلب الواسع مثل "ابحث عن المشاكل" ينتج نتائج أقل فائدة من سؤال فشل محدد. +تبدأ جودة التدقيق من نطاقه. طلب عام مثل "ابحث عن المشاكل" ينتج نتائج أقل فائدة من سؤال فشل محدد وملموس. ## تكوين التدقيق - 1. انتقل إلى **تحليل → التدقيقات → تدقيق جديد** وأدخل الاسم والوصف. - 2. عيّن التكرار، نافذة الوقت، نطاق الوكيل/البيئة، الأخطاء المتجاهلة، الحساسية، والحد الأقصى للنتائج. - 3. في **الوكلاء**، أضف أو راجع سياق الوكيل، ثم أضف إيجاز المشغل وأي عناوين URL مرجعية HTTPS عامة. - 4. اختر قنوات الإشعارات وحدد **إنشاء تدقيق**. يتم إدراج التشغيل الأول على الفور. + 1. انتقل إلى **Analyze → Audits → New audit** وأدخل الاسم والوصف. الاسم فريد لكل منظمة؛ الوصف يسجل ما تتوقع أن يكتشفه هذا التدقيق. + 2. في **when it runs**، حدد التكرار والنافذة الزمنية. في **what it reads**، ضيّق السكان باستخدام البيئات والوكلاء وأنواع الأخطاء المراد تجاهلها — حقل فارغ يتضمن كل شيء. في **how it judges**، حدد الحساسية وعدد النتائج لكل تشغيل. + 3. في **what it knows**، اكتب موجز المشغل وأضف الصفحات التي يقرأها التدقيق. الموجز هو خلفية يقرأها النموذج قبل فحص أي حدث واحد: يُضاف إلى ما يبحث عنه هذا التدقيق بالفعل، وليس أبداً بديلاً، وليس أبداً دليلاً على نتيجة. + 4. افتح درج **agents** لإضافة أو مراجعة سياق كل وكيل. يحفظ بشكل مستقل عن التدقيق، والرأس الخاص به يحسب عدد وكلائك الذين لديهم واحد بالفعل. انظر [agent context](/ar/audits/agent-contracts). + 5. اختر قنوات الإشعارات واختر **create audit**. يبدأ التدقيق الجديد مفعّلاً، وتم جدولة التشغيل الأول له فوراً. + + ![نموذج التدقيق الجديد يحتوي على الاسم والوصف والتكرار والنافذة الزمنية ونطاق البيئة والوكيل والأخطاء المتجاهلة وإعدادات التحليل والموجز والصفحات المرجعية وقنوات الإشعارات.](/images/dashboard/audit-new.png) - ![نموذج التدقيق الجديد يحتوي على الاسم والوصف والتكرار والنافذة ونطاق البيئة والوكيل والأخطاء المتجاهلة وإعدادات التحليل والإيجاز وصفحات المرجع وقنوات الإشعارات.](/images/dashboard/audit-new.png) + **agents** في بطاقة **what it reads** هو مرشح نطاق — يحدد الجلسات التي يمسحها كل تشغيل. ما يقوم به الوكيل *من أجله* يعيش في درج الوكلاء المنفصل. - + ```bash fp audits create checkout-reliability \ --description "Find checkout failures that agents do not recover from" \ @@ -30,16 +32,44 @@ icon: "sliders-horizontal" --url https://runbooks.example.com/checkout ``` - يتم إدراج التشغيل الأول على الفور. أدرج الإيجاز وعناوين URL المرجعية أثناء الإنشاء بحيث يتلقاها التشغيل. + لكل حقل ما عدا الاسم قيمة افتراضية على الخادم، لذا `fp audits create nightly` البسيط هو بالفعل تدقيق يومي صحيح. يتم رفض الاسم المأخوذ مقدماً، قبل إنشاء أي شيء. تبدأ التدقيقات الجديدة مفعّلة إلا إذا مررت `--disabled`، ويتم جدولة التشغيل الأول للتدقيق المفعّل فوراً. + + استند إلى تعريف مُحفوظ باستخدام JSON مع `--file audit.json` وطبّق الأعلام فوقه. هذا هو المسار القابل للتكرار عندما تتم مراجعة تعريفات التدقيق أو الاحتفاظ بها في التحكم في الإصدار. انظر المرجع الكامل [`fp audits create`](/ar/reference/cloud-cli#audits). +## النطاقات والقيم الافتراضية + +تتم التحقق من صحة الإعدادات الرقمية على كلا الجانبين، لذا تكون القيمة خارج النطاق خطأ استخدام وليس طلب مرفوض. + +| الإعداد | علم CLI | القيم المقبولة | القيمة الافتراضية | +| --- | --- | --- | --- | +| التكرار | `--schedule-interval-secs` | 3600–604800 (ساعة واحدة إلى 7 أيام) | 86400 (يومي) | +| نقطة ربط الجدولة | `--schedule-anchor` | ISO 8601 UTC؛ يتم رفض نقطة ربط أبعد من 365 يوماً | الساعة 09:00 UTC التالية | +| النافذة الزمنية | `--window-mode` | `fixed`, `since_last` | `since_last` | +| النظر للخلف | `--lookback-window-secs` | 3600–7776000 (ساعة واحدة إلى 90 يوماً) | 604800 (7 أيام) | +| الحساسية | `--sensitivity` | `low`, `medium`, `high` | `medium` | +| النتائج لكل تشغيل | `--top-k` | 1 أو أكثر | 50 | + +تحدد نقطة الربط مرحلة الجدولة: تهبط التشغيلات على `anchor + N * interval`، لذا لا يمكن للتشغيل البطيء أو **run now** اليدوي أن يجرف التكرار. يتم جدولة التشغيل الأول فوراً عند الإنشاء بغض النظر عن نقطة الربط. + +## الموجز والصفحات المرجعية + +يُظهر النموذج كلا الحدين كعدادات، والـ CLI يفرض نفس الحدين: + +- الموجز محدود بـ 8192 حرفاً (`--text`، أو `--text-file` لقراءته من ملف — مرّر أحدهما أو الآخر، وليس كليهما). +- يشير التدقيق إلى خمس صفحات على الأكثر، عام `https://` فقط (`--url`، مكرر). + +تتم التحقق من صحة عناوين URL المرجعية أثناء الحفظ. يتم رفض العناوين الخاصة والحلقية وعناوين بيانات السحابة، ويفشل عنوان URL المرفوض الإنشاء بالكامل — لم يتم ترك تدقيق نصف مصنوع. يتم جلب الصفحات المقبولة في الخلفية، لذا لن يوقف الموقع البطيء الحفظ. يعيد كل تشغيل قراءتها ويعود إلى اللقطة المخزنة عندما لا يمكن الوصول إلى واحدة، واللقطات تنعش بمفردها كل أسبوع. استخدم `fp audits context-refresh ` عندما تعرف أن صفحة تغيرت وتريد التقاطها قبل التشغيل التالي. + +أرسل الموجز والعناوين مع طلب الإنشاء بدلاً من مكالمة ثانية. يستحق التدقيق الجديد المفعّل في اللحظة التي يتعهد بها صفه، لذا يمكن للسياق المكتوب لاحقاً أن يتفوق عليه المرسل ويفوت التشغيل الأول — التشغيل الذي تراقبه. غيّره لاحقاً مع `fp audits context-set `، الذي يستبدل أيهما تسميه ويترك الآخر وحده. + - ابدأ بجلسة فاشلة معروفة وعدة جلسات عادية. وهذا يعطي التدقيق مثالاً إيجابياً ومجموعة مقارنة. + ابدأ بجلسة فاشلة معروفة وعدة جلسات عادية. هذا يعطي التدقيق مثالاً إيجابياً ومجموعة مقارنة. - يتم تخزين سياق التدقيق كمورد منفصل بحيث لا يؤدي تحرير التدقيق إلى إزالة المادة المرجعية بشكل عرضي. + يتم تخزين سياق التدقيق كمورد خاص به. نقطة نهاية التعريف ترفض كتابته عند التحديث، لذا لن يؤدي تحرير عادي غير مرتبط للتدقيق إلى الكتابة فوق الموجز أو الصفحات المرجعية. \ No newline at end of file diff --git a/docs/ar/index.mdx b/docs/ar/index.mdx index 0887d98c1..74af08b02 100644 --- a/docs/ar/index.mdx +++ b/docs/ar/index.mdx @@ -1,42 +1,58 @@ --- ---- -title: "اجعل وكيلك آمنًا تماماً" -description: "قابلية الملاحظة والتطبيق لكل بيئة تشغيل يعمل فيها وكيلك — واجهات سطر الأوامر للترميز، بوابات الدردشة، المساعدات المستضافة ذاتياً، والوكلاء المزودين بأدوات المراقبة الخاصة بك." +title: "اجعل وكيلك failproof" +description: "شاهد ما يفعله وكلاؤك، وجد الأخطاء، ووقفها من الحدوث مرة أخرى." icon: "shield-check" --- -Failproof AI يساعد الفرق على فهم ما فعله الوكلاء، والعثور على أماكن فشلهم، ونشر الحماية قبل حدوث نفس السلوك مرة أخرى. +Failproof AI يساعد أي شخص يقوم بتشغيل الوكلاء على فهم ما حدث، والعثور على الأخطاء، ومنع تكرارها. + +يعمل مع 12 بيئة وكيل شائعة، بما في ذلك Claude Code و Codex و Hermes و OpenClaw و Goose. يمكن للوكلاء المبنيين باستخدام LangChain أو CrewAI أو LlamaIndex أو Pydantic AI أو وقتك الخاص الإبلاغ من خلال [Python SDK](/ar/reference/custom-agents). + + + + ثبّت Failproof AI، وصل وكلاءك، واختر ما تريد فرضه. + + + ابحث عن الجلسات، وحقق في الأخطاء، وابنِ لوحات معلومات باللغة الطبيعية. + + -**البيئة التشغيلية** هي أي شيء يعمل فيه وكيلك بالفعل. Failproof AI يربط 12 منها — واجهات سطر أوامر للترميز مثل Claude Code و Codex، وبوابات دردشة مثل Hermes، ومساعدات مستضافة ذاتياً مثل OpenClaw — وتنطبق نفس الأحداث والسياسات وسجل الجلسات على كل واحدة منها. الوكلاء الذين ليس لديهم بيئة تشغيلية يقدمون تقارير من خلال [Python SDK](/ar/reference/custom-agents)، الذي يتتبعهم ويقومون بتدقيقهم؛ تطبيق سياسة هناك يتطلب خطاف في وقت التشغيل الخاص بك. +## ابدأ محليًا أو اتصل بـ Cloud - - استخدم المهارة لأتمتة مشروعك وتوصيله والتحقق من وصول سجلات الوكيل. + + افتح لوحة المعلومات على `localhost:8020` وقم بتشغيل `failproofai audit`. يبقى سجل وكيلك على هذه الآلة. - - حلل واستعلم وقم ببناء لوحات معلومات وتشغيل عمليات التدقيق باللغة الطبيعية على سجلات وكيلك. + + شاهد الجلسات عبر الآلات وأدر السياسات لفريقك. +يختار الإعداد عن قصد عدم وجود حزمة سياسة. أضف حزمتنا بعد الإعداد: + +```bash +failproofai policies add FailproofAI/policies +``` + +حتى ذلك الحين، فقط `block-failproofai-commands` يعمل. إنه يوقف الوكيل من تعطيل Failproof AI. + +## ما الذي يمكنك فعله + - - تابع استدعاءات النموذج والأدوات والأخطاء والمدخلات البشرية والكمون وقرارات السياسة في جلسة واحدة. + + تابع تشغيل الوكيل من خلال استدعاءات النموذج والأدوات والأخطاء وقرارات السياسة. - - قم بتدقيق مجموعة محددة من الجلسات وراجع النتائج المدعومة بالأدلة وتابع الإصلاح كمشاكل. + + راجع الأدلة عبر تشغيل واحد أو أكثر. - حول وضع فشل معروف إلى سياسة وراقب تأثيره ونشره عبر أسطولك. + لاحظ حماية على النشاط الفعلي، ثم فرضها عندما تكون جاهزًا. -> **جلسة → تدقيق → نتيجة → مشكلة → سياسة**
-> تتبع ما حدث، أوجد الفشل، أدر الاستجابة، ثم منع نفس السلوك في التشغيلات المستقبلية. - -## ابدأ من هنا - -إذا كنت تنشر وكيلك المزود بأدوات المراقبة للمرة الأولى، فابدأ بـ [البدء السريع](/ar/start/quickstart). إذا كانت البيانات تصل بالفعل، فافتح [الجلسات](/ar/sessions/overview) وتفحص تشغيلاً حقيقياً قبل تكوين عمليات التدقيق أو السياسات. +> **Session → Audit → Finding → Issue → Policy** +> شاهد ما حدث، وجد الخطأ، وتحمل المسؤولية عن الرد، ثم منعه. - - أكمل سير العمل من الطرف إلى الطرف الآخر من المراقبة إلى سياسة آمنة ومنشورة. - \ No newline at end of file + + الإعداد يدعم Linux و macOS. راجع [harnesses المدعومة](/ar/reference/harnesses) لمعرفة ما يمكن لكل بيئة وكيل مراقبته أو حظره. + \ No newline at end of file diff --git a/docs/ar/policies/builtin-catalog.mdx b/docs/ar/policies/builtin-catalog.mdx index afda0631f..9ca7c095e 100644 --- a/docs/ar/policies/builtin-catalog.mdx +++ b/docs/ar/policies/builtin-catalog.mdx @@ -1,106 +1,147 @@ --- +--- title: "كتالوج السياسات المدمجة" -description: "اطّلع على كل سياسة مدمجة من سياسات Failproof AI، وحافزها، والحالة الموصى بها، والمعاملات القابلة للتكوين." +description: "استعرض كل سياسة من سياسات Failproof AI المدمجة، مع محفزاتها وحالتها الافتراضية والمعاملات القابلة للتكوين." icon: "list-checks" --- -الحزمة المثبتة هي مصدر الحقيقة لتوفر السياسات. قم بتشغيل `failproofai policies` بعد كل تحديث لأن إدخالات الكتالوج والسلوك قد يتغيران مع إصدار الحزمة. +يتم تسليم 38 من أصل 39 سياسة مدمجة كحزمة `FailproofAI/policies`؛ يتم شحن `block-failproofai-commands` مجمعة في الحزمة لأن الحزمة قد لا تعلن `alwaysOn`. الحزمة المثبتة هي مصدر الحقيقة لما يمكن لهذا الجهاز أن يفرضه: + +```bash +failproofai policies show FailproofAI/policies # the catalog, as published +failproofai policies # what is enabled here +``` + +يسرد `failproofai policies` الملفات المخصصة وملفات الاتفاقيات والحزم المثبتة والتعيينات السحابية. لا يحتوي على قسم مدمج، لذا لا يمكنه الإجابة على "أي من السياسات المدمجة موجود" — `policies show` و[Policy Hub](https://befailproof.ai/policy-hub/FailproofAI/policies/) هما المكانان اللذان يتم الإجابة عليهما هناك. -## خط الأساس الموصى به +## القيم الافتراضية وكيفية الاختيار -يعمل الإعداد الموجه حالياً على تفعيل معقمات الأسرار، وحماية البيئة، الحماية الذاتية، حراس الأوامر الكارثية، وسلامة الفروع المحمية: +يقوم `failproofai policies add FailproofAI/policies` بتفعيل القيم الافتراضية للحزمة — الصفوف الـ 10 المشار إليها بـ **on** أدناه. يتم تفعيل `block-failproofai-commands` بغض النظر وليست جزءًا من هذا التحديد. يأخذ `--all` كل شيء؛ `--category ` و`--policy ` يأخذان جزءًا. الاختصار بجانب كل عنوان هو ما يطابقه `--category`: -```text -sanitize-jwt sanitize-api-keys -sanitize-connection-strings sanitize-private-key-content -sanitize-bearer-tokens protect-env-vars -block-env-files block-secrets-write -block-failproofai-commands block-sudo -block-curl-pipe-sh block-rm-rf -block-push-master block-force-push +```bash +failproofai policies add FailproofAI/policies --category git,database ``` -`block-failproofai-commands` **مفعل دائماً**. تم إدراجه أعلاه لتوضيح المعلومات، لكنه يتسجل عند كل تقييم سواء ظهر في مجموعة السياسات المفعلة لديك أم لا، ولا يمكن تعطيله أو إيقافه مؤقتاً — فالحارس الذي يمكن للعامل إيقاف الإنفاذ عنه ليس حارساً. +`block-failproofai-commands` **مفعل دائمًا**. يسجل نفسه في كل تقييم سواء ظهر في اختيارك أم لا، ولا يمكن تعطيله أو إيقافه مؤقتًا — الحماية ضد تعطيل الوكيل للفرض الذي يمكن للوكيل تعطيله ليست حماية. قد لا تعلن الحزمة عن `alwaysOn`، وهذا هو السبب في شحن هذه السياسة الواحدة مجمعة في الحزمة بدلاً من أن تكون في الحزمة. -الموصى به مقصود أن يكون أضيق من **الكل**. سياسات البنية التحتية وسير العمل يمكن أن تقاطع العمل الصحيح وينبغي تفعيلها للمستودعات والأجهزة التي تحتاجها. +## التعقيم — `sanitize` -## الأسرار والبيئة +تعمل هذه على `PostToolUse`، بعد تنفيذ الأداة بالفعل. **تكتشف وترفض نتيجة الأداة**؛ لا تحرر كلمة فرعية وتعيد الباقي. -| السياسة | الحافز | النتيجة | -| --- | --- | --- | -| `sanitize-jwt` | `PostToolUse` | إخفاء JWTs من مخرجات الأدوات قبل أن يراها النموذج. | -| `sanitize-api-keys` | `PostToolUse` | إخفاء مفاتيح OpenAI و Anthropic و GitHub و AWS و Stripe و Google الشائعة. | -| `sanitize-connection-strings` | `PostToolUse` | إخفاء سلاسل اتصال قواعد البيانات التي تحتوي على بيانات اعتماد. | -| `sanitize-private-key-content` | `PostToolUse` | إخفاء أجسام مفاتيح PEM الخاصة. | -| `sanitize-bearer-tokens` | `PostToolUse` | إخفاء رموز الترخيص. | -| `protect-env-vars` | `PreToolUse` على أدوات الغلاف | منع الأوامر التي تفرغ متغيرات البيئة. | -| `block-env-files` | `PreToolUse` | منع قراءة وكتابة ملفات `.env`. | -| `block-read-outside-cwd` | `PreToolUse` على أدوات القراءة أو glob أو grep أو shell | إبقاء القراءة داخل دليل العمل للجلسة. | -| `block-secrets-write` | `PreToolUse` على أدوات الكتابة | منع الكتابة إلى أسماء ملفات المفاتيح السرية والبيانات الاعتمادية الشائعة. | - -## الأوامر الخطيرة والبنية التحتية - -| السياسة | الحافز | النتيجة | -| --- | --- | --- | -| `block-sudo` | `PreToolUse`, `PermissionRequest` | منع `sudo` إلا إذا تطابق نمط السماح. | -| `block-curl-pipe-sh` | `PreToolUse` | منع النصوص البرمجية المحملة الموجهة مباشرة إلى الغلاف. | -| `block-rm-rf` | `PreToolUse` | منع أنماط الحذف العودية الكارثية. | -| `block-failproofai-commands` | `PreToolUse`, `PermissionRequest` | **مفعل دائماً، لا يمكن تعطيله.** منع كل استدعاء CLI من Failproof AI، والإيقاف الذاتي، وإلغاء تثبيت مدير الحزم. | -| `block-kubectl` | `PreToolUse` | حماية أوامر Kubernetes. | -| `block-terraform` | `PreToolUse` | حماية أوامر Terraform و OpenTofu. | -| `block-aws-cli` | `PreToolUse` | حماية أوامر AWS CLI. | -| `block-gcloud` | `PreToolUse` | حماية أوامر Google Cloud CLI. | -| `block-az-cli` | `PreToolUse` | حماية أوامر Azure CLI. | -| `block-helm` | `PreToolUse` | حماية أوامر Helm. | -| `block-gh-pipeline` | `PreToolUse` | حماية عمليات GitHub CLI الطافرة لسير العمل والتشغيل والدمج والإصدار والذاكرة والعمليات السرية. | - -## سلامة Git وقاعدة البيانات - -| السياسة | الحافز | النتيجة | -| --- | --- | --- | -| `block-push-master` | `PreToolUse` | منع الدفع المباشر إلى الفروع المحمية المُعدَّلة. | -| `block-force-push` | `PreToolUse` | منع الدفع القسري؛ يبقى `--force-with-lease` مسموحاً بالتطبيق الحالي. | -| `block-work-on-main` | `PreToolUse` | منع الالتزامات والدمج على الفروع المحمية. | -| `warn-git-amend` | `PreToolUse` | تحذير قبل إعادة كتابة التزام باستخدام `--amend`. | -| `warn-git-stash-drop` | `PreToolUse` | تحذير قبل حذف أو مسح المخزن المؤقت نهائياً. | -| `warn-all-files-staged` | `PreToolUse` | تحذير على `git add -A` أو `git add .` أو `git add --all` الواسع. | -| `warn-destructive-sql` | `PreToolUse` | تحذير على `DROP` و `TRUNCATE` و `DELETE` بدون `WHERE` من خلال عملاء قواعد البيانات المعروفة. | -| `warn-schema-alteration` | `PreToolUse` | تحذير على عمليات `ALTER TABLE` المعروفة لأعمدة وإعادة تسمية. | - -## الحزم وسلوك النظام وحلقات العامل - -| السياسة | الحافز | النتيجة | -| --- | --- | --- | -| `warn-package-publish` | `PreToolUse` | تحذير قبل النشر إلى السجلات. | -| `warn-global-package-install` | `PreToolUse` | تحذير قبل التثبيت العام للحزمة. | -| `prefer-package-manager` | `PreToolUse` | إرشاد العامل لاستخدام مدير حزم مسموح. | -| `warn-large-file-write` | `PreToolUse` على أدوات الكتابة | تحذير فوق حد حجم الملف المُعدَّل. | -| `warn-background-process` | `PreToolUse` | تحذير على أنماط العمليات الخلفية المنفصلة أو طويلة العمر. | -| `warn-repeated-tool-calls` | `PreToolUse` | تحذير بعد ثلاث مكالمات أدوات متطابقة أو أكثر. | +الرفض هنا يصل إلى النموذج فقط على الأطر التي تستهلك حكم `PostToolUse` — **codex** و **copilot**، حيث يحل السبب محل نتيجة الأداة بالكامل. على claude و cursor و opencode و pi و hermes و openclaw و factory و devin و antigravity و goose، يكون `PostToolUse` مراقبة فقط: يتم تسجيل الكشف ولا تزال الإخراج يصل إلى النموذج. + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `sanitize-jwt` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على JWT. | +| `sanitize-api-keys` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على مفتاح OpenAI أو Anthropic أو GitHub أو AWS أو Stripe أو Google. | +| `sanitize-connection-strings` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على سلسلة اتصال قاعدة بيانات بها بيانات اعتماد مضمنة. | +| `sanitize-private-key-content` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على محتوى مفتاح خاص بصيغة PEM. | +| `sanitize-bearer-tokens` | `PostToolUse` | on | ارفض نتيجة أداة تحتوي على رمز `Authorization: Bearer`. | + +## البيئة — `environment` + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `protect-env-vars` | `PreToolUse` على `Bash` | on | منع الأوامر التي تقرأ متغيرات البيئة. | +| `block-env-files` | `PreToolUse` | on | منع القراءة والكتابة لملفات `.env`. | +| `block-read-outside-cwd` | `PreToolUse` على `Read`، `Glob`، `Grep`، `Bash` | off | حافظ على قراءات الملفات داخل دليل العمل للجلسة. | + +## الأوامر الخطرة — `dangerous-commands` + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `block-sudo` | `PreToolUse`، `PermissionRequest` على `Bash` | on | منع `sudo` ما لم يطابق نمط السماح. | +| `block-curl-pipe-sh` | `PreToolUse` على `Bash` | on | منع النصوص المحملة الموجهة مباشرة إلى shell. | +| `block-failproofai-commands` | `PreToolUse`، `PermissionRequest` على `Bash`، `Write`، `Edit`، `NotebookEdit` | **always on** | منع كل استدعاء CLI من Failproof AI، الإيقاف الذاتي وإلغاء التثبيت. | +| `block-rm-rf` | `PreToolUse` على `Bash` | off | منع أنماط الحذف العودي الكارثية. | +| `block-secrets-write` | `PreToolUse` على `Write` | off | منع الكتابة لأسماء ملفات المفاتيح السرية والبيانات الاعتمادية الشائعة. | + +## أوامر البنية التحتية — `infra-commands` + +السبعة كلهم معطلة بشكل افتراضي: فهي تبوب الأدوات التي يستخدمها العمل الشرعي بشكل مستمر، لذا فهي تنتمي إلى المستودعات والآلات التي تحتاج إليها. -## سير عمل نهاية المهمة +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `block-kubectl` | `PreToolUse` على `Bash` | off | ابوب طفرات `kubectl` في الكتلة. | +| `block-terraform` | `PreToolUse` على `Bash` | off | ابوب أوامر `terraform` و`tofu`. | +| `block-aws-cli` | `PreToolUse` على `Bash` | off | ابوب أوامر CLI `aws`. | +| `block-gcloud` | `PreToolUse` على `Bash` | off | ابوب أوامر `gcloud`. | +| `block-az-cli` | `PreToolUse` على `Bash` | off | ابوب أوامر `az`. | +| `block-helm` | `PreToolUse` على `Bash` | off | ابوب أوامر `helm`. | +| `block-gh-pipeline` | `PreToolUse` على `Bash` | off | ابوب عمليات `gh` التي تسبب طفرات: تشغيل workflow وإعادة تشغيل وإلغاء التشغيل وضم PR وإنشاء وحذف الإصدار وحذف الذاكرة وتعيين وحذف السر. الأوامر الفرعية للقراءة فقط مثل `gh pr view` غير مطابقة. | -تتطلب هذه السياسات حزام يصدر حدث `Stop` متوافق. +## Git — `git` -| السياسة | النتيجة | +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `block-push-master` | `PreToolUse` على `Bash` | on | منع الدفع المباشر إلى الفروع المحمية المكونة. | +| `block-force-push` | `PreToolUse` على `Bash` | off | منع الدفع القسري. يبقى `--force-with-lease` و`--force-if-includes` مسموحًا. | +| `block-work-on-main` | `PreToolUse` على `Bash` | off | منع الالتزامات والدمج على الفروع المحمية. | +| `warn-git-amend` | `PreToolUse` على `Bash` | off | تحذير قبل إعادة كتابة التزام باستخدام `--amend`. | +| `warn-git-stash-drop` | `PreToolUse` على `Bash` | off | تحذير قبل حذف أو مسح stashes دائمًا. | +| `warn-all-files-staged` | `PreToolUse` على `Bash` | off | تحذير على عمليات `git add -A` أو `git add .` أو `git add --all` الواسعة. | + +## قاعدة البيانات — `database` + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `warn-destructive-sql` | `PreToolUse` على `Bash` | off | تحذير على `DROP` و`TRUNCATE` و`DELETE` بدون `WHERE` عبر عملاء قواعد البيانات المعروفة. | +| `warn-schema-alteration` | `PreToolUse` على `Bash` | off | تحذير على عمليات `ALTER TABLE` المعروفة للأعمدة وإعادة التسمية. | + +## الحزم والنظام — `packages-system` + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `warn-package-publish` | `PreToolUse` على `Bash` | off | تحذير قبل النشر إلى npm و PyPI و crates.io و RubyGems وسجلات مماثلة. | +| `warn-global-package-install` | `PreToolUse` على `Bash` | off | تحذير قبل تثبيت الحزم بشكل عام. | +| `prefer-package-manager` | `PreToolUse` على `Bash` | off | منع مدير حزم غير المفضل وتوجيه الوكيل لاستخدام الموجودة. | +| `warn-large-file-write` | `PreToolUse` على `Write` | off | تحذير أعلى عتبة حجم الملف المكونة. | +| `warn-background-process` | `PreToolUse` على `Bash` | off | تحذير على أنماط العمليات المنفصلة أو خلفية. | + +## سلوك الذكاء الاصطناعي — `ai-behavior` + +| السياسة | المحفز | القيمة الافتراضية | النتيجة | +| --- | --- | --- | --- | +| `warn-repeated-tool-calls` | `PreToolUse` | off | تحذير عند استدعاء الأداة نفسها ثلاث مرات أو أكثر بمعاملات متطابقة. | + +## سير العمل — `workflow` + +الخمسة كلهم يعملون على `Stop` ومعطلة بشكل افتراضي. + +| السياسة | القيمة الافتراضية | النتيجة | +| --- | --- | --- | +| `require-commit-before-stop` | off | ارفض الإكمال بينما تبقى أعمال مسارة غير مرتكبة. | +| `require-push-before-stop` | off | ارفض الإكمال بينما تبقى الالتزامات محلية فقط. | +| `require-pr-before-stop` | off | اطلب طلب سحب للفرع الحالي. | +| `require-no-conflicts-before-stop` | off | اطلب دمج نظيف ضد الفرع الأساسي المكون. | +| `require-ci-green-before-stop` | off | اطلب النجاح في فحوصات CI على التزام HEAD الحالي، مع تجاهل الأشغال القديمة على الالتزامات السابقة. | + +هذه تحتاج إلى إطار عمل يتم استهلاك حكم `Stop` الخاص به. ليس كل إطار عمل: + +| إطار العمل | `Stop` | | --- | --- | -| `require-commit-before-stop` | رفض الإنجاز بينما يبقى العمل المتتبع غير ملتزم. | -| `require-push-before-stop` | رفض الإنجاز بينما تبقى الالتزامات محلية فقط. | -| `require-pr-before-stop` | طلب طلب دمج للفرع الحالي. | -| `require-no-conflicts-before-stop` | طلب دمج نظيف مقابل فرع القاعدة المُعدَّل. | -| `require-ci-green-before-stop` | طلب اكتمال فحوصات CI في HEAD الحالي بنجاح. | +| claude و codex و copilot و cursor و openclaw و factory و devin و antigravity | تم التحقق من الحجب: يفرض الرفض دورة أخرى | +| pi | ملاحظة. يتم نقل السبب إلى الدورة التالية كتعليمات وليس كبوابة | +| goose و hermes | لم يتم تثبيت أي hook `Stop`، لذا هذه الخمسة لا تعمل أبدًا | +| opencode | لم يتم التحقق. `Stop` ليست من بين الأحداث التي يستهلك opencode حكمًا منها | + +تعمل عمليات Cursor Cloud Agent VM على لا أي stop hooks، لذا فإن جلسة Cursor هناك غير مغطاة على الرغم من أن Cursor المحلي ليس كذلك. + + +تعود سياسات `warn-*` بـ `instruct`، وليس `deny`. (`prefer-package-manager` هي الاستثناء بين الأسماء غير `block-*`: تعود بـ `deny`، لذا تحجب على كل إطار عمل يستهلك حكم `PreToolUse` — وهي الاثني عشر جميعها.) على Hermes و Goose و على Pi و OpenClaw و Factory خارج قناة `Stop` وعلى Antigravity خارج `Stop` و`UserPromptSubmit`، `instruct` تنخفض إلى السماح بالإضافة إلى ملاحظة على stderr — لا يتم إخبار الوكيل. `UserPromptSubmit` الخاص بـ Antigravity هي قناة حقيقية ثانية: يتم حقن التعليمات كرسالة مؤقتة قبل تشغيل النموذج. + ## مرجع المعاملات -قم بتكوين المعاملات تحت كائن `policyParams` للنطاق المحدد. يتم التحقق من الأنواع من قبل كل سياسة. +قم بتكوين المعاملات تحت كائن `policyParams` الخاص بالنطاق المختار. يتم التحقق من الأنواع بواسطة كل سياسة. -| السياسة | المعامل | النوع والافتراضي | +| السياسة | المعامل | النوع والقيمة الافتراضية | | --- | --- | --- | -| `sanitize-api-keys` | `additionalPatterns` | `pattern[]`, `[]`؛ الإدخالات تحتوي على `regex` و `label` | +| `sanitize-api-keys` | `additionalPatterns` | `pattern[]`, `[]`؛ تحتوي الإدخالات على `regex` و`label` | | `block-read-outside-cwd` | `allowPaths` | `string[]`, `[]` | | `block-sudo` | `allowPatterns` | `string[]`, `[]` | | `block-rm-rf` | `allowPaths` | `string[]`, `[]` | -| حاجبات البنية التحتية | `allowPatterns` | `string[]`, `[]` | +| Infrastructure blockers | `allowPatterns` | `string[]`, `[]` | | `block-secrets-write` | `additionalPatterns` | `string[]`, `[]` | | `block-push-master` | `protectedBranches` | `string[]`, `["main", "master"]` | | `block-work-on-main` | `protectedBranches` | `string[]`, `["main", "master"]` | @@ -112,7 +153,6 @@ block-push-master block-force-push ```json { - "enabledPolicies": ["block-sudo", "block-push-master"], "policyParams": { "block-sudo": { "allowPatterns": ["sudo systemctl status"] @@ -124,6 +164,10 @@ block-push-master block-force-push } ``` + +اسم السياسة المكشوف كمفتاح `policyParams` يتم احترامه لـ `FailproofAI/policies` فقط. بالنسبة لأي حزمة أخرى فإن المفتاح هو `pack///` — حزمة غريب تعلن اسم السياسة نفسه تحصل على افتراضات المخطط، وليس معاملات لك. + + - نمط السماح يوسّع ما قد يفعله العامل. اختبر الرمزنة الدقيقة وأنماط الأوامر على الحزام المستهدف قبل نشره عبر الأسطول. +نمط السماح يوسع ما قد يفعله الوكيل. اختبر الترميز والمتغيرات الدقيقة للأمر على إطار العمل الهدف قبل نشره عبر الأسطول. \ No newline at end of file diff --git a/docs/ar/policies/builtin.mdx b/docs/ar/policies/builtin.mdx index d6f1ecc55..cd530086f 100644 --- a/docs/ar/policies/builtin.mdx +++ b/docs/ar/policies/builtin.mdx @@ -1,58 +1,100 @@ --- ---- title: "السياسات المدمجة" -description: "تفعيل الحماية المحتفظ بها للأخطاء الشائعة في وكلاء الذكاء الاصطناعي." +description: "استخدم الحماية الموثوقة للحالات الشائعة لفشل الوكلاء، وفعّل ما تريده منها." icon: "library" --- -تغطي السياسات المدمجة معالجة الأسرار والملفات البيئية وأوامر shell التدميرية والفروع المحمية وأدوات السحابة والبنية التحتية ونشر الحزم والاستدعاءات المتكررة وفحوصات سير عمل نهاية المهمة. +المدمجات هي 39 سياسة موثوقة تغطي تسع فئات من حالات فشل الوكلاء. جميعها ما عدا واحدة **تُسلّم كحزمة**، `FailproofAI/policies`، بنفس الطريقة التي يتم بها تسليم سياسات أي شخص آخر. الحزمة لا تشحن حزمتها الخاصة، لذا التثبيت الجديد لا ينفذ شيئاً إلى أن تختاره: -## تفعيل والتحقق من سياسة مدمجة +```bash +failproofai policies add FailproofAI/policies +``` - - - 1. قم بتثبيت السياسة على جهاز متصل باستخدام واجهة سطر الأوامر المحلية. - 2. قم بتشغيل إجراء اختبار آمن في الوكيل المقيس. - 3. انتقل إلى **Observe → policy** وقم بالتصفية حسب اسم السياسة أو بيئة الجهاز أو القرار. - 4. افتح الجلسة المرتبطة لتأكيد إدخال الأداة المطابق والسبب المُرجع. +يفعّل هذا الإعدادات الافتراضية للحزمة — 10 من 38 سياسة التي تحملها الحزمة. الـ 39 سياسة هي `block-failproofai-commands`، وهي مفعّلة بغض النظر: يتم شحنها مجمّعة في الحزمة، وتسجيل في كل تقييم، ولا يمكن تعطيلها أو إيقافها. لا يمكن لحزمة أن تعلن `alwaysOn`، ولهذا السبب هذا الحماية لا تسير في مسار الحزمة. - +## ما تغطيه الفئات التسع + +| الفئة | `--category` slug | السياسات | +| --- | --- | --- | +| تنقية البيانات | `sanitize` | 5 | +| البيئة | `environment` | 3 | +| الأوامر الخطرة | `dangerous-commands` | 5 | +| أوامر الهياكل الأساسية | `infra-commands` | 7 | +| Git | `git` | 6 | +| قاعدة البيانات | `database` | 2 | +| الحزم والنظام | `packages-system` | 5 | +| سلوك الذكاء الاصطناعي | `ai-behavior` | 1 | +| سير العمل | `workflow` | 5 | + +هذه هي أعداد الفهرس المجمّع، وتصل إلى 39. الحزمة تحمل 38 منها، لأن `block-failproofai-commands` هي `alwaysOn` ولا تسير في مسار الحزمة — لذا `--category dangerous-commands` تختار الأربع الأخرى. + +خذ جزء بدلاً من الإعدادات الافتراضية: + +```bash +failproofai policies add FailproofAI/policies --category git,database +failproofai policies add FailproofAI/policies --policy block-rm-rf +failproofai policies add FailproofAI/policies --all +``` + +## اقرأ الفهرس قبل أن تختاره + + ```bash + failproofai policies show FailproofAI/policies failproofai policies - failproofai policy add block-rm-rf --cli claude --scope project - failproofai config --status ``` - أزلها باستخدام `failproofai policy remove block-rm-rf --cli claude --scope project`. + `policies show` يقرأ البيان المنشور — كل سياسة، مجمّعة حسب الفئة، موضحة كافتراضية أو اختيارية — دون تنزيل أو استيراد كود الحزمة. `failproofai policies` يسرد ما هو مفعّل على هذه الآلة: الملفات المخصصة، ملفات الاتفاقية، الحزم المثبتة والتعيينات السحابية. لا يحتوي على قسم مدمج، لذا يجيب على "ما هو مفعّل هنا"، وليس أبداً "ما هو موجود". + + + تصفح نفس الفهرس في متصفح، بدون CLI، في [befailproof.ai/policy-hub](https://befailproof.ai/policy-hub/). كل حزمة لها صفحة في `/policy-hub///` وكل سياسة لها صفحة في `/policy-hub////`. + + + 1. ثبّت السياسة على آلة متصلة باستخدام CLI المحلي. + 2. شغّل إجراء اختبار آمن في الوكيل المجهز بأداة. + 3. اذهب إلى **Observe → policy** وصفّ حسب اسم السياسة أو بيئة الآلة أو القرار. + 4. افتح الجلسة المرتبطة للتأكد من مطابقة إدخال الأداة والسبب المُرجع. -اعرض قائمة بالسياسات المتاحة في النسخة المثبتة لديك: - -```bash -failproofai policies -``` - -قم بتفعيل سياسة واحدة لمشروع: +## فعّل واحدة أو أطفئها ```bash -failproofai policy add block-rm-rf --scope project +failproofai policies add block-rm-rf --cli claude --scope project +failproofai policies remove block-rm-rf --cli claude --scope project ``` -قم بتفعيل عدة سياسات لأجهزة اختبار معينة: +`policies add` و `policies remove` تأخذ بالضبط **واحدة** اسم سياسة. قم بتشغيلها بدون اسم على الإطلاق وستحصل على منتقي، مع ما هو مفعّل بالفعل محدد. للعديد من الأسماء في نفس الوقت، استخدم نموذج التثبيت: ```bash failproofai policies --install block-sudo block-force-push \ --cli claude codex --scope project ``` -بعض السياسات تقبل معاملات أو تحمل علامة beta. راجع الوصف ونطاق المطابقة والسلوك الافتراضي قبل الطرح. قد تحمي سياسة ما سير عمل واحد وتحظر العمليات الصحيحة في آخر. + + على آلة بدون حزمة مثبتة، `failproofai policies add ` يجلب `FailproofAI/policies` من إصدارها على GitHub لتلبية الاسم — لذا هذا الأمر الأول يحتاج الشبكة. + + +## ليس كل سياسة تفرض على كل جهاز + +السياسة تغيير السلوك فقط حيث يستهلك الجهاز الحكم للحدث الخاص به. حالتان تستحقان التحقق قبل أن تعتمد على مدمج: + +| الحدث | حيث يتم التحقق من أن الرفض يغيير السلوك | +| --- | --- | +| `PreToolUse` | جميع 12 أجهزة | +| `Stop` | claude, codex, copilot, cursor, openclaw, factory, devin, antigravity. لا يتم تثبيت `Stop` hook على goose أو hermes، pi ينقل السبب إلى الدور التالي بدلاً من ذلك، و opencode لم يتم التحقق منه | + +لذا السياسات الخمس `require-*-before-stop` في فئة سير العمل يمكن تفعيلها على آلة وتظل لا تُطلق أبداً، اعتماداً على الوكيل الذي يعمل هناك. VMs Cursor Cloud Agent لا تشغل أي stop hooks على الإطلاق. + +سياسات `warn-*` و `prefer-*` تُرجع `instruct` بدلاً من `deny`. على Hermes و Goose، وخارج قناة `Stop` على Pi و OpenClaw و Factory و Antigravity، يتدهور `instruct` إلى allow بالإضافة إلى ملاحظة على stderr: المشغل يراها في السجلات، الوكيل لا. + +بعض السياسات تقبل معاملات. راجع الوصف، طابق النطاق والافتراضي قبل النشر — سياسة تحمي سير عمل واحد قد تحجب عمليات صحيحة في آخر. - - راجع جميع السياسات الحالية البالغ عددها 40، ومحفزاتها والأساس الموصى به والمعاملات. + + جميع 39 سياسة مدمجة، حسب الفئة، مع مشغلاتها والإعدادات الافتراضية والمعاملات. - يُفضل نطاق المشروع للتوقعات المحددة للمستودع ونطاق المستخدم لمتطلبات الأمان على مستوى الجهاز. + `failproofai config` يسلك كل وكيل مدعوم في نطاق المستخدم ولا يختار أي سياسات — لا يحتوي على علم `--scope`. مرر `--scope project` إلى `failproofai policies add` أو `failproofai policies --install` فقط عندما تنتمي التوقعات حقاً إلى مستودع واحد. \ No newline at end of file diff --git a/docs/ar/policies/custom.mdx b/docs/ar/policies/custom.mdx index 7a6d93fd0..32e3ca8d3 100644 --- a/docs/ar/policies/custom.mdx +++ b/docs/ar/policies/custom.mdx @@ -1,73 +1,52 @@ --- --- title: "السياسات المخصصة" -description: "اكتب سياسة لنمط فشل فريد لسير عمل وكيلك." -icon: "shield-plus" +description: "اكتب قاعدة للسلوك المحدد لوكيلك أو سير عملك." +icon: "code-2" --- -أنشئ ملف ينتهي بـ `policies.js` أو `policies.mjs` أو `policies.ts` ضمن `.failproofai/policies/`. تُحمّل ملفات الاتفاقية تلقائياً على نطاق المشروع والمستخدم. +تحقق من [الكتالوج المدمج](/ar/policies/builtin-catalog) قبل كتابة سياسة. القاعدة المراجعة عادة ما تكون أأمن من واحدة جديدة. -## اختبر السياسة قبل النشر على السحابة +## ابدأ من سياسة تعمل - - - 1. ثبّت السياسة المخصصة على آلة اختبار واحدة وأطلق إجراءً متطابقاً وعدم تطابق شرعياً. - 2. انتقل إلى **Observe → policy** وقارن بين القرارين. - 3. افتح كل جلسة مرتبطة وتحقق من أن حمل الحدث يحتوي على أدلة كافية للقاعدة. - 4. عندما يكون السلوك صحيحاً، انقل المصدر المراجع إلى **Admin → policy editor** وأصدر نسخة. - - - - ```bash - failproofai policies --install --custom ./security.policies.ts \ - --cli claude --scope project - failproofai policies - ``` +```bash +failproofai publish --init guards.mjs +failproofai policies -i -c ./guards.mjs +``` - ملفات الاتفاقية ضمن `.failproofai/policies/` تُحمّل بدون `--custom`. احفظ أمر التثبيت الصريح في CI عندما يجب أن يفشل التحقق على وحدة معطوبة. - - +الكتل الأساسية تحجب `git push --force`. عدّلها، اطلب من وكيلك أن يحاول الإجراء المحجوب، وافحص **Policies → Activity**. -```ts +```js import { customPolicies, allow, deny } from "failproofai"; customPolicies.add({ - name: "protect-production-paths", - description: "Block writes to production configuration", - match: { events: ["PreToolUse"] }, - fn: async (ctx) => { - if (ctx.toolName !== "Write" && ctx.toolName !== "Edit") return allow(); - const path = String(ctx.toolInput?.file_path ?? "").replaceAll("\\", "/"); - if (path.split("/").includes("production")) { - return deny("Writes to production configuration require approval."); - } - return allow(); - }, + name: "protect-production", + description: "Production changes need a human", + match: { events: ["PreToolUse"], toolNames: ["Bash"] }, + fn: async (ctx) => + String(ctx.toolInput?.command ?? "").includes("production") + ? deny("Ask a human before changing production.") + : allow(), }); ``` -يتطابق هذا مع `production/config.yml` و `/srv/production/config.yml` و `/srv/production` و `C:\\production\\config.yml` لكل من `Write` و `Edit`. لا يتطابق مع أسماء مثل `production-backup` لأن `production` يجب أن تكون قطعة مسار كاملة. +تعيد السياسة `allow()` أو `deny(message)` أو `instruct(message)`. استخدم `deny` عندما يجب إيقاف الإجراء؛ لا يمكن لكل نطاق توصيل تعليمات مرة أخرى للوكيل. -تحقق وثبّت ملفاً صريحاً: +## تحميل تلقائي -```bash -failproofai policies --install --custom ./security.policies.ts -``` +ضع الملفات المسماة `*policies.js` أو `*policies.mjs` أو `*policies.ts` تحت: -سياق السياسة يتضمن نوع الحدث والحمل المُعايير واسم الأداة والإدخال ومعادات الجلسة والمعاملات ومصدر CLI عند توفره. +- `.failproofai/policies/` لمشروع واحد. +- `~/.failproofai/policies/` لمستخدمك. ## اختبر مسارات الفشل -قم بالتحقق بعد تغيير ملف الدخول أو أي وحدة محلية يستوردها: +اختبر كلاً من الإجراء غير الآمن والعمل المشروع الذي يبدو مشابهاً. تأكد من أن القرار جاء من سياستك وليس من قاعدة أخرى. + +أزل ملفات الاختبار الصريحة باستخدام: ```bash -failproofai policies --install --custom ./security.policies.ts --scope project +failproofai policies -u -c ``` -مسار CLI الصارم يفشل للملفات المفقودة وأخطاء بناء الجملة والواردات غير المحللة والاستثناءات على مستوى أعلى والمهلات الزمنية لتحميل الوحدة. في وقت الإنفاذ، يتم تسجيل ملف مخصص معطوب وتخطيه حتى تتمكن السياسات المدمجة من المتابعة. تعامل مع أي تحذير تحميل كفقدان للإنفاذ المتوقع والتنبيه عليه في سجلات الإنتاج. - -استخدم أسماءً فريدة عالمياً عبر السياسات الصريحة والاتفاقية والمُدارة من السحابة. اجعل دوال السياسة حتمية، وقيّد الاستدعاءات الخارجية بمهل زمنية قصيرة، وأرجع `allow` أو `instruct` أو `deny` مقصود على كل مسار. - - - السياسة المخصصة هي كود إنفاذ. اختبر الحقول المفقودة وأسماء الأدوات البديلة والمدخلات المشوهة—ليس فقط المطابقة المتوقعة. - \ No newline at end of file +عندما تكون السياسة جاهزة، [انشر حزمة](/ar/policies/publish-a-pack) أو [نشرها عبر Cloud](/ar/policies/deploy). \ No newline at end of file diff --git a/docs/ar/policies/deploy.mdx b/docs/ar/policies/deploy.mdx index 8cc7efbea..3c74d1a67 100644 --- a/docs/ar/policies/deploy.mdx +++ b/docs/ar/policies/deploy.mdx @@ -1,52 +1,55 @@ --- --- title: "نشر السياسات" -description: "إطلاق نسخة سياسة تم مراجعتها إلى الأجهزة المقصودة." +description: "راقب سياسة على نشاط الوكيل الفعلي، ثم طبّقها أو تراجع عنها." icon: "cloud-upload" --- -يربط النشر نسخة واحدة أو أكثر من السياسات بمجموعة مستهدفة من الأجهزة المسجلة. +نشّر سياسة تمت مراجعتها على جهاز واحد في كل مرة. ابدأ في وضع المراقبة. -## تطبيق نشر +## الطرح من سطر الأوامر - - - 1. انتقل إلى **Admin → enforcement**، ابحث عن الجهاز، وقم بتوسيع صفه. - 2. اختر **edit**، أضف نسخة السياسة المراجعة، واختر **observe** أو تأثيرها الإجباري. - 3. طبّق التغيير، ثم انتظر فحص الجهاز التالي وتأكد من حالة نشره وتغطيته. - 4. انتقل إلى **Observe → policy** للفحص القرارات المباشرة. +```bash +fp policies test ./rule.mjs --tool Bash --command "git push --force" --expect deny +fp policies publish no-force-push ./rule.mjs +fp fleet deploy --add no-force-push:observe +fp guardrails summary --since 24h --machine +fp fleet deploy --add no-force-push:enforce +``` - ![محرر نشر الجهاز مع نسخ السياسات، وتأثيرات الفرض والمراقبة، وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png) - - - قم بالنشر من واجهة سطر الأوامر باستخدام `fp fleet`. راجع مجموعة النتائج قبل تطبيقها — يطبع `deploy` الخطة الكاملة ويسأل **فقط على محطة تفاعلية بدون `--json`**. تحت `--json`، مع `--yes`، أو مع إعادة توجيه stdin (خطوة CI، سكريبت، وكيل يشغل shell) يتم التطبيق فوراً بدون خطة وبدون مطالبة — لذا قم بتشغيل `fp fleet show ` أولاً إذا كنت تريد المراجعة: +يقيّم وضع المراقبة السياسة الفعلية ويسجل القرارات غير المسموحة، لكنه لا يحجب الوكيل. - ```bash - fp fleet list - fp fleet show - fp fleet deploy --add no-force-push - ``` + + إن استخدام `--add no-force-push` بدون إضافة يطبق السياسة فوراً. أضف `:observe` لطرح خادع. + - يعرض `fp fleet diff ` النية مقابل التسليم (يُقرأ الجهاز كـ `behind` حتى يقوم بالاستطلاع التالي)، `fp fleet history ` يسرد الأجيال، و `fp fleet rollback ` يستعيد واحداً — يرفض إذا كان هذا الجيل يسمي سياسة تم تعطيلها أو حذفها. +إذا تسبب التطبيق في مشاكل: - تحقق من الجهاز نفسه باستخدام `failproofai config --status`، واستخدم `fp sessions --env production --since 24h` و `fp events --event-type hook_completed` بعد النشر للتحقق من وصول النشاط إلى Cloud. - - +```bash +fp fleet history +fp fleet rollback +``` - - - قم بنشر نسخة تم مراجعتها، وليس مسودة قابلة للتغيير، بدءاً بجهاز غير إنتاجي أو مجموعة صغيرة يمكنك فحص جلساتها. - - - راجع التطابقات والأسباب والأدوات المتأثرة والإيجابيات الكاذبة بدون حجب العمل. - - - قم بالترقية بعد المطابقات المرصودة التي تفصل الإجراءات غير الآمنة عن الإجراءات الصحيحة، ثم تأكد من أن كل جهاز مقصود قد سحب النشر ويقدم التقارير عن القرارات. - - +## النشر من لوحة التحكم -تحتاج الأجهزة إلى القدرة على `policies:pull`. يتم التحكم في الإبلاغ عن الأحداث بشكل منفصل بواسطة `events:add`؛ تحقق من كليهما عندما تتوقع تحليل Cloud والفرض. +1. انتقل إلى **Admin → enforcement**. +2. افتح الجهاز المستهدف. +3. أضف إصدار السياسة مع التأثير **observe**. +4. طبّق النشر. +5. راجع النتائج تحت **Observe → policy**. +6. رقّ نفس الإصدار إلى **enforce** عندما تكون المطابقات صحيحة. - - إدارة الفرض هي سير عمل إداري في Cloud. لا تعامل مسارات الفرض للمسؤول الجذر فقط كنقاط نهاية API عادية للعملاء `/v1`. - \ No newline at end of file +![محرر نشر الجهاز مع إصدارات السياسات وتأثيرات enforce و observe وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png) + +## استبدال أو مرحلة مسبقة من مجموعة + +- `--remove ` يزيل سياسة واحدة. +- `--set ...` يستبدل مجموعة السياسات الكاملة. +- `--create` يحضّر نشراً قبل أن يتحقق الجهاز للمرة الأولى. +- `fp fleet diff ` يقارن الحالة المقصودة والمطبقة. + + + بدون Cloud، انشر حزمة باستخدام `failproofai publish --effect observe` وفتّش القرارات في لوحة التحكم المحلية. + + +تحتاج الأجهزة إلى `policies:pull` لاستقبال النشرات و `events:add` للإبلاغ عن القرارات. \ No newline at end of file diff --git a/docs/ar/policies/failure-behavior.mdx b/docs/ar/policies/failure-behavior.mdx index a75a67cbc..dd8797e3f 100644 --- a/docs/ar/policies/failure-behavior.mdx +++ b/docs/ar/policies/failure-behavior.mdx @@ -1,68 +1,49 @@ --- --- -title: "سلوك الفشل" -description: "افهم ما يحدث عند عدم توفر تقييم السياسة أو daemon المحلي." +title: "سلوك فشل السياسة" +description: "افهم لماذا يرفض Failproof AI عندما لا يتمكن التقييم من الرد." icon: "shield-alert" --- -تم تصميم Failproof AI بحيث يكون فشل الإنفاذ مرئياً بدلاً من السماح الصامت بعمل محفوف بالمخاطر. +بعد الإعداد، خدمة `failproofaid` المحلية هي المُقيِّم الوحيد. إذا لم تتمكن من الرد، يتم رفض الإجراءات المحمية بدلاً من السماح بها بصمت. -## تشخيص كتلة مغلقة الفشل +## تشخيص حظر على مستوى الجهاز - - - 1. انتقل إلى **Admin → enforcement** وافتح الآلة. - 2. تحقق من آخر تسجيل دخول، والنشر المعين، والنشر المبلغ عنه. - 3. انتقل إلى **Observe → policy** وافتح جلسة القرار المرفوض. - 4. تأكد مما إذا كان السبب يشير إلى إمكانية الوصول إلى daemon أم عدم التطابق في الإصدار أم السياسة نفسها. - - - - ```bash - failproofai config --status - npm install -g failproofai@latest - failproofai config - ``` - - إعادة تشغيل `failproofai config` يحدّث ويعيد تشغيل daemon بعد ترقية الحزمة. - - - -على آلة تم تكوينها لاستخدام `failproofaid`، يكون daemon هو المقيّم الوحيد. إذا كان غير قابل للوصول أو كان إصدار البروتوكول الخاص به لا يطابق CLI، يفشل تقييم hook بشكل مغلق. يتم رفض الإجراء مع سبب يوجه المشغل إلى التحقق من daemon أو تحديثه. - -قبل تكوين daemon، تقيّم hooks السياسات أثناء المعالجة. بمجرد تسجيل تكوين daemon، لا يعود Failproof AI إلى تقييم ثاني بصمت عند فشل daemon. +```bash +failproofai config --status +systemctl status failproofaid@$USER # Linux +sudo launchctl print system/ai.failproof.failproofaid.$USER # macOS +``` -## الاستجابة لقرار مغلق الفشل +قم بتشغيل `failproofai config` لإصلاح الخدمة أو تثبيت الإصدار المطابق. -1. قم بتشغيل `failproofai config --status`. -2. إذا اختلفت الإصدارات، أعد تشغيل `failproofai config` بعد تحديث الحزمة. -3. إذا كان daemon غير قابل للوصول، افحص حالة الخدمة وسجلات الملف الشخصي المحلي. -4. استأنف عمل agent فقط بعد التأكد من أن مسار تقييم السياسة المعروف سليم. +يمكن أن يبدو الفشلان متشابهين: - - لا تحاول تكرار الإجراء المحظور بشكل متكرر. استجابة مغلقة الفشل تعني أن النظام لم يتمكن من إثبات أن الإجراء كان آمناً. - +| الفشل | المعنى | +| --- | --- | +| الخدمة غير متاحة | المقبس ليس لديه مُقيِّم عامل خلفه | +| عدم تطابق الإصدار | واجهة سطر الأوامر والخدمة لا تتفقان على البروتوكول | -## لن يتم تحميل الحزمة +كلاهما يرفض، لكن تقارير الحالة تفصل بينهما. -آلة تم إخبارها بفرض حزمة، ولا يمكنها تشغيلها، ترفض بدلاً من المتابعة بصمت. المحفز هو **توقع مسجل**، وليس توقع فارغ: آلة بدون حزم مثبتة تكون صامتة، بينما حزمة تم إعلانها ولن تُحل — أو تسجل أقل من ما يعلنه البيان الخاص بها — ترفض. +## لن يتم تحميل حزمة -الرفض **ضيق**، على عكس daemon غير قابل للوصول. daemon الذي لا يمكن الوصول إليه يعني أنه لم يحدث أي تقييم على الإطلاق، لذلك لا يمكن معرفة شيء آمن. حزمة لن تتحمل لديها مجموعة قابلة للعد من الحراس المفقودين، لأن كل سياسة معلنة تحمل `match` خاصة بها — لذلك ترفض فقط الأحداث والأدوات التي غطتها تلك السياسات، وكل شيء آخر يمضي قدماً. +تحديد حزمة مفقودة أو مُعدَّلة أو غير صالحة يرفض الأحداث المغطاة بسياساتها المحددة. وهذا يمنع اختفاء حزمة مكسورة بينما يبدو الجهاز محمياً. -لا تنطلق بسبب: +`failproofai policies` يسمي الحزمة وخطأ التحميل. -- حزمة `observe`، التي تقيّم وتتجاهل بالبناء -- سياسات لم تأخذها، أو أوقفتها بشكل صريح -- حزمة لم يتلقاها المحمّل، حيث لا يمكن التمييز بين «لا تسجيلات» و تخطي متعمد -- توقف جلسة نشطة -- مهلة زمنية للتحميل، وهي عابرة — لحظة قرص واحدة بطيئة يجب ألا ترفض حتى يتدخل إنسان +```bash +failproofai policies +failproofai policies remove owner/repo +failproofai policies add owner/repo@ +``` -`UserPromptSubmit` **توجه** بدلاً من الرفض، مهما أعلنت السياسة المفقودة. رفض شامل سيأخذ معه ويغلقك خارج agent الذي يمكنه إصلاح المشكلة. +البيانات الوصفية غير القابلة للقراءة توسع الرفض الآمن بدلاً من تضييقه بناءً على البيانات التي لا يمكن الوثوق بها. -### ماذا تفعل +## ما يبقى متاحاً -```bash -failproofai pack list -``` +لوحة المعلومات المحلية وأوامر الحالة لا تزال تعمل بينما يفشل تقييم السياسة. استخدمها لتحديد الخدمة أو الحزمة أو الإصدار الذي يحتاج إلى إصلاح. -يسمي أي حزمة مثبتة لن يتم تحميلها، ويقول السبب، ويخرج برمز غير صفر. ثم إما أعد تثبيتها (`failproofai pack add `) أو أزلها (`failproofai pack remove `) — إزالتها تسحب التوقع، والرفض يتوقف معها. \ No newline at end of file + + لا تتجاوز قرار الإغلاق عند الفشل بحذف خدمة أو ملفات الحزمة. أصلح الخدمة أو أعد تثبيت الحزمة أو أزل التعيين من خلال واجهة سطر الأوامر بحيث يعود الجهاز إلى حالة معروفة. + \ No newline at end of file diff --git a/docs/ar/policies/fleet.mdx b/docs/ar/policies/fleet.mdx index 5f2b83cb8..94e203edf 100644 --- a/docs/ar/policies/fleet.mdx +++ b/docs/ar/policies/fleet.mdx @@ -1,53 +1,62 @@ --- --- -title: "نشر السياسات على الأجهزة" -description: "تعرّف على الأجهزة المسجلة والمحدثة والتي تفرض إصدارات السياسة المقصودة." +title: "تغطية الأسطول" +description: "اطّلع على الأجهزة التي استقبلت وطبّقت السياسات المقصودة." icon: "network" --- -يجيب تغطية الأسطول على السؤال حول ما إذا كانت السياسة موجودة حيث توجد المخاطر. تتبع الأجهزة من خلال معرّف مستقر وتسمية يمكن قراءتها من قبل الإنسان، ثم قارن بين حالة النشر المخصصة والمُبلغ عنها. +تقارن تغطية الأسطول ما خصصته السحابة مع ما طبّقه كل جهاز آخر مرة. -## التحقق من التغطية +## التحقق من جهاز - - - 1. انتقل إلى **Admin → enforcement** واستعرض إجمالي الأجهزة التي تفرض وتراقب. - 2. ابحث عن جهاز حسب المعرّف أو التسمية، أو قم بالتصفية للأجهزة التي تفتقد سياسة. - 3. وسّع الصف لمقارنة السياسات المعينة والنشر المُبلغ عنه ووقت آخر تسجيل دخول والسجل. - 4. أعِد التحديث بعد فترة استطلاع الجهاز عندما يبقى النشر المطبق قيد الانتظار. +```bash +failproofai config --status +failproofai flush --wait --timeout 120 +``` - ![أسطول الإنفاذ يعرض تغطية السياسة وحالة نشر الجهاز وتعيينات المراقبة والإنفاذ.](/images/dashboard/enforcement-fleet.png) - - - ```bash - failproofai config --status - failproofai config --machine-label checkout-runner-03 - failproofai flush --wait - ``` +من السحابة: + +```bash +fp fleet list +fp fleet diff +fp fleet show +``` - استخدم `fp events --agent-id --since 24h` للتأكد من وصول نشاط وكيل الجهاز إلى السحابة. - - +يتطلب `fp fleet` جلسة تسجيل دخول، وليس مفتاح API. -استخدم عروض التغطية للبحث عن: +| الأمر | ما يفعله | +| --- | --- | +| `fp fleet list` | اسرد الأجهزة وحالة النشر | +| `fp fleet show ` | اعرض مجموعة السياسات لجهاز واحد | +| `fp fleet deploy --add ` | أضف أو حدّث سياسة واحدة | +| `fp fleet deploy --remove ` | أزل سياسة واحدة | +| `fp fleet deploy --set ...` | استبدل المجموعة بأكملها | +| `fp fleet diff [machine]` | قارن الإصدارات المقصودة والمطبّقة | +| `fp fleet history ` | اسرد أجيال النشر | +| `fp fleet rollback ` | استعد جيلاً | +| `fp fleet rename "