Anti-Slop-Prüfungen

Agenten schreiben schnell plausiblen Code – manche davon nutzen Abkürzungen, die ein sorgfältiger Ingenieur nicht wählen würde: ein übersprungener Test zur Erreichung des Grüns, ein verschluckter Fehler, ein zurückgelassener Platzhalter, eine stummgemachte Typüberprüfung oder eine zweite Variante für etwas, das im Codebase bereits existiert. Anti-Slop prüft diese Fälle in jeder Änderung und sendet die Änderung vor Ihrer Sichtbarkeit wieder an den Entwickler-Agenten zurück.

Es handelt sich um eine Prüfung innerhalb Ihrer Qualitätskontrolle, nicht um eine separate Bewertung. Eine Änderung besteht die Prüfung, wenn sie nichts einführt, das blockiert.

Wonach gesucht wird#

Regeln werden in Gruppen eingeteilt. Jede Regel entweder blockiert, gibt einen Rat oder zeichnet auf Info.

• Tests – gezielte oder übersprungene Tests, gelöschte Tests, entfernte oder abgeschwächte Assertions sowie Tests, die nicht fehlschlagen können.
• Unterdrückungen – neue Lint-Deaktivierungen, Typ-Ignorierungen und any Typumwandlungen.
• Build und CI – entfernte oder neutralisierte Testschritte, gesenkte Schwellenwerte, "Pass mit keinen Tests", GitHub Aktionen, die nicht an einen Commit gebunden sind.
• Testnachweise – zwischengespeicherte Ergebnisse, die als Ausführung ausgegeben werden, null ausgeführte Tests oder eine teilweise Ausführung, die als vollständig gemeldet wird.
• Produktionscode – verbleibende Debug-Informationen, Platzhalter, Mock-Daten, Anmerkungen für Menschen sowie ausgelieferter Testcode.
• Fehlerbehandlung – verschluckte Fehler, Fallbacks, die Fehler verbergen, sowie offene Berechtigungsprüfungen.
• Abhängigkeiten – Pakete, die nicht existieren oder als bösartig gemeldet werden, neue Pakete mit Namen bekannter Produkte, Pakete, die beim Installieren Code ausführen, sowie Manifeste, die ohne zugehörigen Lockfile geändert wurden.
• Sicherheit – Geheimnisse im Code, deaktivierte TLS-Prüfungen, entfernte Autorisierungsprüfungen sowie heruntergeladene Skripte, die direkt aus dem Netzwerk ausgeführt werden.
• Kommentare, Architektur, Änderungsumfang, Caching und der Agenten-Verlauf – die Aufzeichnung dessen, was der Agent getan hat, etwa das Bearbeiten eines Tests unmittelbar nach einem Fehler.

Jede Regel in Anti-Slop-Regeln, aufgerufen über die Zeile Anti-Slop in der Qualitätskontrolle, zeigt an, womit sie übereinstimmt, warum sie wichtig ist und welche Wirkung sie in der Organisationseinstellung oder in einem Projekt hat.

Nur das, was durch die Änderung eingeführt wurde, blockiert.#

Die meisten Repositorys enthalten bereits einige dieser Muster. Anti-Slop ordnet jedes Ergebnis in eine von drei Gruppen ein:

• Eingeführt – neu in dieser Änderung.
• Bearbeitet – bereits vorhanden, in einer Zeile oder Funktion, die von der Änderung bearbeitet wird.
• Vorhanden – an anderer Stelle im Repository.

Nur ein eingeführtes Ergebnis einer blockierenden Regel führt zum Scheitern der Prüfung. Bearbeitete und vorhandene Ergebnisse werden aufgezeichnet, sodass Sie Ihre Schulden in der Factory unter Schulden nachverfolgen und dort eine Aufgabe zur Behebung der Regelergebnisse erstellen können – sie hindern jedoch nicht an unabhängiger Arbeit. Das Verschieben von Code zählt nicht als Einführung; das Kopieren schon.

