Skip to content

[auto] update translations #754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
NiveditJain merged 1 commit into from
Aug 25, 2026
Merged

[auto] update translations #754

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
29 changes: 15 additions & 14 deletions docs/ar/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,19 +1,20 @@
---
title: "اجعل وكيلك آمناً من الأعطال"
description: "المراقبة والإنفاذ لكل بيئة تشغيل يعمل بها وكيلك — واجهات سطر الأوامر للترميز، بوابات الدردشة، المساعدات المستضافة ذاتياً، ووكلاؤك المجهزون بأدوات المراقبة."
---
title: "اجعل وكيلك آمنًا تماماً"
description: "قابلية الملاحظة والتطبيق لكل بيئة تشغيل يعمل فيها وكيلك — واجهات سطر الأوامر للترميز، بوابات الدردشة، المساعدات المستضافة ذاتياً، والوكلاء المزودين بأدوات المراقبة الخاصة بك."
icon: "shield-check"
---

يساعد Failproof AI الفرق على فهم ما فعله الوكيل، واكتشاف مكان فشله، ونشر الحماية قبل تكرار السلوك نفسه مرة أخرى.
Failproof AI يساعد الفرق على فهم ما فعله الوكلاء، والعثور على أماكن فشلهم، ونشر الحماية قبل حدوث نفس السلوك مرة أخرى.

**البيئة التشغيلية** هي ما يعمل وكيلك بداخله فعلياً. يتصل Failproof AI بـ 12 منها — واجهات سطر الأوامر للترميز مثل Claude Code و Codex، بوابات الدردشة مثل Hermes، المساعدات المستضافة ذاتياً مثل OpenClaw — وتطبق الأحداث والسياسات وسجل الجلسات نفسه على كل واحدة منها. يرسل الوكلاء بدون بيئة تشغيلية البيانات من خلال [Python SDK](/ar/reference/custom-agents)، الذي يتتبع ويدقق فيها؛ لإنفاذ سياسة هناك تحتاج إلى hook في runtime الخاص بك.
**البيئة التشغيلية** هي أي شيء يعمل فيه وكيلك بالفعل. Failproof AI يربط 12 منها — واجهات سطر أوامر للترميز مثل Claude Code و Codex، وبوابات دردشة مثل Hermes، ومساعدات مستضافة ذاتياً مثل OpenClaw — وتنطبق نفس الأحداث والسياسات وسجل الجلسات على كل واحدة منها. الوكلاء الذين ليس لديهم بيئة تشغيلية يقدمون تقارير من خلال [Python SDK](/ar/reference/custom-agents)، الذي يتتبعهم ويقومون بتدقيقهم؛ تطبيق سياسة هناك يتطلب خطاف في وقت التشغيل الخاص بك.

<Columns cols={2}>
<Card title="إعداد Failproof" icon="wand-sparkles" href="/ar/start/quickstart">
استخدم المهارة لتجهيز مشروعك، واتصل به، وتحقق من وصول سجلات الوكيل.
<Card title="قم بإعداد Failproof" icon="wand-sparkles" href="/ar/start/quickstart">
استخدم المهارة لأتمتة مشروعك وتوصيله والتحقق من وصول سجلات الوكيل.
</Card>
<Card title="اسأل مساعد Failproof" icon="message-square-text" href="/ar/sessions/assistant">
حلل واستعلم وأنشئ لوحات معلومات وقم بعمليات تدقيق باللغة الطبيعية على سجلات الوكيل.
حلل واستعلم وقم ببناء لوحات معلومات وتشغيل عمليات التدقيق باللغة الطبيعية على سجلات وكيلك.
</Card>
</Columns>

Expand All @@ -22,20 +23,20 @@ icon: "shield-check"
تابع استدعاءات النموذج والأدوات والأخطاء والمدخلات البشرية والكمون وقرارات السياسة في جلسة واحدة.
</Card>
<Card title="ابحث عن الأعطال بشكل منهجي" icon="scan-search" href="/ar/audits/overview">
دقق مجموعة محددة من الجلسات، راجع النتائج المدعومة بالأدلة، وتتبع التصحيح كمشاكل.
قم بتدقيق مجموعة محددة من الجلسات وراجع النتائج المدعومة بالأدلة وتابع الإصلاح كمشاكل.
</Card>
<Card title="منع التكرار" icon="shield-check" href="/ar/policies/overview">
حول طريقة فشل معروفة إلى سياسة، راقب تأثيرها، ونشرها عبر أسطولك.
حول وضع فشل معروف إلى سياسة وراقب تأثيره ونشره عبر أسطولك.
</Card>
</Columns>

