Keine dieser Korrekturen hat funktioniert, nachdem die Seite neu geladen wurde

Die Routen waren behoben. Der State-Endpoint war neu geschrieben. Das Datenformat war korrigiert. Jede Änderung im Repository bestätigt, in der Datei sichtbar, genau wie beabsichtigt.

Browser neu geladen. Nichts hat sich geändert.

Dieselbe kaputte Tabelle. Dieselbe leere Canvas.

Was Tatsächlich Passiert Ist

Die Plattform läuft lokal in Docker — eine Reihe von Containern, jeder mit einem eigenen Service, verbunden über eine gemeinsame Konfiguration. Die Front-End-Webanwendung ist als Volume gemountet: Quelldateien auf der Festplatte werden direkt in den Container gemappt. Vite, das Build-Tool, beobachtet Dateiänderungen und lädt den Browser automatisch neu.

Nur dass es nicht beobachtet hat.

Unter Windows mit Docker über WSL2 — die Linux-Kompatibilitätsschicht, die Windows für Container nutzt — propagieren die Filesystem-Event-Benachrichtigungen, auf die Vite zum Erkennen von Änderungen angewiesen ist, nicht korrekt über die Virtualisierungsgrenze hinweg. Das Linux-Benachrichtigungssystem meldet die Änderung. Windows leitet sie nicht weiter. Vite sieht das Datei-Update nie. Der Browser liefert weiterhin den Code aus, der vorher da war.

Die Korrektur war eine Zeile in der Vite-Konfiguration: usePolling: true. Statt auf Benachrichtigungen über Änderungen zu warten, prüft Vite alle 300 Millisekunden auf welche. Etwas weniger effizient. Funktioniert.

Die Table Engine — der Backend-Service, der den eigentlichen Spielzustand verwaltet — hatte ihre eigene Version desselben Problems. Backend-Services in diesem Stack laufen nicht im Watch-Modus. Code-Änderungen erfordern einen manuellen Container-Neustart. Standardverhalten für einen Production-Service. Man muss nur wissen, dass man neu starten muss.

Die Andere Sache, Die Falsch War

Nachdem die Environment-Probleme gelöst waren, tauchte ein dritter Bug auf: Die Table Route hatte einen Auth Guard, der den Browser immer zur Login-Seite schickte.

Nicht weil der Nutzer nicht eingeloggt war. War er. Der Guard prüfte einen TanStack Router Context-Wert, der nie befüllt wurde — der Router war ohne Context Provider konfiguriert, also war context.auth immer undefined. Der Guard las "nicht authentifiziert", leitete zum Login um. Login sah eine authentifizierte Session, leitete zurück zum Lobby um. Der Browser geriet in eine Schleife.

Eine Zeile geändert. Der Guard wurde aktualisiert, um direkt vom Authentication Store zu lesen — dasselbe Pattern, das jede andere Route in der Anwendung verwendet. Behoben.

Was Das Von Der Person An Der Tastatur Verlangt

Die Korrekturen waren korrekt. Das System hat sie nicht aufgegriffen. Diese Beobachtung — dass korrekter Code und laufender Code zwei verschiedene Dinge sind — erforderte, das Entwicklungsumfeld gut genug zu kennen, um die richtige Frage zu stellen.

Der Agent kann die Korrektur schreiben. Er kann den Bug nachverfolgen, sobald du ihn beschreibst. Er kann nicht bemerken, dass der Browser eine gecachte Version des Codes von vor der Konfigurationsänderung ausliefert. Diese Beobachtung ist menschlich.

Das System gut genug zu kennen, um zu diagnostizieren, warum eine korrekte Korrektur nicht greift — das ist der Teil, der nicht automatisiert wird.

Nach der Polling-Konfiguration, nach den Container-Neustarts, nach der Auth-Guard-Korrektur: Der Tisch lud. Die Sitze erschienen. Der Buy-In-Dialog wurde gerendert. Die Lobby-Cards hatten die richtige Höhe. Alles funktionierte.

Der nächste Post behandelt, wie Integration Testing aussah, sobald wir ein funktionierendes System zum Testen hatten — und warum diese Phase gleich aussieht, egal ob AI oder Menschen den Code geschrieben haben.

Für die Founder-Perspektive auf das Navigieren dieser Art von Debugging-Prozess — was die Human-in-the-Loop-Rolle wirklich verlangt, wenn AI den größten Teil des Codebase geschrieben hat — gibt's das auf The Salty Korean.

Stay salty.