لماذا يتجاهل وكيل البرمجة تعليماتك؟

لماذا تتجاهل وكلاء البرمجة تعليماتك

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

لكل سبب إصلاح مختلف، لذلك تتمثل المهمة الأولى في التمييز بينها. لا تمثل الأحرف الكبيرة وكلمة IMPORTANT تشخيصاً. تستخدم الآلية الموضحة أدناه Claude Code مثالاً عملياً، لأن سلوك التحميل والضغط فيه موثق بالتفصيل حتى August 2026. تختلف الأدوات الأخرى في التفاصيل، لكنها تتصرف بالطريقة نفسها على نحو عام.

لنعرّف مصطلحين أولاً. نافذة السياق هي كتلة النص التي يراها النموذج في دور معيّن: system prompt، وملفات التعليمات الخاصة بك، والمحادثة، وكل ملف قرأه الوكيل. أما harness فهو البرنامج المحيط بالنموذج، أي البرنامج الذي يقرأ الملفات من القرص ويجمع تلك الكتلة. تتعلق معظم الشكاوى الواردة في هذا المنشور في الواقع بالـharness، لا بالنموذج.

ملف التعليمات رسالة وليس إعداداً

ملف التعليمات ليس ملف إعدادات. لا يقرأ وقت التشغيل أي شيء في CLAUDE.md ويفرضه. يقرأ الـharness الملف من القرص ويلصق النص في المحادثة. في Claude Code، يُرسل هذا المحتوى في رسالة مستخدم توضع بعد system prompt، ولذلك يرى النموذج قواعدك بالطريقة نفسها التي يرى بها أي نص آخر كتبته.

يترتب على ذلك أثر غير مريح. تتنافس قواعدك مع كل جزء آخر من النص في نافذة السياق، وبالمستوى نفسه. القاعدة ادعاء. أما الملف الذي فتحه الـagent للتو فهو دليل. عندما يختلف الاثنان، ينتصر الدليل غالباً، ولا يظهر أي خطأ لأن شيئاً لم يحدث خطأ من وجهة نظر النموذج.

توضح الوثائق الرسمية ذلك صراحة: تُعامل ملفات التعليمات على أنها سياق، لا إعدادات مفروضة. لحظر إجراء بغض النظر عما يقرره النموذج، تحتاج إلى hook، لا إلى جملة. احتفظ بهذه الفكرة. معظم الإصلاحات في نهاية هذا المنشور هي تطبيق لهذه الفكرة على حالة محددة.

ما ملفات التعليمات التي تُحمَّل، ومتى

يصعد Claude Code في شجرة الأدلة بدءاً من الدليل الذي شغّلته منه. يُحمِّل عند بدء التشغيل كل ملفي CLAUDE.md وCLAUDE.local.md من جذر نظام الملفات وصولاً إلى دليل العمل بالكامل. تُجمَّع هذه الملفات بهذا الترتيب، لذلك يُقرأ الملف الأقرب إلى الدليل الذي شغّلت منه البرنامج أخيراً. وداخل الدليل نفسه، يُضاف ملف .local بعد الملف الرئيسي.

تعمل الملفات الموجودة في الأدلة الفرعية الواقعة أسفل دليل العمل بطريقة مختلفة. لا تُحمَّل عند بدء التشغيل. بل تُحمَّل عندما يقرأ الوكيل ملفاً في ذلك الدليل. وينطبق الأمر نفسه على القواعد المقيدة بالمسار في .claude/rules/ التي تحتوي على حقل paths: في الواجهة الأمامية للبيانات الوصفية؛ إذ تدخل هذه القواعد في السياق عند قراءة ملف مطابق، وليس في كل دورة.

يشرح هذا الاختلاف جزءاً كبيراً من حالات الفشل المُبلَّغ عنها. تضع قاعدة في packages/api/CLAUDE.md، وتطرح سؤالاً عن واجهة API، فيجيب الوكيل من دون أن يفتح أي ملف تحت packages/api/. لم تُهمَل القاعدة، بل لم تكن موجودة في السياق أصلاً. إذا كان مستودعك يوزّع الإرشادات على ملفات تعليمات لكل حزمة في مستودع متعدد الحزم، فتحقّق من هذا أولاً في كل مرة.