> **الجلسة → التدقيق → البحث → المشكلة → السياسة**<br />
> تتبع ما حدث، ابحث عن الفشل، أدر الاستجابة، ثم منع السلوك نفسه في الأدوار المستقبلية.
> **جلسة → تدقيق → نتيجة → مشكلة → سياسة**<br />
> تتبع ما حدث، أوجد الفشل، أدر الاستجابة، ثم منع نفس السلوك في التشغيلات المستقبلية.

## ابدأ من هنا

إذا كنت تنشر وكيلك المجهز بأدوات المراقبة للمرة الأولى، ابدأ بـ [الدليل السريع](/ar/start/quickstart). إذا كانت البيانات تصل بالفعل، افتح [الجلسات](/ar/sessions/overview) وفتش عملية تشغيل حقيقية قبل تكوين عمليات التدقيق أو السياسات.
إذا كنت تنشر وكيلك المزود بأدوات المراقبة للمرة الأولى، فابدأ بـ [البدء السريع](/ar/start/quickstart). إذا كانت البيانات تصل بالفعل، فافتح [الجلسات](/ar/sessions/overview) وتفحص تشغيلاً حقيقياً قبل تكوين عمليات التدقيق أو السياسات.

<Card title="ابحث عن عطل واحد ومنعه" icon="arrow-right" href="/ar/start/quickstart">
أكمل سير العمل الشامل من الالتقاط إلى سياسة تم نشرها بأمان.
<Card title="ابحث عن عطل واحد وحده منع" icon="arrow-right" href="/ar/start/quickstart">
أكمل سير العمل من الطرف إلى الطرف الآخر من المراقبة إلى سياسة آمنة ومنشورة.
</Card>
36 changes: 20 additions & 16 deletions docs/ar/policies/deploy.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
---
title: "نشر السياسات"
description: "طرح نسخة سياسة تم مراجعتها على الأجهزة المستهدفة."
description: "إطلاق نسخة سياسة تم مراجعتها إلى الأجهزة المقصودة."
icon: "cloud-upload"
---

Expand All @@ -11,38 +11,42 @@ icon: "cloud-upload"

<Tabs>
<Tab title="لوحة التحكم">
1. انتقل إلى **المسؤول → الإنفاذ**، ابحث عن الجهاز، وقم بتوسيع صفه.
2. اختر **تعديل**، أضف نسخة السياسة المراجعة، واختر **مراقبة** أو تأثيرها الإنفاذي.
3. طبّق التغيير، ثم انتظر الفحص التالي للجهاز وأكّد حالة النشر والتغطية.
4. انتقل إلى **مراقبة → سياسة** لفحص القرارات المباشرة.
1. انتقل إلى **Admin → enforcement**، ابحث عن الجهاز، وقم بتوسيع صفه.
2. اختر **edit**، أضف نسخة السياسة المراجعة، واختر **observe** أو تأثيرها الإجباري.
3. طبّق التغيير، ثم انتظر فحص الجهاز التالي وتأكد من حالة نشره وتغطيته.
4. انتقل إلى **Observe → policy** للفحص القرارات المباشرة.

![محرر نشر الجهاز يعرض نسخ السياسات وتأثيرات الإنفاذ والمراقبة وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png)
![محرر نشر الجهاز مع نسخ السياسات، وتأثيرات الفرض والمراقبة، وإجراء تطبيق النشر.](/images/dashboard/enforcement-editor.png)
</Tab>
<Tab title="واجهة سطر الأوامر">
لا يتم عن قصد كشف نقاط نهاية النشر السحابي كأوامر `fp` عادية. تحقق من الجهاز محليًا، ثم قم بالنشر عبر لوحة التحكم:
قم بالنشر من واجهة سطر الأوامر باستخدام `fp fleet`. راجع مجموعة النتائج قبل تطبيقها — يطبع `deploy` الخطة الكاملة ويسأل **فقط على محطة تفاعلية بدون `--json`**. تحت `--json`، مع `--yes`، أو مع إعادة توجيه stdin (خطوة CI، سكريبت، وكيل يشغل shell) يتم التطبيق فوراً بدون خطة وبدون مطالبة — لذا قم بتشغيل `fp fleet show <machine>` أولاً إذا كنت تريد المراجعة:

```bash
failproofai config --status
fp fleet list
fp fleet show <machine-id>
fp fleet deploy <machine-id> --add no-force-push
```

استخدم `fp sessions --env production --since 24h` و `fp events --event-type hook_completed` بعد النشر للتحقق من وصول النشاط إلى Cloud.
يعرض `fp fleet diff <machine-id>` النية مقابل التسليم (يُقرأ الجهاز كـ `behind` حتى يقوم بالاستطلاع التالي)، `fp fleet history <machine-id>` يسرد الأجيال، و `fp fleet rollback <machine-id> <generation>` يستعيد واحداً — يرفض إذا كان هذا الجيل يسمي سياسة تم تعطيلها أو حذفها.

