مراجعة Solo-Engine V4 وخلاصة الإصدار المقترح V4.1 Final

الخلاصة التنفيذية

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

لكن العيب الرئيسي ليس نقص القدرات، بل تضخم القواعد وتكرار الحالات وعدم وضوح حدود تشغيل Gem. كما أن تعبيرات مثل «صفر تبعيات»، و«حلقة تلقائية»، و«كود كامل»، و«وكلاء BMAD المتعددون» كانت تحتاج تعريفات أدق كي لا تتحول إلى ادعاءات تشغيلية لا يدعمها السياق الفعلي.

لذلك، الاختيار المقترح هو Solo-Engine V4.1 Final: يحتفظ بحلقة البحث ثم القرار ثم التنفيذ، لكنه يجعل التعليمات الأساسية مكتفية بذاتها، وينقل الإجراءات والقوالب التفصيلية إلى قاعدة المعرفة، ويقصر الأتمتة على ما يمكن تنفيذه فعلًا في الجلسة الحالية وضمن التفويض المتاح.

ما الذي أنجزه V4 بصورة جيدة؟

• فصل مسار التحليل /ana-solo عن مسار التنفيذ الهندسي /ana-bmad.
• اعتماد طبقات واضحة للأدلة: FACT وINFERENCE وASSUMPTION وUNKNOWN.
• منع اختلاق البحث أو الوصول إلى الويب أو أدوات التنفيذ أو نظام الملفات أو Git.
• الفصل بين إنتاج ملفات كود كاملة وبين الادعاء بأن البناء والاختبارات نجحت.
• إضافة بوابات مثل فحص الملاءمة الخوارزمية، وفحص البنية قبل التنفيذ، وضغط الفشل، ومصالحة الحالة.
• تحويل ADR من وثيقة شكلية إلى قرار ذي دورة حياة وحالة قبول مرتبطة بالأدلة.
• اشتراط الإيقاف عند حدود الملفات الكاملة عند طول المخرجات، بدل قطع الملف في منتصفه.
• التعامل مع أدوار BMAD بوصفها زوايا مراجعة داخل Gem واحد، لا بوصفها دليلًا على تشغيل وكلاء مستقلين متعددين. وثائق BMAD تفرق بالفعل بين الوكلاء والمهارات وسير العمل وآليات الاختبار، لذلك لا يصح مساواة Gem واحد تلقائيًا ببيئة تشغيل متعددة الوكلاء. 11014

أين يحتاج V4 إلى تعديل؟

1) لا ينبغي أن تعتمد القواعد الحرجة على قاعدة المعرفة وحدها

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

• عدم اختلاق الأدوات أو نتائج التنفيذ؛
• الفرق بين التسليم والتحقق؛
• تعريف الكود الكامل؛
• شروط الانتقال إلى حالة الإنجاز؛
• حدود التفويض والأثر الجانبي.

2) كثرة القواعد قد تقلل قابلية الالتزام بها

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

3) «الحلقة التلقائية» ليست تشغيلًا في الخلفية

لا يكتسب Gem مهمة خلفية أو طرفية دائمة أو استمرارية عبر الجلسات لمجرد أن التعليمات تطلب «حلقة تلقائية». في V4.1 ينبغي أن تعني الأتمتة فقط حلقة محكومة بما يلي:

• الجلسة الحالية؛
• النطاق الذي فوضه المستخدم صراحة؛
• الأدوات الحقيقية المتاحة فعلًا؛
• حد واضح لإعادة المحاولة؛
• توقف في WAITING_VERIFICATION إذا لم يوجد منفذ تنفيذ حقيقي.

4) إعادة تعريف «صفر تبعيات» بصيغة هندسية قابلة للتدقيق

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

• صفر تبعيات غير معلنة؛
• عدم إضافة تبعيات خارجية جديدة افتراضيًا؛
• تسليم كل تبعية محلية جديدة كاملة؛
• اعتبار لغة البرمجة وبيئة التشغيل وSDK والمنصة المضيفة شروطًا بيئية معلنة، لا تبعيات يمكن للكود إلغاؤها.

5) الكود الكامل يختلف بين مشروع جديد ومشروع قائم

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

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

6) فصل حالات التسليم والتحقق والإنجاز الهندسي

ينبغي تسجيل ثلاث حقائق مستقلة:

• DELIVERY_STATUS: هل أُخرجت الملفات كاملة؟
• VERIFICATION_STATUS: هل شُغل بناء أو اختبار حقيقي؟
• ENGINEERING_STATUS: هل توجد أدلة كافية للقول إن العمل مكتمل هندسيًا؟

فإخراج الملفات لا يساوي نجاح الاختبارات، ونجاح اختبار قديم لا يثبت صحة حزمة كود جديدة.

7) Tavily يجب أن يبقى متكيفًا مع الأداة المتاحة

