# حذف الذكاء الاصطناعي قاعدة البيانات: خطة استعادة في 7 دقائق

> ما يجب فعله بعد حذف البيانات: أوقف الوكيل، ووثّق الحادثة، واستخدم git reflog وPITR واللقطات واستعادة الملفات. أمثلة وإجراءات وقائية.

Source: https://ailoot.ai/blog/ar/ai-deleted-database-recovery/
Canonical: https://ailoot.ai/blog/ar/ai-deleted-database-recovery/
Language: ar
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-032
Revision: sha256-b43c9a0b25a76c8c7cc3d1e6c98ccf6e3363512e1356caa6d7cea6d9c97e7065


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

لقد حذف وكيل ذكاء اصطناعي للتو قاعدة بياناتك أو ملفاتك أو بيئة الإنتاج بأكملها. تساعد الاستجابة السريعة على الحد من الضرر، لكن الاستعادة ليست مضمونة ولا تقتصر على سبع دقائق. ينظم هذا الدليل خطوات الاستجابة، مع أولوية إيقاف الكاتب وحفظ الأدلة والبيانات الناجية. أوقف الوكيل أولًا، ثم وثّق الحادثة، وبعدها استعد البيانات. لا داعي للذعر—اتبع قائمة التحقق.

</div>



[تتوفر معلومات عملية عن العمل مع Ailoot في الوثائق](https://ailoot.ai/docs/).

## ماذا تفعل في الدقيقة الأولى: توقّف، ولا داعي للذعر

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

أوقف الكاتب المدمّر فورًا، بما فيه أي ابن يستمر بعد توقف الوكيل. لا تعِد التشغيل ولا تنه عمليات غير مرتبطة قد تحمل ملفات محذوفة مفتوحة. الاستعادة غير مضمونة؛ فقد تجعلها الكتابة وSSD discard/TRIM مستحيلة. احفظ الدليل والبيانات الباقية على جهاز مستقل متحقق منه قبل تعديل النسخة المتضررة.

</div>

عندما يحدث هذا لك، فإن **أول ما يجب فعله هو إيقاف الوكيل**. لا تحاول التراجع عن أفعاله بنفسك، ولا تطلب منه «استعادة كل شيء»، ولا تُشغّل مطالبات جديدة. فكل إجراء لاحق من الوكيل قد يستبدل كتل القرص التي ربما لا تزال بياناتك مخزنة فيها.

1.  ### أغلق طرفية الوكيل

    قاطع الأمر الخطير فورًا بـ Ctrl+C؛ ولا تنتظر انتهاء الحذف. لا يوقف توقف الوكيل بالضرورة أوامره الأبناء أو مهامه البعيدة أو استعلامات القاعدة. حدد الكاتب الفعلي وأوقف العملية أو ألغها، وصعّد الإنهاء إذا واصل التدمير. أبق العمليات غير المرتبطة ذات الملفات المفتوحة القابلة للاستعادة حية.

2.  ### لا تُعِد تشغيل حاسوبك المحمول

    قد تبقى بيانات محذوفة قابلة للاستعادة، لكن التخزين وسلوك القاعدة وSSD discard/TRIM والكتابة اللاحقة تحدد ذلك. قلل الكتابة على الوحدة المتأثرة ولا تفترض بقاء البايتات.

3.  ### لا تُنهِ العمليات المفتوحة

    احفظ العمليات غير المرتبطة التي تحمل ملفات محذوفة مفتوحة؛ فقد تُمكن الاستعادة عبر واصفاتها. لا يشمل ذلك الكاتب المدمر: أوقفه أولًا، ولا تُبق حذفًا جاريًا لمجرد حفظ مقبض مفتوح.

4.  ### ابدأ تسجيل الشاشة

    سجّل الوقت الدقيق والمسارات المتأثرة ومخرجات الأوامر الظاهرة. احفظ التسجيل أو السجلات على جهاز مستقل متحقق منه بدل الوحدة المتضررة. احفظ الملفات الباقية المتتبعة وغير المتتبعة والمتجاهلة وبيانات Git الوصفية هناك قبل الاستعادة.

بعد ذلك، لديك 6 دقائق للاستعادة. هيا بنا.

## الدقيقتان 2–3: وثّق بدقة ما حدث

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

شخّص المشكلة قبل الاستعادة. من دون فهم دقيق لـ«ما الذي حُذف، ومن حذفه، ومتى، وبأي أوامر»، ستستعيد البيانات عشوائيًا وقد تتلف بيانات لا تزال سليمة. افتح نافذة طرفية جديدة (غير النافذة التي يعمل فيها الوكيل)، وشغّل `git status` و`git log --since` و`ps aux | grep claude`. انسخ فورًا مجلد `~/.claude/projects/`؛ فهو يحتوي على سجل الجلسة الكامل للوكيل، وقد يساعد في الاستعادة.

</div>

افتح نافذة طرفية جديدة، لا النافذة التي يعمل فيها الوكيل. افتح نافذة أخرى. نفّذ هذه الأوامر الثلاثة بالتتابع.

**1. سجّل بدقة ما تغيّر في مستودع git:**

```bash
git status
git log --since="30 minutes ago" --all --oneline
```

قد يبقى ملف متتبع محذوف في الفهرس أو commit. احفظ شجرة العمل الحالية، بما فيها غير المتتبع والمتجاهل، قبل أي استعادة؛ فقد تستبدل الاستعادة الموضعية تعديلات ناجية. افحص واستعد في نسخة مستقلة.

**2. تحقّق من عمليات الوكيل قيد التشغيل:**

```bash
ps aux | grep -i claude
ps aux | grep -i cursor
```

حدد العملية التي ما زالت تكتب كتابة خطرة؛ فلا يكفي تطابق الاسم. أوقف ذلك الكاتب وتحقق من توقفه. احفظ العمليات غير المرتبطة ذات الملفات المفتوحة المفيدة؛ وإذا فشل الإنهاء اللطيف واستمر التدمير، فقد يلزم الإنهاء القسري.

**3. احفظ سجل جلسة الوكيل:**

يخزّن Claude Code جلسات JSONL في `~/.claude/projects/`. ويخزّنها Cursor في `~/.cursor/`. أنشئ نسخة الآن:

```bash
cp -r ~/.claude/projects /external/incident-evidence/claude-projects
```

استبدل `/external/incident-evidence/` بمجلد أدلة قائم على جهاز مركب مستقل متحقق منه. لا تكتب النسخة على الوحدة المتأثرة أو فوق دليل قائم. يحتوي هذا المجلد على المحادثة الحرفية مع الوكيل—الأوامر التي نفّذها، وردوده، والترتيب الذي حدثت به. وهو مصدرك الأساسي للتحقيق في الحادثة، وربما لاستعادة الملفات المحذوفة من سياق الوكيل (انظر الخطوة 4).

## الدقيقة 4: git reflog—أفضل فرصة لديك

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

قد يحدد reflog commits اختفت من سجل الفروع، لكنه لا يحفظ ملفات العمل غير المثبتة. بعد حفظ الناجي وبيانات Git الوصفية على جهاز مستقل، افحص النسخة المحفوظة واستعد commit متحققًا منه إلى شجرة عمل مستقلة. لا تبدأ بإعادة ضبط الشجرة المتضررة.

</div>

يسجل `git reflog` تحركات المراجع المحلية ما دامت إدخالاتها محتفظًا بها. تختلف الصلاحية والتنظيف وقد تزال كائنات غير قابلة للوصول؛ وليس أرشيفًا مضمونًا لكل commit سابق. نفّذ الاستعادة التالية من نسخة مستودع محفوظة على الجهاز المستقل.

**الخطوة 1. اعرض السجل:**

```bash
git reflog --all
```

ستحصل على قائمة تشبه ما يلي:

```
1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel
```

ابحث عن النقطة **التي سبقت** الضرر الذي سببه الوكيل. كل إدخال هو «لقطة» لحالة المستودع في تلك اللحظة.

**الخطوة 2. استعد إلى شجرة عمل مستقلة:**

بعد نسخ المستودع وكل العمل الناجي إلى جهاز مستقل، نفّذ هذا من نسخة المستودع المحفوظة. استبدل القيمة بـ SHA للـ commit الذي فحصته في reflog، واختر اسم فرع ووجهة غير مستخدمين:

```bash
RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"
```

افحص الملفات في `../recovery-check` وقارنها بالملفات غير المثبتة المحفوظة قبل نسخ أي شيء إلى الأصل. يستخرج الأمر commit مستقلًا ولا يعيد ضبط الشجرة المتضررة. تتشارك الأشجار المرتبطة مخزن كائنات Git للنسخة؛ فهي مساحة استعادة وليست نسخة احتياطية مستقلة. راجع [وثائق git-worktree الرسمية](https://git-scm.com/docs/git-worktree).

**إذا نُظّف reflog أيضًا (أي تمكّن الوكيل من تشغيل `git gc`):**

```bash
git fsck --lost-found
```

يعثر هذا الأمر على الـ commits والـ blobs «المفقودة» (كائنات الملفات) التي لم تعد مرتبطة بأي فرع. وستظهر في `.git/lost-found/commit/` و`.git/lost-found/other/`. لاستعادة ملف منها:

```bash
git cat-file -p <SHA1-blob> > recovered-file.ext
```

**متى لا يساعد git reflog:**

- كان الملف موجودًا في شجرة العمل فقط، من دون commit أو stash → لا يستطيع reflog العثور عليه
- مرّ أكثر من 90 يومًا (القيمة القياسية لـ `gc.reflogExpire`) وشُغّل `git gc`
- حُذف المستودع بأكمله (`rm -rf .git`)—عندئذ تحتاج إلى Time Machine أو لقطة

## الدقيقة 5: استعد قاعدة البيانات من نسخة احتياطية

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

تستعيد ميزة الاستعادة إلى نقطة زمنية (PITR) في PostgreSQL قاعدة البيانات إلى أي ثانية ضمن نافذة تتراوح بين 7 و35 يومًا. وهي تعمل مع Yandex Cloud Managed Postgres وAWS RDS وSupabase Pro، وكذلك عبر مهمة cron محلية لـ `pg_dump` في Coolify. الشرط الأساسي هو أن تكون PITR مفعّلة **قبل** الحادثة؛ فلا يمكن تفعيلها بأثر رجعي. استعد دائمًا إلى مثيل جديد، ولا تستعد أبدًا فوق قاعدة بيانات مباشرة، كي لا يؤدي التراجع إلى إتلاف مزيد من البيانات. إذا لم تكن PITR مفعّلة، فاستخدم أحدث لقطة.

</div>

حُذفت قاعدة البيانات باستخدام `DROP DATABASE` أو `DROP TABLE` أو `DELETE FROM ... WHERE ...` (من دون جملة WHERE). ماذا تفعل؟

**الخطوة 1. تحقّق مما إذا كان مزوّدك يوفّر PITR:**

| المزوّد | نافذة PITR | أمر الاستعادة |
|----|----|----|
| AWS RDS | من 1 إلى 35 يومًا (قابلة للتهيئة) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` |
| Yandex Cloud Managed Postgres | 7 أيام (افتراضيًا) | استعد من النسخة الاحتياطية في وحدة التحكم + حدّد الوقت |
| Supabase Pro | 7 أيام (<bdi>Pro+</bdi> فقط) | UI: Database → Backups → Restore |
| Coolify + pg_dump محلي | وفق جدول cron | `pg_restore -d new_db backup.dump` |

**الخطوة 2. استعد إلى مثيل جديد، لا إلى المثيل القديم:**

لا تستعد أبدًا فوق قاعدة بيانات مباشرة. أنشئ مثيلًا جديدًا من النسخة الاحتياطية، ثم حوّل التطبيق إليه. إذا حدث خطأ ما، يمكنك إعادة DNS إلى وجهته السابقة.

**الخطوة 3. إذا لم تكن PITR مفعّلة، فاستخدم أحدث لقطة:**

```bash
# AWS RDS، اعرض اللقطات:
aws rds describe-db-snapshots --db-instance-identifier my-db

# الاستعادة من لقطة:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00
```

**تنبيه بشأن Supabase**، وقد فاجأ هذا كثيرين في 2026: عند تفعيل PITR، **يتوقف إنشاء** النسخ الاحتياطية اليومية. هذا سلوك غير بديهي؛ فقد ينتهي بك الأمر من دون أي نسخ احتياطية. تحقّق من Dashboard → Database → Backups للتأكد من أن PITR مفعّلة وأن لديك لقطة للاستعادة منها.

## الدقيقة 6: Time Machine وlsof ولقطات القرص

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

إذا حُذفت الملفات من القرص—لا من git أو قاعدة بيانات—فهناك ثلاث طرق عملية للاستعادة. على macOS، استخدم Time Machine مع لقطات كل ساعة (إذا كان الحاسوب المحمول متصلًا بـ Time Capsule أو قرص خارجي). على Linux، شغّل `sudo lsof | grep deleted`—فقد يستعيد الملفات التي لا تزال عملية ما تفتحها (الاستعادة غير مضمونة)؛ وانسخها عبر `/proc/PID/fd/N`. للحالات الحرجة، أنشئ لقطة للقسم بأكمله باستخدام `dd`، ثم استعد الملفات باستخدام `extundelete` أو `photorec`.

</div>

**macOS—Time Machine:**

```bash
# اعرض اللقطات:
tmutil listbackups

# استعد ملفًا من أحدث نسخة احتياطية:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx
```

ينشئ Time Machine لقطات كل ساعة، ويحتفظ باللقطات كل ساعة لمدة يوم، واللقطات اليومية لمدة أسبوع، واللقطات الأسبوعية إلى أجل غير مسمى. إذا كان حاسوبك المحمول متصلًا بـ Time Capsule أو قرص خارجي، فستجد مشروعك هناك مع إمكانية الاستعادة بدقة ساعة.

**Linux—حُذف الملف، لكن عملية ما لا تزال تفتحه:**

```bash
# اعثر على جميع الملفات «المحذوفة» التي لا تزال عملية ما تفتحها:
sudo lsof | grep deleted

# ستظهر أسطر شبيهة بما يلي:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# انسخ الملف مباشرة من /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt
```

احتمال النجاح نحو 95% إذا لم تُغلق العملية. يعمل هذا على ext4 وxfs وbtrfs.

**macOS—طريقة مماثلة باستخدام `lsof`:**

```bash
lsof | grep deleted
```

نسخ الملف أصعب (إذ لا يوجد `/proc/`)، لكن يمكنك فعل ذلك باستخدام `lldb`:

```bash
lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE
```

**لقطة للقرص بأكمله (Linux، الملاذ الأخير):**

```bash
sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress
```

يحفظ هذا القسم بأكمله كصورة. بعد ذلك، استعد البيانات باستخدام `extundelete` أو `photorec`. يعتمد احتمال الاستعادة على مقدار البيانات التي كُتبت إلى القرص منذ الحذف. إذا لم يُكتب أي شيء، فالنسبة 80–90%. وإذا كان النظام يعمل منذ ساعة بالفعل، فالنسبة 20–30%.

## الدقيقة 7: ماذا لو لم تكن هناك نسخة احتياطية

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

لا توجد نسخة احتياطية، وgit reflog فارغ، وقد استُبدلت بيانات القرص بالفعل ببيانات جديدة. لا يزال هناك خياران أخيران: التواصل مع دعم المزوّد (تستعيد AWS وYandex Cloud وGoogle Cloud البيانات من مخازنها الداخلية من وقت لآخر)، أو الاستعادة عبر إصدارات S3 (إذا كانت مفعّلة، فجميع الإصدارات موجودة فعليًا).

</div>

**الخيار 1—دعم المزوّد:**

تستعيد AWS وYandex Cloud وGoogle Cloud وDigitalOcean البيانات دوريًا من مخازنها الداخلية، حتى بعد كارثة يتسبب بها العميل، ولا سيما في الخطط المدفوعة. افتح تذكرة دعم، وقدّم الوقت الدقيق للحادثة وأرفق لقطات شاشة للحالة. ينجح هذا غالبًا مع المزوّدين الكبار الذين يحتفظون بنسخ احتياطية تلقائية من جانبهم. احتمال النجاح 40–60%؛ وتتراوح مدة الرد بين 24 و72 ساعة.

**الخيار 2—إصدارات S3:**

إذا كانت الملفات في S3 (أو Yandex Object Storage) وكان نظام الإصدارات مفعّلًا، فإن جميع الإصدارات **موجودة فعليًا**؛ لكنها معلّمة ببساطة على أنها «محذوفة».

```bash
# AWS—اعرض الإصدارات:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# استعد إصدارًا:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json
```

**تنبيه بالغ الأهمية:** لا يحتفظ Claude Code بالجلسات إلى الأبد—إذ تُحذف ملفات JSONL القديمة تلقائيًا بعد عدة أسابيع. لضمان الاحتفاظ بسجل JSONL لشهر كامل في حال وقوع كارثة، انسخ `~/.claude/projects/` إلى قرص خارجي مرة أسبوعيًا باستخدام مهمة cron بسيطة:

```bash
# في crontab، كل يوم أحد الساعة 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/
```

هذا مجاني وينقذك عندما «يختفي كل شيء، ولا توجد نسخة احتياطية، وreflog فارغ».

## 7 قواعد لضمان ألا يحدث هذا مجددًا

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

سبع قواعد تمنع وكيل الذكاء الاصطناعي من حذف قاعدة بياناتك أو كودك. استخدم Plan Mode قبل العمليات التدميرية. استخدم hooks مختبرة لرصد نصوص أوامر خطرة مختارة مع حدود أذونات مفروضة. امنح الوكيل مستخدم قاعدة بيانات للقراءة فقط. نفّذ commit تلقائيًا بعد كل تعديل للملفات. استخدم مجلد sandbox معزولًا للتجارب. أنشئ لقطات للقرص باستخدام `restic` كل ساعة. أرشف جلسات JSONL على قرص خارجي.

</div>

**1. استخدم Plan Mode قبل أي عملية تدميرية.** في Claude Code:

```bash
claude --plan
```

ينشئ الوكيل خطة **قبل** أن يتصرف. تقرؤها، فترى `DROP TABLE users` وتلغي العملية. من دون Plan Mode، يقرر الوكيل بنفسه وينفّذ خلال أجزاء من الثانية. تعرّف على المزيد في [دليل Plan Mode في Claude Code](https://ailoot.ai/blog/ar/claude-code-plan-mode/).

**2. Hooks كإنذار إضافي.** استخدم PreToolUse مختبرًا يقرأ JSON الحدث من stdin ويخرج بالرمز 2 عند رصد إجراء عالي المخاطر. يغطي المثال الكامل أدناه Bash وWrite وEdit؛ وليس حد أمان وقد يفوّت عمليات غير مباشرة. أبق أذونات القاعدة والعزل مقيدة.

**3. أنشئ مستخدم DB للقراءة فقط للوكيل.** أنشئ مستخدمًا منفصلًا للوكيل **لا** يملك صلاحيات `DROP` أو `TRUNCATE` أو `DELETE`:

```sql
CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;
```

عندما يحتاج الوكيل فعلًا إلى الكتابة، انتقل يدويًا إلى مستخدم آخر. يكفي مستخدم للقراءة فقط للمهام اليومية (تحليل البيانات والتقارير ولوحات المعلومات).

**4. احفظ التغييرات التي راجعتها في Git.** يمكن أن يطبع hook من نوع `PostToolUse` في `.claude/settings.json` تذكيرًا بعد عمليتي `Write` و`Edit`:

```json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'راجع الفروق وأنشئ commit يدويًا للملفات المتفق عليها فقط.' >&2"
          }
        ]
      }
    ]
  }
}
```

يطبع هذا المثال تذكيرًا فقط؛ ولا يضيف ملفات إلى الفهرس ولا ينشئ commit. راجع الفروق ثم أنشئ commit يدويًا للملفات المتفق عليها فقط. لا يحفظ reflog التغييرات غير المسجلة في commit.

**5. استخدم مشروع sandbox للتجارب.** لا تسمح أبدًا للوكيل بالعمل في مشروع يحتوي على بيانات حقيقية للعملاء. أنشئ مجلدًا منفصلًا باسم `~/sandbox-projects/` يضم نسخة من المشروع وبيانات اصطناعية. استخدمه لتجربة مطالبة أو وكيل أو خادم MCP جديد. إذا حدث خطأ ما، فلن يتضرر شيء.

**6. أنشئ لقطات للقرص باستخدام `restic` كل ساعة.**

```bash
# التثبيت:
brew install restic  # macOS
sudo apt install restic  # Linux

