لقد قمت بشحن أحد عشر إصدارًا من Neotoma في الفترة ما بين 26 فبراير و1 أبريل 2026. كان [إصدار المطورين] الأولي (/posts/neotoma-developer-release) عمليًا ولكنه صعب. لقد نجح الأمر على جهازي، وفي سير العمل الخاص بي، مع دمج افتراضاتي. وظهرت خمسة أسابيع من تعليقات المقيِّمين، والتجربة اليومية، والاستخدام في العالم الحقيقي، حيث تعطلت مع الجميع.

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

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

والثالث هو سلامة البيانات في ظل الظروف الحقيقية. يغطي هذا المنشور ما تغير في حزمة npm، وليس الموقع أو المستندات.

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

## توقف CLI عن افتراض أنه أنا

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

كان الإصلاح الأول هو دقة المسار. عند تثبيت Neotoma عالميًا عبر npm وتشغيله من دليل عشوائي، تحتاج واجهة سطر الأوامر (CLI) إلى العثور على مواردها الخاصة دون وجود عملية سحب المصدر. أضاف الإصدار 0.3.3 دقة احتياطية من موقع الحزمة المثبتة. تم شحن الإصدار 0.3.8 "openapi.yaml" داخل npm tarball لذا كان ملف المواصفات متاحًا دائمًا، وليس فقط عند استنساخ الريبو.

وجاء الكشف عن البيئة بعد ذلك. تُميِّز واجهة سطر الأوامر (CLI) الآن بين التشغيل من الخروج المصدر والتشغيل من تثبيت npm عالمي. يتم ربط الميزات التي تتطلب مصدرًا (مثل وضع النفق) برسائل خطأ واضحة بدلاً من حالات الفشل المبهمة. تغيرت المصطلحات في مخرجات واجهة سطر الأوامر (CLI) أيضًا: "مسار Neotoma" لموقع وقت التشغيل الذي تم تكوينه، و"الخروج من المصدر" لسير عمل التطوير. استخدمت اللغة السابقة كلمة "repo" لكليهما، الأمر الذي أربك الأشخاص الذين قاموا بالتثبيت عبر npm وليس لديهم repo.

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

كان الإصدار 0.3.11 هو أكبر إصدار منفرد لواجهة سطر الأوامر (CLI). لقد أضافت بحثًا مرنًا ('--entities' و'--file' مع المعرفات الموضعية، و'--identifier'، و'--query' كأسماء مستعارة)، ومسار إدخال منظم مفضل للمتجر ('--entities' و'--file' جنبًا إلى جنب مع `--json=` الموجود)، و'storage merge-db' لدمج قواعد بيانات SQLite مع أوضاع حل التعارض. جعل الإصدار 0.4.0 معالجة الوسيطات أكثر موثوقية عبر أغلفة العقدة والكعكة والدينو.

التأثير الصافي: انتقل سطر الأوامر من "يعمل على جهازي" إلى "يعمل على تثبيت npm جديد في دليل عشوائي على جهاز شخص آخر." وكانت تلك الفجوة أكبر مما كنت أتوقع.

## أصبح MCP آمنًا للاستخدام اليومي للوكيل

خادم MCP هو الطريقة التي يتفاعل بها الوكلاء مع Neotoma. يجب أن تكون موثوقة بطرق مختلفة عن CLI. لا يقوم الوكلاء بقراءة رسائل الخطأ. إنهم يعيدون المحاولة، أو يسيئون تفسير، أو يسقطون السياق بصمت.

كان الإصلاح الأول لـ MCP تافهًا ولكنه مهم. v0.3.8 تم نقل سجلات معلومات تسجيل المخطط من stdout. يستخدم MCP stdio للاتصال المنظم بين الوكيل والخادم. يؤدي تسجيل الدخول إلى نفس الدفق إلى إتلاف البروتوكول. سيحصل الوكلاء على ردود مشوهة أو يتعطلون. أدى نقل السجلات إلى stderr إلى إصلاح فئة من حالات الفشل الصامتة التي كان من الصعب تشخيصها.

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

