Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents

بناءً على ورقة البحث "Lore: إعادة توظيف رسائل Git Commit كبروتوكول معرفي مهيكل لوكلاء البرمجة بالذكاء الاصطناي" (Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents) للكاتب إيفان ستيتسنكو (مارس 2026)، إليكم ملخصاً تقنياً مفصلاً.

1. بيان المشكلة: "ظل القرار" (The Decision Shadow)

تحدد الورقة عقبة حرجة في عصر تطوير البرمجيات بمساعدة الذكاء الاصطناعي: فقدان المعرفة المؤسسية المعروفة باسم "ظل القرار".

• الظاهرة: كل عملية "commit" للكود تلتقط الـ diff (ما الذي تغير) ولكنها تتجاهل السبب (لماذا تغير). يتضمن ذلك القيود، والبدائل المرفوضة، وتقييمات المقايضات، والسياق الاستشرافي.
• النتيجة: مع تحول وكلاء الذكاء الاصطناعي إلى المنتجين والمستهلكين الأساسيين للكود، فإنهم يفتقرون إلى "المعرفة الضمنية" اللازمة لفهم المنطق الهيكلي وراء الكود الموجود. يؤدي هذا إلى ظهور "الكود الموروث" (Legacy Code) حيث يعمل الكود ولكن منطقه يكون غامضاً.
• القيود الحالية: الحلول الحالية مثل سجلات قرارات الهندسة المعمارية (ADRs) هي عالية المستوى للغاية (تفتقر إلى تفاصيل التنفيذ) وتعاني من مشكلة "انزياح المزامنة". أما التوائم الرقمية للكود (Code Digital Twins) ورسوم المعرفة البيانية (Knowledge Graphs) فهي ثقيلة جداً وتتطلب بنية تحتية ضخمة. كما أن رسائل الـ commit المولدة بالذكاء الاصطناعي تكتفي حالياً بتلخيص الـ diff (ما الذي تغير) بدلاً من تلخيص القصد (لماذا تغير).

2. المنهجية: بروتوكول Lore

يقترح المؤلف Lore، وهو بروتوكول خفيف الوزن يعيد توظيف رسالة Git commit الحالية لتصبح سجلاً للقرار مهيكلاً وقابلاً للتحليل من قبل الآلة.

البنية الأساسية

• الآلية: يستخدم Lore خاصية Git Trailers، وهي ميزة أصلية في Git لإنشاء أزواج (مفتاح-قيمة) في رسائل الـ commit. هذا لا يتطلب أي بنية تحتية جديدة، أو قواعد بيانات، أو خوادم.
• "ذرة Lore" (The Lore Atom): يُعاد تعريف الـ commit بوصفه وحدة ذرية من المعرفة المؤسسية. وهي مرتبطة بشكل غير قابل للتغيير بتغيير الكود المحدد، مما يضمن عدم انزياح المعرفة عن السياق أبداً.
• هيكل التنسيق:
  1. سطر القصد (Intent Line): يصف لماذا تم إجراء التغيير (ليس فقط ما الذي تغير).
  2. الجسم (Body): السياق السردي.
  3. الـ Trailers (البيانات الوصفية المهيكلة): أزواج (مفتاح-قيمة) قابلة للقراءة آلياً تحتوي على بيانات قرار محددة.

مفردات الـ Trailers (حقول البيانات الوصفية الرئيسية)

يحدد البروتوكول "trailers" محددة لالتقاط سياق القرار:

• Constraint: (القيد) القواعد التي شكلت القرار (مثال: "خدمة المصادقة لا تدعم فحص الـ token").
• Rejected: (المرفوض) البدائل التي تم تقييمها واستبعادها، مع ذكر الأسباب (لمنع الوكلاء المستقبليين من إعادة استكشاف المسارات المسدودة).
• Confidence: (الثقة) تقييم المؤلف (منخفض، متوسط، مرتفع).
• Scope-risk: (خطر النطاق) مدى تأثير التغيير (ضيق، متوسط، واسع).
• Reversibility: (قابلية التراجع) ما إذا كان التغيير نظيفاً، أو يتطلب هجرة بيانات، أو غير قابل للتراجع.
• Directive: (التوجيه) تعليمات استشرافية للمعدلين المستقبليين (مثال: "لا تقم بالتضييق دون التحقق من المصدر العلوي").
• Tested / Not-tested: (تم الاختبار / لم يتم الاختبار) حالة التحقق والفجوات الموجودة.
• Related: (مرتبط) مراجع لعمليات commit ذات صلة عبر الـ hash.

أدوات العمل وتفاعل الوكلاء