هناك مشكلة أخرى في التحميل، وهي السبب الأكثر شيوعاً لعبارة «تجاهل الوكيل تعليماتي»: يقرأ Claude Code CLAUDE.md، وليس AGENTS.md. إذا كان المستودع يعتمد AGENTS.md معياراً ولا يحتوي على CLAUDE.md، فلن يجد Claude Code أي شيء يحمّله. الحل المدعوم هو CLAUDE.md يكون سطره الأول @AGENTS.md، ويستورد الملف عند بدء التشغيل، مع وضع أي ملاحظات خاصة بـClaude تحته. يعمل الرابط الرمزي أيضاً عندما لا يكون لديك شيء إضافي تريد إضافته. أما تحديد ما يجب أن يتضمنه هذا الملف في الأصل فهو سؤال منفصل، وتتناوله إرشادات فصل تعليمات الوكيل عن توثيق المستخدمين.

تحقّق من تحميل الملف قبل إعادة صياغته

لا تعدّل الصياغة قبل أن تتأكد من أن الوكيل يستطيع رؤية الملف. هناك فحصان، ويأتي الفحص الأبسط أولاً.

شغّل /context داخل الجلسة. يعرض هذا الأمر النافذة الحالية مقسّمة حسب الفئة، وتسرد قائمة Memory files أسماء كل ملفات التعليمات التي حُمّلت فعلياً. إذا لم يظهر ملف في هذه القائمة، فهو ليس جزءاً من المحادثة، ولذلك لا يمكن أن يؤثر أي شيء تكتبه بداخله. يعرض /memory مواقع الملفات ويفتحها للتحرير، بما في ذلك الملفات التي لم تُنشأ بعد.

للحصول على إجابة أكثر دقة، سجّل عمليات التحميل. يُطلِق حدث الخطاف InstructionsLoaded في كل مرة يدخل فيها CLAUDE.md أو ملف قواعد إلى السياق، ويُبيّن المطابق سبب التحميل: session_start أو nested_traversal أو path_glob_match أو include أو compact. ضع ما يلي في .claude/settings.json:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

يتلقى الخطاف بياناته بصيغة JSON عبر الإدخال القياسي، لذلك يضيف cat السجل الكامل. راقبه باستخدام tail -f /tmp/instructions-loaded.log أثناء العمل. تُتجاهل حالة الخروج لهذا الحدث، لذلك لا يستطيع الخطاف سوى المراقبة ولا يمكنه منع التنفيذ. إذا لم يظهر ملفك المتداخل مطلقاً في ذلك السجل أثناء جلسة توقعت فيها تحميله، فتوقف عن إعادة صياغة النص. المشكلة في موضع الملف.

ماذا تفعل الجلسة الطويلة بقواعدك

ينطبق هنا تأثيران منفصلان، ويحتاج كل منهما إلى استجابة مختلفة.

البُعد. تظل القاعدة التي ذكرتها في الدور 1 ضمن نافذة السياق في الدور 90، لكنها تنافس الآن نصاً امتد على 90 دوراً، وهو أحدث وأكثر تحديداً لما تفعله حالياً. لا يمكنك معالجة ذلك عبر الإعدادات، لكن يمكنك قياسه. نفّذ المهمة نفسها في جلسة جديدة. إذا التزمت القاعدة هناك وفشلت بعد التعمق في جلسة طويلة، فالبُعد هو السبب.

