בדיקות אנטי-סלופ

סוכנים כותבים קוד הגיוני במהירות, וחלק מהקוד הזה משתמש בקיצורי דרך שמהנדס זהיר לא היה בוחר בהם: מבחן שהושמט כדי להשיג תוצאה חיובית, שגיאה שנבלעה, פריט עמידה שנשאר במקום, בדיקת סוג שנדחתה, דרך נוספת לבצע פעולה שכבר קיימת בקוד המקור שלך. Anti-slop הבודק מחפש דברים אלה בכל שינוי ושולח את השינוי בחזרה לסוכן המפתחים לפני שאתה רואה אותו.

זוהי בדיקה אחת ב- מדיניות האיכות, ולא ציון נפרד. שינוי עובר את הבדיקה כשהוא אינו מכיל דבר שיחסום אותו.

מה הוא מחפש?#

הכללים מקובצים למשפחות. כל כלל או חוסם, ממליץ או רושם מידע.

• מבחנים — מבחנים ממוקדים או שהושמטו, מבחנים שנמחקו, אימותים שהוסרו או נחלשו, מבחנים שאינם יכולים להיכשל.
• דיכויים — כיבויי lint חדשים, התעלמויות מסוגים ו any המרות.
• בנייה ו- CI — שלבי מבחן שהוסרו או ניטרלו, סף שנמוך יותר, "הצלחה ללא מבחנים", פעולות GitHub שלא נקשרו לקומיט.
• ראיות מבחן — תוצאות מקוריות שנמסרו כאילו נערכו, אפס מבחנים שבוצעו, הפעלה חלקית שדווחה כהשלמה.
• קוד ייצור — שאריות דיבוג, תחליפים, נתוני מוק, הערות למתכנתים, קוד מבחן שנשלח לייצור.
• טיפול בשגיאות — שגיאות שנבלעו, פתרונות חלופיים שמסתירים כישלונות, בדיקות הרשאה שמאפשרות גישה ללא הגבלה.
• תלויות — חבילות שאינן קיימות או שדווח עליהן כזדוניות, חבילות חדשות שנקראות כמו חבילה פופולרית, חבילות שמריצות קוד בעת התקנתן, קבצי מניפסט ששונו ללא קובץ הנעילה שלהם.
• אבטחה — סיסמאות בקוד, בדיקות TLS שנכבו, בדיקות אישור שהוסרו, סקריפטים שנטענו ורצו ישירות מהרשת.
• הערות, ארכיטקטורה, היקף השינוי, אחסון מטמון וה- מסלול הסוכן — רישום של מה שעשה הסוכן, כמו עריכת מבחן מיד לאחר שנכשל.

כל כלל ב- כללי Anti-slop, שנפתחים משורת Anti-slop ב-בקרת איכות, מציגים מה הם תואמים, מדוע הם חשובים ומה הם עושים בהגדרות ברירת המחדל של הארגון או בפרויקט.

רק מה שנוסף בשינוי חוסם את הבדיקה.#

ברוב מאגרי הנתונים כבר קיימים חלק מהדפוסים האלה. Anti-slop מסווג כל ממצא לתוך אחת משלוש הקבוצות:

• נוסף — חדש בשינוי הזה.
• נגיעה — כבר קיים, בשורה או בפונקציה שהשינוי עורך.
• קיים — במקום אחר במאגר הנתונים.

רק ממצא נוסף של כלל חוסם גורם לכישלון בבדיקה. ממצאי נגיעה וקיים נרשמים כדי שתוכל לעקוב אחר החוב שלך במפעל, תחת כותרת חוב, ולפתוח משימה לתיקון הממצאים של הכלל שם, אך הם לעולם לא יעכבו עבודה שאינה קשורה. העברת קוד אינה נחשבת כהוספתו; העתקתו כן.

ניקוי חוב שבועי#

החוב הקיים אינו חוסם, אך אין צורך שיישאר. פתח פרויקט ב-בקרת איכות, הרחב Anti-slop והפעל ניקוי חוב שבועי. פעם בשבוע Coroid סורק את ענף ברירת המחדל של הפרויקט ופותח משימות ניקוי קטנות עבור החוב שהוא מוצא, כמה קבצים בכל פעם. הוא שומר פתוחים לכל היותר כמו מספר משימות פתוחות בכל פעם מציין (שתיים כברירת מחדל), כך שהניקוי לעולם לא ידחוק הצידה את העבודה שאנשים ביקשו. כל שינוי מאפשר ביטול.

הניקוי מוגדר לפי פרויקט. לוח הזמנים שלו מופיע במפעל ומציין ש-בקרת איכות מנהלת אותו; שנה אותו כאן, לא שם.

