Ein lokaler Umzug als Infrastrukturtest mit Codex

Eine lokale Entwicklungsumgebung umzuziehen wirkt zunächst wie eine einfache Infrastrukturaufgabe. Ein Repository wird von einem Laufwerk auf ein anderes kopiert, ein paar Pfade werden angepasst, danach startet man Backend und Frontend neu. In der Praxis ist der Vorgang selten so geradlinig. Lokale Datenbanken, .env-Dateien, Portbelegungen, Docker-Volumes, IDE-Kontext, alte Arbeitsverzeichnisse und Testzugänge bilden eine kleine, gewachsene Betriebslandschaft.

Der Umzug meiner lokalen Lutions-Entwicklungsumgebung begann mit einem konkreten Speicherplatzproblem auf einem Laptop. Es ging nicht um ein lange geplantes Infrastrukturprogramm, sondern um eine notwendige Veränderung: Das Repository sollte vom alten Pfad C:\github\lutions nach R:\Repositories\lutions wechseln. Gleichzeitig wollte ich die Gelegenheit nutzen, die bislang separat auf dem Rechner installierten Komponenten meiner Entwicklungsumgebung – MariaDB, PHP/Laravel und die Frontend-Toolchain – in einen lokalen Docker-Compose-Stack zu überführen. VS Code, Git, Docker Desktop und LM Studio sollten dagegen bewusst außerhalb des Stacks bleiben.

Es lag für mich auf der Hand, die notwendige operative Kleinarbeit nicht vollständig selbst auszuführen, sondern Codex anhand klarer Anforderungen arbeiten zu lassen: Zielpfade, Datenbereich, Rollback-Grenzen, die außerhalb des Stacks weiter genutzten Werkzeuge und die erforderlichen Smokes waren vorgegeben. Codex unterstützte Inventar, Umsetzung, Verifikation und Doku-Nachzug. Das produktive Lutions-System diente dabei zugleich als Arbeitsprotokoll: Ich legte die Ausgangsanforderung als Parent-Ticket an; daraus entstanden Untertickets für die einzelnen Schritte. In diesen Tickets wurden Entscheidungen, Umsetzung, Prüfschritte und offene Punkte nach unserem festgelegten Vorgehen festgehalten. Bei risikoreicheren Schritten ergänzten unabhängige Test- und Review-Fazits die eigene Prüfung. Ich behielt die Zielentscheidungen, Freigaben und interaktiven Bestätigungen. Der Fall ist intern dokumentiert über LUMVP-1214 und die Untertickets LUMVP-1215 bis LUMVP-1220 (Lutions, 2026a).

Die folgende Abbildung zeigt einen Ausschnitt dieser Dokumentation. Sichtbar sind das unabhängige Auditor-Fazit, der Parent-Abschluss und die Untertickets, die den Ablauf in überprüfbare Arbeitspakete gliedern.

Dieser Erfahrungsbericht stützt sich ausschließlich auf interne, nicht öffentlich zugängliche Tickets, Repository-Dateien und Runbooks. Er dokumentiert daher einen nachvollziehbaren Einzelfall, keine unabhängig reproduzierbare Studie.

1. Der Anlass war Speicherplatz, nicht Docker

Der neue Zielpfad war früh klar:

R:\Repositories\lutions

Auch der neue Docker-Datenbereich war vorgegeben:

R:\DockerData

Damit war die technische Richtung bekannt, aber noch nicht der operative Zustand. Ein lokaler Entwicklungsaufbau besteht nicht nur aus Dateien im Repository. Er besteht aus einem Zusammenspiel von Git-Metadaten, lokalen Secrets, .env-Dateien, Datenbankdaten, installierten Laufzeiten, Ports, Editorfenstern, Terminalzuständen und alten Gewohnheiten. Wenn ein Teil davon still auf den alten Pfad oder die alte Datenbank zeigt, kann die Umgebung oberflächlich starten und später an anderer Stelle brechen.

Deshalb war der erste sinnvolle Schritt nicht Docker, sondern Inventar. Wo liegen Repositories? Welche Skripte kennen absolute Pfade? Welche Laufzeiten sind lokal installiert? Welche Ports sind belegt? Welche Datenbank ist aktuell maßgeblich? Welche Teile müssen erhalten bleiben, welche dürfen verworfen werden? Diese Fragen klingen unspektakulär, aber sie verhindern die klassische Falle: Man migriert die Dateien, aber nicht den Arbeitskontext.