الاختصار. عندما تمتلئ النافذة، يختصر المضيف المحادثة حتى تلك اللحظة ثم يواصل العمل انطلاقاً من ذلك الملخص. ما يبقى هو ما يراه الملخِّص مهماً، وهذا لا يطابق بالضرورة ما تراه أنت مهماً. توثّق Claude Code النتيجة لكل آلية، والفروق كبيرة. يُعاد حقن جذر المشروع CLAUDE.md والقواعد غير المقيّدة بالنطاق من القرص بعد الاختصار. وتُعاد حقن الذاكرة التلقائية من القرص. أما القواعد التي تحتوي على paths: في frontmatter فتُفقد إلى أن تتم قراءة ملف مطابق لها مرة أخرى. وتُفقد ملفات CLAUDE.md المتداخلة في الدلائل الفرعية إلى أن تتم قراءة ملف في ذلك الدليل الفرعي مرة أخرى.

رتّب تعليماتك وفقاً لذلك الجدول، وسيتضح ترتيب الهشاشة. القاعدة التي كتبتها في المحادثة فقط هي أكثر عناصر الجلسة هشاشة؛ فهي تستمر فقط إذا احتفظ بها الملخص مصادفةً. وتأتي بعدها القاعدة الموجودة في packages/api/CLAUDE.md، لأنها حُمّلت مرة واحدة ثم أزيلت من الملخص، ولا تعود إلا عند القراءة التالية في ذلك الدليل. أما القاعدة الموجودة في ملف جذر المشروع فهي الأكثر دواماً، لأنها تُقرأ من القرص مرة أخرى في كل مرة.

لذلك، إذا كان يجب أن تظل التعليمات سارية طوال الجلسة، فضعها في ملف جذر المشروع من دون frontmatter من النوع paths:. أما كل ما عدا ذلك فهو مفاضلة ينبغي أن تختارها عن قصد. يشرح إدارة ما يبقى في نافذة السياق /compact مع التركيز على الوسائط، و/clear بين المهام غير المرتبطة، وكلاهما يغيّر معدل إتاحة الفرصة للملخّص كي يقرر ما كانت عليه قواعدك.

لماذا تتغلب الشفرة المحيطة على القاعدة

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

تصف القاعدة تفضيلاً. أما الشفرة فتبرهن على وجود تفضيل. عندما يفتح الوكيل ثلاثة ملفات في الوحدة التي يوشك على تعديلها، ويستدعي ORM مباشرةً في الملفات الثلاثة، فسيجد السياق جملة تجريدية واحدة في جانب، وثلاثة أمثلة ملموسة وحديثة ومرتبطة بالمهمة في الجانب الآخر. يكون نسخ النمط المحلي هو السلوك الصحيح عادةً. لكنه خطأ هنا فقط لأنك تعرف شيئاً لا يعرفه السياق: تلك الملفات قديمة.

لذلك اكتب هذه المعلومة في القاعدة. تصمد القواعد التي تذكر الأدلة المضادة الموجودة في المستودع عند تطبيقها على مستودع حقيقي. أما القواعد التي تذكر تفضيلاً مجرداً فلا تصمد.

يمر أي وصول جديد إلى قاعدة البيانات عبر app/repositories/. وما زالت الملفات الموجودة ضمن app/legacy/ تستدعي ORM مباشرةً. هذه شفرة قديمة وليست النمط المعتمد. لا تنسخها.

تؤدي الجملة الثانية الدور الأساسي. فهي تخبر الوكيل بما سيوشك على العثور عليه وكيفية قراءته، قبل أن يعثر عليه. وينطبق الإصلاح نفسه على أي قاعدة يناقضها مستودعك بوضوح: أسلوب commits لا يتبعه سجلّك، أو بنية اختبارات يتجاهلها نصف مجموعتك، أو اصطلاح imports لا يطبَّق إلا في الشفرة الجديدة. عندما تختلف الشفرة عن الملف، اذكر هذا الاختلاف في الملف.

لا يمكن التحقق من القاعدة الغامضة، لذلك لا يمكن اتباعها

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

طبّق الاختبار التالي على كل سطر في ملفك. اكتب أمر shell يُرجع حالة خروج غير صفرية عند خرق القاعدة. إذا لم تتمكن من كتابة هذا الأمر، فالقاعدة غير قابلة للتحقق. قارن بين الأزواج التالية:

