VISION.md — Comment penser ce projet

Le fichier de pensée du Minecraft OS

José Gasser (J0bot) · AGPL-3.0

Résumé

Document de vision (non technique) expliquant comment José pense le XERB0XI0N : une logique fractale où les petites choses se connectent pour former de plus grandes, faites des mêmes petites choses. Pose la grammaire de nommage (-ION brique, -XION réseau, sans suffixe entité), l'auto-connexion sans menu (principe Chill-Tekk), le pont réel↔virtuel via Minecraft comme outil de design spatial, ArchiXION premier ploxion, et le test du joueur de 12 ans. Synthèse : transformer la réalité en blocs, et les blocs en réalité.

§1VISION.md — Comment penser ce projet

Ce fichier n'est pas technique. Il explique comment José PENSE ce projet. Si tu comprends ce fichier, tu comprends tout le reste automatiquement. Lis ça avant de coder quoi que ce soit.

§2Le principe fondamental

Tout dans XERB0XI0N suit UNE seule logique : les petites choses se connectent pour former des grandes choses, et les grandes choses sont faites des mêmes petites choses. C'est fractal. C'est récursif. C'est Minecraft.

Un bloc seul = une unité. Deux blocs côte à côte = déjà un système. Dix blocs = une machine. Mille blocs = un monde. Et chaque bloc reste un bloc. Il ne change pas. C'est le contexte qui change.

C'est exactement comme les atomes → molécules → cellules → organes → corps. Ou comme les Bions → Cubions → Boxions → Xerboxion.

Quand José dit "LedION", il ne voit pas un bloc Minecraft. Il voit un composant physique réel (une LED strip) représenté dans un espace 3D. Il voit le fil qui relie cette LED à un ESP32. Il voit le groupe de LEDs qui forment une zone. Il voit l'export JSON qui va configurer le vrai contrôleur. Le bloc Minecraft est juste le pixel de cette réalité.

§3Comment nommer les choses

Les noms ne sont JAMAIS arbitraires. Ils décrivent la nature de la chose.

-ION = une unité. Un atome. Une particule. Quelque chose qui existe seul.

• LedION = une LED, un point de lumière
• WledION = un module d'adressabilité
• SensorION = un capteur
• Le suffixe -ION dit : "je suis une brique de base"

-XION = un réseau. Un groupe. Des IONs connectés.

• LedXION = un groupe de LedIONs qui forment une unité logique
• Le suffixe -XION dit : "je suis l'émergence de plusieurs IONs connectés"

Pas de -ION = une entité complète, pas une brique.

• Xerbot = un robot/contrôleur. C'est pas une brique dans un mur, c'est un agent qui agit.
• Xerboxion = le système entier. Pas une brique, le truc complet.

Quand tu crées un nouveau concept : demande-toi — est-ce que c'est une brique (-ION), un réseau de briques (-XION), ou une entité autonome (pas de suffixe) ?

§4L'auto-connexion

C'est LE truc que personne ne capte du premier coup.

Dans Minecraft vanilla, tu poses un bloc. C'est un bloc. Point. Dans MinecraftOS, poser deux blocs côte à côte = créer une relation. Le système détecte automatiquement que ces deux blocs sont connectés et forme un groupe (Cubion).

Tu n'as PAS besoin de :

• Ouvrir un menu
• Cliquer sur "créer un groupe"
• Connecter des fils
• Configurer quoi que ce soit

Tu poses. Ça se connecte. C'est tout.

C'est le principe Chill-Tekk : la technologie la plus avancée doit être la plus invisible. Poser un bloc à côté d'un autre, c'est le geste le plus simple possible dans Minecraft. Et ce geste simple crée de la complexité automatiquement.

Un mur de 50 LedIONs = un seul LedXION. Un Xerbot posé à côté = il scanne tout le groupe d'un coup. L'intelligence est dans le système, pas dans l'utilisateur.

§5Le pont réel ↔ virtuel

Chaque bloc dans Minecraft représente quelque chose de RÉEL. Pas une métaphore. Une correspondance directe.

Le workflow réel de José :

1. Scanner son bar avec le téléphone (Polycam)
2. Importer le scan dans Minecraft (FileToVox → Litematica)
3. Placer les LedIONs sur les murs/plafond du bar reconstruit
4. Ajuster les couleurs, les zones, les effets
5. Poser un Xerbot, scanner → export JSON
6. Flasher ce JSON sur l'ESP32 réel
7. Les vraies LEDs s'allument avec la même config que dans Minecraft

C'est pas un jeu. C'est un outil de design spatial qui utilise Minecraft comme interface.

§6ArchiXION est le premier, pas le dernier

ArchiXION (architecture/LEDs) est le premier PL0XI0N de design. Mais la logique BionBlock est GÉNÉRIQUE. Le même système servira pour :

• SolidWorXION — design mécanique. Des blocs qui représentent des pièces mécaniques.
• KiCadoXION — design PCB. Des blocs qui représentent des composants électroniques.
• FuXION — design 3D général.

Chaque fois, c'est le même pattern : BionBlock spécialisé → auto-grouping → contrôleur → export. La seule chose qui change, c'est les propriétés du bloc et le format d'export.

Quand tu codes un BionBlock, tu codes pour TOUS les futurs outils de design. Pas juste pour les LEDs.

§7L'état d'esprit maker

José ne pense pas en "features" ou en "user stories". Il pense en blocs qu'on pose et qu'on connecte. Chaque idée se traduit en : "quel bloc je pose, et qu'est-ce qui se passe quand je le pose à côté d'un autre ?"

Si la réponse est compliquée → mauvais design. Si la réponse est "ça se connecte tout seul" → bon design. Si la réponse nécessite un menu → acceptable mais pas idéal. Si la réponse nécessite de lire une doc → échec.

Le test ultime : est-ce qu'un joueur Minecraft de 12 ans comprendrait ce que fait le bloc sans explication ? Si oui, c'est bien. Si non, simplifie.

§8Pourquoi Minecraft

Pas parce que c'est un jeu populaire. Parce que Minecraft a déjà résolu les problèmes les plus durs de l'informatique :

• Mémoire → chunks (lazy loading natif)
• Scheduler → tick system (20 Hz, déterministe)
• Filesystem → NBT (arbre clé-valeur sur chaque bloc)
• Apps → dimensions (espaces isolés)
• Permissions → claims (par chunk)
• UI → l'espace 3D lui-même

Et surtout : Minecraft est l'espace où José a toujours été le plus créatif, le plus libre, le plus lui-même. C'est pas un choix technique. C'est un choix existentiel. Le mod transforme l'endroit où il est le plus heureux en outil de travail.

§9Ce que "bien coder" veut dire ici

1. Ça compile et ça marche. Pas de code théorique. Du code qui tourne.
2. Ça feel vanilla. Sons MC, widgets MC, couleurs MC. Pas de UI alien.
3. C'est extensible sans refactor. Un nouveau BionBlock = une nouvelle classe + registration. Pas de réécriture.
4. C'est spatial. Tout se passe dans le monde 3D. Pas dans des menus imbriqués.
5. C'est immédiat. Poser → résultat. Pas poser → configurer → valider → résultat.

§10En une phrase

XERB0XI0N c'est transformer la réalité en blocs, et les blocs en réalité.

Tout le reste découle de ça. Si tu comprends cette phrase, tu comprends le projet.

Statut : draft · Licence : AGPL-3.0 · minecraft-os-vision