# إنشاء المستودع:
restic init --repo /external/backups

# نسخ المشروع الحالي احتياطيًا:
restic --repo /external/backups backup ~/projects

# جدولة cron كل ساعة:
crontab -e
# أضف:
0 * * * * restic --repo /external/backups backup ~/projects
```

احتفظ بسبعة أيام من النسخ الاحتياطية كل ساعة وأربعة أسابيع من النسخ اليومية، ويمكنك دائمًا الرجوع إلى أي نقطة في الماضي. هذا مجاني ولا يستغرق الإعداد سوى 10 دقائق.

**7. أرشف جلسات Claude Code بصيغة JSONL.** سبق ذكر ذلك، لكننا نعيده هنا كقاعدة مستقلة: جدْوِل عملية `rsync` أسبوعية لمجلد `~/.claude/projects/` إلى قرص خارجي. هذا مجاني ولا يحتاج إلا إلى سطر واحد في crontab.

## Hooks جاهزة لحظر الأوامر الخطرة

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

المثال أدناه إنذار PreToolUse لنصوص أوامر Bash مختارة ومسارات Write/Edit حساسة. يقرأ JSON من stdin ويخرج 2 عند المطابقة. قد يفوّت أعمالًا غير مباشرة أو مخفية؛ فيكمل العزل والاعتماد المقيد ولا يستبدلهما. ادمجه في الإعداد القائم واختبر سلوكه قبل الاستخدام.

</div>

ادمج هذا الإدخال في `.claude/settings.json` دون استبدال hooks القائمة:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}
```