Wöchentliche Schuldenbereinigung#

Vorhandene Schulden blockieren nicht, müssen aber nicht bestehen bleiben. Öffnen Sie ein Projekt in der Qualitätskontrolle und erweitern Sie Anti-Slop und aktivieren Sie Wöchentliche Schuldenbereinigung. Einmal pro Woche scannt Coroid den Standardzweig des Projekts und erstellt kleine Bereinigungsaufgaben für die gefundenen Schulden – jeweils einige Dateien pro Aufgabe. Es bleiben maximal so viele offene Bereinigungsaufgaben bestehen, wie in Offene Aufgaben gleichzeitig angegeben sind (standardmäßig zwei); dadurch überlagert die Bereinigung niemals die von den Nutzern angeforderte Arbeit. Jede Änderung bietet eine Undo-Funktion.

Die Bereinigung wird pro Projekt festgelegt. Ihr Zeitplan wird in der Factory aufgeführt und gibt an, dass die Qualitätskontrolle sie verwaltet; ändern Sie sie hier, nicht dort.

Neue Aufgaben bot früher eine Vorlage „Wöchentliche technische Schuldenbereinigung“ an. Ein daraus erstellter Zeitplan läuft weiter und trägt den Namen des Schalters; unterbrechen Sie ihn in der Factory, falls die Schuldenbereinigung ihn ersetzt.

Aktivierung#

In Qualitätskontrolle, wählen Sie die Organisationseinstellung oder ein Projekt aus und aktivieren Sie Anti-Slop. Damit werden fünf Erwartungen hinzugefügt:

1. Die Tests belegen weiterhin die Änderung.
2. Nichts Unvollständiges oder nur für Tests Bestimmtes wird ausgeliefert.
3. Keine neuen strukturellen Schulden.
4. Der Änderungsumfang bleibt im Rahmen und entspricht dem Stil dieses Codebases.
5. Neue Abhängigkeiten sind echt und vertrauenswürdig.

Die Änderung wird sofort angewendet: der nächste Lauf des Projekts oder aller Projekte, die die Standardeinstellung übernehmen, beinhaltet die Prüfung. Die Einstellungen der Zeile bestimmen die Änderungsdisziplin, die blockierende und bewertende Regeln gruppiert, und das Deaktivieren bewahrt sie für das nächste Aktivieren auf.

Wahl der Änderungsdisziplin#

Die Disziplin gibt dem Entwickler-Agenten vor, wie weit eine Änderung reichen darf:

• Präzise — nur das, was die Spezifikation vorgibt; andere Probleme werden gemeldet, aber nicht behoben.
• Ausgewogen (Standard) — auch kleine Fehler in den Zeilen zu korrigieren, die durch die Änderung betroffen sind.
• Restaurativ — auch die in den Funktionen gefundenen Unregelmäßigkeiten zu bereinigen, die durch die Änderung bearbeitet werden.

Der Agent arbeitet vor der Einreichung nach denselben Regeln: Er erhält zuvor die festgelegten Vorgaben und Ihre isolierten Muster, prüft nach jeder Bearbeitung die schnellen Regeln und hat eine Chance, blockierende Befunde vor der Qualitätsprüfung zu beheben.

Anpassung an Ihr Codebase#

