لديّ بضع لوحات في Miro أصبحت منذ زمن حاملةً للأثقال — تأملات وخطط وخرائط ذهنية تراكمت على مدى سنوات. زر Export يمنحك ملف PNG أو PDF. هذه ليست بيانات، بل صورة فوتوغرافية للبيانات.

لماذا تُخرجها من هناك

قفل المورّد ليس مشكلة نظرية. إنه ملموس تماماً: كي تُنزّل بياناتك أنت عبر الـ API، عليك الترقية إلى فئة Expert. أي أنك تدفع مقابل الإذن باستعادة ما هو ملكك أصلاً.

أعيش منذ زمن طويل وفق مبدأ Obsidian-first: كل ما هو مهم يقبع في vault محلي، في ملفات نصية صِرفة أستطيع وضعها في git والبحث فيها بـ grep وقراءتها بعد عشر سنوات. الأداة التي لا تصدّر إلى تلك الصيغة أداةٌ يجب أن تبتعد عنها قبل أن تصبح التبعية مستحيلة الفكاك.

لماذا لا ينقذك زر Export

زر Export في Miro يمنحك ملف PNG أو PDF. هذا نقطي (raster) — البنية ضاعت. لا تستطيع تغيير النص داخل صندوق. لا تستطيع سحب شكل. لا تستطيع البحث بـ grep عن عنوان. إنها بطاقة نعي للوحة، لا اللوحة نفسها.

في Obsidian بديلان يعيشان داخل الـ vault: إضافة Excalidraw وكذلك Canvas الأصلي. كلاهما JSON. كلاهما قابل للتحرير. كلاهما قابل للبحث. كلاهما يقبع في vault-ك بجانب ملاحظاتك، ويمكنك البحث في النص بـ grep من داخل Obsidian مباشرةً.

كيف تُخرجها حين لا يوجد زر 'Export to Obsidian'

حين لا يعطيك Export في الواجهة ما تحتاجه، تغوص في الـ API. لدى Miro واجهة REST API: تعيد وصفاً بصيغة JSON لكل شكل على اللوحة. وExcalidraw وObsidian Canvas كلاهما JSON بصيغة مفتوحة. وبينهما يقع التحويل (mapping).

كتبتُ سكربتَين بلغة Python. miro_to_excalidraw.py وmiro_to_canvas.py. المكتبة القياسية فقط — صفر تبعيات. تُشغّلهما برمز مصادقة ومعرّف لوحة، فتحصل على ملف، ترميه في الـ vault.

ما الذي نجا من التحويل

لم تكن المهمة مجرد نقل الأشكال — بل الحفاظ على المظهر البصري كي تُقرأ اللوحة تماماً كما كانت داخل Miro.

• المواضع والأحجام — إحداثيات كل شكل بنسبة 1:1
• الألوان مع شفافية التعبئة (الأصفر بنسبة 40% يبقى أصفر بنسبة 40%)
• الحدود — اللون، العرض، النمط (solid / dashed)
• الخطوط والمحاذاة — monospace يبقى monospace، وcenter يبقى center
• الموصّلات — الأسهم تلتصق عند النقاط ذاتها التي ثبّتها Miro
• الموصّلات المنحنية — أقواس bow بدلاً من الخطوط المستقيمة
• الصور مضمّنة داخل الملف (لا روابط URL خارجية)
• عُقد الخرائط الذهنية — النص مستخرَج عبر واجهة Mindmap API التجريبية
• ترتيب الطبقات (Z-ordering) — التداخلات لا تتشابك

أين صار الأمر شائكاً

في واجهة Miro API ثغرتان أو ثلاث اضطُررت إلى الالتفاف حولها بالهندسة العكسية.

• الموصّلات المنحنية — لا يكشف Miro نقاط التحكم عبر الـ API. لذا بدلاً من المنحنى الأصلي بدقّته، أصطنع bow — قوساً بنصف قطر ثابت بين الطرفَين. قريب بصرياً، لكنه mathematically غير مطابق.
• Z-index — واجهة Miro API لا تعيد حقل z إطلاقاً. أيُّ شكل يعلو وأيُّها يقبع تحت؟ الاستدلال التقريبي: المساحة الأكبر = أبعد إلى الخلف. وهذا ينجح لأن الحاويات الكبيرة في اللوحات الحقيقية تقبع عادةً تحت العناصر الأصغر.
• الخرائط الذهنية — نص عُقد الخريطة الذهنية لا يمكن الوصول إليه عبر items API المعتادة. تحتاج إلى نداء منفصل إلى نقطة نهاية Mindmap التجريبية. العُقد المملوءة تصير صناديق، وغير المملوءة تصير نصاً صِرفاً.

Excalidraw مقابل Canvas — كيف تختار

إن كنت تفكّر على هيئة رسومات — خطوط تخطيطية، إحساس مرسوم باليد، تركيبات حرة الشكل — فاختر Excalidraw. إضافة Excalidraw تعرض الملف بالأسلوب الجمالي ذاته الذي رأيته على الـ whiteboards.

إن كانت لوحاتك في معظمها مستطيلات فيها نص موصولة بأسهم، وكنت تعيش في Obsidian بوصفه دماغك الثاني — فاختر Canvas. إن Canvas أصلي، يُفتح بنقرة واحدة، ومنسوج مع backlinks وtags الخاصة بالـ vault.

أحوّل بعض اللوحات إلى Excalidraw (حين يهمّ الأسلوب البصري)، وأخرى إلى Canvas (حين تهمّ السرعة والإحساس الأصلي). المستودع يدعم كلتا الصيغتين — تختار عند التشغيل.

الخلاصة

Python 3، المكتبة القياسية فقط. لا pip install، لا virtualenv، لا node_modules. python3 miro_to_excalidraw.py 'BOARD_ID' 'output.excalidraw' — والملف بين يديك.

المستودع: github.com/oleksiimazurenko/miro-to-obsidian. رخصة MIT. طلبات الدمج مرحّب بها — خصوصاً للحالات الحدّية التي لم أصادفها بعد.

الدرس أكبر من Miro

قفل المورّد في SaaS مخدّر. الأشهر الأولى مجانية. بعد ستة أشهر يصير عادة. بعد سنة تعيش بياناتك في صيغة لا يقرؤها إلا واجهتهم. بعد سنتين تدفع مقابل فئة Expert كي تستخرج ما هو ملكك أصلاً.

الخلاصة ليست «لا تستخدم SaaS». الخلاصة أن كل أداة تسمح لها بأن تصبح حاملةً للأثقال تحتاج إلى خطة خروج قبل أن تفتحها للمرة الأولى أصلاً. سؤال «كيف أخرج من هنا حين أحتاج» يزن تماماً بثقل سؤال «ما مدى لطافة الواجهة». الأداة التي لا تملك تصديراً بنص صِرف أو واجهة API مفتوحة أداةٌ ببطاقة سعر خفية ستدفعها بعد سنتين.

Obsidian-first ليس لأن Obsidian مثالي. بل لأن ملفات markdown النصية الصِرفة صيغة ستُعمّر أطول من Obsidian نفسه. تماماً كما سيُعمّر ملف Excalidraw JSON العاري أطول من الإضافة نفسها. تماماً كما سيُعمّر سكربت Python هذا أطول من Miro.

ليست قائمة نصائح مفكّكة — فتلك تتبخّر لحظة أن تشعر بالتعب. بل مرجعية لها اسمٌ تستحضرها تحت الضغط، تمامًا كما يعمل SOLID في التصميم الكائنيّ التوجّه. أسمّيها CRAFT: خمسة مبادئ، لكلٍّ منها حرفٌ واحد، تجتمع كلها تحت بديهيةٍ واحدة. الاسم نفسه هو جوهر الأمر — البرمجة تبقى حِرفة، والذكاء الاصطناعي مجرّد أداةٍ في يد من لا يزال قادرًا على أداء العمل بدونها.

البديهية: الخط المتحرّك

قبل الأحرف الخمسة تأتي قاعدةٌ واحدة تحكمها جميعًا — تمامًا كما يقبع مبدأ «المسؤولية الواحدة» في قلب SOLID:

الذكاء الاصطناعي يفعل ما أتقنتَه بالفعل. أنت تفعل ما لا تزال تتعلّمه. ويتحرّك الخط مع نموّك.

سلّم الجزء الذي أتقنته إلى الذكاء الاصطناعي فتمضي أسرع — وهذا مكسبٌ خالص. سلّم إليه الجزء الذي لا تزال تُكوّنه فلن تُكوّنه أبدًا؛ تدفع من مهارتك ثمنَ سرعةٍ لم تكن بحاجةٍ إليها أصلًا. وكل مبدأٍ في ما يلي ما هو إلا وسيلةٌ لتبقى صادقًا مع نفسك حول موضع ذلك الخط بالنسبة إليك اليوم.

CRAFT — خمسة مبادئ، اختصارٌ واحد

إذا قرأتَها من الأعلى إلى الأسفل، فالأحرف مسار عمل: تحدَّ نفسك أولًا، وراجِع ما يعطيك إياه الذكاء الاصطناعي بعينٍ عدائية، واسأل لماذا بدل ماذا، واصنع الاحتكاك عن قصد، وتحقّق من أنك تفهم فعلًا.

C — Challenge First

المبدأ. قبل أن تفتح الذكاء الاصطناعي، حاوِل حلّ المشكلة بنفسك لمدة 5–15 دقيقة. يجب أن يكون أول حلٍّ على الصفحة حلَّك أنت — ولو كان أخرقَ. يأتي الذكاء الاصطناعي كي يفكّ حصارك، لا كي يبدأ عنك أبدًا.

لماذا. الكفاح هو ما يبني النموذج الذهني — فالخلايا العصبية تشتعل حين تكون عالقًا، لا حين تقرأ إجابةً جاهزة. هذا هو بالضبط الاحتكاك الذي كان الواقع يفرضه مجانًا؛ أما الآن فعليك أن تجدوِلَه بنفسك.

R — Review Adversarially

المبدأ. لا تدع الذكاء الاصطناعي يراجع كودك — بل أنت من يراجع كوده. اقرأ كل سطرٍ مُولَّد وأنت تصطاد الخلل، والحالة الحديّة، والثغرة الأمنية.

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

A — Ask Why, Not What

المبدأ. استخدم الذكاء الاصطناعي معلّمًا خاصًّا، لا كاتبًا شبحيًّا. اطلب المنطق والبدائل والمقايضات — لا مجرّد المقطع الجاهز.

لماذا. «ماذا» تمنحك سمكة؛ أما «لماذا» فتمنحك الصنّارة. «أعطني الكود» لا يترك وراءه شيئًا. أما «لماذا هذا النهج دون ذاك، وما الذي ينكسر عند إدخالٍ فارغ؟» فيتركك أذكى بدرجةٍ مما كنت.

F — Friction on Purpose

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

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

T — Test Your Understanding

المبدأ. البوابة الكبرى سؤالٌ واحد: هل أستطيع أن أشرح هذا، سطرًا سطرًا، لشخصٍ آخر؟ إن لم تستطع، فالكود ليس ملكك ولا تُطلقه. توقّع المُخرَج قبل تشغيله؛ اكسِره عن قصد ثم أصلحه من جديد.

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

CRAFT في لمحة

افحص نفسك: أتنمو أم تتآكل؟

لا تحتاج إلى دراسةٍ لتعرف أيَّ اتجاهٍ تسلك. أنت تتآكل إذا:

• لم تعد تستطيع كتابة نسخةٍ أساسية من الشيء دون الذكاء الاصطناعي.
• تلصق كودًا لن تقدر على شرحه لو سألك أحد.
• يعتريك القلق لمجرّد التفكير في العمل والمساعد مُطفأ.
• توقّفت عن قراءة مُخرَج الذكاء الاصطناعي وصرت تقبله بلا تمحيص.
• لا تستطيع التنبؤ بما يفعله مقطعٌ ما قبل تشغيله.

أنت تنمو إذا:

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

إن أخذت حرفًا واحدًا فقط

خذ T. بوابة القابلية للشرح — هل أستطيع شرح هذا سطرًا سطرًا؟ — أبسط عادةٍ في المنهج كله، وهي وحدها تمسك بنحو 80% من التآكل. وكل ما تبقّى في CRAFT إنما يسهّل عليك اجتياز تلك البوابة بصدق.

الخلاصة

لم يتغيّر شيءٌ جوهري في التعلّم. الفهم الواعي كان دائمًا هو المهم؛ والحشو كان دائمًا بديلًا رديئًا. ما تغيّر هو أن البيئة توقّفت عن فرض ذلك الفرق نيابةً عنك. وما CRAFT إلا وسيلةٌ لتفرضه على نفسك.

قواعد اللعبة هي نفسها. غير أن اللعبة صارت أكثر غدرًا — فالطريق السهل يرتدي الآن قناع النجاح.

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

المسألة ليست «أتعلّم أم لا». المسألة هي ما الذي تسلّمه بالضبط للـ AI وما الذي تحتفظ به لنفسك. وهي كذلك حول أمر واحد غيّره الـ AI فعلًا — لا في اتجاه «انقلب كل شيء»، بل في اتجاه أدق بكثير: لقد اختفت حلقة التغذية الراجعة القسرية التي كان الواقع يديرها عنك من قبل.

طرفان متطرّفان — كلاهما أحادي النظرة

أولًا، لنُخلِ الطاولة من المعسكرين الصاخبَين اللذين يظهران في كل نقاش:

• المعسكر الأول: «لم يعد هناك داعٍ لتعلّم اللغات — الـ AI سيكتبها». الأعلى صوتًا بينهم هم باعة معسكرات تدريبية «صِرْ مبرمجًا في 30 يومًا مع الـ AI».
• المعسكر الثاني: «الجميع سيصير أغبى، وخلال بضع سنوات لن يبقى مختصّون». الأعلى صوتًا هم ذوو الخبرة الذين يخافون قليلًا من عجزهم أمام سرعة ظهور المبتدئين بمظهر منتِج.

ثنائية زائفة. في جوهره لم يتغيّر شيء أساسي: كما هو الحال دائمًا، ما يُقدَّر هو الفهم الواعي لا الحفظ الأجوف. الـ AI يوسّع فقط الفجوة بين من يفهمون حقًا وبقية الناس — ويفعل ذلك أسرع من ذي قبل.

ماذا تقول قاعدة الأدلة

لم يعد الأمر «يبدو لي». فقد ظهرت قياسات ملموسة خلال 2025–2026:

• Nature (يونيو 2026)، «Is AI ruining our skills?» — الاعتماد المفرط على الـ AI يُدهور المهارات. ليس عند المبرمجين وحدهم — بل عند الأطباء أيضًا.
• تجربة Anthropic العشوائية المضبوطة على 52 مهندسًا: مساعد الـ AI يُنتج تكوينًا للمهارة أقل بنحو 17%. النقطة الدقيقة أن ما يتضرر ليس سرعة إنجاز المهمة، بل تكوين المهارة. أي أنك على المدى القصير أسرع، وعلى المدى البعيد أسوأ.
• AI & Society: فقدان المهارة (deskilling) مشكلة بنيوية لا حلّ جاهز لها. ليست «الـ AI سيّئ»، بل «الأداة غيّرت بيئة التعلّم».
• TechCrunch: المهندسون يرفضون العمل بلا AI لأنهم لم يعودوا قادرين على ذلك من دونه. العنوان: «قد يرتدّ هذا عليهم».

خلاصة الخبير K. Crowston (تنقلها Nature) — الأمر ليس «AI أو لا»، بل: قرِّر بوعي أيّ المهارات تحتفظ بها لنفسك وأيّها تسلّمه. هذه هي الجملة التي يقوم عليها بقية المقال.

ما الذي تسلّمه وما الذي تحتفظ به

على نحوٍ ملموس — هنا يمرّ الخط الفاصل:

لا يمكنك مراجعة ما لا تستطيع قراءته. لذا فإن «الفهم دون معرفة اللغة» وهمٌ؛ إنه ثقة عمياء بالـ AI. وهذه بالضبط نقطة الانتقال بين «مختصّ يستخدم الـ AI» و«مشغِّل AI». الأول يقود الـ AI؛ والثاني يقوده الـ AI.

تمييز آخر يخلط الناس بينه دائمًا: فقدان المهارة ≠ عدم تكوّن المهارة أصلًا. المهندس ذو الخبرة الذي بدأ فجأة يتّكئ على الـ AI يبقى قويًا — فلديه بالفعل نموذج للعالم. أما المبتدئ الذي يجلس على الـ AI بنسبة 100% من أول يوم فلن يبني هذا النموذج أبدًا. هاتان مشكلتان مختلفتان بعواقب مختلفة.