تحقق من الجهاز نفسه باستخدام `failproofai config --status`، واستخدم `fp sessions --env production --since 24h` و `fp events --event-type hook_completed` بعد النشر للتحقق من وصول النشاط إلى Cloud.
</Tab>
</Tabs>

<Steps>
<Step title="اختر النسخة والأهداف">
قم بنشر نسخة تم مراجعتها وليس مسودة قابلة للتغيير، بدءًا بجهاز غير إنتاجي أو مجموعة صغيرة يمكنك فحص جلساتها.
قم بنشر نسخة تم مراجعتها، وليس مسودة قابلة للتغيير، بدءاً بجهاز غير إنتاجي أو مجموعة صغيرة يمكنك فحص جلساتها.
</Step>
<Step title="مراقبة القرارات">
راجع المطابقات والأسباب والأدوات المتأثرة والإيجابيات الخاطئة دون حجب العمل.
<Step title="راقب القرارات">
راجع التطابقات والأسباب والأدوات المتأثرة والإيجابيات الكاذبة بدون حجب العمل.
</Step>
<Step title="الإنفاذ والتحقق من التغطية">
قم بالترقية بعد أن تفصل المطابقات المراقبة الإجراءات غير الآمنة عن الإجراءات الصحيحة، ثم تأكد من أن كل جهاز مستهدف قد سحب النشر ويُبلّغ عن القرارات.
<Step title="فرض والتحقق من التغطية">
قم بالترقية بعد المطابقات المرصودة التي تفصل الإجراءات غير الآمنة عن الإجراءات الصحيحة، ثم تأكد من أن كل جهاز مقصود قد سحب النشر ويقدم التقارير عن القرارات.
</Step>
</Steps>

تحتاج الأجهزة إلى قدرة `policies:pull`. يتم التحكم في تقارير الأحداث بشكل منفصل بواسطة `events:add`؛ تحقق من كليهما عندما تتوقع تحليل الـ Cloud والإنفاذ.
تحتاج الأجهزة إلى القدرة على `policies:pull`. يتم التحكم في الإبلاغ عن الأحداث بشكل منفصل بواسطة `events:add`؛ تحقق من كليهما عندما تتوقع تحليل Cloud والفرض.

<Warning>
إدارة الإنفاذ هي عملية سير عمل إدارية في الـ Cloud. لا تتعامل مع مسارات الإنفاذ الحصرية للجذر كنقاط نهاية `/v1` API عادية للعملاء.
إدارة الفرض هي سير عمل إداري في Cloud. لا تعامل مسارات الفرض للمسؤول الجذر فقط كنقاط نهاية API عادية للعملاء `/v1`.
</Warning>
46 changes: 24 additions & 22 deletions docs/ar/policies/editor.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,48 +1,50 @@
---
---
title: "محرر السياسات"
description: "إنشاء وتعديل السياسات ذات الإصدارات من نمط فشل مؤكد."
description: "إنشاء ومراجعة السياسات ذات الإصدارات من نمط فشل مؤكد."
icon: "file-pen-line"
---

استخدم محرر السياسات لتحويل نتيجة بحث أو مشكلة إلى قاعدة قابلة للنشر. حافظ على فصل عملية التأليف عن النشر بحيث لا يمكن لمسودة أن تغيّر السلوك المباشر بصمت.
استخدم محرر السياسات لتحويل نتيجة بحث أو مشكلة إلى قاعدة قابلة للنشر. احتفظ بالتأليف منفصلاً عن النشر بحيث لا يمكن لمسودة أن تغيّر السلوك الحي بصمت.

عندما تكون لديك مشكلة بها نمط إجراء قابل للتكرار، افتحها ضمن **Analyze → issues** واختر **generate policy**. يشرح Failproof AI أولاً ما إذا كانت السياسة يمكنها التعبير عن المشكلة، ثم ينقل النية المراجعة وسياق البحث إلى المحرر. يبقى المصدر المُنشأ مسودة إلى أن تنشره.
عندما تكون لديك مشكلة بها نمط إجراء قابل للتكرار، افتحها تحت **Analyze → issues** واختر **generate policy**. يشرح Failproof AI أولاً ما إذا كانت السياسة يمكنها التعبير عن المشكلة، ثم تنقل النية المراجعة وسياق النتيجة إلى المحرر. يبقى المصدر المُنتج كمسودة حتى تنشره.

## نشر إصدار السياسة