واصل الإصدار 0.4.0 هذا العمل من خلال إدخال تحسينات على إنشاء المخطط الزمني وإسقاط المراقبة وحساب اللقطات وسلوك تسجيل المخطط. هذه هي الآليات الداخلية التي تحدد ما يراه الوكلاء عند الاستعلام عن حالة الكيان. إن الحصول عليها بشكل صحيح يعني حصول الوكلاء على إجابات متسقة وصحيحة عبر الجلسات.

## أصبحت تصفية الصفحات والكيانات صادقة

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

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

## أصبح دمج قاعدة البيانات أداة حقيقية

لقد [كتبت عن فقدان واستعادة 6000 ذكرى](/posts/how-i-lost-and-recovered-6000-memories) في مارس. حفزت هذه التجربة على شحن "storage merge-db" كأمر CLI مناسب في الإصدار 0.3.11.

يدمج الأمر قاعدتي بيانات SQLite مع معالجة واضحة للتعارض. ثلاثة أوضاع: "آمن" (افتراضي، يفشل في أي تعارض)، "الاحتفاظ بالهدف" (يفوز الهدف عند الاصطدام)، "الاحتفاظ بالمصدر" (فوز المصدر). يقوم وضع التشغيل الجاف بمعاينة ما سيتم إدراجه وما قد يتعارض قبل الالتزام. بعد الدمج، يقوم الأمر بإعادة حساب لقطات الكيان من سجل المراقبة بحيث تظل الحالة المشتقة صحيحة.

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

## توسيع دعم الأدوات المتعددة

يدعم إصدار المطور Cursor وClaude وChatGPT عبر MCP. أضاف الإصدار 0.3.11 وثائق تكامل ChatGPT واضحة وتم شحن `openapi_actions.yaml`، وهو سطح على شكل OpenAPI لسير عمل إجراءات GPT وHTTP المخصصة. وهذا يعني أن ChatGPT يمكنه استهلاك Neotoma ليس فقط من خلال MCP ولكن من خلال واجهة الإجراءات الأصلية التي تستخدمها GPTs المخصصة.

تم تحديث عقد OpenAPI نفسه عبر الإصدارين 0.3.11 و0.4.0 ليعكس التغييرات في طبقة الإجراء. إذا كنت تستهلك Neotoma برمجيًا عبر واجهة برمجة التطبيقات (API)، فإن هذه الإصدارات تتطلب إعادة فحص أي عملاء تم إنشاؤهم.

## تمت إزالة مسار الاستخراج القديم

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

هذا هو نوع التغيير غير المرئي للمستخدمين ولكنه مهم لاتجاه المشروع. الورم نيوتوما هي طبقة الحقيقة، وليست طبقة الاستدلال. مسار الاستخراج غير واضح هذا الخط. الآن لا.

## ما علمتني إياه السرعة

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

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

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

المرحلة القادمة مختلفة. أجابت الأسابيع الخمسة الأولى "هل ينجح الأمر مع شخص ليس أنا". يجيب الامتداد التالي على "لماذا يتحول شخص ما عما قام ببنائه بالفعل."

يقوم ما لا يقل عن عشرة أشخاص في [مجموعة التقييم](/posts/customer-research-through-agents) ببناء ذاكرة الوكيل الخاصة بهم. ملفات Markdown، SQLite، نبضات JSON، CRMs ذات الملفات المسطحة. نفس المشكلة، وتنفيذ مختلف. قام العديد منهم بتسمية المحفزات الدقيقة للوقت الذي يتعطل فيه الحل الخاص بهم: عمليات الكتابة المتزامنة من وكلاء متعددين، وأسئلة المصدر التي لا يمكنهم الإجابة عليها، والتي تتجاوز بضع عشرات من الكيانات النشطة. تلك المحفزات هي خارطة الطريق الخاصة بي.

تأتي الأهداف التالية الملموسة مما طلبه المقيِّمون، وليس من قائمة أمنيات الميزات.