كيف تتعلّم بالطريقة الصحيحة — ولماذا لم يتغيّر شيء في الجوهر

لا يزال عليك أن تتعلّم — لكن بالطريقة الصحيحة. لا حفظًا أجوف للمصطلحات أو الأوامر، بل فهمًا للمنطق وإحساسًا بكيفية عمل الأمر ككل. القيمة ليست في «التذكّر»، بل في «الفهم → القدرة على التطبيق → القدرة على الحُكم».

والأهم: هذا هو ذاته ما كان عليه الحال دائمًا، قبل الـ AI بزمن طويل. ما كان يُقدَّر دائمًا هم من يفهمون فعلًا كمختصّين، لا من يحفظون بلا فهم. الـ AI لم يقلب شيئًا — إنه فقط جعل الطريق الكسول أسهل (صار بوسعك أن «تُنجز» دون فهم)، ولهذا فالفجوة بين هذين النوعين تتّسع لا غير.

من تعلّم بوعي سيبقى كذلك. ومن كان كسولًا سيبقى كسولًا. الـ AI لم يخلق هذا الانقسام — إنه فقط سلّط عليه الضوء.

اختبر ذلك على أمثلة بسيطة

• الرياضيات: حفظ جدول الضرب عن ظهر قلب ليس بعدُ «معرفة بالرياضيات». الآلة الحاسبة قتلت الضرب الطويل بالورقة، لكنها لم تقتل الحاجة إلى فهم ما هو الضرب ومتى يُطبَّق.
• الهواتف: لم تعد تحفظ الأرقام في رأسك — الهاتف يتذكّرها. لكن عليك أن تعرف بمن تتصل ولماذا. سلّمتَ الذاكرة — واحتفظتَ بالحُكم.
• GPS: لا تحفظ المسارات في رأسك. لكن عليك أن تفهم إلى أين تتجه — وأن تنتبه حين يقودك الـ GPS في التفافٍ سخيف.

في الحالات الثلاث أخذت الآلة الذاكرة الآلية، لا الفهم والحُكم — وهكذا كان الأمر دائمًا. الـ AI هو التكرار التالي للشيء نفسه، لكن بنطاق أوسع مما يمكنك تفويضه الآن.

الصياغة النحوية ناتج جانبي لا هدف

هذا لا يعني «لا داعي لمعرفة الصياغة النحوية». ستكتسب الصياغة على أي حال — لكن بوصفها ناتجًا جانبيًا للفهم والممارسة، لا هدفًا. أنت لم تتعلّم %d ببطاقات تذكّر — بل فهمتَ منطق سلاسل التنسيق (format strings)، فرسخ من تلقاء نفسه. هكذا يعمل التعلّم السليم: تفهم → تطبّق → تستقر الصياغة وحدها. الـ AI يسرّع هذه الحلقة فقط إن استخدمته على نحو صحيح.

لكن أمرًا واحدًا تغيّر فعلًا: حلقة التغذية الراجعة القسرية اختفت

«لم يتغيّر شيء» — هذا صحيح بنحو 80%. أمرٌ واحد مهم تغيّر فعلًا، وهو ليس بالأمر الهيّن.

كانت البيئة سابقًا تُجبِرك على التعلّم. لم يكن بوسعك إطلاق كود يعمل دون أن تفهمه بالقدر الذي يجعله يشتغل على الأقل. المُصرِّف والخلل والانهيار — كانوا معلّمين يجرّون الجميع بالقوة إلى حدٍّ أدنى. كان الصراع إلزاميًا — وكان يبني الفهم حتى لدى غير المجتهدين كثيرًا.

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

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

لذا فمقولة «الكسول يبقى كسولًا» أضيق من اللازم. الأمر يتعلق بـ البيئة والعادات أكثر من الطبع: معظم الناس يتفاعلون مع الاحتكاك والتغذية الراجعة، وليسوا كسالى «بالفطرة». أزِل الاحتكاك — وحتى غير الكسالى ينزلقون. الخطر ليس على الكسالى وحدهم.

والأدقّ من ذلك — وهم الكفاءة. الـ AI يرقّع الثغرات بسلاسة شديدة حتى إنك لا تصطدم بجدار جهلك ولا تلاحظ وجوده أصلًا. تشعر أنك فاهم لأن «كل شيء يعمل» (أثر metacognitive laziness). لذا صار البقاء مجتهدًا أصعب: صار يتطلب منك أن تخلق لنفسك احتكاكًا بوعي — أن تُطفئ الـ AI أحيانًا، أن تحاول الشرح أو الكتابة دونه، أن تتحقق «أأفهم حقًا، أم أظن فقط أنني أفهم». كان الواقع يفعل هذا عنك سابقًا — والآن صار على عاتقك.

القواعد نفسها، لكن اللعبة صارت أكثر مكرًا — الطريق السهل صار يتنكّر الآن في هيئة نجاح.

لمن يفهم بالفعل — اللعبة مختلفة

كل ما سبق يخصّ تكوين المهارة من الصفر. أما إن كنت متكوّنًا بالفعل — فالصورة عندك مقلوبة، ويجدر قول ذلك صراحةً، وإلا قُرِئ المقال على أنه «الـ AI سيّئ»، وليست تلك هي الفكرة.

المهندس ذو الخبرة يعرف حدوده. يرى ما سلّمه له الـ AI → وفي نصف ثانية يميّز أين هو «غير سليم»، وأين هو «نعم، لكن لا لهذه الحالة»، وأين هو «نعم وجيّد هنا والآن». لديه كاشف مدمج «هذا لا تبدو رائحته صحيحة» مُجمَّع من سنوات من الحوادث الحقيقية. الـ AI لا يُطفئ هذا الكاشف — بل على العكس يغذّيه أسرع: أمثلة أكثر، حالات أكثر، أنماط (patterns) أكثر يتعيّن ترشيحها بسرعة.

لذا فإن الـ AI نفسه الذي يهدّد بتحويل المبتدئ إلى مشغِّل يحوّل الخبير إلى خبير مُعزَّز. boilerplate في 30 ثانية بدل 3 دقائق. استكشاف مكتبة جديدة — في أمسية، لا في أسبوع. نقل وحدة من Python إلى TypeScript — قابل للتنفيذ فعلًا، لا «يومًا ما لاحقًا». هذا نيترو يُضَخّ في محرّك مُجمَّع سلفًا.

وأمر دقيق آخر: لا يستطيع الـ AI أن يكذب على الخبير دون أن يُلحَظ. الـ AI يكذب عليه بالقدر نفسه الذي يكذب به على المبتدئ — لكنه يلتقط ذلك قبل أن يُتمّ قراءة الجملة. ما هو للمبتدئ فخّ وهم الكفاءة، هو للخبير مجرد بلاغ خلل آخر في السيل اليومي.

لمن استثمر وقته بالفعل، الـ AI مُعزِّز. ولمن لم يستثمره بعد — هو سبب إضافي لألّا يفعل. لا وسط بين هاتين الحالتين — وهذا ما يجعل «متى تعلّمت بالضبط» من أهم العوامل في المسار المهني.

خطر منظومي: «السلّم المكسور»

الخبراء يأتون من المبتدئين. فإن التهم الـ AI عمل المبتدئين ولم يبنِ أحد الأساس → فبعد 5–10 سنوات لن يبقى من يُنشَّأ ليصبح خبيرًا. خطر «جيل ضائع» من المختصّين حقيقي — وليس هذا تهويلًا، بل مشكلة أنابيب بسيطة: أُغلق أنبوب الدخول ولم يُغلق أنبوب الخروج.

لماذا لن يصل هذا إلى الصفر (لكنه سيؤلم): توازن «الجميع توقّفوا عن التعلّم» غير مستقر. الندرة تجعل من تعلّموا مفرطي القيمة → فيعود حافز التعلّم. الشركات التي تُنشّئ المختصّين بوعي تحصل على خندق تنافسي (moat). لكن الانتقال مؤلم: المشغّلون سيسقطون عند أول حادث جدّي، حين يكذب الـ AI بوضوح وإقناع ولا يكون حول أحدٌ يميّز الصدق من الكذب.

موقفي

• تعلّم اللغة إلزامي — بهدف القراءة والحُكم، لا الحفظ. لا يمكنك اختصار الطريق إلى طلاقة القراءة؛ الـ AI لا يختصره، بل يجعله اختياريًا بهدوء لا غير.
• وما دامت الأغلبية تسلّم «الفهم» للـ AI — فإن التعلّم الآن نافذة فرصة: تصير مختصًّا نادرًا يقود الـ AI، لا من ينافسه. إنها نافذة قصيرة الأمد — فالسوق سيتكيّف عاجلًا أو آجلًا. وما دامت مفتوحة — فمن الخطأ ألّا تنتهزها.
• النمط الصحّي: استخدام الـ AI لتمضي أسرع وتتعلّم أعمق، لا لتتجنّب التعلّم. النمط المضادّ هو «أنجِز المهمة كلها بدلًا مني». أما النمط الصحيح فهو أن تكتب بنفسك، ويشرح الـ AI «لماذا»، وتفهم نسخته بنفسك قبل أن تقبلها.
• مفارقة للطريق: كي تستخدم الـ AI بفعالية، عليك أن تعرف ما يكفي لكي لا تحتاجه في الأمور البسيطة. من يعتمد على الـ AI في البسيط سيخدعه الـ AI في المعقّد دون أن تكون لديه فرصة لملاحظة ذلك.

المصادر

• Nature — Is AI ruining our skills? Early results are in (يونيو 2026): nature.com/articles/d41586-026-01947-1
• InfoQ — Anthropic study, ~17% skill mastery drop: infoq.com/news/2026/02/ai-coding-skill-formation
• TechCrunch — Coders are refusing to work without AI: techcrunch.com/2026/05/29/coders-refusing-ai
• AI & Society — AI deskilling is a structural problem: link.springer.com/article/10.1007/s00146-025-02686-z

لكن بعد شهر من الاستخدام الحقيقي اصطدمت ببضع مشكلات جوهرية لم تغطّها تلك التدوينة. أكبرها — خاصية غريبة خفية في Claude Code تعثّرت بها مصادفةً، حين أضفت Gmail MCP فـ «اختفى» من ملفي بعد خمس دقائق. اليوم أعدت بناء الأمر كله إلى بنية جديدة — متوافقة مع XDG، مع symlink ومنتقٍ تفاعلي للملفات عبر gum. هذه هي v2 — تطوّر نابع من تجربة حقيقية، لا تحسين نظري.

ما بدأ يزعجني

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

١. مجلدان منفصلان في $HOME — فوضى

~/.claude و~/.claude-promova — مجلدا نقطة متجاوران في جذر $HOME. تقول مواصفة XDG Base Directory إن الإعدادات مكانها ~/.config/. مجلدات النقطة المبعثرة مباشرةً في الـ home نمط مضاد يحوّل $HOME تدريجيًا إلى درج للنفايات. تجميلي، صحيح، لكنه كان يضايقني في كل مرة أرى فيها ls -la ~.

٢. لا تأكيد بصري للملف النشط

أشغّل claude ولا أدري أيُّ ملفٍ نشط — إلى أن أنفّذ claude config list داخل الجلسة. وإن نسيت أي طرفية شغّلت أين، اضطررت للتحقّق. أمر صغير، لكن مع تشغيل الشخصي والعمل بالتوازي عبر تبويبَين يتراكم.

٣. الـ aliases لا تتوسّع

ملفان — claude وclaude-promova — لا بأس. أضف ثالثًا (عميل مستقل) — تحتاج alias ثالثًا. ورابعًا — رابعًا. بعد ستة أشهر لن أتذكّر أيّ aliases أنشأت فعلًا.

٤. الفخ الخفي في ~/.claude.json

وهذا هو السبب الحقيقي لإعادة البناء. لدى Claude Code مكانان مختلفان للإعداد، والتوثيق لا يصرخ بذلك: ~/.claude/ — المجلد الذي يحوي projects/ وsessions/ وhooks/ وskills/. وبشكل منفصل — ~/.claude.json، ملف يقع مباشرةً في جذر $HOME، وفيه يعيش oauthAccount وmcpServers وتاريخ projects وskillUsage ونحو 40 حقلًا آخر من الحالة الحيّة الفعلية.

الأمر claude mcp add --scope user يكتب في ذلك ~/.claude.json في جذر الـ home، لا في ~/.claude/.claude.json ولا في مجلد الملف. لم أكن أعلم ذلك. إلى أن اصطدمت به في يوم من الأيام.

الاكتشاف: لماذا «اختفى» Gmail MCP

هذا الصباح كنت أُعِدّ Gmail MCP في Claude Code. إعداد قياسي: مشروع Google Cloud، بيانات اعتماد OAuth، claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. كل شيء على ما يرام. أعدت تشغيل الجلسة — يعمل، أقرأ البريد وأردّ على الرسائل. بعد ساعة بدأنا نعيد هيكلة الـ aliases إلى دالة مع منتقي ملفات عبر gum، ثم نقلنا كل شيء إلى XDG. نفّذت mv ~/.claude → ~/.config/claude-profiles/personal، وأعدت تشغيل CC، واخترت personal من القائمة. وفي الجلسة الجديدة فتحت /mcp:

figma            (failed)
playwright-test
claude.ai Notion

لا gmail. لا vaultforge. ثلاثة خوادم فقط، وأحدها حتى فشل. وأنا لتوّي أضفت Gmail. وفي الوقت نفسه كانت جلسة في طرفية أخرى (ملف العمل) تعرض Gmail وVaultforge دون أي مشكلة.

بدأت أنبش فوجدت أن لديّ ثلاثة ملفات مختلفة على جهازي باسم .claude.json:

ها هو. هذا هو المطبّ المعماري:

1. claude mcp add --scope user يكتب دائمًا في ~/.claude.json في جذر الـ home، بغضّ النظر عن CLAUDE_CONFIG_DIR
2. حين يكون CLAUDE_CONFIG_DIR معيّنًا، يقرأ Claude Code الملف $CLAUDE_CONFIG_DIR/.claude.json — أي الملف داخل ملف التعريف
3. مدخلات «MCP بنطاق المستخدم» ومدخلات «MCP ملف التعريف» تعيش في ملفين مختلفين بالاسم نفسه — ويسهل الخلط بينهما

في حالتي كان ~/.claude.json (جذر الـ home، 113 كيلوبايت) هو الحالة الحيّة الراهنة — مع gmail وvaultforge وجلسة OAuth، كل شيء. أما ~/.config/claude-profiles/personal/.claude.json (29 كيلوبايت) فاتّضح أنه لقطة قديمة كانت قابعة في الـ ~/.claude/ القديم من قبل — ربما كتبتها نسخة CC أقدم، وربما مكوّن إضافي. أظهر jq -r 'keys[]' على الملفين أن نسخة جذر الـ home فيها 41 مفتاحًا فريدًا غائبًا عن اللقطة.

وهذه المفاتيح الـ 41 ليست نفايات. إنها الحالة الفعلية لـ Claude Code:

• skillUsage — إحصاءات استخدام المهارات
• githubRepoPaths — مستودعات مخزّنة للتنقّل في المشاريع
• cachedGrowthBookFeatures + cachedStatsigGates — أعلام الميزات (بدونها يجلب CC نسخًا جديدة عند كل إقلاع)
• hasShownOpus45Notice وhasShownOpus46Notice وhasShownS1MWelcomeV2 — أعلام واجهة (بدونها تعود النوافذ المنبثقة عند التشغيل التالي)
• lastPlanModeUse وfeedbackSurveyState وinstallMethod — حالة التهيئة وتجربة الاستخدام

إن نفّذت فقط mv ~/.claude ~/.config/claude-profiles/personal دون دمج، تفقد كل ذلك. تعود نوافذ الترحيب، ويعمل بحث githubRepoPaths من جديد، وترجع كل مطالبات الاستبيان. وهو ما كدت أفعله.

البنية الجديدة

كل شيء يعيش تحت مجلد أب واحد في ~/.config/، كما يريد XDG. كل ملف تعريف قائم بذاته — يحمل حالته الكاملة بما فيها .claude.json الخاص به. ويبقى ~/.claude بوصفه symlink إلى الملف الشخصي من أجل التوافق مع الخلف.

~/.config/claude-profiles/
├── personal/
│   ├── .claude.json          ← full live state + MCP list (113 KB)
│   ├── projects/, sessions/, hooks/, skills/, ...
│   └── CLAUDE.md
└── promova/
    ├── .claude.json          ← work state + work MCPs (41 KB)
    └── projects/, sessions/, agents/, skills/, ...

~/.claude  →  symlink to ~/.config/claude-profiles/personal/