• Regel-Überschreibungen — öffnen Sie eine Regel in den Anti-Slop-Regeln, um sie zum Blockieren, Warnen, Melden oder Stoppen einzustellen – entweder für die Organisation oder für ein einzelnes Projekt.
• Regelpakete — Ihre eigenen Muster, verbotene Imports und Abhängigkeiten, Dateigrößenlimits oder Ergebnisse von bereits genutzten Tools (SARIF). Jede Speicherung ergibt eine neue Version, und eine Prüfung stellt sicher, dass die ausgewählte Version verwendet wird.
• Quarantäne — Muster, die nicht mehr kopiert werden sollen, jeweils mit dem zu verwendenden Ersatz. Die Agenten werden angewiesen, diese nicht zu verbreiten, und neue Kopien werden gekennzeichnet.
• Ausgeschlossene Pfade — in Qualitätskontrolle → Anti-Slop: Die generierten oder übernommenen Dateien werden von der Anti-Slop-Prüfung nicht berücksichtigt; ein Muster pro Zeile (dist/**, vendor/**). Nutzen Sie diese für kompilierte Build-Ergebnisse: Eine geänderte Datei, die die 512 KiB-Grenze des Scanners überschreitet und von einer Regel benötigt wird, macht die Prüfungen unbrauchbar.
• Repository-Datei — .coroid/anti-slop.yml im Repository kann Regeln hinzufügen und Ausnahmen vornehmen generated/, vendor/, node_modules/ und __generated__/ Verzeichnisse. Die Datei wird von der Basis der Änderung aus gelesen, sodass eine Änderung ihre eigenen Regeln nicht lockern kann – das Bearbeiten erfordert außerdem eine Freigabe.
• Lockdateien und Übersetzungskataloge — Anti-Slop zählt ihre Änderungen, liest sie aber nicht aus. Kataloge sind die Dateien .coroid/i18n.json gibt am Basisort der Änderung an; die Globalisierungsprüfung liest diese aus. Eine eigene Regel, die diese Dateien nennt, liest sie ebenfalls aus.

Neue Abhängigkeiten#

Modelle schlagen manchmal ein Paket vor, das nicht existiert – oft eine plausible Kombination aus zwei echten Namen. Angreifer registrieren solche Namen bei npm und PyPI, damit beim nächsten Installieren ihr Code ausgeführt wird; dieser Angriff wird Slopsquatting genannt. Die Cloud Security Alliance beschreibt ihn: Fast eines von fünf der 2,23 Millionen Codebeispiele in der zitierten Studie nannte mindestens ein Paket, das nicht existierte.

Anti-Slop prüft jedes von einer Änderung hinzugefügte Paket in package.json, einer Anforderungsdatei oder pyproject.toml:

• Blockaden — ein Paket, das nicht in seinem öffentlichen Registry enthalten ist, oder eines, das OSV als bösartig einstuft. Die Änderung wird vor Ihrer Sichtweise an den Entwickler-Agenten zurückgesendet.
• Warnungen — ein vor weniger als 30 Tagen veröffentlichtes Paket, eines mit sehr wenigen Downloads, eines dessen Name ein oder zwei Buchstaben von einem populären Paket abweicht, oder ein npm-Paket, das beim Installieren Code ausführt. Ein PyPI-Paket mit einem als bösartig gemeldeten Release löst ebenfalls eine Warnung aus, da Coroid nicht weiß, welches Release eine Anforderung installiert.

Ist ein Registry nicht erreichbar, gibt die Prüfung dies im Ergebnis an und entscheidet auf Basis der Pakete, die sie abfragen kann. Die Änderung wird dabei nicht zurückgehalten.

Welche Namen Coroid abfragt#

Das Abfragen eines Namens sendet ihn an ein öffentliches Registry – daher wählt ein Besitzer oder Administrator aus, welche Namen Coroid verlassen dürfen, in Qualitätskontrolle → Anti-Slop → Prüfung neuer Abhängigkeiten. Die Einstellung gilt für alle Projekte in der Organisation.

• Öffentliches npm und PyPI, sofern das Repository kein anderes Registry angibt — alle neuen Abhängigkeiten werden geprüft, außer wo .npmrc, eine Anforderungsdatei, pip.conf, uv.toml, eine Pipfile oder Python-Tool-Einstellungen neben dem Manifest oder in einem darüberliegenden Ordner ein anderes Registry oder Index angeben. Bei der Auswahl müssen Sie bestätigen, dass kein privates Registry außerhalb Ihrer Repositorys eingerichtet ist – etwa in Benutzer- oder CI-Einstellungen – und es wird festgehalten, wann und von wem die Bestätigung erfolgte. Begrenzte npm-Pakete (@scope/name) werden nur dort geprüft, wo .npmrc das öffentliche Registry für ihren Bereich angibt.
• Nur wenn das Repository das öffentliche Registry angibt — der Standardfall. Ein Paket wird nur geprüft, wenn .npmrc festlegt registry=https://registry.npmjs.org/, seine Anforderungsdatei exakt eine --index-url https://pypi.org/simple Zeile enthält, oder eine Poetry-Abhängigkeit eine Quelle nutzt, die auf pypi.org verweist. Die meisten Repositorys tun dies nicht – daher werden die meisten neuen Abhängigkeiten nicht geprüft.
• Deaktiviert — keine Namen werden geprüft, und erfundene Pakete werden nicht erkannt.

Nur die Namen neuer Abhängigkeiten verlassen Coroid. Sie werden an registry.npmjs.org und pypi.org, an api.npmjs.org für die npm-Downloadzahlen sowie an api.osv.dev (mit der npm-Version) für Berichte zu schädlichen Paketen. Ihr Code wird niemals übermittelt. Die Ergebnisse werden bis zu einem Tag lang gespeichert, sodass für jede Änderung nicht erneut nach demselben Namen gesucht wird.

Ergebnisse und Akzeptanz#

Die Ergebnisse einer Aufgabe werden in deren Qualität Abschnitt in der Factory angezeigt. Wenn der Entwickler-Agent die blockierenden Ergebnisse vor der Überprüfung behoben hat, öffnet sich der Abschnitt mit Von Anti-Slop vor der Überprüfung erfasst, den betreffenden Regeln sowie unter Zeigen Sie an, wo und wann, die Datei und Zeile jedes Ergebnisses sowie der zugehörige Prüfungsvorgang. In der Factory, unter Schulden, werden die vor der Überprüfung erfassten Abkürzungen der letzten 30 Tage gezählt und Projektleiter sowie Administratoren die Projekte angezeigt, die diese noch nicht überprüfen – mit Anti-Slop aktivieren.

Um ein Ergebnis zu akzeptieren, gibt man einen Grund und ein Ablaufdatum an; die Akzeptanz wird für genau dieses Ergebnis festgehalten. Agenten können ihre eigenen Ergebnisse nicht akzeptieren. Wenn ein Agent angibt, dass ein Test fehlerhaft war und ihn ändert, muss ein Prüfer diese Änderung vor dem Bestehen der Prüfung genehmigen.

Regeln bewerten#

Zwei Regeln befragen ein Modell zeilenweise: eine abwehrhafte Prüfung auf etwas, das durch den gezeigten Code unmöglich ist, sowie ein Kommentar, der dem nebenstehenden Code widerspricht. Sie geben nur Ratschläge, blockieren nie. Regeln zur Bewertung aktivieren ist für eine neue Prüfung aktiviert, mit einer pro Ausführung begrenzten Anzahl an Entscheidungen; man kann sie in den Einstellungen der Prüfung deaktivieren.

Ihre eigenen Agenten#

Die gleichen Regeln können auch Ihre selbst ausgeführten Agenten steuern:

• AGENTS.md-Snippet herunterladen, im Anti-Slop Einstellungen eines Projekts in Qualitätskontrolle, liefert die Änderungsdisziplin, Quarantäne und Top-Regeln des Projekts als Abschnitt, den man in die Anweisungen der eigenen Agenten einfügen kann.
• Über den Coroid MCP-Server anti_slop_rules beschreibt Ihre veröffentlichte Richtlinie und anti_slop_scan scannt einen Branch eines synchronisierten Projekts im Lesemodus.