فحوصات anti-slop

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

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

ما الذي تبحث عنه؟#

تُصنّف القواعد في مجموعات. كل قاعدة إما أن تحظر، تقدم نصيحة أو تسجل معلومات.

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

كل قاعدة في قواعد Anti-slop، والتي تُفتح من صف قواعد Anti-slop في ضبط الجودة، توضح ما الذي تتطابق معه، سبب أهميتها وما الذي تفعله في الإعدادات الافتراضية للمنظمة أو في مشروع معين.

فقط ما أُدخل حديثًا في التغيير هو ما يعيق سير العمل.#

معظم المستودعات تحتوي بالفعل على بعض من هذه الأنماط. تقوم قواعد Anti-slop بتصنيف كل نتيجة إلى واحدة من ثلاث مجموعات:

• مُدخل حديثًا — جديد في هذا التغيير.
• تم تعديله — موجود مسبقًا، في سطر أو دالة تم تعديلها بواسطة التغيير.
• موجود مسبقًا — موجود في مكان آخر من المستودع.

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

تنظيف الديون التقنية أسبوعيًا#

الديون التقنية الموجودة مسبقًا لا تعيق سير العمل، لكن لا يجب أن تبقى. افتح مشروعًا في ضبط الجودة، ووسّع Anti-slop وقم بتفعيل تنظيف الديون التقنية أسبوعيًا. مرة كل أسبوع، يقوم Coroid بمسح الفرع الافتراضي للمشروع وإنشاء مهام تنظيف صغيرة للديون التي يجدها، بعدة ملفات في كل مرة. يحتفظ بأقصى عدد من مهام التنظيف المفتوحة كما يحدده عدد المهام المفتوحة في الوقت نفسه (افتراضيًا اثنتان)، لذا لا يطغى تنظيف الديون على العمل الذي طلبه المستخدمون. كل تغيير يوفر خيار التراجع.

يتم ضبط عملية التنظيف لكل مشروع على حدة. جدولها الزمني مدرج في مصنع ويوضح أن ضبط الجودة هو من يديره؛ غيّره هنا وليس هناك.

كان عمل جديد يوفر قالب «تنظيف الديون التقنية أسبوعيًا». الجدول الذي تنشئه منه يستمر في العمل ويُسمى تحت خيار التفعيل؛ أوقفه في مصنع إذا حلّ تنظيف الديون محله.

تفعيله#

في ضبط الجودة، اختر الإعدادات الافتراضية للمنظمة أو مشروعًا معينًا وقم بتفعيل Anti-slop. يضيف خمسة متطلبات:

1. لا يزال الاختبار يثبت صحة التغيير.
2. لا يتم شحن أي شيء غير مكتمل أو مخصص للاختبار فقط.
3. لا توجد ديون تقنية هيكلية جديدة.
4. يبقى التغيير ضمن نطاقه ويتم قراءته كما في مستودع الكود الخاص بك.
5. التبعيات الجديدة حقيقية وموثوقة.

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

اختيار انضباط التغيير#

يحدد انضباط التغيير مدى ابتعاد التغيير عن المعايير المسموح بها من قبل وكيل المطور:

• جراحي — يلتزم فقط بما تتطلبه المواصفات؛ أما المشاكل الأخرى فيتم الإبلاغ عنها، ولا يتم إصلاحها.
• متوازن (افتراضي) — يصلح أيضًا المشاكل الصغيرة في الأسطر التي تمسها التغييرات على أي حال.
• إصلاحي — يقوم أيضًا بتنظيف النتائج المكتشفة داخل الدوال التي تعدلها التغييرات.

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

تكييفه مع قاعدة الكود الخاصة بك#