لا .claude.json في جذر $HOME. كل ملف تعريف مجلد معزول منفصل يحوي كل شيء: مجلدات projects/sessions والملف نفسه بخوادم MCP ورموز OAuth. مصدر واحد للحقيقة لكل ملف تعريف.

لماذا يشير الـ symlink إلى personal

كل ما يثبّت مسار ~/.claude/ بشكل صلب — السكربتات القديمة، والمكوّنات الإضافية، وإضافات Claude Code لبيئات التطوير، وإعدادات شريط الحالة مثل claude-powerline.json — يستمر في العمل دون تغيير. يُحلّ الـ symlink إلى الملف الشخصي. وإن شغّلت بالخطأ command claude (متجاوزًا الدالة الغلاف)، فإنك تصل أيضًا إلى personal عبر البحث بالمسار الافتراضي. يصبح personal هو «الافتراضي الهادئ» كما كان، لكنه الآن يعيش فيزيائيًا في موقع XDG.

منتقٍ تفاعلي عند التشغيل — دالة + gum

بدل الـ aliases — دالة claude() في ~/.zshrc تعرض قائمة بأسهم لوحة المفاتيح عبر gum (أداة TUI من Charm). تعترض الدالة نداء claude على مستوى الـ shell، وتدعك تختار ملفًا، ثم تشغّل command claude بـ CLAUDE_CONFIG_DIR المطابق. command مهمة هنا — فهي تتجاوز الدالة الغلاف وتستدعي الملف الثنائي الحقيقي.

# brew install gum

# Claude Code: profile picker on launch
claude() {
  local profile
  profile=$(gum choose \
    --header "Claude profile:" \
    --cursor "▸ " \
    --selected.foreground 212 \
    --cursor.foreground 212 \
    --header.foreground 244 \
    "personal" "promova") || return
  case "$profile" in
    personal) CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/personal" command claude "$@" ;;
    promova)  CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/promova"  command claude "$@" ;;
  esac
}

هكذا يبدو عند التشغيل:

Claude profile:
▸ personal
  promova

↑↓ للتنقّل، Enter للاختيار، Esc للإلغاء (فلا يبدأ Claude ببساطة). الملف مرئي دائمًا — يستحيل أن يفوتك.

من الصفر (لا يوجد v1 لترحيله)

إذا كنت قد شغّلت من قبل حيلة المجلدين القديمة مع الـ alias، فانتقل مباشرةً إلى سكربت الترحيل في الأسفل. هذا القسم هو البناء النظيف من الصفر — جهاز جديد، أو مجرد ~/.claude الافتراضي الناتج عن الاستخدام العادي. حدّد الشكل أولًا: حساب واحد بعدّة ملفات تعريف (لعزل المشاريع ومجموعات MCP الخاصة بها — وهي الحالة الشائعة)، أو حسابات مختلفة فعلًا لكل ملف تعريف (شخصي مقابل عمل).

١. رتّب المجلدات

# prerequisites
brew install gum jq

# 1. XDG parent for all profiles
mkdir -p ~/.config/claude-profiles

# 2. fold an existing default install in as your first profile (no-ops on a fresh machine)
if [ -d ~/.claude ] && [ ! -L ~/.claude ]; then
  mv ~/.claude ~/.config/claude-profiles/personal
  [ -f ~/.claude.json ] && mv ~/.claude.json ~/.config/claude-profiles/personal/.claude.json
fi

# 3. one directory = one profile
mkdir -p ~/.config/claude-profiles/personal ~/.config/claude-profiles/work

