نقل Hansard سجل 25 مشروعًا و53 محادثة من Claude Code إلى Codex

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

واجه مؤلف المادة الأصلية هذه المشكلة تحديدًا: فبعد حظر مؤسسة Anthropic المدفوعة الخاصة به، اضطر إلى نقل عمله إلى Codex. ظل على حاسوبه 25 مشروعًا و53 محادثة في Claude Code. نقلت أداة الاستيراد المدمجة في Codex نحو 50 جلسة، لكن بعض المحادثات ارتبط بمشروعات غير صحيحة، واختلط السياق المفيد برسائل النظام. من الناحية الشكلية، ظهر السجل. أما عمليًا، فكانت مواصلة العمل اعتمادًا عليه غير مريحة.

لماذا لا يحل الاستيراد البسيط المشكلة

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

يقترح Hansard بنية مختلفة. تُجمع سجلات Claude Code وCodex وCursor وOpenCode وKimi Code وعدد من الأدوات الأخرى في أرشيف مستقل. لا يحصل الوكيل على الأرشيف كاملًا، بل يستخدم البحث للعثور على الجلسات المرتبطة بالمشروع ولا يقرأ إلا المقاطع المناسبة. يوفر ذلك مساحة نافذة السياق ويحافظ على رابط إلى المناقشة الأصلية.

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

كيفية إنشاء الأرشيف

يوفر Hansard تطبيقًا رسوميًا لنظامي Windows وmacOS، إلى جانب واجهة سطر أوامر لأنظمة Windows وLinux وmacOS. قبل الاستيراد، يُستحسن التحقق من المصادر المكتشفة وحجم البيانات المتوقع باستخدام الأمر hansard init --dry-run. يبدأ الاستيراد الأولي الكامل عبر hansard init --since all، ويمكن التحقق من حالته باستخدام الأمرين hansard status وhansard doctor.

لربط البحث بـCodex، يُستخدم hansard integrations add-to codex، ولربطه بـClaude Code يُستخدم hansard integrations add-to claude، أما OpenCode فيُستخدم معه hansard integrations add-to opencode. بعد تغيير الإعدادات، يجب إعادة تشغيل الوكيل. في Codex، يُستدعى البحث عبر المهارة $recall، وفي Claude Code وOpenCode عبر الأمر /recall.

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

قيود يجب عدم نسيانها

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

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

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