Aus dieser Perspektive war der alte Worktree C:\github\lutions kein Müll, sondern Rollback. Er blieb bewusst erhalten. Der neue Worktree wurde zum aktiven Arbeitsstand, der alte Stand blieb eine Sicherheitsleine. Das ist eine kleine, aber wichtige Architekturentscheidung im Alltag: Nicht alles, was technisch veraltet ist, sollte sofort gelöscht werden. Gerade bei lokalen Entwicklungsumgebungen ist ein lebender Rückweg oft wertvoller als eine sofort saubere Platte.

2. Docker wurde nicht als Selbstzweck eingeführt

Docker hatte im Projekt bereits eine Vorgeschichte. Es gab früher einen Anlauf, der wieder verworfen wurde. Daraus ergab sich eine klare Entscheidung: Alte Docker-Artefakte mussten nicht konserviert werden. Sie konnten verworfen und neu aufgebaut werden. Diese Entscheidung vereinfachte den Umzug erheblich, weil der neue Stack nicht an halb gültige Altannahmen gebunden war.

Der lokale Docker-Stack wurde anschließend auf den tatsächlichen Entwicklungsbedarf zugeschnitten: PHP/Laravel, MariaDB, Node/npm/Vite und die passenden Ports. Der Stack sollte den lokalen Alltag stabilisieren, nicht eine produktionsähnliche Infrastruktur simulieren. Die Host-Werkzeuge blieben auf dem Laptop. Das ist ein pragmatischer Schnitt: Docker übernimmt die projektbezogenen Laufzeiten und Daten, während Editor, Git, Docker Desktop und andere Werkzeuge dort bleiben, wo sie für den Entwickler sinnvoll bedienbar sind.

Der neue Datenbereich R:\DockerData war dabei mehr als ein Speicherort. Er machte die Trennung sichtbar: Repository auf R:, Docker-Daten ebenfalls auf R:, alte Host-Daten und lokale Werkzeuge bleiben zunächst verfügbar. Dadurch wurde aus einem diffusen „alles irgendwie auf eine andere Platte“ eine nachvollziehbare Zielarchitektur.

Wichtig ist auch, was nicht passiert ist. Der Umzug selbst war kein Release-Schnitt: Es wurde keine eigenständige Version erhöht und keine eigenen Release Notes erzeugt. Der Docker-Stack ist ein lokaler Entwicklungsstack, dokumentiert im entsprechenden Operations-Runbook (Lutions, 2026b). Diese Begrenzung schützt vor Scope Creep. Lokale Entwicklungsstabilität ist ein eigenes Ziel; sie muss nicht heimlich zum Release-Projekt werden.

3. Die Datenübernahme als lokaler Abgleich

Die Datenübernahme war kein Eingriff in Test- oder Produktivsysteme, sondern ein lokaler Abgleich für die neue Docker-Umgebung. Die bisherige lokale Datenbank blieb als Rückweg erhalten. Es ging also nicht darum, einen kritischen Bestand zu verschieben, sondern darum, sicherzustellen, dass die Docker-Umgebung mit dem erwarteten Datenbestand startet und Laravel die Compose-Datenbank korrekt erreicht.

Die Datenübernahme lief vollständig automatisiert ab: Der Ablauf sicherte den Datenbestand, importierte ihn in die Docker-Datenbank und führte die vorgesehenen Zähl- und Zugriffssmokes aus (Lutions, 2026c). Weitere manuelle Eingriffe waren nicht erforderlich. Der alte lokale Datenbankdienst blieb aktiv; so ließ sich die neue Umgebung prüfen, ohne den bisherigen Arbeitsstand sofort aufzugeben. Der anschließende Login-Smoke war davon bewusst getrennt.

4. Der Login-Smoke machte die Konfigurationslücke sichtbar

Nach dem Start des Docker-Stacks liefen Container, Frontend und Backend; die technischen Endpunkte waren erreichbar. Der davon getrennte Login-Smoke schlug jedoch fehl. Zunächst erschien die Meldung:

Session konnte nicht geladen werden. Bitte neu anmelden.

Bei einem weiteren Versuch folgte ein Serverfehler mit Status 500.

Die Ursache lag nicht in einem fehlenden Container, sondern in der Konfigurationsgrenze zwischen Host- und Containerwelt. Laravel nutzte im Container noch Datenbankwerte, die zur Host-Welt passten. Für den Container musste DB_HOST auf db zeigen, nicht auf 127.0.0.1. Der Fix bestand daher nicht nur in einer einmaligen .env-Korrektur, sondern in einer kleinen Absicherung des lokalen Entrypoints: Beim Containerstart werden die für den Docker-Stack erwarteten DB-Werte in backend/.env gesetzt (Lutions, 2026d).