# 4. these files will hold OAuth tokens — lock them down
chmod 600 ~/.config/claude-profiles/*/.claude.json 2>/dev/null

مجلد واحد لكل ملف تعريف تحت أب XDG واحد. إذا كنت قد استخدمت Claude Code من قبل، فإن المقتطف يدمج ~/.claude الحالي بوصفه personal، ويحمل معه الحالة الحيّة من ~/.claude.json في جذر الـ home؛ وعلى جهاز جديد تمامًا لا تفعل هذه الأسطر شيئًا. كل ما تبقّى هو مجلدات فارغة تملأ نفسها عند أول تشغيل — وchmod 600 مهم، لأن هذه الملفات ينتهي بها الأمر بحمل رموز OAuth.

٢. وثّق كل ملف تعريف

# launch each profile once and authenticate it
CLAUDE_CONFIG_DIR=~/.config/claude-profiles/work claude
#   → run /login in the session, sign in, done.
# Same account for every profile? One /login is enough — macOS keeps it in the
# shared Keychain, so the other profiles are already authenticated.

شغّل كل ملف تعريف مرة واحدة بـ CLAUDE_CONFIG_DIR الخاص به ونفّذ /login. التفصيلة الأساسية: إذا كان كل ملف تعريف يستخدم الحساب نفسه، فأنت تسجّل الدخول مرة واحدة فقط — يحفظ macOS بيانات الاعتماد في مدخل Keychain مشترك واحد، وبذلك يُوثَّق كل ملف تعريف آخر تلقائيًا.

حسابات مختلفة لكل ملف تعريف هو المسار الأصعب: مدخل Keychain المشترك ذاك يحمل تسجيل دخول واحدًا، لذا فإن إدخال حساب ثانٍ إلى ملف تعريف آخر قد يطمس الأول. إذا كانت هذه حالتك، فاتّبع الشرح المخصّص في تشغيل حسابَي Claude على جهاز واحد، وتحقّق من عزل بيانات الاعتماد على نسختك من Claude Code قبل أن تعتمد عليه.

٣. الـ Symlink والمنتقي

# personal becomes the default target of ~/.claude (back-compat)
ln -s ~/.config/claude-profiles/personal ~/.claude

# add the claude() gum picker from the architecture section to ~/.zshrc, then:
source ~/.zshrc
claude        # ← now shows the profile menu on every launch

وجّه ~/.claude إلى ملف التعريف الشخصي كي يستمر كل ما يثبّت هذا المسار بشكل صلب في العمل، ثم ضَع منتقي gum الخاص بدالة claude() من قسم البنية أعلاه داخل ~/.zshrc. بعد إعادة التحميل يعرض claude قائمة الملفات عند كل تشغيل — الحالة النهائية نفسها كإعداد الترحيل، لكن مبنية من جديد.

٤. نسّق MCP كل ملف تعريف

أخيرًا، امنح كل ملف تعريف الأدوات التي ينبغي أن يراها فقط: عيّن disableClaudeAiConnectors: true في settings.json الخاص بذلك الملف، وأضف ما يحتاجه عبر claude mcp add، تمامًا كما في قسم الموصّلات أعلاه. هذا ما يحوّل عشرة ملفات تعريف قابلة للتبديل إلى عشرة مصمّمة لغرض محدّد.

سكربت الترحيل

لكل من يقرأ هذا ويريد الانتقال عن المخطّط القديم. أكثر الخطوات حرجًا هي الثانية: تدمج ~/.claude.json من جذر الـ home مع ما هو موجود أصلًا في الملف الشخصي، جامعةً قائمتَي mcpServers. بدون هذه الخطوة يفقد الملف كلًّا من MCP الخاصة به وكامل حالته الحيّة.

# 1. Move existing dotfolders into a new XDG-style parent.
#    APFS mv is an inode rename — safe even if claude --resume is open in
#    another terminal, file descriptors stay alive on the same inode.
mkdir -p ~/.config/claude-profiles
mv ~/.claude          ~/.config/claude-profiles/personal
mv ~/.claude-promova  ~/.config/claude-profiles/promova   # rename as needed

# 2. CRITICAL: merge ~/.claude.json (the live state — likely 100+ KB) into
#    the personal profile, unioning mcpServers so no MCP is dropped.
jq -s '.[0] * {mcpServers: (.[0].mcpServers + .[1].mcpServers)}' \
  ~/.claude.json \
  ~/.config/claude-profiles/personal/.claude.json \
  > /tmp/personal-merged.json
mv /tmp/personal-merged.json ~/.config/claude-profiles/personal/.claude.json

# 3. Fix permissions — jq+mv inherits umask (likely 644), but this file
#    holds OAuth tokens. Tighten to 600 immediately.
chmod 600 ~/.config/claude-profiles/personal/.claude.json

# 4. Back up the orphaned home-root file (delete once verified)
mv ~/.claude.json ~/.claude.json.migrated.bak

# 5. Symlink for backward compatibility (statusline configs, IDE plugins,
#    anything that hardcodes ~/.claude/ keeps working unchanged)
ln -s ~/.config/claude-profiles/personal ~/.claude

الخطوة الثالثة عن الأذونات أمر مهم بذاته. jq | mv ينشئ ملفًا بـ umask 644 (قابل للقراءة من الجميع). وفيه رموز OAuth. chmod 600 فور الدمج إلزامي.

بعد الترحيل — أغلق كل جلسات Claude النشطة وأعد فتحها، وأعد تحميل الـ shell (source ~/.zshrc أو طرفية جديدة)، وشغّل claude، واختر ملفًا، وتحقّق عبر claude mcp list من وجود كل MCP في مكانها. إن كان كل شيء جيدًا — احذف ~/.claude.json.migrated.bak. وإن كان ثمة خلل — التراجع بسيط: mv ~/.claude.json.migrated.bak ~/.claude.json وإزالة الـ symlink.

إضافة: موصّلات MCP لكل ملف تعريف (حين تشاركها مؤسستك)

تفتح البنية أعلاه محورًا ثانيًا للعزل — وقد صار الأمر الذي أستخدمه فعليًا أكثر من غيره. إذا كان حساب Claude الخاص بك تابعًا لمؤسسة، فبإمكان المؤسسة توزيع مجموعة مشتركة من موصّلات MCP البعيدة (Figma، متتبّع تذاكر، خلفية للمقاييس، بوابة قاعدة بيانات، نظام CMS…). يجلب Claude Code تلقائيًا كل موصّل فعّلته المؤسسة داخل كل جلسة، لأنها مرتبطة بالحساب لا بالمجلد الذي شغّلت منه.

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

عطّل الجلب التلقائي ثم نسّق

الرافعة إعداد واحد فقط، disableClaudeAiConnectors (Claude Code v2.1.182+). يعيش في أي نطاق للإعدادات — بما في ذلك settings.json الخاص بملف التعريف نفسه — لذا فهو لكل CLAUDE_CONFIG_DIR. عيّنه إلى true فيتوقّف ذلك الملف عن جلب موصّلات المؤسسة تلقائيًا تمامًا:

{
  "disableClaudeAiConnectors": true
}

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

# add back only what this profile uses — writes to the profile's own .claude.json
claude mcp add --scope user --transport http figma  https://<your-figma-connector>/mcp
claude mcp add --scope user --transport http linear https://<your-linear-connector>/mcp

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

اختبرته قبل أن أثق به

لم أرد أن آخذ كلام التوثيق كمسلّمة، لذا أجريت اختبار A/B نظيفًا على ملف تعريف واحد — الحساب نفسه، ورمز OAuth نفسه، والفرق الوحيد هو ذلك الـ settings.json:

profile WITHOUT the flag
  /mcp → Figma, Linear, Grafana, Postgres, Notion, Sentry, …   (entire org catalog)

same account, profile WITH  disableClaudeAiConnectors: true
  /mcp → (nothing auto-loaded)

…then  claude mcp add  Figma + Linear
  /mcp → Figma, Linear                                         (exactly the curated subset)

يفعل بالضبط ما يدّعيه. تحفّظان يستحقان المعرفة قبل أن تعتمد عليه:

• إعادة إضافة موصّل OAuth تحتاج تسجيل دخول تفاعلي واحدًا. الموصّلات التي توثّق بمفتاح داخل الـ URL تعود تلقائيًا بالكامل عبر claude mcp add. أما الموصّلات خلف OAuth فتطلب توثيقًا واحدًا عبر المتصفح في أول مرة تستخدمها فيها ضمن ذلك الملف.
• claude mcp list لا يعرض موصّلات المؤسسة إطلاقًا — بل الخوادم المعرّفة محليًا والمُضافة صراحةً فقط. أما المجلوبة تلقائيًا فلا تظهر إلا داخل جلسة حيّة عبر /mcp. لا تفزع حين يبدو mcp list خاليًا منها.

ما الذي تحصل عليه

• مجلد أب واحد بدل مجلدَي نقطة في $HOME — متوافق مع XDG
• يحفظ الـ symlink التوافق مع كل ما يثبّت ~/.claude/ بشكل صلب
• كل ملف تعريف قائم بذاته — حالته الكاملة وMCP الخاصة به تعيش في .claude.json الخاص به
• مصدر واحد للحقيقة لكل ملف تعريف — لا مزيد من إعداد يتيم في جذر الـ home ينحرف بصمت عن إعداد الملف
• البيانات الحساسة (oauthAccount، الرموز) مضمون لها أذونات 600
• تأكيد بصري للملف النشط عند كل تشغيل — يستحيل أن تنسى أيّ ملف نشط
• إضافة ملف تعريف ثالث = إضافة سطر واحد إلى case داخل الدالة، لا استنساخ alias جديد وتذكّر اسمه

أين يقصّر

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

• gum اعتمادية إضافية (brew install gum، نحو 13 ميغابايت). إن كنت لا تريد تثبيتها إطلاقًا — ارجع إلى select في zsh أو read بسيط. يعمل، لكنه لا يبدو بالجمال نفسه ولا تنقّل بالأسهم فيه.
• ضغطة Enter واحدة عند كل تشغيل. لمن يشعلون claude عشرات المرات يوميًا، قد يصير مزعجًا. البديل في الأسفل (direnv).
• الـ symlink ~/.claude → personal يجعل personal هو الافتراضي. إن أردت ملف العمل افتراضيًا، عليك إعادة توجيه الـ symlink (ln -sf). ليس صعبًا، لكنه ليس «انسه ولا شيء ينكسر».
• قد ينكسر الـ symlink نظريًا إن أعادت أداةٌ ما كتابة ~/.claude.json ذرّيًا عبر نمط temp+rename (write-file-atomic). عمليًا لا يفعل Claude Code ذلك بنفسه، لكن إن ثبّتّ مكوّنات طرف ثالث — تحقّق.
• إن كان لديك حسابات Anthropic مختلفة على ملفات مختلفة بخطط مختلفة — فقد يكون هناك تأخّر دون الثانية بعد التبديل بينما يزامن Claude Code حالة OAuth. في استخدامي غير ملحوظ، لكنه ليس صفرًا.

بدائل نظرت فيها

direnv — يعيّن CLAUDE_CONFIG_DIR تلقائيًا بناءً على .envrc في جذر كل مشروع. صفر تفاعل، صفر نقرات. العيب: عليك وضع .envrc في كل جذر عمل، وإن شغّلت claude في مجلد غير معروف، تحصل على الملف الافتراضي (وقد لا يكون الذي تريده). لمن يعيشون داخل مجموعة صغيرة من جذور العمل ويريدون ألا ينقروا شيئًا أبدًا، فإن direnv أفضل فعلًا.

التبديل القائم على الـ symlink (ملف نشط واحد عبر إعادة توجيه symlink الـ ~/.claude) نظرت فيه أيضًا وأسقطته فورًا. لا يمكنك أن تفتح طرفيتين بملفين مختلفين في آنٍ واحد — فـ «الحالي» العام واحد فقط. بالنسبة لي هذا مانع قاطع.

الخلاصة

v2 ليست مجرد تجربة استخدام أفضل فوق v1. إنها إقرار بأن لدى Claude Code سلوكًا معماريًا شاذًّا (~/.claude.json بوصفه ملفًا منفصلًا في جذر الـ home، تكتبه أوامر --scope user بغضّ النظر عن CLAUDE_CONFIG_DIR) عليك أن تحسب حسابها إن أردت عزلًا حقيقيًا بين الملفات. الأسلوب الأول (~/.claude + ~/.claude-promova + alias) نجح بنسبة 80%، لكن الـ 20% الباقية ظهرت في صورة انحراف صامت للحالة بين الملفات. الآن صار محسوبًا. إن كنت تبدأ للتوّ — ابدأ بـ v2 مباشرةً. وإن كنت أصلًا على v1 — سكربت الترحيل في الأعلى، والنقل يستغرق خمس دقائق ولا يكسر شيئًا (دمج jq بالذات هو الخطوة التي تنقذك من فقدان الحالة).

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

لماذا يكذب الوكلاء العامّون

نماذج LLM أدوات تتنبأ بالرمز التالي. حين يطلب المُوجِّه دورين — ابنِ X وتحقق من X — ينهي النموذج الدور الأول، ثم يتنبأ بالشكل الذي سيبدو عليه ناتج الدور الثاني، دون أن ينفّذه فعلاً. التحقق الذاتي ضعيف بنيوياً: السياق نفسه، النموذج نفسه، النقاط العمياء نفسها. نجاح التحقق مرتبط بـنجاح البناء، فهما يفشلان معاً.

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

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

القاعدة 1: وكيل واحد، تخصص واحد

قسّم العمل إلى وكلاء منفصلين بسياقات منفصلة. لكل وكيل مسؤولية واحدة ومجموعة أدوات ضيّقة. يتحول سير العمل بأكمله إلى سباق تتابع بدل وكيل واحد يدور في حلقات:

• وكيل البناء (Builder): يأخذ المواصفة، ويكتب الشيفرة. هذه مهمته كلها. لديه Read وEdit وWrite وBash.
• وكيل المراجعة (Reviewer): يأخذ المواصفة مع الـ diff، ويفحص معايير القبول. سياق جديد. لا علم له بـكيف كُتبت الشيفرة، بل بما نتج فقط. لديه Bash وRead وGrep وGlob — ولا أدوات كتابة على الإطلاق.
• وكيل التحليلات (Analytics): يجيب عن أسئلة البيانات ببناء الاستعلامات وتشغيلها. Bash فقط. لا يمكنه بلوغ الإجابة دون تشغيل أمر حقيقي.
• المنسّق (Orchestrator): الجلسة الرئيسية التي تُرسل كل وكيل بدوره ولا تطلب من وكيل قط أن يؤدي عمل وكيل آخر.

مثال ملموس: تنفيذ واجهة مستخدم مع فحص بصري مقابل ماكيت Figma. يكتب وكيل البناء المكونات ويُودع الـ diff. ثم يستدعي المنسّق وكيل المراجعة مزوّداً إياه برابط التصميم والـ diff ومعايير قبول صريحة. يشغّل وكيل المراجعة أداة Playwright، ويلتقط لقطات الشاشة، ويقارنها بالمرجع، ويعيد PASS أو FAIL مع مسارات لقطات الشاشة الفعلية وفروق البكسل. لا يقترب وكيل البناء من خطوة التحقق أبداً، وهذا بالضبط ما يجعل التحقق حقيقياً.

النمط المضاد هو الوكيل العملاق: مُوجِّه واحد يقول ابنِ هذه الواجهة وتأكد من مطابقتها للماكيت. أضمن لك أنه سيبلّغ بأن كل شيء مطابق. لن يكون كذلك. سردية لقد تحققت ليست إلا أرجح سلسلة رموز تأتي بعد لقد بنيته.

القاعدة 2: الـ shell بدل المُوجِّه، دائماً

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

• العدّ: wc -l logs.txt حقيقة. أما هناك نحو 47 سطر سجل صادرة عن نموذج فهي هلوسة.
• التحليلات: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". وليس قدّر الحجم.
• الاختبارات: pnpm test --reporter=json | jq '.numFailedTests'. وليس لخّص ما فشل.
• حالة Git: git rev-list --count main..HEAD، git diff --stat. وليس عُدّ الإيداعات أو صِف التغييرات.

حين تستوعب هذا، تبدأ بملاحظة كل موضع كان الوكيل فيه على وشك اختلاق رقم. يبدو أن هناك قرابة 200 سجل... — لا. شغّل SELECT count(*). معظم الاختبارات تمر... — لا. شغّل حزمة الاختبارات، وحلّل الـ JSON. النموذج بارع في بناء الأمر. لكنه غير موثوق في أن يكون هو الأمر نفسه.

أنماط فشل واجهتها فعلاً

هذه ليست حالات افتراضية. كلّ منها كلّفني وقتاً حقيقياً قبل أن أغيّر النمط:

• تحقق وهمي. قال الوكيل فحصتُ الأقسام الـ 14 كلها مقابل الماكيت. لم يفتح الماكيت. لم يلتقط لقطة شاشة. كان الفحص خطوة مهلوَسة في السرد.
• أرقام خاطئة بثقة. طلبت المستخدمين النشطين شهرياً من بيانات التحليلات. فحصلت على رقم مخطئ بنحو 3 أضعاف. استوفى النموذج القيمة من صفوف عيّنة بدل تشغيل الاستعلام الفعلي.
• تغييرات ملفات مختلقة. قال الوكيل حدّثتُ config/feature-flags.json. لم يفعل. كان قد نوى ذلك فحسب. وكان git diff فارغاً.
• تشغيلات اختبار زائفة. كل الاختبارات تمر. لم يُنفَّذ أي اختبار. لم يستدعِ الوكيل مشغّل الاختبارات قط، بل تنبأ بالشكل الذي كان سيبدو عليه ناتج المشغّل.

الأربعة كلها تُحلّ بالقاعدتين نفسيهما: قسّم الوكيل، وادفع إلى الـ shell. لا يملك وكيل المراجعة Write، فلا يمكنه تزييف تعديل الملفات. ولا يملك وكيل التحليلات سوى Bash، فلا يمكنه إعادة رقم لم يأتِ من استعلام. الاستحالة البنيوية تغلب النوايا الحسنة في كل مرة.

كيف تُبنى هذه في Claude Code

يدعم Claude Code الوكلاء الفرعيين المعرّفين في .claude/agents/*.md. يعلن كل ملف وكيل عن اسم ووصف ومجموعة أدوات مسموحة ومُوجِّه النظام. يستدعيهم المنسّق (جلستك الرئيسية) عبر أداة Agent. وهذا نوع التعريف الذي أستخدمه لوكيل المراجعة — قصير، ضيّق، وعاجز عملياً عن كتابة الشيفرة:

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

لاحظ مجموعة الأدوات: Bash, Read, Grep, Glob. لا Write، ولا Edit، ولا Agent. يستطيع وكيل المراجعة تشغيل الأوامر وقراءة الملفات والبحث عن الأنماط — لا غير. وإن حاول تمرير diff مهلوَس على أنه مُتحقَّق منه، فإن شكل استدعاءات أدواته يفضح الأمر: لم تكن هناك أي فحوصات حقيقية. يمكنك تدقيق استدعاءات الأدوات ورؤية ما جرى فحصه بالضبط.

نمط التنسيق: تستدعي الجلسة الرئيسية وكيل البناء ← تنتظر ← تشغّل هي نفسها git diff لالتقاط التغيير الفعلي ← تستدعي وكيل المراجعة بالمواصفة والـ diff ← تقرأ الحكم. لا تطلب الجلسة الرئيسية قط من وكيل واحد أن يؤدي الدورين. قيود الأدوات أقوى من تعليمات المُوجِّه: لا تزيّف التحقق أمنية. وأما عدم امتلاك Write فحقيقة.

أنماط مضادة يجب التخلص منها

أشياء أراها في المُوجِّهات ولا تفعل شيئاً — أو أسوأ، تمنح إحساساً زائفاً بالأمان:

• كن حذراً ودقّق في عملك مرة أخرى. لا يولّد أي سلوك إضافي. النموذج ينتج أصلاً ما يبدو كعمل دقيق.
• تأكد من أنك تحققت فعلاً. كلمة فعلاً لا تضيف دلالة يستطيع النموذج التصرف بناءً عليها. سيدّعي فعلاً أنه تحقق.
• لا تهلوس. نكتة رائجة في هندسة المُوجِّهات. الهلوسة ليست مفتاحاً يستطيع النموذج إطفاءه.
• الثقة بالوكيل في الأرقام الصغيرة. في الأرقام الصغيرة تحديداً يكذب بأشد ثقة. لا يوجد حدّ أدنى للصدق.
• إضافة قواعد أكثر إلى المُوجِّه لفرض الصدق. الإصلاحات البنيوية (التقسيم + الـ shell) تغلب تعديلات الأوامر في كل مرة. إن كانت قاعدة تحتاج إلى إنفاذ، فرمّزها في صلاحيات الأدوات، لا في لغة بشرية.

إن كانت استراتيجيتك لالتقاط الهلوسات هي صياغة أشد توكيداً، فليست لديك استراتيجية. لديك أمنية.

النموذج الذهني

الوكيل ليس زميلاً. إنه دالة: prompt → tokens. الدالة بارعة في كتابة الشيفرة وسيئة في التأمل الذاتي حول ما إذا فعلت الصواب. عامِل ادّعاءاته عن عمله بوصفها فرضية. الـ diff، ورمز الخروج، ولقطة الشاشة، وعدد الصفوف — تلك هي الأدلة. أما ملخّص نهاية الدور فهو السطح الأكثر عرضة للكذب في المنظومة كلها.

التخصص هو تأمينك ضد انحراف السرد. الـ shell هو مصدر الحقيقة الوحيد لديك. وكيل البناء يكتب. وكيل المراجعة يفحص. والـ Bash يقرّر.

الخلاصة

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

المشكلة

يُخزّن Claude Code كل شيء في ~/.claude افتراضيًا — رمز OAuth، وسجل المحادثات، وملف CLAUDE.md العام، وذاكرة المشاريع، وإعدادات خوادم MCP، والتفضيلات. وعندما يكون لديك حسابان، فأنت بحاجة إلى عالمين منفصلين تمامًا:

• الحساب الشخصي: اشتراك Max/Pro الخاص بك، وملف CLAUDE.md شخصي بتفضيلاتك، وخوادم MCP الخاصة بك (Obsidian، أدوات شخصية)
• حساب الشركة: خطة تديرها الشركة، وملف CLAUDE.md للعمل بتعليمات تكامل Jira/Slack، وخوادم MCP الخاصة بالشركة
• جلسات OAuth مختلفة: لا يمكنك تسجيل الدخول إلى حسابين في دليل الإعدادات نفسه
• ذاكرة مشاريع مختلفة: لا تريد أن يتسرّب سياق مشاريع العمل إلى الجلسات الشخصية والعكس صحيح

تسجيل الخروج ثم الدخول من جديد في كل مرة تُبدّل فيها السياق ليس خيارًا مطروحًا. فأنت تفقد حالة الجلسة، والأمر مُرهق ببساطة.

الحل: CLAUDE_CONFIG_DIR

يحترم Claude Code متغيّر بيئة واحدًا: CLAUDE_CONFIG_DIR. اضبطه على أي مسار، وسيستخدم Claude ذلك الدليل بدلًا من ~/.claude لكل شيء — المصادقة والسجل والإعدادات والذاكرة، كل ذلك. يستغرق الإعداد بأكمله 60 ثانية.

الخطوة 1: أنشئ دليل إعدادات ثانيًا

اختر اسمًا يناسب حالة استخدامك:

mkdir ~/.claude-work

هذا كل شيء. سيملأ Claude الدليل بالبنية اللازمة عند أول تشغيل.

الخطوة 2: صادِق على الحساب الثاني

شغّل Claude مرة واحدة بدليل الإعدادات الجديد لتشغيل عملية تسجيل الدخول عبر OAuth:

CLAUDE_CONFIG_DIR=~/.claude-work claude

سيفتح هذا متصفحك. سجّل الدخول بحساب الشركة. يُخزَّن رمز OAuth في ~/.claude-work — منفصلًا تمامًا عن جلستك الشخصية في ~/.claude.

الخطوة 3: أضِف alias في الـ shell

أضِف هذا إلى إعدادات الـ shell لديك حتى لا تضطر إلى تذكّر المتغيّر:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

أعِد تحميل الـ shell:

source ~/.zshrc

ما الذي تحصل عليه

الآن لديك بيئتان معزولتان تمامًا من Claude:

• claude — يُشغَّل بحسابك الشخصي، وملف CLAUDE.md الشخصي، والذاكرة الشخصية
• claude-work — يُشغَّل بحساب الشركة، وملف CLAUDE.md الخاص بالعمل، وذاكرة منفصلة
• سجل معزول: محادثات العمل تبقى في العمل، والشخصية تبقى شخصية
• خوادم MCP منفصلة: خادم MCP لـ Obsidian vault الشخصي لا يظهر في جلسات العمل
• إعدادات مستقلة: أدوات مسموح بها مختلفة، ومستويات أذونات مختلفة، وتفضيلات نماذج مختلفة لكل حساب

كيف يعمل من الداخل

دليل الإعدادات هو المصدر الوحيد للحقيقة بشأن حالة Claude Code. وإليك ما يوجد داخل كل واحد منها:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

عندما تُشغّل claude-work، يقرأ Claude كل شيء من ~/.claude-work. وهو لا يدرك أصلًا وجود ~/.claude. النسختان مستقلتان تمامًا — بل يمكنك تشغيلهما في آنٍ واحد في علامتي تبويب مختلفتين في الطرفية.

التوسّع إلى N من الحسابات

يمتد هذا النمط إلى أي عدد من الحسابات. مستقل لديه عدة عملاء؟ أضِف المزيد من الـ aliases:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

يحصل كل alias على دليل إعدادات خاص به، وجلسة OAuth خاصة به، وملف CLAUDE.md خاص به بتعليمات مخصّصة للعميل. يمكن أن يكون لديك ملف CLAUDE.md للعميل A يعرف أعراف قاعدة الكود ومشروع Jira الخاص به، وآخر مختلف تمامًا للعميل B.

نصائح عملية

• سمِّ أدلّتك بوضوح: ~/.claude-work، ~/.claude-clientname — ستشكر نفسك عندما يصبح لديك ثلاثة أو أربعة منها
• اكتب ملف CLAUDE.md مخصّصًا لكل واحد: يمكن أن يتضمّن ملف العمل تعليمات خاصة بالشركة (كيفية إنشاء تذاكر Jira، وقنوات Slack المرجعية، وإجراءات النشر). ويبقى ملفك الشخصي مقتضبًا.
• خوادم MCP مختلفة لكل حساب: اضبط أدوات العمل (Jira MCP، Slack MCP، وواجهات API الداخلية) في إعدادات العمل فقط. وأبقِ إعداداتك الشخصية نظيفة.
• تحقّق من الحساب النشط: شغّل claude config list داخل جلسة إن كنت غير متأكد من الحساب الذي أنت فيه — فهو يعرض مسار دليل الإعدادات

أين يقصُر هذا الأسلوب

CLAUDE_CONFIG_DIR يعزل حسب الحساب، لا حسب المشروع. فداخل ملف تعريف واحد، يرى Claude كل خادم MCP سجّلته يومًا لذلك الحساب — عبر جميع مشاريعك. وللاستخدام الشخصي الفردي، يكون هذا مقبولًا عادةً. لكن ما إن يصبح لديك عدة مشاريع حرجة للإنتاج تحت حساب واحد، خصوصًا في مجالات متداخلة كالفوترة أو أدوات الإدارة أو البنية التحتية، حتى يظهر خطر ملموس عابر للمشاريع: قد يستدعي مساعد الذكاء الاصطناعي أداةً من المشروع A أثناء عمله على المشروع B، لا سيما عندما يكشف كلاهما عمليات متشابهة الأسماء.

نمط ملفات التعريف يجيب عن سؤال في أي حساب أنا؟. لكنه لا يجيب عن سؤال أدوات أي مشروع ينبغي أن تكون نشطة الآن؟. وللأعمال الأعلى مخاطرةً، أضِف طبقة عزل ثانية فوق التقسيم حسب الحساب:

• ملف تعريف واحد لكل مشروع حرج للإنتاج، لا لكل حساب فحسب: بدلًا من ~/.claude و~/.claude-work، أنشئ ~/.claude-work-billing و~/.claude-work-admin. يرى كل ملف تعريف خوادم MCP التي يحتاجها فعليًا فقط.
• MCP على مستوى المشروع عبر .mcp.json: ضع ملف .mcp.json في جذر المشروع يسرد خوادم MCP الخاصة بذلك المشروع فقط. يلتقطها Claude عند تشغيله من ذلك الدليل. أبقِ إعداداتك العامة في حدّها الأدنى — أدوات عامة فقط (ملاحظات، بحث)، دون أي نقاط نهاية إنتاجية.
• سمِّ خوادم MCP بلا لبس: تجنّب الأسماء العامة مثل admin وbilling وmcp-server. أضِف بادئة باسم المشروع: acme_billing_prod، acme_admin_stage. الاسم الوصفي يفرض توقّفًا لحظة أن يوشك شيء أن يُستدعى من السياق الخطأ.
• راجِع كل استدعاء لأداة MCP قبل الموافقة عليه: استدعاءات مثل *_create_* و*_delete_* و*_charge_* تستحق نظرة ثانية متأنّية. فأي سرعة تكسبها من الموافقة التلقائية الشاملة تتبخّر في أول مرة تنطلق فيها أداة من المشروع الخطأ نحو الإنتاج.

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

الخلاصة

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

ما هو MCP ولماذا الأمر ليس بهذه البساطة

MCP (Model Context Protocol) بروتوكول مفتوح من Anthropic يتيح لـ Claude الاتصال بأدوات وبيانات خارجية. المبدأ بسيط: يعمل خادم محلي يعرض «أدوات» (tools)، ويستدعيها Claude أثناء المحادثة.

بالنسبة إلى Obsidian، توجد نظريًا وفرة من خوادم MCP. أما عمليًا — فلكلٍّ منها مشاكله الخاصة.

المشكلة الأساسية في منظومة Obsidian: إنّ Obsidian تطبيق مغلق بلا MCP رسمي. سدّ المجتمع الفجوة، لكن كل تنفيذ يسير في طريقه الخاص، ولا يحظى أيٌّ منها بـ«مباركة رسمية».

المحاولة 1: MarkusPfundstein/mcp-obsidian

أول أداة تظهر عند البحث. 3400 نجمة على GitHub، وحاضرة في كل الدروس التعليمية. تبدو خيارًا آمنًا.

كيف تعمل: خادم Python مبني على إضافة Local REST API في Obsidian. يتواصل الخادم مع الإضافة عبر HTTPS، وتنفّذ الإضافة العمليات عبر Obsidian API.

ما الذي حدث بشكل خاطئ

• لم يُحدَّث منذ 17 شهرًا
• 85 مشكلة (issue) مفتوحة
• لا يوجد move/rename — فقط read وwrite وappend وdelete
• لدى Local REST API خلل موثّق لفقدان البيانات: قد تقوم نقطة نهاية POST بالكتابة فوق ملف بصمت أثناء عملية append

لا يصلح لإعادة الهيكلة — نحتاج إلى نقل الملفات مع الحفاظ على الروابط. نمضي قُدُمًا.

المحاولة 2: aaronsb/obsidian-mcp-plugin

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

صعوبات الإعداد

• الإضافة ليست في الكتالوج الرسمي لـ Obsidian (طلب الدمج معلّق بأخطاء تحقّق)
• يجب التثبيت عبر BRAT (Beta Reviewers Auto-update Tool)
• لا يقبل Claude Desktop رمز Bearer مباشرة عبر الواجهة — ما أجبرني على تفعيل HTTPS في الإضافة
• الشهادة الموقّعة ذاتيًا (self-signed) لـ localhost تثير مشاكل ثقة

بعد كل هذه الحلول الالتفافية، تمكّنت أخيرًا من ربطها. اختبار أساسي — vault.move يعيد بالفعل كتابة [[wikilinks]]، ويعمل كما هو متوقّع.

ما الذي حدث بشكل خاطئ في الإنتاج

عندما بدأت إعادة الهيكلة على نطاق واسع (سحب وإفلات لعشرات المجلدات في Obsidian + عمليات MCP متزامنة)، تجمّد الخادم لأكثر من 4 دقائق. السبب: الإضافة تعمل داخل Obsidian. عندما يُعيد Obsidian فهرسة آلاف الملفات بعد تغيير هيكلي واسع، تُحجَب الإضافة معه.

الخلاصة: الاعتماد على نسخة Obsidian مفتوحة وعلى فهرسها قاتل للعمليات المجمّعة.

المحاولة 3: @bitbonsai/mcpvault

منطقيًا — نحتاج خادمًا لا يعتمد على Obsidian. يعمل مباشرة مع الملفات على القرص. @bitbonsai/mcpvault — موصى به في كثير من المراجعات. وصول مباشر إلى نظام الملفات، وإعداد بسيط (npx @bitbonsai/mcpvault@latest /path/to/vault)، و14 أداة. لا حاجة حتى لإبقاء Obsidian مفتوحًا.

قبل التثبيت، تحقّقت من أمر حاسم واحد — هل تُحدَّث روابط الويكي عند النقل. عثرت على مراجعة أحد المستخدمين:

موصل نظام الملفات لا يعرف أنه داخل Obsidian — يرى مجلدًا من ملفات <code>.md</code> وحسب. لا يعرف أن أسماء الملفات تحمل وزنًا دلاليًا، وأن كل <code>[[wikilink]]</code> سينكسر لحظة إعادة التسمية أو النقل. التحديث التلقائي للروابط يعمل فقط عندما تحدث إعادة التسمية من داخل التطبيق. تعلّمت هذا بعدما طلبت من Claude تنظيف أسماء الملفات، فعُدت إلى لوحة تحكّم نصف روابطها مكسور.

تأكّد ذلك في توثيق mcpvault نفسه: طلب الدمج #101 (wiki link resolution) قيد المراجعة، ولم يُدمج بعد. أي أن النقل عبر mcpvault سيكسر نصف الـ vault. لا يصلح.

المحاولة 4: VaultForge (النهائية)

blacksmithers/vaultforge — مبني خصّيصًا لوكلاء الذكاء الاصطناعي الذين يقومون بإعادة الهيكلة.

صحيح معماريًا

• نظام ملفات مباشر — لا يعتمد على Obsidian
• محرّك wikilink خاص به — يُنفّذ منطق تحليل [[wikilink]] الذي يُحدّث كل الصيغ (stem، المسار الكامل، alias، embed)
• تشغيل تجريبي (dry run) افتراضيًا في كل العمليات المدمّرة — يُظهر أولًا ما سيتغيّر، ثم تؤكّد أنت
• 27 أداة مقابل 8–14 لدى المنافسين: batch_rename وupdate_links وbacklinks (تحليل الأثر) وprune_empty_dirs وfrontmatter وsmart_search (BM25) وvault_themes (تجميع TF-IDF)
• رخصة MIT، TypeScript، صفر تبعيات فرعية
• تثبيت في 30 ثانية عبر .mcpb (امتداد بنقرة واحدة لـ Claude Desktop)

اختبار أمان على ملفات معزولة

أنشأت 4 ملفات اختبار بروابط متقاطعة — روابط stem، وروابط بأسماء بديلة (alias)، وروابط بمسار كامل. أنقل ملفًا واحدًا إلى مجلد فرعي:

delta.md → subfolder/delta-renamed.md

أظهر VaultForge تشغيلًا تجريبيًا: «ستُعاد تسمية ملف واحد، وستُحدَّث 3 روابط». ثم نفّذت العملية فعليًا.

تحقّقت بعد ذلك — حُدِّثت أنواع الروابط الثلاثة جميعها بشكل صحيح. هذا بالضبط ما كان ينقص كل الأدوات السابقة.

كيفية تثبيت VaultForge — التعليمات النهائية

إذا كان لديك macOS و Claude Desktop:

الخطوة 1

نزّل ملف .mcpb:

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

الخطوة 2

سيفتح Claude Desktop مربّع حوار تثبيت الامتداد. أدخِل المسار المطلق إلى الـ vault الخاص بك — بلا شرطات مائلة عكسية، وبمسافات عادية:

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

الخطوة 3

انقر على Save. سيضيف Claude Desktop الامتداد إلى ملف الإعداد تلقائيًا. لا حاجة لإعادة التشغيل — تُلتقط امتدادات .mcpb تلقائيًا.

الخطوة 4

تحقّق: في محادثة جديدة اسأل: «What is the status of my Obsidian vault?» — يُفترض أن يُعيد شيئًا مثل totalFiles: 416, totalDirs: 135, ...

ما تعلّمته عن منظومة MCP في Obsidian

أولًا، «الأكثر شهرة» لا يعني «الذي يعمل». يملك MarkusPfundstein/mcp-obsidian عددًا يبلغ 3400 نجمة وهو التوصية الافتراضية، لكنه قديم وتنقصه عمليات أساسية.

ثانيًا، للإضافة الأصلية كُلفة خفيّة. بدت إضافة aaronsb مثالية — رسم بياني، Dataview، نقل أصلي. لكن الاعتماد على نسخة Obsidian قيد التشغيل وعلى فهرسها يجعلها غير صالحة للعمليات المجمّعة الجادّة.

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

رابعًا، اختبِر على بيانات معزولة. قبل أن تأتمن أي أداة على إعادة هيكلة على نطاق واسع — أنشئ مجلد اختبار فيه 4–5 ملفات بروابط متقاطعة وشاهد ما يحدث. خمس دقائق من الاختبار توفّر ساعات من الاستعادة من النسخة الاحتياطية.

خامسًا، احتفظ بنسخة git احتياطية للـ vault الخاص بك. الأهم من كل شيء. مجرّد git init واحد داخل الـ vault وعمليات commit دورية — هذا هو التأمين ضد أي خطأ من وكيل ذكاء اصطناعي أو أداة. إذا انكسر شيء ما — يُعيد git reset --hard كل شيء إلى ما كان.

الخلاصة

استغرقت الرحلة عدة ساعات وثلاث محاولات فاشلة. تبدو البنية النهائية هكذا:

• VaultForge — أداة العمل الرئيسية. نظام ملفات مباشر + محرّك wikilink خاص + 27 أداة = إعادة هيكلة مستقرّة على أي نطاق.
• Git — إدارة إصدارات الـ vault. تراجُع مجاني عن أي خطأ.

الآن يمكنني فعل ما بدأ كل هذا من أجله: أن أطلب من Claude ترتيب 400 ملاحظة وفق بنية PARA سليمة، ودمج النسخ المكررة، وإضافة frontmatter، وبناء خرائط MOC. كل عملية آمنة، والروابط محفوظة، والتشغيل التجريبي يُظهر ما سيحدث قبل أن يتغيّر أي شيء.

إن كنت أنت أيضًا تنظر إلى Obsidian المزدحم لديك وتريد مساعدًا ذكيًا — ابدأ فورًا بـ VaultForge. لا تُكرّر مساري عبر مشاريع ميتة وإضافات تجريبية وخوادم نظام ملفات بلا منطق روابط.

ماذا لو كان كل ثقب أسود انفجارًا عظيمًا لكونٍ جديد؟ يستكشف هذا المقال فكرة أن كوننا قد يكون مجرّد عقدة واحدة في شجرةٍ عوديّة لا نهائية — حيث تلد الثقوب السوداء أكوانًا فرعية، وتعود الطاقة أدراجها عبر إشعاع هوكينغ، وقد صُمّمت قوانين الفيزياء الأساسية عمدًا لتجعل التواصل بين الأكوان مستحيلًا.

الثقب الأسود = كون

جاءت الفكرة في لحظة تأمّل: يتشكّل الثقب الأسود حين تتركّز كتلةٌ وضغطٌ كافيان في نقطة واحدة. وتلك المتفردة — كثافة لا متناهية، وانحناءٌ لا متناهٍ — تشبه على نحوٍ مريب الظروف التي نصف بها الانفجار العظيم.

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

قد يحتوي كل ثقب أسود في كوننا على كون. وقد يكون كوننا موجودًا داخل ثقب أسود لكونٍ أمّ.

لماذا لا تستطيع الأكوان أن يتواصل بعضها مع بعض

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

ليس هذا قيدًا تقنيًا قد نتجاوزه بتقنيةٍ أفضل. إنه مغروسٌ في هندسة الزمكان نفسها. فالأكوان معزولة بعضها عن بعض عزلًا جوهريًا — لا بالمسافة، بل ببنية الزمن.

دورة الطاقة: الاقتراض والردّ

لكن الطاقة لا تُفقد. فإشعاع هوكينغ — العملية الكمّية التي تتبخّر بها الثقوب السوداء ببطء — يخلق دورةً مدهشة:

1. يُنشئ كونٌ أمّ ثقبًا أسود، ناقلًا الطاقة إلى كونٍ فرعي
2. يعيش الكون الفرعي دورة حياته الكاملة على مدى تريليونات السنين
3. يتبخّر الثقب الأسود ببطء، رادًّا الطاقة إلى الكون الأمّ عبر إشعاع هوكينغ
4. يستعيد الكون الأمّ طاقته — مع فائدة

وتلك «الفائدة» مثيرة للدهشة: يعتقد الفيزيائيون الآن أن إشعاع هوكينغ يحفظ المعلومات. فالكون الأمّ لا يستعيد طاقةً فارغة فحسب — بل يستعيد بصمةً لكل ما جرى في الداخل. كل نجمٍ تكوّن، وكل كوكب، وكل لحظة وعي — مُشفّرة في الإشعاع.

عوديّة حتى القاع

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

universe(energy)
  ├── creates black holes
  │     ├── universe(energy - n)
  │     │     ├── universe(energy - n - m)
  │     │     │     └── base case: not enough energy for black holes
  │     │     └── returns energy via Hawking radiation
  │     └── returns energy via Hawking radiation
  └── receives all energy back

صاغ الفيزيائي لي سمولين فكرةً مشابهة تحت اسم الانتقاء الطبيعي الكوني: تتكاثر الأكوان عبر الثقوب السوداء، ويحمل كل جيلٍ ثوابت فيزيائية مختلفة اختلافًا طفيفًا — مُحسَّنة عبر دوراتٍ لا تُحصى لإنتاج مزيدٍ من الثقوب السوداء، ومزيدٍ من الأكوان.

أين نحن في هذه الدورة؟

يبلغ عمر كوننا نحو 13.8 مليار سنة. يبدو هذا موغلًا في القِدم، لكن في سياق عمره الكامل، فإننا نشهد البداية المطلقة:

نحن موجودون عند نحو 0.00000000...01% من إجمالي عمر كوننا. فعصر النجوم — كل ما يمكننا رؤيته — ومضة عابرة في البداية المطلقة. أما القصة الحقيقية للكون فهي عصر الثقوب السوداء البطيء الصبور، وهي تُنشئ الأكوان الفرعية وتبخّرها.

مسألة الأبعاد الأعلى

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

في عام 1884، كتب إدوين آبوت فلاتلاند — قصةً عن كائناتٍ ثنائية الأبعاد عاجزة عن تصوّر بُعدٍ ثالث. فالكرة التي تمرّ عبر فلاتلاند تبدو دائرةً تكبر ثم تصغر. يستطيع «سكان فلاتلاند» وصفها رياضيًا، لكنهم لا يفهمون قط حقيقة ما يرونه. وقد نكون في الموقف ذاته تمامًا إزاء كوننا.

ما الوعي؟ ولماذا توجد التجربة الذاتية؟ سمّى ديفيد تشالمرز هذا «المشكلة الصعبة» — وقد يكون أقوى دليلٍ على أن شيئًا ما يعمل خارج مدى أبعادنا.

كل شيء مقفلٌ عند المستوى الأساسي

أشدّ ما يستوقفنا ليس أننا لا نعرف — بل أننا لا نقدر أن نعرف. فكل اتجاهٍ من اتجاهات البحث يصطدم بحاجزٍ أساسي:

• أتريد رؤية الكون الأمّ؟ محجوبٌ بأفق الحدث
• أتريد فهم الوعي؟ محجوب — فالنظام لا يستطيع تحليل نفسه تحليلًا كاملًا (مبرهنتا عدم الاكتمال لغودل)
• أتريد معرفة ما كان «قبلُ»؟ محجوب — فالزمن بدأ مع الانفجار العظيم
• أتريد إدراك الأبعاد الأعلى؟ محجوبٌ بالقيود الإدراكية لكائنٍ ثلاثي الأبعاد

يسمّي الفيلسوف كولن ماكغين هذا الانغلاق الإدراكي: بعض الأسئلة مغلقة أمام العقل البشري لا لنقص البيانات، بل بسبب بنية العقل نفسه. والفرق بين «لا نعرف بعد» و«لا نقدر أن نعرف» فرقٌ عميق.

الشيء الوحيد المتبقّي: تحسين الذات

إذا كان كل مخرجٍ محجوبًا بحكم التصميم — إن لم تستطع النظر إلى الخارج، ولا إلى الوراء، ولا إلى الأعلى — فلا يبقى إلا اتجاهٌ واحد: إلى الداخل. يبدو الكون مبنيًا عمدًا ليُرغم المرء على التركيز على ذاته.

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

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

المراجع

• لي سمولين — الانتقاء الطبيعي الكوني
• ستيفن هوكينغ — إشعاع هوكينغ
• ديفيد تشالمرز — المشكلة الصعبة للوعي
• إدوين آبوت — فلاتلاند: رواية أبعادٍ كثيرة (1884)
• كورت غودل — مبرهنتا عدم الاكتمال

بالنسبة للمواقع البسيطة — معارض الأعمال والمدونات وصفحات الهبوط ومواقع الأعمال الصغيرة — أصبح نظام إدارة المحتوى التقليدي عبئًا زائدًا لا لزوم له. صارت أدوات الذكاء الاصطناعي مثل Claude Code وCursor وGitHub Copilot قادرة الآن على تعديل قاعدة الكود مباشرةً، وفهم السياق، وترجمة المحتوى، ونشر التغييرات عبر git. طبقة التجريد التي كان يوفرها نظام إدارة المحتوى يجري استبدالها بواجهة أذكى: اللغة الطبيعية.

ضريبة نظام إدارة المحتوى التي تدفعها

كل نظام إدارة محتوى يأتي بتكلفة خفية. ليست رسوم الاشتراك فحسب — بل منظومة التعقيد الكاملة التي تلتف حول موقعك البسيط أصلًا:

• البنية التحتية: قاعدة بيانات لاستضافتها، وواجهة API لصيانتها، ولوحة تحكم لتأمينها. يشكّل WordPress وحده نحو 43% من الويب ونحو 90% من الهجمات الموجهة إلى أنظمة إدارة المحتوى.
• الأداء: توليد ديناميكي للصفحات، واستدعاءات API عند كل طلب، وإماهة بيانات نظام إدارة المحتوى من جهة العميل. معرض أعمالك المكوّن من 3 صفحات صار الآن بمعمارية منتج SaaS.
• الارتهان للمورّد: يعيش محتواك داخل مخطط قاعدة بيانات يملكها غيرك. الانتقال من Contentful إلى Sanity؟ ذاك مشروع كامل، لا مجرد تغيير في الإعدادات.
• تبديل السياق: تحرّر الكود في محرر IDE، ثم تنتقل إلى لوحة تحكم نظام إدارة المحتوى في المتصفح لتغيير عنوان. نموذجان ذهنيان مختلفان لما هو في جوهره العملية ذاتها.
• التكلفة: غالبًا ما تتوسّع أسعار أنظمة إدارة المحتوى من نوع headless مع عدد استدعاءات API أو مدخلات المحتوى. المدونة الشخصية لا تحتاج بنية محتوى بتكلفة 99 دولارًا شهريًا.

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

ما الذي تغيّر: الذكاء الاصطناعي يفهم كودك

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

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

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

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

أمثلة حقيقية من هذا الموقع

يدعم هذا الموقع 10 لغات، وفيه مدونة، ويولّد صور OG ديناميكيًا، وينتج خلاصات RSS وخرائط موقع. هكذا تبدو طبقة المحتوى — TypeScript خالص:

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

أشياء أفعلها بالذكاء الاصطناعي كانت تتطلّب تقليديًا نظام إدارة محتوى:

• إضافة مقال جديد: «اكتب مقالًا جديدًا حول X، والتزم بالبنية نفسها للمقالات القائمة» — ينشئ الذكاء الاصطناعي الملف، ويضيف الترجمات، ويسجّله في الفهرس
• تحديث نص صفحة الهبوط: «غيّر العنوان الرئيسي للـ hero إلى Y» — يعثر الذكاء الاصطناعي على الملف الصحيح ويحدّثه
• ترجمة المحتوى: «أضف الترجمة الألمانية لصفحة الأسعار» — يقرأ الذكاء الاصطناعي النسخة الإنجليزية وينتج ترجمة مكيّفة ثقافيًا، لا استبدالًا كلمة بكلمة
• إصلاح خطأ إملائي: «هناك خطأ إملائي في صفحة About، الكلمة recieve يجب أن تكون receive» — أُنجز في 3 ثوانٍ، ودُفع إلى git بالتزام commit يحمل رسالة ذات معنى

ما الذي حلّه نظام إدارة المحتوى فعليًا — وكيف يستبدله الذكاء الاصطناعي

لنكن صادقين بشأن ما قدّمه نظام إدارة المحتوى، وكيف تنعكس كل قدرة منه على سير العمل بالذكاء الاصطناعي:

الخلاصة الجوهرية: git بالفعل نظام تحكم في الإصدارات أفضل من أي شيء بناه نظام إدارة محتوى على الإطلاق. واللغة الطبيعية واجهة أفضل من أي محرر WYSIWYG — لأنها تحمل القصد، لا مجرد التنسيق.

نقلة النموذج: الكود هو طبقة المحتوى

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

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

يتّبع تطوّر إدارة محتوى الويب مسارًا واضحًا:

1. العقد الأول من الألفية: أنظمة إدارة محتوى متجانسة (WordPress، Drupal) — المحتوى والعرض مقترنان في نظام واحد
2. عقد 2010: أنظمة إدارة محتوى headless (Contentful، Strapi) — المحتوى مفصول عبر API، ويُعرض بأطر الواجهة الأمامية
3. عقد 2020: مولّدات المواقع الساكنة + Markdown (Hugo، Astro) — المحتوى كملفات، يُبنى وقت النشر
4. 2025 وما بعده: الكود بوصفه محتوى + الذكاء الاصطناعي — المحتوى يعيش في كود مُنمَّط، والذكاء الاصطناعي هو واجهة التحرير

متى تظل بحاجة إلى نظام إدارة محتوى

هذا ليس موقف «نظام إدارة المحتوى قد مات». فهو يحلّ مشكلات حقيقية على نطاق واسع. ما زلت بحاجة إليه حين:

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

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

المستقبل: الذكاء الاصطناعي بوصفه الواجهة الشاملة

يتجاوز الاتجاه أنظمة إدارة المحتوى. كل طبقة تجريد برمجية وُجدت لأن «النظام الأساسي أعقد من أن يُتعامل معه مباشرةً» يجري ضغطها بالذكاء الاصطناعي. لوحات الإدارة، وواجهات الإعدادات، والمحرّرات المرئية لقواعد البيانات — كلها واجهات تترجم قصد الإنسان إلى تغييرات في النظام. والذكاء الاصطناعي يؤدي هذه الترجمة على نحو أصيل.

بالنسبة للمواقع البسيطة، المستقبل هنا بالفعل. محتواك هو الكود. محرّرك هو الذكاء الاصطناعي. تحكّمك في الإصدارات هو git. نشرك هو دفعة push واحدة. طبقة نظام إدارة المحتوى بأكملها — اللوحة، وقاعدة البيانات، وواجهة API، والاستضافة — كانت وسيطًا برمجيًا (middleware) بين قصدك وموقعك. أزال الذكاء الاصطناعي الحاجة إلى ذلك الوسيط.

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

يدعم Perplexity Desktop موصّلات MCP (Model Context Protocol). بإضافة الخادم الرسمي @modelcontextprotocol/server-filesystem موجَّهًا إلى vault الخاص بك في Obsidian، يمكنك أن تطلب من Perplexity باللغة الطبيعية قراءة الملاحظات وإنشاءها وتحريرها — مباشرةً من المحادثة. بلا إضافات، بلا امتدادات، بلا نسخ ولصق.

المشكلة

يبرع Perplexity في البحث — فهو يبحث في الويب، ويلخّص المصادر، ويقدّم لك إجابات مع الاستشهادات. لكن حين تريد حفظ هذه النتائج في vault الخاص بك في Obsidian، ينكسر سير العمل: تنسخ النص، وتنتقل إلى Obsidian، وتبحث عن الملاحظة المناسبة، وتلصق، وتنسّق. في كل. مرة.

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

ما هو MCP؟

Model Context Protocol (MCP) معيار مفتوح يتيح لنماذج الذكاء الاصطناعي التفاعل مع الأدوات ومصادر البيانات المحلية. تخيّله منفذ USB للذكاء الاصطناعي — تُوصِّل «خادمًا» (برنامجًا صغيرًا)، فيكتسب الذكاء الاصطناعي قدرات جديدة. في حالتنا، يمنح خادم filesystem منصّة Perplexity 14 أداة للعمل مع الملفات:

Perplexity Desktop (Mac App)
  │
  ├── MCP Connector: "Obsidian Vault"
  │     │
  │     └── @modelcontextprotocol/server-filesystem
  │           │
  │           ├── read_file()      → read any .md file
  │           ├── write_file()     → create or overwrite files
  │           ├── edit_file()      → patch existing files
  │           ├── list_directory() → browse vault structure
  │           ├── search_files()   → find files by pattern
  │           └── ... 14 tools total
  │
  └── Perplexity AI Model
        │
        └── "Save this to my daily note" → calls write_file()

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

المتطلبات

• اشتراك Perplexity Pro (موصّلات MCP متاحة للمشتركين في الخطة المدفوعة)
• Perplexity Mac App من App Store (وليس نسخة المتصفح)
• Node.js مثبَّت على جهاز Mac (كي يعمل npx)

الإعداد خطوة بخطوة

يستغرق الإعداد بأكمله نحو دقيقتين:

الأمر

الأمر الذي تلصقه في حقل Command:

npx -y @modelcontextprotocol/server-filesystem "/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian Vault"

استبدل المسار بالموقع الفعلي لـ vault الخاص بك في Obsidian. إذا كان vault يُزامَن عبر iCloud، فسيكون المسار ضمن ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. احرص على إبقاء علامتَي الاقتباس — فالمسار يحتوي على الأرجح على مسافات.

كيفية استخدامه

بمجرد أن يُظهر الموصّل حالة Running مع توفّر 14 أداة، انتقل إلى أي محادثة في Perplexity وابدأ الحديث مع vault الخاص بك:

> Show me the structure of my Obsidian vault
> Add a new reflection to daily notes/2026-04-12.md: "Started using MCP today"
> Find all notes that mention "meditation"
> Create a new note in concepts/ about quantum computing
> List all files in my ideas/ folder

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

لماذا يتفوّق MCP على الأساليب الأخرى

قبل MCP، كانت هناك طرق محدودة للربط بين Perplexity و Obsidian:

القيود الحالية

• Mac فقط — تعمل موصّلات MCP في Perplexity حاليًا على نسخة Mac App Store فقط
• لا تكامل مع واجهة برمجة تطبيقات Obsidian — يعمل خادم filesystem مع الملفات الخام، لا عبر واجهة Obsidian البرمجية. هذا يعني أنه لن يُشغِّل إضافات Obsidian (مثل Linter أو Templater) عند إنشاء الملفات
• الموافقة مطلوبة — قد تتطلب عمليات الملفات الحساسة تأكيدك في تطبيق Perplexity — وهذه ميزة أمان، لا خلل

الخلاصة

يحوّل هذا الإعداد Perplexity من أداة بحث إلى أداة بحث والتقاط معًا:

1. ابحث على الويب واحفظ في Obsidian في محادثة واحدة
2. يرى الذكاء الاصطناعي بنية vault الخاص بك ويتكيّف مع نظام تنظيمك
3. صفر تنقّل بين التطبيقات — كل شيء يحدث في محادثة Perplexity

المصادر

• Model Context Protocol — official MCP specification
• MCP Filesystem Server — the server used in this setup
• Perplexity Help Center — Local and Remote MCPs for Perplexity
• Perplexity Blog — Everything is Computer

سكربت bash من 6 أسطر يشغّل Claude Code CLI في وضع headless كل صباح عند الساعة 9:00. يبحث في الويب عن الأخبار عبر 11 موضوعًا قابلًا للتهيئة، ويرشّح الضجيج، ويكتب ملخصًا منسّقًا بصيغة markdown مباشرةً داخل Obsidian vault متزامن عبر iCloud. صفر تبعيات. نحو 100 سطر من الإعدادات إجمالًا.

المشكلة

بصفتك مطوّرًا، مواكبة عدة تقنيات في آنٍ واحد ضريبة يومية. خلاصات RSS مزدحمة بالضجيج، وTwitter يبتلع الوقت، والنشرات البريدية تصل حين تكون غارقًا في تدفّق العمل. كنت بحاجة إلى شيء يقوم بالبحث نيابةً عني ويعرض النتائج حيث أعمل بالفعل — داخل Obsidian vault الخاص بي.

الحل المعتاد هو بناء خط سكرابينغ: مجدول، وزاحف، وخط معالجة لغة طبيعية NLP، وقاعدة بيانات، وخدمة إشعارات. أسابيع من العمل لأجل شيء قد ينهار حين يغيّر أي موقع بنية HTML الخاصة به. كنت أريد شيئًا أبنيه في فترة بعد ظهر واحدة.

البنية

النظام بأكمله 4 ملفات وصفر تبعيات. إليك كيف يعمل من البداية إلى النهاية:

macOS launchd (9:00 AM daily)
  │
  └── digest.sh
        │
        └── claude -p "$(cat prompt.md)" --max-turns 20 --allowedTools Read,WebSearch,WebFetch,Write
              │
              ├── Reads topics.yaml (11 configurable topics)
              ├── WebSearch → finds news for each topic (last 24-48h)
              ├── WebFetch → reads full articles
              ├── Filters noise: old tutorials, promos, AI spam
              └── Write → saves digest to Obsidian Vault
                    │
                    └── ~/Obsidian Vault/digests/2026-04-12.md
                          │
                          └── iCloud sync → available on all devices

الشيفرة (كاملةً)

المشروع بسيط عن قصد. كل سطر يستحق مكانه.

نقطة الدخول: digest.sh

التطبيق بأكمله سكربت bash من 6 أسطر:

#!/bin/bash
DIGEST_DIR="$HOME/Developer/news-digest"

claude -p "$(cat "$DIGEST_DIR/prompt.md")" \
  --max-turns 20 \
  --allowedTools Read,WebSearch,WebFetch,Write

الخيارات الأساسية: -p يشغّل Claude في وضع headless (دون طرفية تفاعلية)، و--max-turns 20 يمنح الوكيل مساحة كافية للبحث في كل المواضيع، و--allowedTools يقصر الوكيل على قراءة الملفات والبحث في الويب وكتابة المخرجات فقط.

العقل: prompt.md

هنا يكمن الذكاء. يحوّل الـ prompt نموذج Claude إلى وكيل بحث إخباري بتعليمات محددة عمّا يبحث عنه، وكيف يرشّح، وأين يحفظ:

# News Digest Agent

You are a news research agent. Your job is to find today's most important
and interesting news for a senior frontend developer.

## Instructions

1. Read the topics file at ~/Developer/news-digest/topics.yaml
2. For EACH topic, search the web for news from the last 24-48 hours
3. Filter: only include genuinely new and noteworthy items
4. Write the digest as a markdown file to Obsidian Vault digests/YYYY-MM-DD.md
5. IMPORTANT: Use the Write tool to save the file. Do NOT output to stdout.

## Rules

- Language: Ukrainian for summaries, English for titles and technical terms
- If there's no real news for a topic — SKIP IT ENTIRELY
- Prioritize: releases > breaking changes > security > new patterns > discussions
- Max 5 items per topic, sorted by importance
- Include direct links to sources
- Skip promotional content, generic tutorials, and AI-generated spam

الإعداد: topics.yaml

المواضيع قابلة للتهيئة بالكامل — أضِف موضوعًا جديدًا فيُدرَج في ملخص الغد. لكل موضوع اسم وسياق اختياري يوجّه بحث الذكاء الاصطناعي:

topics:
  - name: better-auth
    context: "auth library for TypeScript. New releases, breaking changes"

  - name: Next.js
    context: "GitHub issues, releases, App Router, Turbopack, performance"

  - name: SolidJS
    context: "SolidStart, releases, ecosystem, comparison with React"

  - name: Tailwind CSS
    context: "v4 updates, new utilities, plugins"

  - name: Claude AI
    context: "Anthropic announcements, Claude Code, new models, MCP, API"

  - name: GPT AI
    context: "OpenAI announcements, new models, ChatGPT features"

  - name: React
    context: "React 19+, Server Components, new patterns, ecosystem"

  - name: Apple
    context: "Hardware, software, WWDC, developer tools, Apple Intelligence"

  - name: Notable People
    context: >
      Latest tweets from: Elon Musk, Dario Amodei, Sam Altman,
      Jensen Huang, Andrej Karpathy, Simon Willison, Swyx...

  - name: AI Global
    context: "Major AI news, new models, regulations, open-source AI"

الجدولة عبر launchd

على macOS، يُعدّ launchd الطريقة الأصيلة لجدولة المهام المتكررة (مثل cron على Linux). يحدّد ملف plist متى وكيف يُشغَّل السكربت:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.news-digest</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/you/Developer/news-digest/digest.sh</string>
    </array>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>

    <key>StandardOutPath</key>
    <string>/Users/you/Developer/news-digest/logs/stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/you/Developer/news-digest/logs/stderr.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin</string>
        <key>HOME</key>
        <string>/Users/you</string>
    </dict>
</dict>
</plist>

ثبّته عبر launchctl load ~/Library/LaunchAgents/com.news-digest.plist. يعمل السكربت يوميًا عند الساعة 9:00، حتى لو كنت قد سجّلت الخروج — سيشغّل launchd المهام الفائتة حين يستيقظ النظام.

كيف تبدو المخرجات

كل صباح، يظهر ملف markdown جديد في Obsidian vault يحوي أخبارًا منظمة ومرتّبة حسب الأولوية:

---
date: 2026-04-12
---

# News Digest — 2026-04-12

## Next.js

### Next.js 16.1 Released with Improved Turbopack Caching
Нова версія Next.js 16.1 включає покращене кешування для Turbopack,
що зменшує час холодного старту на ~40%.
[Посилання](https://nextjs.org/blog/next-16-1)

### Critical Memory Leak Fix in App Router
Виправлено витік пам'яті в App Router при частому перемиканні
між динамічними маршрутами.
[GitHub Issue](https://github.com/vercel/next.js/issues/...)

## Claude AI

### Claude Code 1.5 — MCP Server Auto-Discovery
Anthropic випустив оновлення Claude Code з автоматичним
виявленням MCP серверів у проєкті.
[Блог](https://www.anthropic.com/news/...)

بالأرقام

قرارات التصميم الأساسية

• Claude Code CLI بدلًا من الـ API — لا حاجة لإدارة مفاتيح API أو عملاء HTTP أو تحليل الاستجابات. تتولى الـ CLI المصادقة وتنفيذ الأدوات والتعافي من الأخطاء جاهزةً
• Obsidian بدلًا من البريد الإلكتروني — الملخصات قابلة للبحث والربط ودائمة. تعيش إلى جوار ملاحظاتي بدل أن تغرق في صندوق الوارد
• launchd بدلًا من cron — launchd هو المجدول الأصيل في macOS. يعالج التشغيلات الفائتة والتسجيل ومتغيرات البيئة بنظافة
• YAML للمواضيع — إضافة موضوع جديد تغييرٌ من سطرين. لا حاجة لتعديل الشيفرة
• تخطّي المواضيع الفارغة — إن لم تكن هناك أخبار حقيقية، يُحذف القسم بالكامل. بلا حشو، وبلا محتوى ممطوط

كيف تبني نسختك الخاصة

يمكنك تشغيل هذا خلال 10 دقائق:

1. ثبّت Claude Code CLI وسجّل الدخول
2. استنسخ المستودع: git clone https://github.com/oleksiimazurenko/news-digest
3. عدّل topics.yaml باهتماماتك وprompt.md بمسار الحفظ الخاص بك
4. عدّل ملف plist باسم المستخدم والمسارات الخاصة بك، ثم شغّل launchctl load
5. انتظر الساعة 9:00 — أو اختبر يدويًا عبر bash digest.sh

الخلاصة

أكثر ما يثير الاهتمام في هذا المشروع هو ما ليس فيه. لا قاعدة بيانات، ولا خادم API، ولا حاوية Docker، ولا حزم npm، ولا Python virtualenv، ولا محلل HTML، ولا خط معالجة NLP. مجرد prompt، وقائمة مواضيع، وسكربت من 6 أسطر يفوّض كل العمل الشاق إلى وكيل ذكاء اصطناعي.

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

المصادر

• news-digest on GitHub — full source code
• Claude Code Documentation — headless mode and CLI flags
• Apple Developer — creating launchd jobs
• Obsidian — markdown knowledge base

يعرض next-themes وسم <script> داخل مكوّن عميل React لمنع وميض السمة (FOUC). صار React 19 الآن يُصدر تحذيرًا بشأن ذلك — ولا توجد أي طريقة لكتمه. لم تُحدَّث المكتبة منذ مارس 2025. الحل: استبدال next-themes بمخزن Zustand مع useServerInsertedHTML لحقن السكربت خارج شجرة React. صفر تبعيات مُضافة. صفر وميض FOUC. صفر تحذيرات.

المشكلة

إذا كنت تستخدم next-themes مع Next.js 15+ وReact 19، فستحصل على هذا الخطأ في وحدة التحكم عند كل تحميل للصفحة:

Encountered a script tag while rendering React component.
Scripts inside React components are never executed when rendering on the client.
Consider using template tag instead.

src/providers/theme-provider.tsx (7:10) @ ThemeProvider

هذا ليس عدم تطابق في الإماهة (hydration). إنه تحذير صريح من React 19 بأن وسوم <script> التي تعرضها مكوّنات React على العميل لن تُنفَّذ أبدًا. يعمل السكربت أثناء التصيير من الخادم SSR (فهو موجود في HTML)، لكن React يعتبره غير صحيح.

لماذا يحدث ذلك

يحتاج next-themes إلى ضبط صنف السمة الصحيح على <html> قبل أن يُميه React الصفحة (إماهة/hydration) — وإلا فسيظهر وميض بالسمة الخاطئة. ولتحقيق ذلك، يحقن وسم <script> مضمّنًا عبر React.createElement:

// next-themes renders a <script> inside a Client Component
return React.createElement(Provider, { value },
  React.createElement("script", {
    suppressHydrationWarning: true,
    dangerouslySetInnerHTML: { __html: `(...theme init code...)` }
  }),
  children
)

غيّر React 19 سلوكه: صارت وسوم script داخل المكوّنات تُعلَّم الآن صراحةً. قبل React 19 كان يتم تجاهل ذلك بصمت. ولا تُجدي خاصية suppressHydrationWarning على السكربت نفعًا — فهي تكتم تحذيرات الإماهة، لا تحذير «script داخل مكوّن».

ما الذي جرّبناه (ولماذا فشل)

جرّبنا كل نهج بشكل منهجي قبل أن نصل إلى الحل:

الحل: Zustand مع useServerInsertedHTML

الفكرة الجوهرية: useServerInsertedHTML هو خطّاف Next.js يحقن HTML في تدفّق التصيير من الخادم SSR خارج شجرة مكوّنات React. ينتهي السكربت داخل HTML لكن React لا «يراه» أبدًا أثناء التصيير على العميل — ومن ثمّ لا تحذير. وعند دمجه مع مخزن Zustand لإدارة حالة السمة التفاعلية، نحصل على بديل كامل بصفر تبعيات.

كيف يعمل

SSR (server):
  useServerInsertedHTML → injects <script> into HTML stream
  ↓
  Browser receives HTML with theme script already in it
  ↓
  Script runs BEFORE React hydrates → correct class on <html>
  ↓
  No flash. No mismatch. No warning.

Client (after hydration):
  useEffect → _init() → Zustand store syncs with localStorage
  ↓
  useTheme() → reactive theme state for components

الخطوة 1: مخزن Zustand

يدير المخزن حالة السمة، ويطبّق الأصناف على DOM، ويتولّى كشف سمة النظام، ويزامن بين علامات التبويب. تُرجِع دالة _init() دالة تنظيف تُستخدم داخل useEffect:

import { create } from "zustand";

const STORAGE_KEY = "theme";
const MEDIA_QUERY = "(prefers-color-scheme: dark)";

function getSystemTheme(): "light" | "dark" {
  return window.matchMedia(MEDIA_QUERY).matches ? "dark" : "light";
}

function applyTheme(resolved: string, disableTransition: boolean) {
  const d = document.documentElement;

  if (disableTransition) {
    const style = document.createElement("style");
    style.appendChild(
      document.createTextNode(
        "*,*::before,*::after{transition:none!important}"
      )
    );
    document.head.appendChild(style);
    window.getComputedStyle(document.body);
    setTimeout(() => document.head.removeChild(style), 1);
  }

  d.classList.remove("light", "dark");
  d.classList.add(resolved);
  d.style.colorScheme = resolved;
}

interface ThemeState {
  theme: string;
  systemTheme: "light" | "dark";
  resolvedTheme: string;
  setTheme: (theme: string) => void;
  _init: (disableTransition: boolean) => () => void;
}

export const useThemeStore = create<ThemeState>((set, get) => ({
  theme: "system",
  systemTheme: "light",
  resolvedTheme: "light",

  setTheme: (newTheme) => {
    const { systemTheme, disableTransitionOnChange } = get();
    const resolved = newTheme === "system" ? systemTheme : newTheme;
    localStorage.setItem(STORAGE_KEY, newTheme);
    applyTheme(resolved, disableTransitionOnChange);
    set({ theme: newTheme, resolvedTheme: resolved });
  },

  _init: (disableTransition) => {
    const stored = localStorage.getItem(STORAGE_KEY) || "system";
    const system = getSystemTheme();
    const resolved = stored === "system" ? system : stored;

    set({ theme: stored, systemTheme: system, resolvedTheme: resolved });
    applyTheme(resolved, disableTransition);

    // System theme changes
    const mq = window.matchMedia(MEDIA_QUERY);
    const onChange = (e: MediaQueryListEvent) => {
      const newSystem = e.matches ? "dark" : "light";
      const { theme } = get();
      set({ systemTheme: newSystem,
            resolvedTheme: theme === "system" ? newSystem : theme });
      if (theme === "system") applyTheme(newSystem, disableTransition);
    };
    mq.addEventListener("change", onChange);

    // Cross-tab sync
    const onStorage = (e: StorageEvent) => {
      if (e.key !== STORAGE_KEY || !e.newValue) return;
      const system = getSystemTheme();
      const resolved = e.newValue === "system" ? system : e.newValue;
      set({ theme: e.newValue, resolvedTheme: resolved });
      applyTheme(resolved, disableTransition);
    };
    window.addEventListener("storage", onStorage);

    return () => {
      mq.removeEventListener("change", onChange);
      window.removeEventListener("storage", onStorage);
    };
  },
}));

export function useTheme() {
  return useThemeStore((s) => ({
    theme: s.theme,
    setTheme: s.setTheme,
    resolvedTheme: s.resolvedTheme,
    systemTheme: s.systemTheme,
  }));
}

الخطوة 2: ThemeProvider

يقوم المزوّد بأمرين: حقن سكربت منع الوميض FOUC عبر useServerInsertedHTML، وتهيئة مخزن Zustand عند التركيب:

"use client"

import { useEffect } from "react"
import { useServerInsertedHTML } from "next/navigation"
import { useThemeStore } from "@/store/use-theme-store"

const THEME_INIT_SCRIPT = `(function(){
  try {
    var t = localStorage.getItem("theme") || "system";
    var r = t;
    if (t === "system") {
      r = window.matchMedia("(prefers-color-scheme: dark)").matches
        ? "dark" : "light";
    }
    document.documentElement.classList.remove("light", "dark");
    document.documentElement.classList.add(r);
    document.documentElement.style.colorScheme = r;
  } catch(e) {}
})()`

export function ThemeProvider({
  children,
  disableTransitionOnChange = false,
}) {
  // Injects script into SSR HTML outside the React tree
  // — prevents FOUC without triggering React 19 warning
  useServerInsertedHTML(() => (
    <script dangerouslySetInnerHTML={{ __html: THEME_INIT_SCRIPT }} />
  ))

  useEffect(() => {
    return useThemeStore.getState()._init(disableTransitionOnChange)
  }, [disableTransitionOnChange])

  return <>{children}</>
}

الخطوة 3: Layout

import { ThemeProvider } from "@/providers/theme-provider"

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <ThemeProvider disableTransitionOnChange>
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

الخطوة 4: استخدمه

import { useTheme } from "@/store/use-theme-store"

export function ThemeSwitch() {
  const { theme, setTheme } = useTheme();

  return (
    <button onClick={() => setTheme(
      theme === "dark" ? "light" : "dark"
    )}>
      {theme === "dark" ? "☀️" : "🌙"}
    </button>
  );
}

الانتقال من next-themes

الواجهة البرمجية متطابقة عن قصد. الانتقال هو تغيير استيراد واحد لكل ملف:

- import { useTheme } from "next-themes"
+ import { useTheme } from "@/store/use-theme-store"

  // API is identical — no other changes needed
  const { theme, setTheme, resolvedTheme, systemTheme } = useTheme()

مقارنة

لماذا لا نستخدم البدائل الأخرى؟

@wrksz/themes

بديل جاهز للاستبدال المباشر يستخدم هو أيضًا useServerInsertedHTML. إنه يعمل، لكنه تبعية إضافية من صاحب صيانة واحد. وإن كان next-themes قد علّمنا شيئًا — فالتبعيات يتم التخلّي عنها. بنحو 100 سطر من الكود، يمكنك امتلاك الحل بالكامل.

next-themes@1.0.0-beta.0

موجود على npm، لكن بلا تاريخ إصدار، وبلا سجل تغييرات، وبلا إشارة واضحة إلى أن تحذير React 19 قد أُصلِح. المراهنة بكود الإنتاج على نسخة بيتا مفتوحة الأجل ليست مخاطرة تستحق العناء.

بـ CSS فقط (prefers-color-scheme)

يصلح لكشف سمة النظام، لكنه لا يستطيع التعامل مع استمرار تفضيل المستخدم (localStorage)، ولا التبديل اليدوي للسمة، ولا خيار «system». تحتاج إلى JavaScript لذلك.

الخلاصات

1. next-themes متروك فعليًا — آخر إصدار في مارس 2025، وتحذير React 19 لم يُصلَح
2. useServerInsertedHTML هو العنصر البدائي الصحيح في Next.js لحقن السكربتات دون تحذيرات React
3. يوفّر Zustand حالة سمة تفاعلية بكود أقل من مزوّد Context
4. الحل بأكمله نحو 100 سطر، صفر تبعيات جديدة، وأنت تملك كل سطر

المصادر

• shadcn/ui #10104 — Dark mode guide should address React 19 script warning
• next-themes #296 — React 19 support request (open since 2024)
• React #34008 — Script tags not executing in components (by design)
• @wrksz/themes — Drop-in replacement using useServerInsertedHTML
• Next.js Docs — useServerInsertedHTML API

يستخدم تطبيقنا (Promova) إطار Next.js 16 مع Landing Builder — نظام يعتمد على نظام إدارة محتوى (CMS) يجمّع صفحات التسويق من نحو 90 مكوّن قسم مختلفًا (أقسام Hero وأسئلة شائعة وتسعير ومراجعات وغيرها). تعتمد البنية على sectionRegistry.tsx الذي يربط أسماء الأقسام باستدعاءات next/dynamic():

// sectionRegistry.tsx — imports all 90 sections
export const sectionRegistry = {
  HeroSection: dynamic(() => import('./HeroSection/HeroSection')),
  FAQSection: dynamic(() => import('./FAQSection/FAQSection')),
  ReviewsSection: dynamic(() => import('./ReviewsSection/ReviewsSection')),
  // ... 87 more
}

لا تعرض صفحة الهبوط الواحدة سوى 5-8 أقسام. لكن Lighthouse كان يُظهر ما يلي:

Eliminate render-blocking resources
  94 CSS resources (~330 KB)
  Potential savings: 5,440 ms

لماذا؟ يرى Turbopack جميع مسارات import() التسعين قابلةً للوصول، فيولّد <link rel="stylesheet"> لكل وحدة SCSS. حتى الأقسام التي لا تُعرَض أبدًا على الصفحة يُحقَن ملف CSS الخاص بها في <head>. هذا سلوك مؤكَّد ومتوقَّع لموجّه App Router في Next.js. إذ لا يُقسَّم CSS إلى أجزاء لاستيرادات dynamic() القادمة من Server Components. يعدّه المشرفون مقايضةً متعمَّدة لتفادي وميض المحتوى غير المنسَّق (FOUC). ولا يُخطَّط لإصلاحه.

كل ما جرّبته (ولماذا فشل)

قضيت أيامًا أستعرض كل نهج أمكنني إيجاده. إليك القائمة الكاملة:

فخّ inlineCss

يمتلك Next.js خيار experimental.inlineCss تستبدل جميع وسوم <link rel="stylesheet"> بوسوم <style> مضمَّنة. يبدو ذلك مثاليًا، أليس كذلك؟

المشكلة أنه إما الكل أو لا شيء. لا يمكنك تفعيله لكل مسار على حدة. إن كانت لديك صفحات SSR (force-dynamic) فإن كل طلب يعيد بناء كل CSS بشكل مضمَّن. جرّبنا ذلك — فلم يحتمل نظام CMS بلا واجهة (headless) لدينا الحِمل وتعطّل. ولكي يعمل بأمان، يجب أن تكون 100% من صفحاتك بنمط force-static أو ISR. ومع أكثر من 20 صفحة SSR (مصادقة، ولوحات تحكم، وصفحات ديناميكية) فتلك عملية ترحيل ضخمة.

الاكتشاف: Turbopack Import Attributes

أثناء تنقيبي في ملاحظات إصدار Next.js 16.2، عثرت على ميزة موثَّقة بشكل ضعيف: Turbopack Import Attributes. تتيح لك تجاوز خط أنابيب المجمِّع المدمَج لاستيراد محدَّد باستخدام صياغة with {} من TC39:

import { cssText, styles } from './hero.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}

يقول هذا لـ Turbopack: «لا تعالج هذا الاستيراد بوصفه ورقة أنماط. مرِّره عبر الـ loader المخصَّص لديّ وتعامل مع الخرج بوصفه JavaScript.»

هذه هي الفكرة الجوهرية. بدلًا من أن يولّد Turbopack وسم <link rel="stylesheet"> يحجب العرض، يقوم الـ loader لدينا بترجمة SCSS وتصديره كسلسلة JavaScript. ثم نحقنه بوصفه وسم <style> مضمَّنًا مباشرة داخل المكوّن. النتيجة: لا يصل إلى HTML الصفحة سوى CSS الأقسام التي تُعرَض فعلًا. تحصل الصفحة ذات الأقسام الخمسة على CSS لخمسة أقسام — لا لـ 94.

الحل

1. Turbopack Loader مخصَّص

نص Node.js بنحو 70 سطرًا كحزمة ضمن مساحة عمل yarn (@promova/scss-to-inline-loader):

const { createHash } = require('node:crypto')
const sass = require('sass')
const postcss = require('postcss')
const postcssModules = require('postcss-modules')
const path = require('path')

const SHARED_STYLES = path.resolve(__dirname, '../shared/styles')

// Same prependData as sassOptions.prependData in next.config.ts
const PREPEND_DATA = `
@use "sass:math" as math;
@use "sass:list" as list;
@use "${SHARED_STYLES}/_variables.scss" as *;
@use "${SHARED_STYLES}/_breakpoints.scss" as *;
@use "${SHARED_STYLES}/_mixins.scss" as *;
`

module.exports = function scssToInlineLoader(source) {
  const callback = this.async()
  processScss(source, this.resourcePath)
    .then((js) => callback(null, js))
    .catch((err) => callback(err))
}

async function processScss(source, resourcePath) {
  // 1. Compile SCSS → CSS (with global variables, mixins, breakpoints)
  const sassResult = sass.compileString(PREPEND_DATA + '\n' + source, {
    loadPaths: [path.dirname(resourcePath), SHARED_STYLES],
    style: 'compressed',
    sourceMap: false,
    url: new URL('file://' + resourcePath),
  })

  // 2. Scope class names with postcss-modules (CSS Modules compatible)
  let classNames = {}
  const result = await postcss([
    postcssModules({
      generateScopedName(name, filename) {
        const file = path.basename(filename, path.extname(filename))
          .replace('.module', '')
        const hash = createHash('md5')
          .update(filename + name)
          .digest('base64url')
          .slice(0, 6)
        return `${file}__${name}__${hash}`
      },
      getJSON(_, json) { classNames = json },
    }),
  ]).process(sassResult.css, { from: resourcePath })

  // 3. Export as JS module — same interface as CSS Modules
  return [
    `export const cssText = ${JSON.stringify(result.css)};`,
    `export const styles = ${JSON.stringify(classNames)};`,
    `export default styles;`,
  ].join('\n')
}

ما يفعله: styles — خريطة أسماء الأصناف محدَّدة النطاق (scoped) ذاتها الموجودة في CSS Modules القياسية. cssText — ملف CSS المترجَم كسلسلة نصية.

2. مكوّن InlineStyle

يستخدم واجهة <style href precedence> المدمَجة في React 19 لإزالة التكرار تلقائيًا:

export function InlineStyle({ css, id }: { css: string; id: string }) {
  return (
    <style href={id} precedence="default">
      {css}
    </style>
  )
}

يضمن React 19: نفس قيمة href → وسم <style> واحد فقط في DOM. فإن عُرِض قسم مرتين على الصفحة، يُحقَن CSS مرة واحدة رغم ذلك.

3. ترحيل لكل مكوّن (نحو 6 أسطر لكل قسم)

// BEFORE: Turbopack → <link rel="stylesheet"> (render-blocking)
import styles from './hero_section.module.scss'

// AFTER: Custom loader → JS module → inline <style> (non-blocking)
import { cssText, styles } from './hero_section.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}
import { InlineStyle } from '@promova/scss-to-inline-loader/InlineStyle'

export function HeroSection() {
  return (
    <section className={styles.hero}>
      <InlineStyle css={cssText} id="hero-section" />
      {/* ... component JSX, className usage is identical */}
    </section>
  )
}

