blog.vfg.lol

Archivé. Cet article n'apparaît plus dans les listes du blog : doublon d'un autre article. Lire la version de référence →

Deux POC, un seul prompt : RainbowJourney face à Chromatic River

Comparer deux implémentations parallèles d'un jeu de piano synesthésique, vérifier au lieu de croire les documents, et décider quoi garder de chacune

Deux POC, un seul prompt : RainbowJourney face à Chromatic River

Le point de départ tient en un prompt : un jeu d'apprentissage et d'improvisation au piano MIDI, où chaque note devient couleur, où les prochaines notes possibles apparaissent en fantôme avec l'émotion qu'elles produiraient, et où une fontaine de notes alimente une rivière qui réagit à ce qu'on joue.

Ce prompt a été confié en parallèle à deux chaînes d'agents. Il en est sorti deux POC complets et très différents : RainbowJourney, une application React et TypeScript dans une vallée lumineuse, et Chromatic River, un site statique en JavaScript qui navigue sur un canal vénitien à l'aube.

Les deux fonctionnent. La question n'est donc pas « lequel marche », mais « lequel sert de base, et que faut-il prendre à l'autre ».

Deux philosophies de construction

RainbowJourney a été construit comme un produit. TypeScript strict, Vite, schémas Zod sur les réglages et les sessions, Tonal pour la théorie musicale, IndexedDB pour enregistrer et rejouer les parcours. Il compte 60 tests unitaires, des scénarios Playwright, une CI GitHub, et une documentation abondante : canon de gameplay, handoff, statut, journal de tâches, protocole de retest.

Chromatic River a été construit comme une scène. Aucun build, aucune dépendance installée, three.js chargé par CDN. Le moteur vient d'un template 3D de course de gondoles, et ça se voit dans le meilleur sens : réflexion planaire HDR sur l'eau, ville procédurale peinte sur canvas, brume, oiseaux, lumière rasante. En contrepartie, il n'a aucun test dans le dépôt, aucun type, et rien pour enregistrer une session.

Au premier regard, on a donc un projet solide mais visuellement générique, face à un projet saisissant mais fragile.

Ne pas croire les documents

Comparer deux projets à partir de leurs README revient à comparer deux promesses. L'audit a donc suivi une règle simple : chaque affirmation est vérifiée dans le code ou à l'exécution.

Pour RainbowJourney, les 60 tests annoncés ont été relancés : ils passent, et le typecheck ne signale aucune erreur. Mais trois défauts repérés plus tôt dans la journée ont été recherchés à nouveau, et ils sont toujours là.

Le premier : la boucle logique notifie React toutes les 25 millisecondes, même quand rien n'a changé. Chaque notification invalide les caches, si bien que l'interface recalcule suggestions et couleurs du clavier en permanence, sur le même thread que le rendu 3D.

Le deuxième est plus sournois : la stabilisation des accords sur 40 millisecondes vit dans un getter qui modifie l'état pendant le rendu. Elle ne fonctionne que parce que le premier défaut force un rafraîchissement continu. Corriger l'un sans l'autre casserait la détection d'accords.

Le troisième s'est aggravé. Le monde 3D dessine les traces de la plus ancienne à la plus récente, avec un budget plafonné. Les rubans sont passés à dix segments par note pour un plafond de 1 024 : au-delà de 102 traces visibles, ce sont les notes les plus récentes qui perdent leur ruban. Exactement celles qu'on regarde.

Pour Chromatic River, le travail avait été fait plus tôt : l'audit initial avait trouvé une octave traitée comme un unisson, la note de départ d'une transition jamais affichée, et des « fantômes » qui n'étaient que la gamme entière sans hiérarchie. Corrigés, puis vérifiés en jouant dans le navigateur. Cette vérification a d'ailleurs attrapé deux défauts invisibles à la lecture : une fontaine qui saturait en nuages blancs près de la caméra, et une carte de transition illisible sur le ciel clair.