<Tabs>
<Tab title="لوحة التحكم">
1. انتقل إلى **Admin → policy editor** وفي **compose**، صِف نمط الفشل أو الصق مصدر سياسة JavaScript.
2. تحقق من صحة المصدر وأصلح كل خطأ مُبلّغ عنه.
3. أدخل هوية السياسة ونشرها، ثم استخدم **library** للمقارنة أو تعطيل الإصدارات.
4. اختر **enforcement** عندما يكون الإصدار جاهزاً لطرح آلي على الآلات.
<Tab title="Dashboard">
1. انتقل إلى **Admin → policy editor** وفي **compose**، وصف نمط الفشل أو الصق مصدر سياسة JavaScript.
2. تحقق من صحة المصدر وأصلح كل خطأ يتم الإبلاغ عنه.
3. أدخل هوية السياسة وانشرها، ثم استخدم **library** للمقارنة أو تعطيل الإصدارات.
4. اختر **enforcement** عندما يكون الإصدار جاهزاً لنشر الآلة.

![عرض محرر السياسات مع هوية السياسة والتأليف بمساعدة الذكاء الاصطناعي والتحقق من صحة المصدر وعناصر التحكم في النشر.](/images/dashboard/policy-editor.png)
![عرض compose في محرر السياسات يتضمن هوية السياسة والتأليف بمساعدة الذكاء الاصطناعي والتحقق من المصدر وعناصر التحكم في النشر.](/images/dashboard/policy-editor.png)
</Tab>
<Tab title="CLI">
لا ينشر Cloud CLI إصدارات السياسات. تحقق من صحة المصدر محلياً قبل نسخه إلى المحرر:
انشر من واجهة سطر الأوامر باستخدام `fp policies publish`. تُنشئ **إصدار جديد** ولا تحرر واحداً موجوداً، وتتحقق من المصدر باستخدام node قبل الإرسال — لا يفعل ذلك شيء آخر في المراحل اللاحقة، لذا كان خطأ بناء الجملة قد يظهر على الآلة في وقت الفرض:

```bash
failproofai policies --install --custom ./checkout.policies.ts \
--cli claude --scope project
fp policies test ./checkout.policy.mjs --command "git push --force" --expect deny
fp policies publish checkout-guard ./checkout.policy.mjs --description "Block force-push"
```

انشر الإصدار المراجع من **Admin → policy editor**.
النشر لا ينشر أي شيء — يبقى إصدار جديد غير مستخدم حتى يضعه `fp fleet deploy` على آلة. يقوم `fp policies compose "<plain English>"` بصياغة المصدر بمساعدة مساعد Cloud ويطبعه للمراجعة بدلاً من نشره.

لتثبيت سياسة في وكيل CLI محلي بدلاً من ذلك (وليس Cloud)، استخدم `failproofai policies --install --custom ./checkout.policies.ts --cli claude --scope project`.
</Tab>
</Tabs>

## قائمة فحص التأليف
## قائمة التحقق من التأليف

1. سمّ نمط الفشل باستخدام لغة تشغيلية.
2. اختر أحداث الخطاف والأدوات التي توفر أدلة كافية للقرار.
3. اكتب الشرط الأضيق الذي يطابق السلوك غير الآمن.
4. أرجع سبباً يخبر الوكيل أو المشغل بما يجب فعله بعد ذلك.
5. أضف أمثلة يجب أن تطابق والأمثلة التي يجب أن تبقى مسموحة.
6. احفظ إصدارة جديدة وطلب مراجعة.
1. سمّ نمط الفشل باللغة التشغيلية.
2. اختر أحداث الخطاف والأدوات التي تحتوي على أدلة كافية للقرار.
3. اكتب أضيق شرط يطابق السلوك غير الآمن.
4. أرجع سبباً يخبر الوكيل أو المشغل ما يجب فعله بعد ذلك.
5. أضف أمثلة يجب أن تطابق وأمثلة يجب أن تبقى مسموحة.
6. احفظ إصدار جديد واطلب مراجعة.

استخدم `instruct` عندما يمكن للوكيل تصحيح المسار بأمان. استخدم `deny` عندما يؤدي السماح بالإجراء إلى إنشاء خطر غير مقبول أو لا يمكن عكسه.
استخدم `instruct` عندما يمكن للوكيل تصحيح المسار بأمان. استخدم `deny` عندما يؤدي السماح بالإجراء إلى خلق خطر غير مقبول أو غير قابل للعكس.

<Info>
إصدارات السياسات عبارة عن مدخلات نشر ثابتة. تحرير مسودة ينشئ إصدارة جديدة؛ يجب ألا يعيد كتابة الإصدار المُعيَّن بالفعل للآلات.
إصدارات السياسة هي مدخلات نشر غير قابلة للتغيير. يؤدي تحرير مسودة إلى إنشاء إصدار جديد؛ لا ينبغي أن يعيد كتابة الإصدار المعين بالفعل للآلات.
</Info>
Loading