• غير قابلة للتحقق: "حافظ على صغر حجم الدوال." قابلة للتحقق: "تحتاج الدالة التي يتجاوز طولها 60 سطراً إلى تعليق فوقها يشرح السبب."
• غير قابلة للتحقق: "اختبر تغييراتك." قابلة للتحقق: "شغّل npm test والصق عدد حالات الفشل قبل اعتبار المهمة مكتملة."
• غير قابلة للتحقق: "حافظ على تنظيم الملفات." قابلة للتحقق: "توجد معالجات HTTP في src/api/handlers/. ولا يوضع أي شيء آخر في ذلك الدليل."
• غير قابلة للتحقق: "نسّق الشيفرة بطريقة صحيحة." قابلة للتحقق: "استخدم مسافة بادئة من 2 مسافة في ملفات .ts."

"لا تبالغ في هندسة الحل" هي أول قاعدة يتخلى الناس عنها، لأن إصلاحها لا يتمثل في جملة أقصر، بل في جملة أطول: توضيح ما يعنيه أصغر تغيير ينجح فعلياً يمنح الوكيل معايير يستطيع مقارنتها بالتغييرات التي أجراها بنفسه.

الحجم هو المشكلة نفسها في صورة مختلفة. تستهدف إرشادات Claude Code أن تكون ملفات التعليمات أقل من 200 سطر، وتنص مباشرةً على أن الملفات الأطول تقلل الالتزام بالتعليمات. الملف الذي يحتوي على 700 سطر ليس تعليمات أكثر صرامة. بل هو 700 سطر من الادعاءات، مع فرص أكبر لتناقضها، ويُحتسب ضمن نافذة السياق في كل دور، وهو ما يظهر مباشرةً في استخدامك للرموز المميزة. إن تنظيم الملف بحيث توجد كل قاعدة تحت عنوان يمكن للقارئ استعراضه مشمول في كتابة ملف تعليمات يستطيع الوكيل العمل وفقه.

كيفية تشخيص المشكلة خلال عشر دقائق

نفّذ هذه الخطوات بالترتيب. إن تجاوزت إلى الخطوة الأخيرة مباشرة، فقد ينتهي بك الأمر إلى ملف طويل من القواعد المكتوبة بصيغة آمرة، لكنه لا يزال لا يعمل.

1. تأكد من تحميلها. نفّذ /context واقرأ قائمة Memory files. إذا لم يكن الملف موجوداً، فأصلح موقعه وتوقف. لا تنطبق أي خطوة أخرى في هذه القائمة بعد.
2. أعد إنتاج المشكلة في جلسة جديدة. ابدأ جلسة جديدة وقدّم أصغر مهمة يُفترض أن تؤدي إلى تطبيق القاعدة. إذا نجحت القاعدة هنا وفشلت في جلسة طويلة، فهذا يشير إلى التباعد أو الضغط. وإذا فشلت هنا أيضاً، فالمشكلة في القاعدة نفسها.
3. أزل القواعد المنافسة. اطلب التغيير نفسه في مجلد تتبع شفرته الحالية القاعدة بالفعل. إذا عاد الالتزام بالقاعدة، فهذا يعني أن الشفرة المحيطة كانت تتغلب على عبارتك.
4. ابحث عن تعارض. وجود ملفين يقدّمان إرشادات مختلفة للسلوك نفسه هو فشل موثّق: قد يختار النموذج أحدهما عشوائياً، ولن يخبرك بأنه فعل ذلك.
5. اجعل التحقق ممكناً ثم أعد الاختبار. أعد صياغة القاعدة باستخدام مسار محدد وشرط واضح. إذا ارتفع مستوى الالتزام بها كثيراً، فهذا يعني أن الصياغة كانت سبب المشكلة.

الخطوة 4 عبارة عن أمر واحد. ابحث باستخدام Grep في كل مصادر التعليمات عن الموضوع، وليس في الملف الذي كنت تعدّله فقط:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

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