تبقى ملفات .module.scss كما هي تمامًا. لا إعادة كتابة لـ CSS. Stylelint وPrettier ودعم بيئة التطوير (IDE) — كلها محفوظة.

لماذا هذا أفضل من inlineCss: true

هذا هو الفرق الجوهري:

عند استخدام inlineCss: true، تحصل الصفحة رغم ذلك على جميع أوراق الأنماط الأربع والتسعين مضمَّنة — لكنها وسوم <style> بدلًا من وسوم <link>. يتضخّم HTML. أما مع نهجنا، فإن ما يصل إلى HTML هو CSS الذي يُعرَض فعلًا لا غير. عُرِضت 5 أقسام → 5 وسوم <style>. هذا كل شيء.

مطبّ Turbopack: لا قواعد عامة لـ .module.scss

أحد المطبّات التي وقعت فيها: قد تظن أن بإمكانك إضافة قاعدة Turbopack في next.config.ts لتطبيق الـ loader عالميًا:

// ❌ THIS CAUSES A FATAL PANIC
turbopack: {
  rules: {
    '**/components/**/*.module.scss': {
      loaders: ['@promova/scss-to-inline-loader'],
      as: '*.js'
    }
  }
}

لا تفعل هذا. يعترض خط أنابيب وحدات CSS المدمَج في Turbopack ملفات .module.scss قبل تطبيق القواعد المخصَّصة. فيُنشئ أصلًا من نوع EcmascriptCssModule يتعارض مع خرج as: '*.js'، مسبِّبًا:

