Laravel Boost يستخرج قواعد الذكاء الصناعي من المشاريع القائمة مع مراجعة المطوّر قبل اعتمادها
أضاف Laravel Boost مهارة infer-conventions لفحص المشاريع القائمة واستخلاص قراراتها البرمجية الخاصة، مثل حدود المعمارية وأنماط تمثيل البيانات، ثم اقتراحها كقواعد قابلة للمراجعة. لا تُسجّل القواعد إلا بعد أن يرى المطوّر الأدلة ويوافق عليها، وتُحفظ داخل المستودع تحت .ai/rules.
أبرز النقاط
- مهارة `infer-conventions` في Laravel Boost تستخرج قرارات المشروع القائمة وتقترح تحويلها إلى قواعد ذكاء صناعي.
- الفحص يغطي نحو 49 بُعداً من conventions ضمن 10 مجموعات، منها المعمارية وModels وControllers والاختبارات.
- لا تُسجّل القاعدة المقترحة قبل مراجعة المطوّر للأدلة والصياغة والنطاق؛ والحد الحالي هو ثلاثة أمثلة متسقة بلا بديل منافس ذي معنى.
- يركز Boost على القرارات الخاصة بالتطبيق، لا على defaults الخاصة بـ Laravel أو الخيارات التي تفرضها أدوات مثل Pint وRector.
- تُخزَّن القواعد المعتمدة في `.ai/rules` وتبقى قابلة للتحرير، ضمن version control، ومراجعة pull requests.
- لا يوفر Boost حالياً تدقيقاً آلياً للقواعد التي أصبحت قديمة أو لم تعد مدعومة بالكود.
المشروع الجديد يستطيع فريقه تدوين قواعد العمل تدريجياً، لكن المشروع القائم يحمل سنوات من القرارات الضمنية داخل الـ controllers والـ models والاختبارات وبنية المجلدات. Laravel Boost يحاول الآن تحويل الجزء المفيد من هذه المعرفة إلى قواعد يمكن لوكلاء AI استخدامها أثناء العمل على المستودع.
بدلاً من الاعتماد على فحوصات PHP ثابتة فقط، يستخدم Boost مهارة agent باسم infer-conventions. تفحص المهارة جوانب منظمة من المشروع، تشمل المعمارية وModels وControllers والتحقق من المدخلات وتمثيل البيانات والاختبارات وغيرها، عبر نحو 49 بُعداً ضمن 10 مجموعات.
الفكرة ليست تسجيل كل نمط متكرر. القاعدة المفيدة هي القرار الذي قد يختار وكيل AI تنفيذاً مختلفاً له لو لم يكن السياق متاحاً. فقاعدة مثل «تخزين المال بوحدة السنتات الصحيحة» تؤثر في النمذجة والتحقق والتسلسل والاختبارات، بينما استخدام anonymous migration classes غالباً ما يعكس سلوك Laravel الافتراضي ولا يضيف معرفة خاصة بالمشروع.
لماذا لم يعتمد Boost على الفحص الحتمي فقط؟
بدأت التجربة بأمر Artisan باسم boost:infer-conventions، مع خمسة كواشف لأنماط مثل أسلوب مفاتيح enums، واستخدام guarded مقابل fillable، وأنماط query scopes وقواعد التحقق. لم يستهلك هذا النهج أي model tokens، لكنه تطلب كتابة كاشف PHP مخصص لكل convention جديد، بما يشمل جمع الأدلة وحساب الثقة وصياغة المخرجات.
المشكلة الأخرى أن كثرة ظهور النمط لا تعني بالضرورة أنه قرار مهم. لذلك انتقل Boost إلى مهارة agent قادرة على تقييم الدليل ضمن سياق defaults الخاصة بـ framework، وأدوات الإنفاذ، والمعمارية، وتاريخ المشروع.
الأدلة أولاً، ثم قرار الفريق
لكل قاعدة مقترحة، يعرض Boost الملفات التي تدعمها. والحد الحالي للاقتراح هو وجود ثلاثة أمثلة متسقة على الأقل، من دون بديل منافس ذي معنى. يمكن للمطوّر رفض القاعدة أو تعديل صياغتها أو تغيير نطاقها قبل تسجيلها.
كما يحافظ التقرير على الأدلة المختلطة كما هي بدلاً من اعتبارها convention معتمداً. الهدف هو وصف الحالة الحالية للكود وإظهار قراراته، لا إعادة تصميم التطبيق أو منح الشرعية لأنماط قد لا تكون مقصودة.
يركز الفحص أيضاً على ما يجب استبعاده من القواعد. خيارات التنسيق أو الأسلوب الميكانيكية التي تستطيع أدوات مثل Pint وRector وlinters وstatic analyzers إنفاذها لا ينبغي تكرارها في تعليمات نصية للوكيل. لكن الاستثناءات المقصودة تبقى مهمة؛ فإذا كان المشروع يحافظ على صيغة قد يعيد Rector كتابتها، يمكن للمهارة عرض ذلك للمراجعة باعتباره قراراً معمارياً أو متعلقاً بالتوافق.
قواعد مرتبطة بالنطاق وتعيش مع الكود
بعد اعتماد القاعدة، يستدعي الوكيل أداة MCP باسم record-rule بثلاث قيم: glob للملفات التي تنطبق عليها القاعدة، وtitle للقرار، وnote للسياق الذي يحتاجه الوكيل. تتولى RuleRepository::write() إنشاء أو تحديث ملف Markdown المناسب، وإضافة المسار إلى الـ frontmatter، ثم إعادة بناء الفهرس المولّد.
تُخزَّن النتيجة في .ai/rules، لتكون قابلة للقراءة والتحرير وخاضعة لـ version control ومراجعة الـ pull requests. ويمكن تحميل القواعد بحسب المسار أو المفهوم؛ فإرشادات الـ Models يمكن أن تنطبق على app/Models/**، وإرشادات الاختبارات على tests/**.
يفصل Boost بين ثلاثة أنواع من تعليمات الوكلاء:
- إرشادات Laravel العامة التي تتكرر عبر المهام.
- Skills للمعرفة المتخصصة وworkflows الموجّهة.
- Rules لقرارات وحدود تطبيق واحد بعينه.
هذا الفصل يهدف إلى إبقاء التعليمات المحمّلة دائماً محدودة، مع توفير معرفة المشروع فقط في الأماكن التي تحتاجها.
الميزة تستهلك model tokens عند تشغيل تدقيق conventions، لذا يقترح Laravel استخدامها عند تبنّي Boost ثم بشكل متقطع مع تطور التطبيق. أما تدقيق القواعد القديمة تلقائياً فليس متاحاً حالياً؛ ويطرح المقال إمكان التحقق مستقبلاً من بقاء الأمثلة المشار إليها وصلاحية نطاقات القواعد، على أن تمر أي إعادة كتابة بمراجعة المطوّر.
لماذا يهم؟
الـ AI agent يحتاج إلى معرفة قرارات المشروع التي لا تظهر دائماً في prompt واحد: أين تذهب business logic، وهل توجد repository layer، وكيف تُمثّل بيانات مثل الأموال. ربط هذه المعرفة بالمستودع ومراجعتها عبر pull requests يمنح الفريق مرجعاً مشتركاً قابلاً للتتبع، بدلاً من الاعتماد على ذاكرة كل مطوّر أو على تعليمات عامة لا تراعي خصوصية التطبيق.