• تجاوزات القواعد — افتح قاعدة في إعدادات قواعد Anti-slop لتحديد ما إذا كانت تحظرها، أو تنصح بها، أو تبلغ عنها فقط، أو توقف تنفيذها، سواء للإعدادات الافتراضية للمؤسسة أو لمشروع معين.
• حزم القواعد — أنماطك الخاصة، واستيراداتك وتبعياتك المحظورة، وحدود حجم الملفات، أو نتائج الأدوات التي تستخدمها بالفعل (SARIF). كل عملية حفظ تُنشئ إصدارًا جديدًا، ويقوم النظام بالتحقق من الإصدار المحدد.
• العزل — أنماط لا ترغب في نسخها مرة أخرى، ولكل منها البديل الذي يجب استخدامه بدلاً منها. يُطلب من الوكلاء عدم نشرها، ويتم وسم النسخ الجديدة منها.
• مسارات مستثناة — في قسم ضبط الجودة → Anti-slop، الملفات المولدة أو الموردة التي لا تقرأها أداة Anti-slop، حيث يتم تحديد نمط واحد لكل سطر (dist/**، vendor/**). استخدمها لنتائج بناء مُلتزم بها: ملف تم تعديله يتجاوز حد 512 كيلوبايت المحدد للماسح الضوئي، مما يجعل عمليات التحقق غير متاحة.
• ملف المستودع — .coroid/anti-slop.yml في المستودع يمكنه إضافة قواعد واستثناء generated/، vendor/، node_modules/ و __generated__/ المجلدات. يتم قراءته من قاعدة التغيير، لذا لا يمكن للتغيير تخفيف قواعده الخاصة، ويتطلب تعديله موافقة.
• ملفات القفل وكتالوجات الترجمة — تحسب أداة Anti-slop تغييراتها لكنها لا تقرأها. الكتالوجات هي الملفات .coroid/i18n.json تحددها عند قاعدة التغيير؛ تقوم أداة العولمة بقراءتها. أي قاعدة خاصة بك تسميها لا تزال تقرأها.

تبعيات جديدة#

تقترح النماذج أحيانًا حزمة غير موجودة، وغالبًا ما تكون مزيجًا منطقيًا من اسمين حقيقيين. يقوم المهاجمون بتسجيل مثل هذه الأسماء على منصتي npm وPyPI حتى يتم تشغيل كودهم عند التثبيت التالي، وهي هجمة تُعرف باسم slopsquatting. تصفها منظمة Cloud Security Alliance بالتفصيل: تقريبًا واحدة من بين كل خمس عينات كود من أصل 2.23 مليون عينة في الدراسة التي استشهدت بها تذكر حزمة واحدة على الأقل غير موجودة.

تبحث أداة Anti-slop عن كل تبعية تضيفها التغييرات إلى package.json، ملف متطلبات أو pyproject.toml:

• كتل — حزمة غير موجودة في سجلها العام، أو حزمة تُصنفها OSV على أنها ضارة. تعود التغييرات إلى وكيل المطور قبل أن تصل إليك.
• تنبيهات — حزمة تم نشرها لأول مرة منذ أقل من 30 يومًا، أو لها عدد تنزيلات قليل جدًا، أو اسمها يختلف بحرف أو حرفين عن اسم حزمة شائعة، أو حزمة npm تنفذ كودًا عند تثبيتها. كما تنبه أداة Anti-slop لحزمة PyPI التي تُصنف إصدارها على أنه ضار، لأن Coroid لا تعرف الإصدار الذي سيتم تثبيته وفقًا للمتطلبات.

إذا تعذر الوصول إلى السجل، تذكر النتيجة ذلك وتقرر الحزم التي يمكنها البحث عنها. ولا تؤخر التغييرات.

الأسماء التي تبحث عنها Coroid#

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

• منصة npm وPyPI العامة، ما لم يحدد المستودع سجلًا آخر — يتم البحث عن كل تبعية جديدة، باستثناء الحالات التي .npmrc، ملف متطلبات، pip.conf، uv.toml، Pipfile أو إعدادات أداة Python، بجانب ملف التوضيح أو في مجلد أعلى منه، تحدد سجلًا أو فهرسًا آخر. اختيار هذا الخيار يتطلب منك التأكيد على عدم وجود سجل خاص مُعدّ خارج المستودعات، مثل في إعدادات المستخدم أو CI، ويتم تسجيل تاريخ التأكيد والشخص الذي قام به. أما حزم npm ذات النطاق المحدد (@scope/name) فيتم البحث عنها فقط حيث .npmrc تحدد السجل العام لنطاقها.
• فقط عندما يحدد المستودع السجل العام — الإعداد الافتراضي. لا يتم البحث عن حزمة إلا عندما .npmrc يحدد registry=https://registry.npmjs.org/، وملف المتطلبات الخاص بها يحتوي على سطر --index-url https://pypi.org/simple واحد فقط، أو عندما تستخدم تبعية Poetry مصدرًا يشير إلى pypi.org. معظم المستودعات لا تتبع أيًا من هذين الخيارين، لذا لا يتم التحقق من معظم التبعيات الجديدة.
• معطل — لا يتم البحث عن أي أسماء، وبالتالي لا يتم اكتشاف الحزم المختلقة.

فقط أسماء التبعيات الجديدة تغادر Coroid. تذهب إلى registry.npmjs.org و pypi.org، إلى api.npmjs.org لمعرفة أعداد تنزيلات npm، وإلى api.osv.dev (باستخدام إصدار npm) لتقارير الحزم الضارة. لا يتم إرسال كودك أبدًا. يتم الاحتفاظ بالنتائج لمدة يوم واحد على الأكثر، حتى لا يتم البحث عن نفس الاسم مرة أخرى لكل تغيير.

نتائج والقبول#

تظهر نتائج المهمة في قسم الجودة ضمن مصنع. عندما يصلح وكيل المطور النتائج التي تعيق العمل قبل وصول التغيير إلى مرحلة المراجعة، يفتح القسم بعبارة تم اكتشافه بواسطة anti-slop قبل المراجعة، والقواعد التي اكتشفها وفي قسم عرض المكان والزمان، ملف كل نتيجة وسطرها بالإضافة إلى الفحص الذي اكتشفها. مصنع، ضمن قسم الديون، يحصي الاختصارات التي تم اكتشافها قبل المراجعة خلال آخر 30 يومًا، ويُظهر للمالكين والمشرفين المشاريع التي لم تبدأ بعد في فحصها، مع عبارة تفعيل anti-slop.

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

تقييم القواعد#

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

وكلاؤك الخاصون#

يمكن للقواعد نفسها توجيه الوكلاء الذين تقوم بتشغيلهم بنفسك:

• تنزيل مقتطف AGENTS.md، في قسم Anti-slop إعدادات مشروع ما في ضبط الجودة، يوفر انضباط التغييرات في المشروع وقواعد العزل والقواعد الرئيسية كقسم يمكن لصقه في تعليمات الوكلاء.
• من خلال خادم Coroid MCP server، anti_slop_rules يصف سياستك المنشورة و anti_slop_scan يقوم بفحص فرع من مشروع متزامن، بوضعية للقراءة فقط.