أنشئ `.claude/hooks/check-risk.py` بنص Python 3 التالي:

```python
import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)
```

يقرأ hook حدث JSON الموثق من **stdin**، ويفحص `tool_input.command` أو `tool_input.file_path`، ويخرج 2 للمطابقة. يفحص Write وEdit معًا. اختبر إدخالًا غير حساس مسموحًا وآخر محظورًا قبل الاعتماد عليه، وتحقق من بدء Python والنص المضبوط فعلًا.

هذا إنذار لفظي؛ قد يفوّت خيارات معاد ترتيبها ونصوصًا وأسماء بديلة وأوامر مخفية وأدوات أخرى وكتابات غير مباشرة؛ وقد يرفض أمثلة مقتبسة غير ضارة. لا يمنح أو يسحب أذونات نظام أو قاعدة بيانات. أبق اعتماد الإنتاج خارج البيئة، واستخدم دور قاعدة للقراءة فقط وعزلًا مفروضًا، واحم تكوين hook من التعديل. راجع [مرجع إدخال hook ورموز خروجه الرسمي](https://code.claude.com/docs/en/hooks).

لعملية استثنائية مقصودة، راجعها ونفّذها خارج الوكيل بالحساب المقيد المناسب. ليس متغير بيئة صدفة واجهة موثقة لتعطيل hooks؛ ولا تحكم hooks أوامر الطرفية العادية.

## متى تمنح الذكاء الاصطناعي صلاحيات، ومتى لا تفعل ذلك

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

لا تمنح الوكيل مطلقًا خيار `--dangerously-skip-permissions` في المشاريع التي تحتوي على بيانات حقيقية. في وضع YOLO، تُعطّل جميع وسائل الحماية، وينفّذ الوكيل أي أمر Bash ويكتب الملفات من دون تأكيد، كما ترث الوكلاء الفرعية التي ينشئها هذا الوضع من دون أي وسيلة لتجاوزه. استخدم YOLO فقط داخل مجلد sandbox للتجارب ببيانات وهمية على خوادم MCP أو مطالبات جديدة. وفي كل الحالات الأخرى، استخدم صلاحيات دقيقة عبر `.claude/settings.json` مع قواعد `allow` و`deny` صريحة.

</div>

تصف Anthropic الخيار `--dangerously-skip-permissions` (المعروف أيضًا باسم وضع YOLO) في وثائقها بأنه خيار «للبيئات الموثوقة». لكن في واقع 2026، إنه **طريق مباشر إلى الكارثة**. عندما لا يحتاج الوكيل إلى طلب الإذن، فإنه:

- ينفّذ أي أمر Bash من دون تأكيد
- يكتب الملفات من دون طلب الإذن
- يستدعي وكيلًا فرعيًا **يرث** YOLO ولا توجد طريقة للتراجع عن ذلك

النقطة الثالثة هي الأخطر. إذا بدأت الوكيل الرئيسي في وضع YOLO، فستعمل الوكلاء الفرعية أيضًا بهذا الوضع، ولا يمكنك تجاوز ذلك. مطالبة واحدة—وقد تنفّذ سلسلة تضم 10 وكلاء متوازيين أي شيء في نظامك.

**القاعدة:**

| الحالة | هل وضع YOLO مقبول؟ |
|--------------------------------------------------|--------------------|
| تجربة خادم MCP جديد في مجلد sandbox | ✅ نعم |
| اختبار مطالبة جديدة ببيانات وهمية | ✅ نعم |
| العمل على ملفات مشروع حقيقي | ❌ لا |
| أي أمر يتعامل مع قاعدة بيانات | ❌ أبدًا |
| النشر إلى الإنتاج | ❌ أبدًا |
| إدارة البنية التحتية (AWS، Yandex Cloud) | ❌ أبدًا |

**البديل—صلاحيات دقيقة.** في `.claude/settings.json`:

```json
{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}
```

يرى الوكيل ما يُسمح له به وما لا يُسمح. لن تحتاج إلى النقر على «نعم» أو «لا» في كل مرة—فالوكيل يعمل بسرعة وأنت تتحكم في الحدود.

## التالي: قائمة تحقق من 7 دقائق لإضافتها إلى المفضّلة

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="أهم النقاط">

أهم النقاط

أضف هذا الدليل إلى المفضّلة الآن. عندما تقع الكارثة، افتح الصفحة واتبع قائمة التحقق المكوّنة من 10 نقاط بالترتيب. سيوفر عليك 30 دقيقة من الذعر ويمنعك من استبدال بيانات قد تكون قابلة للاستعادة عن طريق الخطأ. بعد الاستعادة، عد إلى الدليل واضبط القواعد الوقائية السبع كي لا تقع كارثة أخرى الأسبوع المقبل.

</div>

**قائمة التحقق: «حذف الذكاء الاصطناعي شيئًا—ماذا أفعل؟»**

1.  أوقف الكاتب المدمر الفعلي فورًا؛ وتحقق من توقف عملياته الأبناء أو البعيدة
2.  لا تعد التشغيل؛ واحفظ العمليات غير المرتبطة التي تحمل ملفات محذوفة مفتوحة
3.  سجّل وقت الحادث ودليل الأوامر على جهاز مستقل متحقق منه
4.  انسخ الملفات الناجية وبيانات Git الوصفية وسجلات الجلسات المناسبة إلى ذلك الجهاز
5.  في نسخة المستودع المحفوظة، افحص `git reflog --all` واستعد التزامًا تم التحقق منه في شجرة عمل منفصلة (worktree).
6.  إذا لم يساعد git—`git fsck --lost-found`
7.  قاعدة البيانات: PITR (AWS/Yandex/Supabase) أو أحدث لقطة
8.  الملفات: Time Machine على Mac، وlsof على Linux
9.  الملاذ الأخير: دعم المزوّد + إصدارات S3
10. بعد الاستعادة، اضبط القواعد الوقائية السبع الواردة في هذا الدليل

**التالي—الحماية المنهجية:**

- [Plan Mode في Claude Code](https://ailoot.ai/blog/ar/claude-code-plan-mode/)—ليضع الوكيل خطة **قبل** أي عملية تدميرية
- [Hooks في Claude Code](https://ailoot.ai/blog/ar/claude-code-hooks/)—قوالب جاهزة لحظر الأوامر الخطرة
- [كيفية التراجع عن التغييرات في Claude Code](https://ailoot.ai/blog/ar/claude-code-undo-changes/)—دليل مفصّل إلى `/rewind` وgit و5 طرق قياسية للتراجع
- [مراجعة الأمان في Claude Code](https://ailoot.ai/blog/ar/claude-code-security-review/)—فحوصات أمان منتظمة للكود

<div class="section" role="doc-bibliography" aria-label="المصادر">

### المصادر

- [وثائق Anthropic لـ Claude Code Hooks](https://code.claude.com/docs/en/hooks-guide)
- [وثائق Anthropic لـ Claude Code Plan Mode](https://code.claude.com/docs/en/common-workflows)
- [وثائق PostgreSQL للاستعادة إلى نقطة زمنية (PITR)](https://www.postgresql.org/docs/current/continuous-archiving.html)
- [AWS RDS—استعادة مثيل DB إلى نقطة زمنية](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)
- [Yandex Cloud Managed PostgreSQL—النسخ الاحتياطي والاستعادة](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup)
- [وثائق Git reflog](https://git-scm.com/docs/git-reflog)
- [Git fsck—وضع `--lost-found`](https://git-scm.com/docs/git-fsck)

</div>





[افتح Ailoot](https://ailoot.ai/).

## أسئلة شائعة

### هل أنتظر انتهاء أمر الوكيل الحالي؟

لا. أوقف الكاتب المدمر فورًا وتحقق من توقف عملية الابن أو العملية البعيدة أو القاعدة. احفظ العمليات غير المرتبطة التي قد تحمل ملفات محذوفة قابلة للاستعادة؛ فقد يبقى كاتب آخر بعد توقف الوكيل.

### هل أبدأ الاستعادة بـ git reset --hard؟

احفظ أولًا الملفات الناجية المتتبعة وغير المتتبعة والمتجاهلة وبيانات Git على جهاز مستقل. افحص النسخة واستعد commit متحققًا منه إلى شجرة عمل مستقلة؛ فقد يدمر hard reset موضعي تعديلات ناجية غير مثبتة.


## Ailoot · الشركة ومحفظة مشاريعها

تستند Ailoot إلى خبرة تشغيلية متراكمة وقاعدة عملاء واسعة وخدمة مستقرة ومراقبة مستمرة لمؤشرات الأداء KPI.

الشركة ومحفظة مشاريعها: ملايين العملاء؛ مبيعات بالمليارات شهريًا.

توظف Ailoot هذه الخبرة التشغيلية لإتاحة الوصول عبر API إلى قدرات الذكاء الاصطناعي في منتجات العملاء ووكلائهم وتطبيقاتهم وعمليات الأتمتة.