- **إعداد بسيط مع مكافأة فورية.** تعمل واجهة سطر الأوامر (CLI) على أجهزة أخرى الآن، ولكن "يعمل" ليس مثل "خمس دقائق لتقدير القيمة". قضى أحد المقيمين ساعة في قراءة المستندات قبل الإعداد على جهاز افتراضي. يجب أن يستغرق ذلك خمس دقائق، وأول شيء يحدث بعد التثبيت يجب ألا يكون قاعدة بيانات فارغة. يجب أن تقوم عملية الإعداد التي يحركها الوكيل بفحص ملفاتك المحلية، وملء Neotoma بسجلات حقيقية، وإظهار جدول زمني أو رؤية لم تكن لديك من قبل. لحظة aha ليست "تم تثبيتها". لحظة aha هي "أنها تعرف بالفعل شيئًا مفيدًا عن بياناتي."
- **قصة تعايش واضحة.** تساءل العديد من المقيمين عما إذا كان يجب أن يعيش Neotoma جنبًا إلى جنب مع ذاكرة Claude التلقائية أو ذاكرة ChatGPT المدمجة، أو استبدالهما. الجواب جنبًا إلى جنب، ويجب على المنتج أن يوضح ذلك.
- **التعمق في المجالات التي يكون فيها المصدر غير قابل للتفاوض.** الرعاية الصحية، والامتثال، والتدقيق المالي: قال المقيِّمون في تلك المجالات إن اللغة مناسبة بالفعل. ويكمن العمل في وضع المخططات والضمانات الملموسة لتلك القطاعات.

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

- **التقارب المحدود.** الوكلاء عشوائيون. يمكن أن تنتج رسالة المستخدم نفسها أنواعًا مختلفة من الكيانات وأسماء الحقول وهياكل العلاقات اعتمادًا على الحالة المزاجية للنموذج. يحتوي مثيلي على 170 نوعًا من الكيانات، وبعض هذا التنوع عبارة عن انجراف، وليس وجودًا حقيقيًا. تضيف الإصدارات التالية تطبيع وقت الكتابة: تعيينات الأسماء المستعارة بحيث يتم حل "الشراء" و"المعاملة" إلى نفس النوع الأساسي، ومطابقة الحقول الغامضة بحيث لا يؤدي "المبلغ" و"المبلغ_eur" إلى تفرع المخطط، والتخزين المعزز بالاسترجاع بحيث يتحقق النظام من التكرارات قبل أن يقوم الوكيل بإنشائها.
- **حوكمة المخطط.** في الوقت الحالي، يمكن لأي وكيل اختراع نوع كيان جديد في المتجر الأول. هذه الحرية مفيدة في وقت مبكر ولكنها تخلق مشكلة تنظيف على نطاق واسع. تضيف طبقة الإدارة المخططة تسجيل الاسم المستعار، ودورات حياة الإهمال، والتحذيرات التشخيصية عندما ينحرف المتجر عن المخطط الأساسي. يظل النظام متساهلاً في الكتابة ولكنه يقدم تعليقات في الاستجابة حتى يقوم الوكلاء بالتصحيح الذاتي.
- **التنفيذ التدريجي.** يتم استنتاج المخططات اليوم مرة واحدة ولا يتم تشديدها مطلقًا. الخطوة التالية هي تتبع الثقة: بعد إجراء ما يكفي من الملاحظات للنوع، يتبلور المخطط ويمكن للنظام التحذير من فقدان الحقول المشتركة، وعدم تطابق الكتابة، وأنماط العلاقات المعطلة. عدم حجب المتاجر، فقط إظهار ما يبدو خاطئًا. يصبح الوضع الصارم اختياريًا للأنواع عالية المخاطر مثل السجلات المالية حيث يكون تباين الاستخراج مهمًا.

Neotoma هو [مفتوح المصدر على GitHub](https://github.com/markmhendrickson/neotoma). إذا قمت بتجربة إصدار المطور وواجهت بعض الصعوبات، فقد تمت معالجة الكثير منها في هذه الإصدارات. إذا لم تكن قد جربته بعد، فإن أفضل نقطة بداية هي [اطلب من وكيلك تقييم ما إذا كان Neotoma يناسب سير عملك](https://neotoma.io/evaluate). يقرأ الوكيل الصفحة، ويفحص الإعداد الخاص بك، ويخبرك بصراحة ما إذا كان مناسبًا قبل تثبيت أي شيء.