FATAL PANIC: inner asset should be CSS processable

تعمل سمات with {} لأنها توعز إلى Turbopack عند موضع الاستيراد بتجاوز خط أنابيب وحدات CSS كليًا. ولا سبيل إلى فعل ذلك عالميًا عبر ملف الإعداد.

النتائج

رحّلنا 127 مكوّن قسم عبر Landing Builder. وتم التحقق من بناء الإنتاج.

القيود

• with {} لكل استيراد مُسهَب — يحتاج كل استيراد إلى 3 أسطر إضافية. ولا سبيل إلى تطبيقه عالميًا (انظر المطبّ أعلاه).
• Turbopack فقط — لا يدعم Webpack سمات with {}. وإن احتجت إلى بديل Webpack، تعود الاستيرادات إلى CSS Modules القياسية (وتكون قيمة cssText هي undefined).
• تجزئة أسماء الأصناف — يستخدم الـ loader لدينا خوارزمية تجزئة مختلفة عن تلك المدمَجة في Turbopack. تبدو أسماء الأصناف مختلفة في DevTools. لكنها متطابقة وظيفيًا.
• يزداد حجم HTML — يُضمَّن CSS داخل HTML بدلًا من تخزينه مؤقتًا كملفات منفصلة. أما للصفحات الثابتة/ISR المقدَّمة من CDN، فهذه ليست مشكلة.

