Aucune de ces Corrections n'a Fonctionné Après Avoir Rechargé la Page

Les routes étaient corrigées. L'endpoint d'état avait été réécrit. Le format de données était corrigé. Chaque changement confirmé dans le repository, visible dans le fichier, exactement comme prévu.

Navigateur rechargé. Rien n'a changé.

La même table cassée. Le même canvas vide.

Ce Qui Se Passait Réellement

La plateforme tourne localement dans Docker — un ensemble de conteneurs, chacun exécutant un service, connectés via une configuration partagée. L'application web front-end est montée par volume : les fichiers sources sur disque sont mappés directement dans le conteneur. Vite, l'outil de build, surveille les changements de fichiers et recharge automatiquement le navigateur.

Sauf qu'il ne surveillait pas.

Sur Windows avec Docker fonctionnant sur WSL2 — la couche de compatibilité Linux que Windows utilise pour les conteneurs — les notifications d'événements du système de fichiers sur lesquelles Vite s'appuie pour détecter les changements ne se propagent pas correctement à travers la frontière de virtualisation. Le système de notifications de Linux signale le changement. Windows ne le transmet pas. Vite ne voit jamais la mise à jour du fichier. Le navigateur continue à servir le code qui était là avant.

La correction était une ligne dans la configuration Vite : usePolling: true. Au lieu d'attendre d'être notifié des changements, Vite vérifie toutes les 300 millisecondes. C'est légèrement moins efficace. Ça marche.

Le table engine — le service backend qui gère l'état réel du jeu — avait sa propre version du même problème. Les services backend dans cette stack ne tournent pas en mode watch. Les changements de code nécessitent un redémarrage manuel du conteneur. Comportement standard pour un service de qualité production. Il faut juste savoir qu'il faut redémarrer.

L'Autre Chose Qui n'Allait Pas

Une fois les problèmes d'environnement résolus, un troisième bug est apparu : la route de la table avait un auth guard qui envoyait toujours le navigateur vers la page de connexion.

Pas parce que l'utilisateur n'était pas connecté. Il l'était. Le guard vérifiait une valeur de contexte TanStack Router qui n'était jamais peuplée — le router était configuré sans context provider, donc context.auth était toujours undefined. Le guard lisait "non authentifié", redirigeait vers le login. Login voyait une session authentifiée, redirigeait vers le lobby. Le navigateur entrait en boucle.

Une ligne changée. Le guard a été mis à jour pour lire directement depuis l'authentication store, le même pattern que toutes les autres routes de l'application. Corrigé.

Ce Que Cela Demande à la Personne Devant le Clavier

Les corrections étaient correctes. Le système ne les prenait pas en compte. Cette observation — que du code correct et du code qui tourne sont deux choses différentes — demandait de connaître l'environnement de développement assez bien pour poser la bonne question.

L'agent peut écrire la correction. Il peut tracer le bug une fois que tu l'as décrit. Il ne peut pas remarquer que le navigateur sert une version en cache du code d'avant le changement de configuration. Cette observation est humaine.

Connaître le système assez bien pour diagnostiquer pourquoi une correction correcte ne prend pas effet — c'est la partie qui ne s'automatise pas.

Après la configuration du polling, après les redémarrages de conteneurs, après la correction de l'auth guard : la table s'est chargée. Les sièges sont apparus. Le dialogue de buy-in s'est affiché. Les cards du lobby avaient la bonne hauteur. Tout fonctionnait.

Le prochain post couvre à quoi ressemblait l'integration testing une fois qu'on avait un système qui fonctionne pour tester — et pourquoi cette phase se ressemble peu importe si l'AI ou des humains ont écrit le code.

Pour la perspective du founder sur la navigation dans ce genre de processus de debugging — ce que le rôle human-in-the-loop demande vraiment quand l'AI a écrit la majorité du codebase — c'est sur The Salty Korean.

Stay salty.