עבודה חדשה הציעה בעבר תבנית "ניקוי חוב טכני שבועי". לוח זמנים שיצרת ממנה ממשיך לפעול ונקרא תחת המתג; השהה אותו במפעל אם הניקוי של החוב מחליף אותו.

הפעלתו#

ב- בקרת איכות, בחר בברירת המחדל של הארגון או בפרויקט והפעל Anti-slop. הוא מוסיף חמישה ציפיות:

1. המבחנים עדיין מוכיחים את השינוי.
2. שום דבר לא גמור או רק למבחנים לא יישלח לייצור.
3. אין חוב מבני חדש.
4. השינוי נשאר בהיקף ונראה כמו הקוד המקור שלך.
5. תלויות חדשות הן אמיתיות ואמינות.

השינוי נכנס לתוקף מיד: הריצה הבאה של הפרויקט הזה, או של כל הפרויקטים שעוקבים אחר ברירת המחדל, כוללת את הבדיקה. ההגדרות של השורה בוחרות את משמעת השינוי, שמקבצת את הכללים החוסמים והשופטים, והפסקתה שומרת עליהם לפעם הבאה שתפעיל אותה.

בחירת משמעת שינוי#

המשמעת קובעת עד כמה השינוי יכול להתפשט עבור סוכן המפתחים:

• כירורגי — רק מה שהמפרט דורש; בעיות אחרות מדווחות, אך לא מתוקנות.
• מאוזן (ברירת מחדל) — תוקן גם בעיות קטנות בשורות שהשינוי נוגע בהן בכל מקרה.
• משקם — ינקה גם תוצאות בדיקה בתוך הפונקציות שבהן השינוי עורך.

הסוכן פועל לפי אותן כללים לפני הגשתו: הוא מקבל את המשמעת ואת התבניות המבודדות שלך מראש, רואה את הכללים המהירים לאחר כל עריכה, וזוכה להזדמנות אחת לתקן תוצאות חוסמות לפני בדיקת איכות.

התאמתו למאגר הקוד שלך#

• הגדרות משנה לכללים — פתח כלל ב־Anti-slop Rules כדי להגדירו כחוסם, כיועץ, כדיווח בלבד או כמעצור, עבור ברירת המחדל של הארגון או עבור פרויקט בודד.
• חבילות כללים — התבניות שלך, ייבואים ואילוצים אסורים, מגבלות גודל קובץ, או תוצאות מכלים שכבר משתמשים בהם (SARIF). כל שמירה יוצרת גרסה חדשה, והבדיקה שומרת על הגרסה שנבחרה.
• בידוד — תבניות שאינך רוצה שיועתקו יותר, כל אחת עם התחליף שיש להשתמש בו. הסוכנים מקבלים הוראה לא להפיץ אותן, ועותקים חדשים מסומנים.
• נתיבים משוללים — ב־בקרת איכות → Anti-slop, הקבצים המיוצרים או הנרכשים שאין בדיקת Anti-slop קוראת, תבנית אחת לכל שורה (dist/**, vendor/**). השתמש בהם עבור פלט בנייה שנשמר: קובץ משונה שעובר את מגבלת ה־512 KiB של הסורק ודורש כלל מסוים הופך את הבדיקות ללא זמינות.
• קובץ מאגר — .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 שמריצה קוד בעת התקנתה. חבילת 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.

כדי לאשר ממצא, יש לציין סיבה ותוקף; האישור נרשם נגד אותו ממצא בדיוק. סוכנים לא יכולים לאשר את הממצאים של עצמם. כאשר סוכן טוען שבדיקה הייתה שגויה ומשנה אותה, המבקר חייב לאשר את השינוי לפני שהבדיקה תעבור.

כללי Judge#

שני כללים שואלים מודל, שורה אחת בכל פעם: בדיקה הגנתית לדבר שהקוד המוצג הופך אותו לבלתי אפשרי, ותגובה שסותרת את הקוד שלידה. הם רק נותנים המלצה, לעולם לא חוסמים. הפעל את כללי Judge פעיל עבור בדיקה חדשה, עם מגבלת החלטות לכל ריצה; ניתן לכבות אותו בהגדרות הבדיקה.

הסוכנים שלך#

אותם כללים יכולים להנחות גם את הסוכנים שאתה מריץ בעצמך:

• הורד קטע AGENTS.md, בתוך Anti-slop הגדרות של פרויקט ב- בקרת איכות, מספק את משמעת השינויים, הבידוד והכללים העליונים של הפרויקט כסעיף שניתן להדביק להוראות של הסוכנים שלך.
• דרך שרת Coroid MCP server, anti_slop_rules מתאר את המדיניות שפרסמת וגם anti_slop_scan סורק ענף של פרויקט מתואם, בצורה קריאה בלבד.