ناقش المقال السابق أن CLAUDE.md مخصص للثوابت فقط. إذن ماذا يُكتب في memory؟ فتحتُ جميع ملفات memory الخمسة الحاليّة في هذا المشروع ودقّقتها واحدة تلو الأخرى—ما الذي يستحق البقاء، وما الذي يجب حذفه، وأين يقع الحد الفاصل الحقيقي بين CLAUDE.md وmemory.
ناقش المقال السابق أن CLAUDE.md يجب أن يحوي فقط ما لا يستطيع Claude رؤيته من قراءة الشيفرة. سأل قارئ على الفور: وماذا عن memory؟ memory هو أيضًا سياق — فما الفرق الحقيقي؟
ينتهي الأمر بكثير من الناس إلى التعامل مع memory باعتباره "امتدادًا احتياطيًا" لـ CLAUDE.md — يحشرون فيه كل ما يخطر ببالهم. مع مرور الوقت ينتفخ memory، ويقرأه Claude في كل جلسة، وتُتّخذ القرارات بناءً على معلومات متقادمة.
يتخطّى هذا المقال التعريفات المجردة. فتحتُ ملفات memory الخمس العاملة حاليًّا في هذا المشروع ودقّقتها واحدة تلو الأخرى — ما يبقى، وما يُحذف، وما لم يكن ينبغي كتابته أصلًا. على الطريق، يجيب سؤال CLAUDE.md مقابل memory عن نفسه.
السؤال المفيد ليس "أين أضع هذا" — بل "كم تعيش هذه المعلومة، ومن يحدّثها."
feedback_commits — انتظر حتى أقول "commit" قبل أن تعمل commit
feedback_article_authenticity — المقالات التطبيقية لا يمكن اختلاقها
project_i18n_strategy — قرار "إطلاق كل اللغات دفعةً واحدة"
project_howdev_plan — خطة غير مكتملة لـ how2claude.dev
project_article_workflow — خط نشر المقالات
مجمّعة حسب النوع.
المتن قصير: "don't auto-commit, wait for user to confirm."
هذا أعلى أنواع memory عائدًا. تصحيح واحد → دائم في كل الجلسات القادمة.
لماذا لا يُوضع في CLAUDE.md؟ لأنه ليس قاعدة مشروع — إنه عادتي الشخصية في العمل. إن انضم مساهم آخر إلى المشروع، ليس مطلوبًا منه بالضرورة اتباع القاعدة ذاتها. CLAUDE.md على مستوى الفريق. memory "بيني وبين Claude".
لماذا لا أعيد قوله في بداية كل محادثة؟ لأن memory يستمر عبر الجلسات. حين يساعدني Claude الأسبوع القادم، سيظل يتذكّر.
المحفّز واضح: صحّحتُ شيئًا مرةً واحدة، وأريد أن يدوم التصحيح إلى الأبد.
متن هذا القيد محدّد بشكل غير معتاد:
في 2026-04-16، وأنا أكتب ختام سلسلة multi-agent، اختلقتُ قصةً عن "ثلاثة Agent يبنون ميزة webhook"... جميعها مختلقة. سأل المستخدم "هل هذا حقيقي أم مختلَق" — وهو معيار يختلف عن المقالين السابقين (المنهجيين)...
النقطة: حقل Why ليس مبدأً مجردًا — بل حدث محدد + تاريخ + ما الذي جرى.
لماذا كتبه بهذا الشكل؟ بعد ستة أشهر، "المقالات التطبيقية تحتاج مادةً حقيقية" كقاعدة مجردة ستحيّرني — متى وُضعت؟ لماذا؟ لكن "4-16، اختلقتُ قصة agent وكُشفت" يستدعي التذكّر فورًا، ويتيح لي الحكم في الحال إن كانت القاعدة لا تزال سارية.
هذا أثقل قيد في الخمسة. ليس مجرد قاعدة — بل ملف حادثة يمكن لـ Claude ولي استعلام عنه.
المحتوى: لماذا أطلق هذا المشروع جميع اللغات دفعةً واحدة بجرأة — كلفة الترجمة عبر Claude ≈ 0، والوثائق الرسمية بالإنجليزية فقط هي نافذة الفرصة المحورية.
لا يمكنك رؤية هذا من الشيفرة. الشيفرة لا تُظهر سوى 19 ملف locale. لماذا 19، لماذا دفعة واحدة، لماذا أولويّة اليابانية والكورية عالية — كل هذا يسكن في رأسي.
يستقطر memory ذلك "القرار الذهني" إلى شيء راسخ، كي يستطيع Claude لاحقًا حين يقترح ميزة أن يسأل: هل يتعارض هذا مع استراتيجية i18n؟
ليس قاعدة تشغيلية (لا يدخل CLAUDE.md). خلفية استراتيجية (يدخل memory).
الأكثر مؤقّتًا من بينها: خطة تنفيذ من 9 ملفات لموقع مطوّري how2claude.dev، تنتهي بـ "يُستكمل في الجلسة القادمة."
أخطر أنواع memory — يتحول بسهولة إلى memory زومبي. تُنهي العمل وتنسى حذفه؛ في المرة التالية يعامله Claude بوصفه نشطًا ويقدّم نصيحة بناءً على خطة متقادمة ("لم تُنجز step 3 بعد").
تحتاج هذه القيود إلى آلية خروج صريحة: في اللحظة التي يُطلَق فيها how2claude.dev، عليّ حذف هذا القيد يدويًّا.
هذا القيد هو الأكبر كثافةً من حيث المعلومات. ظننته في البداية الأكثر نفعًا — حتى قرأته بعناية:
/write-article و/publish-article → انظر إلى .claude/commands/، تمامdocs/drafts/ يجعل الأمر واضحًا.claude/publish-config.jsonيستطيع Claude استنتاج كل ذلك من قراءة الشيفرة.
الشيء الوحيد الذي يقدّمه memory فعلًا هو الكتلة الأخيرة: "Accounts (production): zh → @how2claude, en → @howtoclaude" — وهذا متقادم بالفعل. أظهرت الجلسة الماضية أن الإنتاج هو فعلًا zh=@howtoclaude. التقط memory لقطةً قبل بضعة أيام؛ وقد انزاح الأمر منذ ذلك.
الخلاصة: يجب أن يذهب 90% من هذا القيد. الجزء الذي يستحق الإبقاء ("استخدم kamal للاستعلام عن الحسابات الحيّة") يناسب CLAUDE.md أكثر — أو الأفضل ألّا يُكتب في أي مكان، لأن الحسابات المضمّنة في memory ستنزاح مجددًا.
1. دور memory الحقيقي هو فتح الغرف التي لا يستطيع Claude دخولها.
2. إن كان Claude يستطيع قراءته من الشيفرة، فلا تضعه في memory.
المبدأ نفسه للمقال السابق عن CLAUDE.md. مسارات الملفات، عناوين API، بنية المجلدات — كلها أسئلة يمكن للشيفرة الإجابة عنها. حشرها في memory لأنك لا تريد إجراء grep مرة، هو رهانك أن المعلومة لن تتغير أبدًا.
3. memory يتآكل.
project_article_workflow هو الدليل — كُتب قبل أيام، ومعلومات الحسابات خاطئة بالفعل. كلما زاد عمر memory قلّت الثقة به. تدقيق دوري > إضافة بلا توقف.
4. حقل Why هو ما ينقذك.
بمقارنة feedbackَي:
feedback_article_authenticity: "4-16، اختلقتُ قصة في مقال multi-agent" → بعد ستة أشهر أستطيع الحكم فورًا إن كانت لا تزال سارية.feedback_commits: فقط "user wants to review" → بعد ستة أشهر لستُ متأكدًا أيّ تصحيح محدد أنجبه.الثاني أضعف بكثير. المبادئ المجردة لا تنجو — لا أحد يتذكر لماذا فُرضت.
عندما تظهر معلومة جديدة، اطرح ثلاثة أسئلة:
السؤال الثالث هو الفخ. معظم المواد "التي لا تتغير" التي تريد تدوينها يمكن في الواقع استنتاجها من الشيفرة — أنت فقط لا تريد أن يعمل Claude grep مرةً أخرى.
بعد مرور واحد، تبرز أشياء:
project_article_workflow قابل للاستنتاج من الشيفرة. هذا القيد يحتاج أكبر عملية جراحية.project_howdev_plan تسليم مؤقت — نظريًا ينبغي أن يكون له آلية خروج.project_i18n_strategy قرار استراتيجي — يستحق المراجعة بعد بضعة أشهر.feedback_commits ضعيف؛ إرفاق حدث محدد سيجعله أقوى.ملاحظة جانبية: توزيع الأنواع لديّ هو feedback×2 + project×3، مع صفر من النوعين user أو reference. يعني أنني لم أخبر Claude بعد "من أنا" أو "من أيّ أنظمة خارجية أقرأ الحالة." ربما هو الدفعة التالية للكتابة.
فخّ memory الأكبر ليس "ما كان يجب أن أكتبه ولم أفعل." بل "ما كتبته والذي أصبح متقادمًا." مع 5 قيود، انزياح واحد يكفي — يستخدم Claude بصمتٍ معلومات قديمة لاتخاذ القرار، ولن ينبّهك إلى الانزياح.
في قيودي الخمسة، أرى بالفعل أشياء تستحق التعديل. ماذا عن قيودك؟