La leçon vaut pour les deux projets : un document « à retester » n'est pas un résultat, et un code défensif qui retombe silencieusement sur l'ancien comportement peut masquer une intégration ratée.

Ce que chacun fait mieux

RainbowJourney l'emporte sur presque tout ce qui fait durer un projet. Sa chaîne MIDI a été éprouvée sur le vrai piano : relais avant l'analyse, relâchement lié à la décision de l'attaque, sortie désarmée en relecture. Il a un éditeur de 28 effets, des règles d'expression, des presets, des panneaux HUD persistants, un clavier AZERTY pour jouer sans piano. Sa couche pédagogique est la plus aboutie : indicateurs de style « safe » sans punition, frise des suggestions suivies, textes d'émotion qui affichent leur degré de certitude au lieu de prétendre à une vérité universelle.

Chromatic River l'emporte sur l'idée elle-même. Le prompt appelait « objectif le plus complexe » l'affichage des prochaines notes possibles avec leur émotion. RainbowJourney le fait avec une liste de deux à quatre suggestions et le même point lumineux sur chaque touche candidate. Chromatic River le fait dans le monde : des bouées flottent sur l'eau devant le bateau, chacune porte un glyphe qui dit sa famille d'intervalle — stable, tension, ouverture — et les quatre meilleures sont mises en avant, le reste en filigrane. Sa théorie musicale est isolée dans des fonctions pures : un classement des candidats qui garantit la diversité des familles, une palette OKLCH à clarté constante sur les douze classes de hauteur, une octave distincte de l'unisson dans les deux sens.

Il reste des points à égalité. Les deux ont un coût de rendu à surveiller, pour des raisons opposées. Et les deux ont une convention de langue incompatible : RainbowJourney impose une interface en ASCII sans accents, Chromatic River est en français accentué.

La synthèse

La recommandation est de garder RainbowJourney comme socle et de porter vers lui ce que Chromatic River exprime mieux.

L'inverse serait plus coûteux : refaire des types, une suite de tests, l'enregistrement et la relecture, un éditeur et une chaîne MIDI validée sur matériel demande bien plus de travail que de porter quelques modules. Et ces modules se portent bien : la théorie de Chromatic River n'importe pas three.js, elle se traduit en TypeScript et se teste immédiatement, avec les assertions déjà écrites pour elle.

L'ordre compte autant que le contenu :

  1. Assainir d'abord le chemin chaud de RainbowJourney. Chaque élément porté ajoute du rendu sur un thread déjà surchargé ; le faire après serait empiler sur un défaut.
  2. Porter la théorie : classement des candidats et palette, avec leurs tests.
  3. Rendre les fantômes lisibles sur le clavier : atlas de glyphes et hiérarchie forte / filigrane. C'est le gain le plus visible pour le joueur, à coût faible.
  4. Mettre les suggestions dans le monde : bouées 3D et fontaine qui part de la touche jouée. Cela prolonge directement l'« hologramme de rivière future » que le canon de RainbowJourney décrit déjà.
  5. Ajouter le canal vénitien comme décor, à côté de la vallée, plutôt que de remplacer le monde.
  6. Retester sur le piano réel et mesurer. Aucun des deux projets n'a aujourd'hui de mesure fiable des images par seconde par niveau de qualité.

Une décision précède l'étape 2 : choisir une seule convention de langue pour le projet combiné.

Ce que cette comparaison apprend

Deux agents partis du même prompt n'ont pas produit deux variantes d'une même chose. L'un a optimisé la durabilité, l'autre l'expression. Aucun n'avait tort, et aucun ne suffit seul.

La méthode qui a rendu la comparaison utile est modeste : lire le code plutôt que les documents, exécuter plutôt que supposer, et jouer dans le navigateur avant de déclarer une correction terminée. C'est à l'écran, pas à la relecture, que la fontaine blanche et la carte illisible sont apparues.

source markdown