الإصلاحات مرتبة حسب قوة تأثيرها

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

1. اجعل القاعدة محددة. اذكر مساراً أو أمراً أو شرطاً. أضف الأدلة المضادة التي سيجدها الوكيل في المستودع، كما هو موضح سابقاً. لا يكلّف ذلك شيئاً، ويعالج نسبة مفاجئة من الحالات.
2. قرّب القاعدة من الشيء الذي تحكمه. ضعها في CLAUDE.md متداخل، أو استخدم قاعدة مقيّدة بنطاق مسار في .claude/rules/، أو أضف تعليقاً في أعلى الملف نفسه. عندئذٍ تُقرأ القاعدة مع الكود الذي تنطبق عليه. اقبل المقابل: أي محتوى يُحمّل بهذه الطريقة يخرج من السياق عند عملية الضغط التالية، ويعود عند القراءة المطابقة التالية.
3. انقل التنفيذ إلى hook. النص يطلب، أما hook فيقرّر. تعمل hooks ككود عند أحداث ثابتة في دورة الحياة، وتطبّق القاعدة بغض النظر عما يستنتجه النموذج.
4. سلّم القاعدة إلى أداة حتمية واحذف النص. مثل التنسيق، وترتيب عمليات الاستيراد، وطول السطر، وعمليات الاستيراد المحظورة، وشكل رسالة commit. استخدم ruff format أو prettier --write أو eslint أو hook من نوع pre-commit. تكون أداة التنسيق صحيحة في كل مرة ولا تستهلك أي رموز. أما الجملة فتكون صحيحة في معظم الأوقات، وتستهلك رموزاً في كل دورة.

الخطوة 3 بالتفصيل. افترض أن ملفات migration يجب ألا يعدّلها الوكيل مطلقاً. ضع ما يلي في .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

وضع ما يلي في .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

شغّل chmod +x .claude/hooks/guard-migrations.sh، ثم ابدأ جلسة جديدة واطلب من الوكيل تعديل ملف ضمن migrations/. سيُرفض التعديل، وستعود رسالتك موضحةً السبب. يؤدي رمز الخروج 2 في PreToolUse إلى حظر استدعاء الأداة قبل تشغيلها، ويُمرَّر نص stderr إلى النموذج بوصفه رسالة الحظر. يُحيل ${CLAUDE_PROJECT_DIR} إلى جذر المشروع، لذلك يعمل hook مهما كان الدليل الذي يوجد فيه الوكيل. لا يحتاج الوكيل إلى الموافقة على القاعدة، أو تذكّرها، أو بقاء القاعدة في السياق. لا يحدث التعديل.

بالنسبة إلى حظر مباشر لا يتضمن أي منطق، تؤدي permissions.deny في إعداداتك المهمة نفسها من دون الحاجة إلى صيانة script، كما أن أنماط الأذونات تحدد ما يُشغَّل من دون سؤالك أولاً. إذا كان يجب فعلاً وضع التعليمات على مستوى system prompt بدلاً من رسالة مستخدم، فإن --append-system-prompt يضعها هناك، لكن يجب تمريرها عند كل استدعاء، ولذلك فهي أنسب للـscripts من العمل التفاعلي.

ما لا يمكنك فرضه بالتوجيه

كن واضحاً بشأن الجزء الذي يقع ضمن مسؤوليتك. موضع التعليمات وصياغتها والتعارضات بين الملفات وحجم الملف مشكلات تتعلق بالكاتب، ولها إصلاحات ينفذها الكاتب. أما ما تبقى فهو سلوك النموذج، ولن تزيله الصياغة الأفضل.

الموافقة ليست امتثالاً. سيقرّ الوكيل بقاعدة ما، ويعيد صياغتها لك بصورة صحيحة، ثم يخالفها بعد استدعاءين للأداة. لا يكلّف الإقرار شيئاً ولا يتنبأ بشيء. لا تعتبره إصلاحاً، ولا تحتسبه اختباراً.

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

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

