Anti-Slop-Prüfungen

Die Agenten schreiben schnell plausiblen Code – ein Teil davon nutzt Abkürzungen, die ein sorgfältiger Ingenieur nicht wählen würde: Ein Test wird übersprungen, um den grünen Status zu erreichen, ein Fehler wird unterdrückt, ein Platzhalter bleibt bestehen, eine Typüberprüfung wird ausgesetzt oder es gibt eine zweite Variante für etwas, das im Code bereits existiert. Die Anti-Slop ‑Prüfung erkennt all diese Fälle in jeder Änderung und sendet die Änderung vor Ihrer Sichtbarkeit zurück an den Entwickler-Agenten.

Es handelt sich um eine Prüfung innerhalb Ihrer Qualitätsrichtlinie, nicht um eine separate Bewertung. Eine Änderung besteht die Prüfung, wenn sie nichts enthält, das Hindernisse verursacht.

Wonach gesucht wird#

Die Regeln sind in Gruppen unterteilt. Jede Regel entweder blockiert, gibt einen Rat oder protokolliert 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, herabgesetzte Schwellenwerte sowie der Fall „mit null Tests bestehen“.
• Testnachweise – zwischengespeicherte Ergebnisse werden als Ausführung ausgegeben, es werden keine Tests ausgeführt oder eine teilweise Ausführung wird als vollständig gemeldet.
• Produktionscode – Debug‑Restbestände, Platzhalter, Mock‑Daten, Hinweise für Menschen sowie Testcode, der ausgeliefert wird.
• Fehlerbehandlung – unterdrückte Fehler, Fallbacks, die Fehler verbergen, sowie offene Berechtigungsprüfungen.
• Kommentare, Architektur, Abhängigkeiten, Änderungsumfang, Sicherheit, Caching und der Agenten-Verlauf – das Protokoll darüber, was der Agent getan hat, etwa das Bearbeiten eines Tests direkt nach einem Fehler.

Die Seite jeder Regel finden Sie in Qualität → Prüfungen → Anti-Slop wo angezeigt wird, worauf die Regel passt und warum sie wichtig ist.

Nur die in der Änderung eingeführten Fälle blockieren die Prüfung.#

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

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

Nur ein eingeführtes Ergebnis einer blockierenden Regel führt zum Scheitern der Prüfung. Berührte und vorhandene Ergebnisse werden protokolliert, damit Sie Ihre technische Schulden sehen können – sie hindern jedoch nicht an unabhängigen Arbeiten. Das Verschieben von Code zählt nicht als Einführung; das Kopieren schon.

Hinzufügen zur Richtlinie#

Öffnen Sie eine Richtlinie in Qualität → Richtlinien und wählen Sie Anti-Slop‑Preset hinzufügen. Damit werden fünf Anforderungen hinzugefügt:

1. Die Tests belegen weiterhin die Richtigkeit der Änderung.
2. Nichts Unvollständiges oder nur für Tests Bestimmtes wird ausgeliefert.
3. Keine neuen strukturellen Schulden.
4. Die Änderung bleibt im Umfang und passt zum Stil des Codebases.
5. Neue Abhängigkeiten sind echte und vertrauenswürdige Komponenten.

Veröffentlichen Sie die Richtlinie – dann wird die Prüfung bei der nächsten Ausführung jedes zugeordneten Projekts berücksichtigt.

Auswahl der Änderungsdisziplin#

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

• Chirurgisch – nur das, was die Spezifikation verlangt; andere Probleme werden gemeldet, aber nicht behoben.
• Ausgewogen (Standard) – auch kleine Probleme auf Zeilen, die die Änderung berührt, werden korrigiert.
• Sanierend – auch die in den von der Änderung bearbeiteten Funktionen gefundenen Muster werden bereinigt.

Der Agent hält sich vor der Einreichung an dieselben Regeln: Er erhält die Disziplin sowie Ihre quarantinierten Muster zu Beginn, sieht nach jeder Bearbeitung die schnellen Regeln und bekommt eine Chance, blockierende Ergebnisse zu korrigieren, bevor die QA erfolgt.

Anpassung an Ihren Codebase#

• Regel‑Überschreibungen – eine Regel deaktivieren oder sie so einstellen, dass sie rät statt zu blockieren, in den Einstellungen der Prüfung.
• Regelpakete – Ihre eigenen Muster, verbotene Imports und Abhängigkeiten, Dateigrößenlimits oder Ergebnisse von bereits genutzten Tools (SARIF). Pakete sind versionsgebunden; eine Richtlinie fixiert die verwendete Version.
• Quarantäne – Muster, die nicht mehr kopiert werden sollen, jeweils mit dem Ersatz, der stattdessen verwendet wird. Die Agenten werden angewiesen, sie nicht zu verbreiten, und neue Kopien werden gekennzeichnet.
• Repository‑Datei — .coroid/anti-slop.yml im Repository kann Regeln hinzufügen und generierte oder vendorisierte Pfade ausnehmen. Sie wird von der Basis der Änderung aus gelesen – eine Änderung kann ihre eigenen Regeln also nicht lockern, und die Bearbeitung erfordert eine Freigabe.

Ergebnisse und Befreiungen#

Die Ergebnisse werden unter Qualität → Ergebnisse, gefiltert nach Prüfung. Um ein Ergebnis zu akzeptieren, muss es mit einem Grund ausgesetzt werden; diese Ausnahme wird für genau dieses Ergebnis festgehalten. Agenten können ihre eigenen Ergebnisse nicht aussetzen. Wenn ein Agent angibt, dass ein Test fehlerhaft war und ihn ändert, muss ein Reviewer die Änderung vor dem Bestehen der Prüfung genehmigen.

Regeln für den Bewertungsprozess#

Zwei Regeln befragen das Modell zeilenweise: eine abwehrhafte Prüfung auf etwas, das durch den dargestellten Code unmöglich ist, sowie ein Kommentar, der dem nebenstehenden Code widerspricht. Sie geben nur Ratschläge, blockieren nichts. Regeln für den Bewertungsprozess aktivieren ist für eine neue Prüfung aktiviert und hat eine pro Ausführung begrenzte Anzahl an Entscheidungen; Sie können es in den Einstellungen der Prüfung deaktivieren.

Ihre eigenen Agenten#

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

• Snippet für AGENTS.md herunterladen, im Technische Schuld Reiter von Qualität → Prüfungen → Anti-Slop, liefert die Disziplin für Änderungen des Projekts, Quarantäne und wichtigste Regeln als Abschnitt, den Sie in die Anweisungen Ihrer Agenten einfügen können.
• Ü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.