Der Fehler machte die Grenze der vorherigen Prüfungen sichtbar, nicht deren Nutzlosigkeit. Ein grüner Healthcheck bestätigt nicht, dass Login, Session, CSRF, Datenbankzugriff und Frontend-Proxy gemeinsam funktionieren. Der entscheidende Nachweis war deshalb der bestätigte Login mit einem vordefinierten Testaccount.

5. Was der Infrastrukturtest über agentische Arbeit zeigte

Der Infrastrukturtest bestand in einer klaren Arbeitsteilung: Ich definierte Zielpfade, Datenbereich, Rollback-Grenzen, die außerhalb des Stacks weiter genutzten Werkzeuge und den erfolgreichen Login als Abnahmekriterium. Codex übernahm innerhalb dieser Vorgaben die wiederholbare operative Arbeit – vom Inventar über die Vorbereitung von Änderungen bis zur Prüfung und Dokumentation der Ergebnisse.

Der praktische Gewinn bestand darin, dass ich nicht jeden Pfad, jede Konfiguration und jedes Runbook selbst nachverfolgen musste. Verantwortung und Abnahme blieben jedoch bei mir. Der Login-Fehler zeigte, warum diese Grenze wichtig ist: Die vorherigen automatisierten Prüfungen waren korrekt, der separate Login-Smoke machte dennoch eine Lücke sichtbar. Agentische Unterstützung verlagerte meine Arbeit damit von der operativen Kleinarbeit hin zu klaren Anforderungen, bewussten Entscheidungen und der abschließenden Prüfung.

6. Grenzen des Ergebnisses

Die technische Überführung ist abgeschlossen, die alte Umgebung wird jedoch bewusst noch nicht bereinigt. Die früheren lokalen Installationen, der frühere Worktree und die lokale Datenbank bleiben als Rückweg erhalten, bis sich der Docker-Alltag über längere Zeit bewährt hat. Der Docker-Stack löst damit ein lokales Entwicklungsproblem; er ist weder eine Produktionsumgebung noch eine neue Deploymentstrategie.

Auch die Automatisierung der backend/.env bleibt eine lokale Lösung. Der Entrypoint setzt die für Docker erwarteten Datenbankwerte, damit die Konfiguration des Rechners und die der Container nicht verwechselt werden. Für produktive Systeme wären Konfigurationsquellen, Secret-Handling und Deployment-Gates anders zu behandeln (Lutions, 2026b; Lutions, 2026e).

Fazit

Der Umzug löste zunächst ein konkretes Speicherplatzproblem. Tragfähig wurde er durch die Verbindung aus Inventar, erhaltenem Rückweg, automatisierter lokaler Datenübernahme und einem separaten Login-Smoke. Der Docker-Stack, der neue Repository-Pfad und die Datenübernahme waren dabei nur die sichtbaren Bestandteile; entscheidend war, dass die Beziehungen zwischen Worktree, Konfiguration, Datenbank und Anwendung überprüfbar blieben.

Der Infrastrukturtest zeigte zugleich den Wert der Arbeitsteilung mit Codex. Ich definierte Ziele, Grenzen und Abnahmekriterien; Codex übernahm innerhalb dieses Rahmens die wiederholbare operative Arbeit. Der erfolgreiche Login blieb der entscheidende Realitätscheck: Automatisierung erleichterte die Umsetzung, ersetzte aber weder bewusste Entscheidungen noch die abschließende Prüfung.

Interne Quellen

Alle folgenden Quellen sind interne, nicht öffentlich zugängliche Projektquellen und dienen der Dokumentation dieses Einzelfalls.

• Lutions (2026a). LUMVP-1214: Lokale Entwicklungsumgebung auf anderes Laufwerk umziehen und containerisieren. Interne Ticketdokumentation mit Parent-/Subticket-Struktur, Milestone-Kommentaren, Testagent-/Auditor-Fazits und Untertickets LUMVP-1215 bis LUMVP-1220.
• Lutions (2026b). docker_development_stack.md. Lokaler Docker-Entwicklungsstack.
• Lutions (2026c). LUMVP-1219: Lokale MariaDB in Docker migrieren. Interne Ticketdokumentation und Backup-Nachweis.
• Lutions (2026d). local-entrypoint.sh und LUMVP-1220. Host-Integration und Docker-DB-Konfigurationsfix.
• Lutions (2026e). README.md, start_test_environment.md, local_repository_relocation.md, test_access.md. Aktualisierte lokale Entwicklerdokumentation.