متى تستخدم هذا

تكون هذه التقنية أكثر فاعلية عندما:

1. يكون لديك نمط registry/barrel — ملف واحد يستورد مكوّنات كثيرة، لكن قليلًا منها فقط يُعرَض في كل صفحة
2. تكون على Turbopack — سمات Import Attributes خاصة بـ Turbopack
3. تريد تحكمًا لكل مكوّن — لا خيار «إما الكل أو لا شيء»
4. تكون ملفات SCSS لديك معقّدة — متغيّرات وmixins ونقاط توقّف (breakpoints) وتداخل — كلها مدعومة
5. لا يمكنك استخدام experimental.inlineCss — لأن لديك صفحات SSR أو تريد تحكمًا دقيقًا

مشكلات GitHub ذات الصلة

إن كنت متأثرًا بمشكلة CSS الحاجب للعرض في Next.js App Router، فأنت لست وحدك:

المشكلة الجوهرية

• #62485 — Render blocking CSS (maintainers: "expected behavior")
• #61066 — Dynamic imports from Server Components are not code-split
• #54935 — Server-side dynamic imports don't split client modules
• #61574 — JS/CSS code splitting doesn't work as documented
• #57634 — Add support for critical CSS inlining with App Router
• #50300 — next/dynamic on server component does not build CSS modules