ملف التعليمات ليس حداً أمنياً. فهو يشكّل السلوك ولا يفرضه. كل ما تكون كلفة الإخفاق فيه مرتفعة، مثل بيانات الاعتماد أو الأوامر المدمرة، ينبغي وضعه ضمن الأذونات أو hook. ينطبق المبدأ نفسه على البيانات في إبقاء الأسرار بعيداً عن متناول الوكيل: لا تطلب من الوكيل ألّا يقرأ ملفاً، بل رتّب بحيث لا يكون الملف قابلاً للقراءة.

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

FAQ

لماذا يتجاهل Claude Code ملف CLAUDE.md؟

تحقق أولاً من أنه حمّله قبل افتراض أنه تجاهله. شغّل /context وراجع قائمة Memory files؛ فالملف الذي لا يظهر اسمه فيها ليس جزءاً من المحادثة. تُرسَل ملفات التعليمات في رسالة مستخدم بعد مطالبة النظام، وتُعامل كسياق لا كإعدادات إلزامية، لذلك لا يوجد ضمان صارم بالامتثال لها. في معظم الحالات الفعلية، يكون السبب واحداً من أربعة: الملف موجود في دليل فرعي لم يقرأ الوكيل منه قط، أو أن ملفين يحتويان على تعليمات متعارضة فاختار النموذج أحدهما عشوائياً، أو أن القاعدة غامضة إلى حد يتعذر معه التحقق من إجراء بالاستناد إليها، أو أن الشفرة المحيطة تعرض سلوكاً مخالفاً لما تنص عليه القاعدة.

هل يغيّر تعديل ملف التعليمات أثناء الجلسة شيئاً؟

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

أي ملف تكون له الأولوية عند تعارض ملف CLAUDE.md في الجذر مع ملف متداخل؟

لا تكون الأولوية لأي منهما بصورة موثوقة. تُجمع الملفات المكتشفة في السياق بدلاً من أن يتجاوز أحدها الآخر، ويكون ترتيبها من جذر نظام الملفات نزولاً إلى دليل العمل، لذلك يُقرأ الملف الأقرب أخيراً فحسب. لا توجد آلية أولوية لحل التناقضات، وتنص وثائق Claude Code على أن القواعد المتناقضة قد تُحل عشوائياً. اكتب الملفات المتداخلة كإضافات تحدد المسار الذي تحكمه، واحذف التناقض بدلاً من محاولة منح إحدى القاعدتين أولوية على الأخرى.

هل تستمر تعليماتي بعد /compact؟

يعتمد ذلك على طريقة تحميلها. يُعاد حقن ملف جذر المشروع CLAUDE.md والقواعد غير المقيّدة بنطاق والذاكرة التلقائية من القرص بعد إجراء compaction. أما القواعد التي تحتوي على frontmatter من النوع paths: والملفات المتداخلة CLAUDE.md في الأدلة الفرعية، فتُفقد إلى أن يُقرأ ملف مطابق مرة أخرى. وكل ما كتبته في الدردشة فقط يستمر إذا احتفظ الملخِّص به مصادفةً. إذا كانت القاعدة يجب أن تظل سارية طوال الجلسة، فضعها في ملف جذر المشروع من دون frontmatter من النوع paths:.

متى ينبغي أن تصبح القاعدة hook بدلاً من أن تكون نصاً؟

عندما يكون الفحص حتمياً وتكون كلفة عدم اكتشاف المخالفة أعلى من كلفة كتابة script صغير. تنطبق هذه الحالة على قيود مسارات الملفات، والأوامر المطلوبة قبل إجراء commit، واستدعاءات الأدوات المحظورة. تمنع PreToolUse hook تنتهي بحالة 2 استدعاء الأداة مباشرة، وتعيد نص stderr إلى النموذج باعتباره السبب، ولذلك تظل القاعدة سارية سواء بقيت في السياق أم لا. وأي شيء يستطيع formatter أو linter تقريره ينبغي أن تتولاه تلك الأداة، ويجب حذفه بالكامل من ملف التعليمات.