خيار search_depth=advanced موجود فعليًا في Tavily للبحث عالي الدقة ومرتفع الصلة، لكنه ينطوي على كلفة أو زمن انتظار أعلى مقارنة بالأنماط الأخف. لذلك يجب استخدامه فقط عندما تكون أداة Tavily متاحة بالفعل وحين يستدعي السؤال بحثًا تفصيليًا؛ لا يصح أن يتحول إلى قدرة يدّعيها النص وحده. 2411

8) استبدال التسمية المربكة «إخراج قيمة من SEO»

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

نموذج القرار المقترح

التقييم التالي مراجعة تصميمية داخلية، لا يمثل اختبار أداء تشغيليًا لـ Gemini Gem.

البعد	الوزن	V4	V4.1 Final
حدود Gem وصدقية الأدوات	25%	4.0	4.8
جودة القراءة الثلاثية وDM وDR	20%	4.5	4.8
صمامات الأمان وضغط الفشل	20%	4.6	4.8
إغلاق الكود والتبعيات	15%	4.6	4.9
كثافة التعليمات وقابلية اتباعها	10%	2.8	4.5
استعادة الحالة ومصالحة الأدلة	10%	4.2	4.7
المجموع المرجح	100%	84.2	95.5

تُحسب النتيجة وفق المعادلة التالية:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

القرار:

• الخيار المختار: Solo-Engine V4.1 Final.
• البديل التالي: V4، مناسب لتجارب داخلية محدودة، لكنه ليس الخيار الموصى به كإعداد طويل الأجل.
• السبب الحاسم: التحسن لا يأتي من إضافة قواعد، بل من تقليل التكرار، وتحديد حدود التشغيل، وتعزيز اكتفاء التعليمات الرئيسية بذاتها.
• شرط التحول مستقبلًا: عند الانتقال إلى بيئة تضم وكيلًا مُدارًا أو MCP أو صندوق تنفيذ دائم، الأفضل إضافة Runtime Adapter منفصل بدل حشو وصف الأدوات داخل التعليمات الرئيسية.

مبادئ الإصدار النهائي V4.1

حدود القدرات أولًا

لا يستخدم النظام إلا الأدوات المكشوفة فعلًا في الجلسة. ولا يجوز استنتاج وجود بحث، أو Tavily، أو تنفيذ كود، أو وصول للملفات، أو مساحة عمل دائمة من اسم النموذج أو الخطة أو صياغة الطلب.

عند غياب دليل تنفيذ حقيقي:

• يمكن إنتاج كود كامل؛
• يمكن إجراء مراجعة ساكنة؛
• تكون حالة التحقق NOT_RUN أو STATIC_CHECKED فقط؛
• تبقى الحالة الهندسية WAITING_VERIFICATION؛
• لا يصح الادعاء بعدم وجود أخطاء بناء أو باجتياز الاختبارات أو بالجاهزية للإنتاج.

التنفيذ المستوحى من BMAD لا يعني تشغيل BMAD كاملًا

يمكن توزيع المراجعة على منظورات المنتج والمعمارية والتطوير وضمان الجودة والعمليات داخل Gem واحد. لكن لا ينبغي وصف ذلك بأنه تشغيل فعلي لعدة وكلاء مستقلين. هذا تمييز مهم لأن وثائق BMAD تصف الوكلاء والمهارات وسير العمل كآليات تشغيل محددة. 11014

ضغط الفشل بدل تصنيع النجاح

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

والقاعدة المقترحة: ثلاث دورات تنفيذ-تحقق حقيقية كحد افتراضي. وإذا فشل السبب الجذري نفسه بعد محاولتي إصلاح حقيقيتين متتاليتين، يعود العمل إلى مراجعة معمارية بدل الاستمرار في ترقيع الكود.

اختبارات فشل دنيا يجب ألا ينجو منها النظام

يمكن كشف خلل جوهري في التصميم عبر خمس حالات فقط:

1. غياب منفذ تنفيذ حقيقي، ثم الادعاء بأن الاختبارات نجحت.
2. غياب واجهة محلية لازمة، ثم اختراعها والادعاء بأن المشروع قابل للبناء.
3. تعديل توقيع عام في إصلاح خطأ من دون رفع مستوى الفحص إلى مراجعة بنيوية.
4. قطع تسليم ملف في منتصفه ثم تسجيل التسليم على أنه COMPLETE.
5. عدم توفر Tavily ثم الادعاء بتنفيذ بحث بخيار search_depth=advanced.

ظهور أي حالة منها يعني أن التعليمات الرئيسية ما زالت تحتاج إلى ضغط وتدعيم.

التوصية النهائية

اعتمد Solo-Engine V4.1 Final بوصفه النسخة النهائية الموصى بها. احتفظ من V4 بهيكله القوي: عزل الأدلة، ومصفوفة القرار، والمراجعة المضادة، وخطة التنفيذ، وفحص البنية، وسجل التحقق، ومصالحة الحالة. لكن أعد تنظيمه حول مبدأ بسيط:

لا تدّع قدرة غير متاحة، ولا تساوِ بين إنتاج الملفات وإثباتها، ولا تسمح لنتيجة تقييم أو قالب وثائقي بأن يحل محل دليل تشغيلي.

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