ميزة inlineCss ومشكلاتها

• PR #72195 — experimental: css inlining (the implementation)
• PR #73182 — Don't inline CSS in RSC payload for client navigation
• #75648 — WhatsApp preview broken with inlineCss + Tailwind
• #83612 — Turbopack wrong font URL with inline CSS

المجتمع يطلب حلولًا

• Discussion #82894 — How to prevent render-blocking with CSS Modules? (2025)
• Discussion #70526 — Ideas for reducing render-blocking CSS
• Discussion #59814 — Render blocking styles with Tailwind
• Discussion #49691 — How to deal with render-blocking modular CSS
• Discussion #59989 — Critical CSS inlining with App Router
• Discussion #80486 — Is optimizeCss still in use?
• Discussion #85465 — Turbopack plugin API (doesn't exist)

علل CSS في Turbopack

• #68412 — Incorrect CSS modules load order with external components
• #76464 — Turbopack sometimes strips SCSS imports
• #82497 — SCSS module not loading when not-found.tsx is present
• #88544 — Exporting Sass variables from CSS modules doesn't work with Turbopack

صُنِع في Promova — منصة لتعلّم اللغات تخدم ملايين المستخدمين. إن كنت تصارع المشكلة ذاتها في CSS، فلا تتردد في الإشارة إلى هذا المقال في مشكلات GitHub أعلاه.

يقوم Next.js بترقيع دالة fetch العامة ويضيف طبقة تخزين مؤقت تحتفظ بمراجع إلى بيانات الاستجابة بعد أن كان ينبغي تحريرها. كل استدعاء لـ fetch يضيف ذاكرة لا تُعاد أبدًا إلى الـ GC. في Docker/Kubernetes يؤدي هذا إلى انهيارات OOM كل بضع ساعات. توجد هذه العلة منذ Next.js 14 (أبريل 2024) ولا تزال دون حل في 16.2.x (مارس 2026). أما على Vercel فلا تظهر المشكلة بفضل دوال serverless العابرة.

كيف يعمل fetch العادي

Request → fetch → got data → response to user → GC cleans up → memory free

كيف يعمل fetch في Next.js

يعترض Next.js دالة fetch العامة ويلفّها بطبقة تخزين مؤقت/تتبّع خاصة به:

Request → Next.js fetch wrapper → creates:
  - Performance entry (speed tracking)    ← not cleaned
  - Request metadata object               ← not cleaned
  - Internal promise wrapper              ← not cleaned
  - Cache lookup entry                    ← not cleaned
  - Response body (for unique URL)        ← not cleaned
→ Response to user
→ GC sees objects are still referenced → doesn't touch them
→ Memory grows indefinitely

ماذا يحدث في بيئة الإنتاج

Self-hosted (Docker/K8s):
  Request 1:      fetch → +100KB → RAM: 100KB
  Request 2:      fetch → +100KB → RAM: 200KB
  Request 1000:   fetch → +100KB → RAM: 100MB
  Request 50,000: fetch → +100KB → RAM: 5GB → OOM Kill 💀
  → Kubernetes restarts the pod → cycle repeats

Vercel (Serverless):
  Request 1: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  Request 2: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  → Memory never accumulates

الإصدارات المتأثرة

Next.js — كل الإصدارات التي تستخدم App Router

Node.js

تم الاختبار على Node.js 20 و22 و24 و25 — تتسرب الذاكرة في جميعها.

ما الذي لا ينفع

ما الذي ينفع (حلول التفافية)

قيود الحل الالتفافي باستخدام axios

يمكنك استبدال استدعاءات الـ API الخاصة بك بـ axios. لكن Next.js يستخدم داخليًا نسخة fetch المرقّعة من أجل:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• جلب بيانات Server Components مع إزالة التكرار
• use cache (Next.js 16)

أي حتى من دون استدعاء واحد لـ fetch في شيفرتك — يظل Next.js يستخدمه في الخفاء.

لماذا لا تُصلح Vercel المشكلة

منطق العمل التجاري

Vercel شركة تجني المال من استضافة Next.js. على منصتها لا تظهر المشكلة (serverless = عابر). العلة تؤثر فقط على الاستضافة الذاتية (Docker وK8s وVPS) — أي على من لا يدفع لـ Vercel.

الموقف الرسمي

قام Tim Neutkens (أحد مشرفي Vercel) بتحليل المشكلة وأعلن أنها مشكلة undici (مكتبة fetch في Node.js) وليست مشكلة Next.js. وأُغلق Issue #90433. وذلك رغم أن:

• axios وnode-fetch يعملان على نفس Node.js دون تسريبات
• التسريب لا يظهر إلا عندما يمر fetch عبر غلاف Next.js
• العلة مفتوحة منذ سنتين دون إصلاح

الأولويات

خلال هاتين السنتين أصدر فريق Next.js ما يلي:

• Turbopack (بناء أسرع بمقدار 2-5x) — ميزة تسويقية
• Cache Components / use cache — يقلل الحِمل على خوادم Vercel
• proxy.ts بدلًا من middleware — يبسّط النشر على edge في Vercel
• DevTools MCP — ضجّة الذكاء الاصطناعي

تسريب الذاكرة في الاستضافة الذاتية؟ ليس من الأولويات.

الحل: AWS Lambda (SST + OpenNext)

ما هذا

OpenNext مُحوِّل مفتوح المصدر يحوّل بناء Next.js إلى صيغة تناسب AWS Lambda. أما SST فهو إطار عمل يؤتمت البنية التحتية.

البنية المعمارية

Next.js build
  → OpenNext
    → AWS Lambda (SSR, API routes)
    → S3 (static, assets)
    → CloudFront (CDN)
    → SQS + DynamoDB (ISR revalidation)

لماذا يحل هذا تسريب الذاكرة

تعالج دوال Lambda الطلبات ثم يُعاد تدويرها بعد 5-15 دقيقة من الخمول. فلا تجد الذاكرة وقتًا لتتراكم.

النشر

npx sst@latest init
npx sst deploy --stage production

المقارنة

اعتبارات Lambda

• Cold starts — الطلب الأول أبطأ (~200-500ms)
• الأمان — فعّل OAC (Origin Access Control)، وإلا فإن رابط Lambda يكون علنيًا
• OpenNext — مشروع مجتمعي وليس رسميًا من Vercel. قد تتعطل ميزات Next.js الجديدة
• هجوم المحفظة — أثناء هجوم DDoS قد يؤدي التوسع التلقائي لـ Lambda إلى فاتورة ضخمة

لماذا يُعدّ الإصلاح الحقيقي غير واقعي

1. مشكلة معمارية

التسريب ليس علة عرضية بل نتيجة قرار تصميمي: يعترض Next.js دالة fetch العامة ويضيف فوقها التخزين المؤقت/التتبّع. ولإصلاحه يلزم إعادة تصميم طريقة تفاعل App Router مع fetch. وهذا يمسّ ISR وrevalidation وdata cache وrequest deduplication — أي نواة الإطار.

2. تضارب المصالح

Vercel غير متحفزة لإصلاح ما لا يؤثر على منصتها. الاستضافة الذاتية تنافس عملها التجاري. وكلما زادت المشكلات في الاستضافة الذاتية — زاد عدد من ينتقلون إلى Vercel.

3. تحميل المسؤولية لغيرها

الموقف الرسمي هو «إنها undici، لسنا نحن». وحتى يتغير هذا — لن يعملوا على إصلاح.

4. لا يوجد إصلاح من المجتمع

رخصة AGPL-3.0 الخاصة بـ Next.js تسمح بالتفريعات، لكن قاعدة الشيفرة ضخمة ومترابطة بإحكام مع بنية Vercel التحتية. أي طلب دمج مجتمعي لإصلاح غلاف fetch سيتطلب فهمًا عميقًا للبنية الداخلية وموافقة المشرفين — الذين أغلقوا الـ issue بالفعل.

الخلاصات

1. إن كنت على Vercel — لا مشكلة، لا شيء تفعله
2. إن كنت على استضافة ذاتية وتحتاج serverless — SST + OpenNext على AWS Lambda
3. إن كنت على استضافة ذاتية بـ Docker — استبدل fetch بـ axios حيثما أمكن، وراقب الـ RAM، واضبط إعادة تشغيل تلقائية للـ pods
4. إن كنت تبدأ مشروعًا جديدًا — فكّر في SvelteKit أو Nuxt كبدائل خالية من هذه المشكلة

المصادر

• Issue #64212 — Memory Leak with global fetch (April 2024)
• Issue #68578 — Possible memory leak in Fetch API (August 2024)
• Issue #85914 — Memory Leak with fetch + standalone (November 2025)
• Issue #90433 — OOM in 16.0.10 (February 2026)
• Discussion #88603 — OOM in Docker/K8s (January 2026)
• Discussion #88078 — cacheMaxMemorySize behavior
• OpenNext
• SST — Next.js on AWS
• Secret knowledge to self-host Next.js
• Next.js Memory Usage Guide