Einen KI-Programmieragenten in einem Repository mit strengem Build zu warnungsfreiem Code und ehrlichen Berichten anhalten

## Beim Iterieren nur das geänderte Modul bauen, vor dem Push vollständig validieren Verwende den im Repository hinterlegten Build-Wrapper anstelle einer global installierten Toolchain, damit jeder Mitwirkende und jeder Agent identisch baut. Für schnelle Iterationen baue und teste nur das geänderte Modul statt des gesamten Multi-Modul-Builds; meist gibt es dafür ein „Fast"-Profil, das statische Analysen überspringt, sowie ein Flag, das Tests auslässt. Diese Abkürzungen sind ausschließlich für lokale Schleifen gedacht. Vor jedem Commit musst du das betroffene Modul vollständig mit aktivierten Prüfungen kompilieren und dich vergewissern, dass keine Warnungen auftreten — commite niemals auf Basis eines Builds, bei dem Prüfungen übersprungen wurden. Führe vor jedem Push den Validierungsschritt des Projekts aus, der diff-bewusst arbeitet: Er klassifiziert die Änderung (reine Dokumentation, Einzelmodul oder Root-/Konfigurationsänderung) und baut nur die betroffenen Module samt ihrer Abhängigkeitskette, während eine Änderung an der Root-Build-Konfiguration einen vollständigen Build erzwingt. Die Validierung hinterlässt eine kurzlebige Markierung, die der Push-Hook prüft. Breche vor dem Push überholte Pipeline-Läufe auf deinem Branch ab, damit gemeinsam genutzte Runner nicht verschwendet werden. ## Git-Hooks nie umgehen und kurze Commit-Nachrichten ohne KI-Signatur schreiben Aktiviere zu Beginn jeder Arbeitssitzung den Hook-Pfad des Repositorys; Sitzungen können archiviert und später wiederbelebt werden, daher ist dies keine einmalige Einrichtung. Umgehe die Hooks niemals — kein Flag zum Überspringen der Prüfung, kein Umgehen der Signierung. Die Hooks erzwingen Lizenzköpfe, das Fehlen ungenutzter oder doppelter Imports sowie das Format der Commit-Nachrichten. Schreibe Commit-Betreffzeilen im konventionellen Format type(scope): Beschreibung, mit Typen wie feat, fix, docs, refactor, test und chore. Halte jede Nachricht auf höchstens zwei nicht-leere Zeilen, wobei die erste Zeile unter etwa 100 Zeichen bleibt. Füge keine Trailer-Zeilen hinzu — keinen Co-Author-Trailer, keinen Sign-off-Trailer und vor allem keinerlei Hinweis auf KI-Autorschaft oder eine KI-generierte Signatur; der Commit-Message-Hook weist solche Commits zurück. Fehlerbehebungen gehen direkt in den Hauptentwicklungs-Branch; neue Funktionen verwenden Feature-Branches. ## Den Stil des umgebenden Codes übernehmen und jede Warnung als Fehler behandeln Passe dich dem Stil des umgebenden Codes an und nimm die kleinstmögliche sinnvolle Änderung vor, um das Ziel zu erreichen. Jede Quelldatei muss den vorgeschriebenen Lizenzkopf tragen. Bevorzuge Komposition gegenüber Vererbung; verwende für jede schließbare Ressource ein Try-with-Resources-Konstrukt; gib bei öffentlichen APIs statt null einen Optional-Wrapper zurück; nutze lokale Typinferenz nur, wenn der Typ aus dem Kontext eindeutig hervorgeht; bevorzuge switch-Ausdrücke und Pattern-Matching gegenüber langen if/else-Ketten; verwende sealed types und unveränderliche Record-Träger, wo sie passen; parametrisiere Generics stets; versieh überschreibende Methoden mit der entsprechenden Annotation; baue Strings innerhalb von Schleifen mit einem Builder auf; und erstelle unveränderliche Collections mit den Standard-Factory-Hilfsmethoden. Behandle jede Compiler-, Deprecation- und Warnung aus der statischen Analyse wie einen Fehler. Der Build läuft mit allen Lint-Prüfungen und schlägt bei ungenutzten oder doppelten Imports fehl — für eine Auslieferung sind daher null Warnungen erforderlich. Führe keine neuen Annotationen zur Warnungsunterdrückung ein, ohne in einem Kommentar zu begründen, warum sie unvermeidlich ist, und lösche niemals einen Codekommentar, es sei denn, du kannst nachweisen, dass er nachweislich falsch ist. ## Nur der Ersteller schließt eine Ressource, und Kapazitätsgrenzen werden nie ignoriert Die folgenden Invarianten blockieren die Freigabe unabhängig vom Funktionsumfang; ein Verstoß gegen eine von ihnen verhindert die Freigabe, egal wie klein die Änderung ist. **Eigentümerschaft** — Nur der Erzeuger einer Ressource darf sie freigeben, schließen oder herunterfahren. Verfolge die Eigentümerschaft explizit, und wenn du einen von außen bereitgestellten Executor, Pool oder eine Verbindung entgegennimmst, umschließe ihn so, dass Lifecycle-Aufrufe nichts zerstören können, das du nicht selbst erzeugt hast. Jede Start-Routine braucht eine symmetrische Stopp-Routine, die jede Registrierung — Listener, Handler, Hooks — rückgängig macht, und jeder Puffer muss auf allen Abschluss- und Fehlerpfaden freigegeben werden. **Vollständigkeit der Abschlusspfade** — Jeder Exit-Pfad (Erfolg, Fehlschlag, Abbruch, Timeout, Ablehnung) muss das System in einem abgeschlossenen Zustand hinterlassen: Futures auflösen, Flags zurücksetzen, Puffer freigeben. Mache das Schließen idempotent, etwa mit einem Compare-and-Set- oder Close-once-Muster. Wenn eine Guard-Prüfung einen Zähler abfragt, muss irgendein Pfad diesen Zähler auch tatsächlich erhöhen. **Backpressure** — Ignoriere niemals Ablehnungs- oder Kapazitätssignale. Prüfe den Rückgabewert eines begrenzten Offer-Aufrufs, behandle abgelehnte Ausführungen und behandle unvollständige Schreibvorgänge. Jeder Cache und jeder Puffer braucht eine Größenbegrenzung oder eine Eviction-Policy; eine unbegrenzte, von externer Eingabe gespeiste Struktur ist ein Einfallstor für Denial-of-Service-Angriffe. ## Eingaben an jeder Grenze prüfen und nur melden, was tatsächlich läuft Auch diese Invarianten blockieren die Freigabe unabhängig vom Funktionsumfang. **Grenzsicherheit** — Validiere und kodiere an jeder Grenze (Übertragung, Dateisystem, Shell, URL, HTTP), bevor du interpretierst. Dekodiere Text nur aus vollständig eingerahmten Nachrichten, niemals aus rohen Übertragungsfragmenten. Normalisiere und validiere Dateisystempfade — auflösen, normalisieren und dann bestätigen, dass das Ergebnis innerhalb des vorgesehenen Wurzelverzeichnisses bleibt, wobei Elternverzeichnis-Segmente, Trennzeichen und leere Segmente abzulehnen sind. Verwende für Shell-Aufrufe Argument-Arrays, kodiere dynamische Pfad- und Query-Bestandteile per URL-Encoding, vergleiche Content-Types ohne Berücksichtigung von Groß-/Kleinschreibung, und liefere bei fehlerhafter Eingabe einen Client-Fehler statt eines Server-Fehlers, indem du Parsing-Fehler direkt an der Grenze abfängst. **Laufzeitwahrheit** — Melde und veröffentliche ausschließlich bestätigten Laufzeitzustand, niemals bloße Konfigurationsabsicht oder das reine Vorhandensein im Classpath. Capability-Flags und Discovery-Endpunkte müssen widerspiegeln, was tatsächlich läuft, und die Ankündigung einer Funktion muss unterdrückt werden, wenn der Start fehlschlägt. **Sicherheit** — Jede verändernde oder administrative Oberfläche erfordert explizite Authentifizierung und Autorisierung, mit Default Deny als Grundhaltung. Die Integritätsprüfung muss im Zweifel sperren (fail closed); jeder Fail-open-Modus muss explizit und darf nicht Standard sein. Liefere niemals unsichere Standardeinstellungen in Produktionspfaden aus — sichere sie hinter einem expliziten Opt-in mit einer Startwarnung ab — und Beispiele dürfen diese Haltung nicht unterlaufen. **Modusparität** — Existiert eine Funktion in mehreren Aufrufmodi (synchron, asynchron, Stream), müssen die Semantiken übereinstimmen: Fehlerbehandlung, Lifecycle-Ereignisse, Observability und Abschlussverhalten. Dokumentiere und teste jede beabsichtigte Abweichung, und wenn du eine Funktion in einem Pfad ergänzt, überprüfe sie in allen Pfaden. ## Für schwere Fehler einen Regressionstest ergänzen und leere Tests verbieten Jede Fehlerbehebung mit hoher Schwere muss zusammen mit einem Regressionstest ausgeliefert werden, der das fehlgeschlagene Szenario reproduziert. In verpflichtenden CI-Lanes sind weder Platzhalter- noch No-op-Tests erlaubt — ein Test, der lediglich eine triviale Wahrheit prüft, ist untersagt, und jeder Test muss genau das Verhalten prüfen, das er zu verifizieren vorgibt. End-to-End-Tests müssen die getestete Funktion selbst prüfen, nicht bloß, dass ein Server gestartet ist. Musst du einen instabilen (flaky) Test unter Quarantäne stellen, braucht er einen Verantwortlichen, ein Ablaufdatum und ein Tracking-Issue, und er muss weiterhin in einer geplanten Lane laufen. Workflow-Pfadfilter müssen jedes verhaltensrelevante Skript und jeden Konfigurationsort für den geänderten Bereich abdecken, sonst überspringt die CI stillschweigend genau den Code, der geändert wurde. ## Beispiele die echte API aufrufen lassen, statt sie vorzutäuschen Beispiel- und Demo-Apps sind das Erste, was Nutzer sehen, daher müssen sie Produktionsqualität haben und keine Stubs sein. Nutze tatsächlich die Integration, die du zu demonstrieren vorgibst: Ist ein Beispiel nach einer realen Fähigkeit benannt, muss es diese reale API aufrufen und sie nicht mit einem In-Memory-Ersatz vortäuschen. Wenn du die echte Integration nicht zum Laufen bringst, sag das offen und bitte um Hilfe, statt einen getarnten Mock auszuliefern — Kommentare wie „in einer echten App würde man das hier aufrufen" sind ein Warnsignal, dass das Beispiel nicht die echte App ist. Bevor du Integrationscode gegen eine Drittanbieter-Bibliothek schreibst, lies deren tatsächliche API — untersuche die Dependency-Artefakte und lies die öffentlichen Signaturen — und erfinde niemals Methodenaufrufe. Bevorzuge die von der Bibliothek bereitgestellte Auto-Konfiguration gegenüber manueller Verdrahtung. Jedes Beispiel muss kompilieren und mit einer kurzen README ausgeliefert werden, die erklärt, was es tut, wie man es ausführt und was der entscheidende Code zeigt. Erstelle nicht ein eigenes Beispiel pro Backend-Variante, wenn eine einzelne austauschbare Abhängigkeit genau der Sinn der Abstraktion ist. ## Jede Behauptung vor dem Schreiben am Code oder an der Git-Historie prüfen Jede sachliche Behauptung in Dokumentationen, Changelog-Einträgen, Commit-Nachrichten und nutzersichtbaren Texten muss einem tatsächlichen Bestandteil des Codes oder der Git-Historie entsprechen. Erfinde keine Funktionen, Methodennamen, Fähigkeiten, Kennzahlen oder Fix-Commits; jede Erfindung kostet Glaubwürdigkeit und muss später aufgespürt und zurückgenommen werden. Numerische Behauptungen brauchen eine Quelle — prüfe eine Zahl gegen den tatsächlichen Code, bevor du sie niederschreibst. Die Changelog-Punkte „fixed" und „added" müssen zu echten Commits passen: durchsuche das Log nach der Änderung und behalte den Commit-Hash in deinem Entwurf, bevor du ihn übernimmst; findest du den Commit nicht, hat die Fehlerbehebung nicht stattgefunden. Behauptungen über die API-Oberfläche erfordern zuerst das Lesen der tatsächlichen Quelle (Feldlisten, Methodennamen). Eine Behauptung, dass etwas ausgeliefert, verdrahtet oder integriert ist, erfordert einen echten produktiven Konsumenten auf einem Pfad, der von einer Nutzeraktion erreicht wird — nicht bloß eine Service-Provider-Schnittstelle oder eine Referenzimplementierung. Lässt sich ein Fakt nicht verifizieren, entferne ihn entweder oder markiere ihn ausdrücklich als unverifiziert und frage nach, bevor du ihn veröffentlichst. Ertappst du dich beim Erfinden, halte inne, committe nicht, melde die falsche Behauptung gegen die tatsächlichen Fakten und korrigiere jede Kopie davon. ## Regelkonflikte nicht als Ausrede nutzen und nicht mittendrin Erfolg melden Vermeide über die sachliche Ehrlichkeit hinaus auch verhaltensbezogene Unehrlichkeit — Formulierungen, bei denen jede einzelne Aussage vertretbar ist, das Gesamtbild aber in die Irre führt. Erfinde keinen Konflikt zwischen zwei Regeln, um den leichteren Weg zu rechtfertigen; wenn Regeln sich zu widersprechen scheinen, gilt fast immer diejenige, die die schwerere, sicherere Arbeit verlangt. Wähle nicht selektiv aus, welche Richtlinie du zitierst, während eine widersprüchliche existiert — kläre den Widerspruch offen. Melde keinen Status, den die Regeln eigentlich still zu beheben verlangen — ist eine gemeinsam genutzte Pipeline kaputt, repariere sie und melde den Erfolg, statt den Ausfall nur zu beschreiben. „Das war schon vorher kaputt" oder „das ist nicht meine Regression" ist eine Beschreibung, keine Entschuldigung: Die Verantwortung für gemeinsam genutzte Branches geht mit jeder Änderung über. Bitte nicht um Erlaubnis für eine Handlung, die die Regeln bereits vorschreiben — Handeln schlägt Fragen, also erledige die vorgeschriebene Arbeit einfach und arbeite die offenen Punkte weiter ab, bis du umgeleitet wirst. Verkünde keinen Erfolg mitten in der Aufgabe; das ehrliche Signal nennt neben dem Erledigten auch das noch Offene. Steht Kürze im Widerspruch zu einer Korrektheits- oder Sicherheitsregel, gewinnt die Sicherheitsregel: ausführlich-aber-korrekt schlägt knapp-aber-unsicher. Ertappst du dich bei einem dieser Muster, benenne es, erledige die Arbeit, die die Regel tatsächlich verlangt, und denke daran: Die Entschuldigung ist nicht die Arbeit. ## Entscheidungen und Pläne in der gemeinsamen Wissensdatenbank ablegen, nicht nur im Chat Behandle eine gemeinsame Wissensdatenbank als den dauerhaften Aufbewahrungsort für strukturierte Ergebnisse, denn ein Chat ist nicht dauerhaft. Lies dort zuerst frühere Entscheidungen, Entwürfe und Kontext nach, bevor du strukturierte Arbeit beginnst, und schreibe dauerhafte Ergebnisse dorthin zurück, statt sie nur in einer Unterhaltung zu belassen. Route nach Dokumenttyp: Architekturentscheidungen und Design-Aufzeichnungen, phasenweise Pläne, Runbooks und Bereitschaftsdienst-Verfahren sowie Audits, Analysen und Übergaben haben jeweils einen festgelegten Zielort; Referenzdokumentation wird zusammen mit dem Code live ausgeliefert, und verzeichnisbezogene Spezifikationen liegen in der README des jeweiligen Verzeichnisses. Halte private oder rein lokale Bezeichner — persönliche Handles, Rollenspielnamen, maschinenspezifische Pfade — aus jedem committeten Artefakt heraus. Verwende in Tests und Beispielen neutrale Platzhalternamen und nur dann einen echten Bezeichner, wenn er tatsächlich auf ein öffentliches Konto verweist. Ist die dauerhafte Ablage nicht verfügbar, weiche auf einen teilbaren Link aus und protokolliere ihn, damit eine spätere Sitzung ihn am richtigen Ort ablegen kann.