• أداة CLI: واجهة سطر أوامر مستقلة (lore) تسمح للوكلاء بالاستعلام عن التاريخ.
  • الاكتشاف: يقوم الوكلاء بتشغيل lore context <path> لتحميل تاريخ القرار.
  • التصفية: يستخدم الوكلاء lore rejected <path> لتجنب الحلول المستبعدة سابقاً.
  • التحقق: تقوم أداة lore validate بالتحقق من الامتثال للتنسيق.
• سير عمل الوكيل: يكتشف الوكلاء البروتوكول عبر الـ CLI، ويجمعون القيود قبل تعديل الكود، ثم يقومون بتسلسل سياق قرارهم الخاص في "ذرات Lore" عند إجراء الـ commit. لا يتطلب الأمر أي SDK خاص للوكيل؛ بل يتطلب فقط تنفيذ أوامر الـ shell.

3. المساهمات الرئيسية

1. تعريف البروتوكول: أول مقترح رسمي لاستخدام رسالة الـ commit نفسها كقناة مهيكلة وقابلة للتحليل آلياً للتواصل بين الوكلاء عبر الزمن.
2. حل بدون بنية تحتية: على عكس النهج المنافسة (رسوم المعرفة البيانية، التوائم الرقمية)، يستفيد Lore من بنية Git التحتية الموجودة، مما يجعله قابلاً للنشر عالمياً.
3. تحول في مستوى التفصيل: ينقل عملية التقاط المعرفة من المستوى المعماري (ADRs) إلى مستوى التنفيذ، حيث يلتقط الـ "لماذا" الدقيقة وراء كل دالة ووحدة برمجية.
4. تصميم متمحور حول الوكيل: صُمم البروتوكول خصيصاً ليستهلكه وينتجه وكلاء الذكاء الاصطناعي، مما ينقل عبء التوثيق من الكتابة البشرية إلى التسلسل الآلي للوكلاء.

4. النتائج واستراتيجية التحقق

• التحليل المقارن: تجادل الورقة بأن Lore يتفوق على ADRs (أفضل في المزامنة)، والتعليقات البرمجية (تاريخ ثابت)، والملخصات المولدة بالذكاء الاصطناعي (التي تضيف معلومات جديدة بدلاً من مجرد إعادة الصياغة).
• التحقق التجريبي المقترح: يحدد المؤلف دراسة مدتها 6 أشهر تقارن بين فريقين يعملان على نفس المشروع:
  • المجموعة الضابطة: تستخدم الـ conventional commits التقليدية.
  • المجموعة التجريبية: تستخدم Lore.
  • المقاييس: معدل نجاح مهام الوكيل، الوقت المستغرق للوصول للحل الصحيح، معدل اقتراح الحلول المرفوضة سابقاً، ودورات المراجعة.
• اختبار الضغط: تعالج الورقة الاعتراضات المحتملة:
  • العبء الإضافي: ضئيل بالنسبة للوكلاء (الذين يمتلكون السياق بالفعل)؛ ويتم تخفيفه عبر lore validate.
  • نافذة السياق (Context Windows): يقوم Lore بضغط النصوص الخام إلى بيانات مهيكلة، مما يجعله أكثر كفاءة من تغذية سجلات الدردشة الكاملة.
  • الثقة: رغم أنه لا يحل مشكلة الثقة، إلا أنه يجعل جودة القرارات قابلة للتدقيق.

5. الأهمية

• حل فجوة الـ "لماذا": يعالج Lore القصور الجوهري في أدوات برمجة الذكاء الاصطناعي الحالية: يمكنهم رؤية ما هو الكود الموجود، لكن لا يمكنهم إعادة بناء لماذا وجد هذا الكود بشكل موثوق.
• الحفاظ على الذاكرة المؤسسية: من خلال معاملة الـ commits كأدوات تسجيل قرارات غير قابلة للتغيير، يخلق Lore "عجلة معرفية" حيث تتراكم ذكاءات المشروع بمرور الوقت، مما يمنع تراكم "الكود الموروث" الذي يعمل وظيفياً ولكنه غير مفهوم.
• القابلية للتوسع: نظرًا لاعتماده على Git القياسي، يمكن تطبيق Lore فوراً على أي مستودع موجود دون تكلفة الانتقال إلى منصات جديدة أو بناء أنظمة خلفية معقدة.
• تحول في النموذج الفكري: يعيد تعريف رسالة الـ commit من مجرد تسمية مقروءة للبشر إلى واجهة بيانات مهيكلة لوكلاء الذكاء الاصطناعي، مما يسمح للوكلاء المستقلين بالاستنتاج حول تطور الكود بنفس العمق الذي يمتلكه المطورون البشر.

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