Récap Session + Avancement Paper

Tout ce qu'on a fait aujourd'hui, et où ça se rattache au paper

José Gasser (J0bot) · AGPL-3.0

Résumé

Récapitulatif d'une session d'architecture ayant produit treize documents de linéarisation d'intention. Le texte relie ce travail au paper (16 sections) : ce qui le confirme (site=premier xerboxion, tiling, tsoin, plugion/ploxion), ce qui l'étend (modes Xerion, OS hors-ligne, ploxion issues, arbre à son) et ce qui reste en suspens en section 16. Conclut que le paper dit pourquoi et quoi, la session dit comment.

§1Récap Session + Avancement Paper

§2Tout ce qu'on a fait aujourd'hui, et où ça se rattache au paper

§3Ce qu'on a produit aujourd'hui

Une grosse session d'architecture. Treize documents, presque tous des linéarisations d'intention pour la suite du projet.

Architecture & infra

• architecture_xerboxion.md — repo central, marketplace de ploxions, boxions, sous-domaines, répartition serveurs
• architecture_serveurs_dns.md — répartition front PHP (xer, api, auth, www sur j0bot.ch) vs VPS (tous les services), DNS posés, redirections multilingues faites
• xerboxion_os_ploxions.md — le xerboxion comme OS, core léger partout, ploxions vs plugions, l'arbre à son
• xerboxion_hors_ligne.md — tout fonctionne hors ligne, local d'abord, réseau pour synchroniser

Le site comme xerboxion

• site_premier_xerboxion.md — page=koin, site=kion, le tout=xerkion=xerboxion
• site_wiki_vivant.md — tout le site est un wiki, tout est slug/koin/tsoin, machine à tsoins fractale
• wiki_intention.md — wiki riche comme Wikipédia, extrapolations séparées, graphe façon Obsidian, scan post-it, sync MURION
• page_tiling_xerminal.md — page workspace tiling façon i3, xerminal + ploxions

Les modes & le système

• premier_cubion_modes_xerion.md — les 8 modes du [[vecteur-xerion|Vecteur Xerion]] (le premier cubion)
• ploxions_fenetres.md — les ploxions à brancher, système de fenêtres avec koin

Les ploxions

• ploxion_finances.md — terrain préparé, structure budget romand, niveaux
• ploxion_minecraft_os.md — Minecraft comme xer, un item Kion, UI adaptée
• ploxion_issues.md + dossier issues/ — système de tickets, 5 issues de Léo

Coordination

• prompt_agent_ploxion5.md — le prompt pour l'agent coordinateur qui prend la vue d'ensemble et dispatch

§4Avancement par rapport au paper

Le paper (xerboxion_paper.md, 16 sections) reste la référence théorique. Voilà comment le travail d'aujourd'hui s'y rattache.

§5Ce qui CONFIRME le paper (concepts déjà dans le paper, maintenant implémentés ou spécifiés)

§3 Architecture de l'écosystème — aujourd'hui on a concrétisé toute la chaîne. Le site comme premier xerboxion (page=koin, site=kion), la répartition serveurs, le marketplace de ploxions. Le paper décrit l'architecture ; aujourd'hui on l'a posée en vrai.

§3.8 / §16.9 Interface picture-in-picture / tiling — le paper a ça en "point en suspens" (§16.9 : window manager façon i3 appliqué à tout l'OS). Aujourd'hui page_tiling_xerminal.md et ploxions_fenetres.md le spécifient concrètement. → §16.9 peut sortir des "points en suspens" et monter dans §3.

§9 Le Tsoin — site_wiki_vivant.md applique le tsoin comme unité de navigation (chaque arrêt = un tsoin). Le paper définit le tsoin théoriquement ; aujourd'hui il devient mécanique d'usage.

§3 PL0XI0NS — la distinction plugion]��]A�4񄁡ɕ��ݥ������᥽����������ȵ�ɕ�����ф�ͱ՜����᥽�����ф��ɕ�������ѕɴ�����᥽�� clarifiée aujourd'hui (le plugion relie comme une API, le ploxion a des niveaux et s'adapte à son hôte) précise le paper.

§6Ce qui ÉTEND le paper (nouveau, à intégrer)

Le [[vecteur-xerion|Vecteur Xerion]] comme modes de session — premier_cubion_modes_xerion.md. Les 8 axes deviennent des modes de travail du système. Le paper parle du Vecteur Xerion comme modèle cognitif, mais pas comme modes opérationnels du xerboxion. → nouveau, à ajouter au paper (lien §3 architecture + le Vecteur Xerion).

Le xerboxion comme OS hors ligne — xerboxion_hors_ligne.md. Le paper dit que le xerboxion tourne en local, mais l'aspect hors-ligne-d'abord avec réconciliation est précisé aujourd'hui. → à intégrer dans §3.

Le ploxion issues — système de tickets avec moi comme testeur. Pas dans le paper. C'est de l'outillage projet, peut rester hors paper ou aller dans une section méthode.

L'arbre à son — xerboxion_os_ploxions.md. Réseau de basses physiques (kions de son) avec map de spatialisation. Extension du concept de kion physique. → pourrait rejoindre §16 comme nouveau point, ou §3 hardware.

§7Ce qui reste EN SUSPENS dans le paper (pas touché aujourd'hui)

Section 16 du paper, toujours ouverte : imprimante 3D biologique (16.1), vêtement connecté (16.2), contrôle par bruits de bouche (16.3), zones (16.4), informatique par ondes (16.5), adaptation sous-marine (16.6), immortalité quantique (16.7), nouvel alphabet (16.8). On n'y a pas touché — ils restent des pistes.

Note : §16.4 (zones) a un lien avec le concept de boxions qu'on a travaillé aujourd'hui — une zone pourrait être l'espace d'un boxion. À creuser une autre fois.

§8L'état global

Le paper = la théorie, stable, 16 sections. Aujourd'hui = l'implémentation et la spécification opérationnelle. On n'a pas écrit dans le paper — on a produit la couche "comment ça se construit vraiment", qui confirme le paper sur l'architecture et l'étend sur trois points (modes Xerion, hors ligne, issues).

Ce qui mérite de remonter dans le paper quand tu voudras l'éditer :

1. §16.9 (tiling) → monte dans §3, c'est plus en suspens, c'est spécifié.
2. Les modes du Vecteur Xerion → nouveau, à ajouter.
3. Le hors-ligne-d'abord → précision dans §3.
4. La distinction plugion]��]A�4񄁡ɕ��ݥ������᥽����������ȵ�ɕ�����ф�ͱ՜����᥽�����ф��ɕ�������ѕɴ�����᥽�� → précision dans §3.

Ce qui reste hors paper (outillage, pas théorie) : Le ploxion issues, le prompt ploxion5, la répartition DNS concrète. C'est de l'opérationnel, ça vit dans le projet, pas dans le paper.

§9Le fil

Aujourd'hui c'était pas de la théorie, c'était de l'architecture concrète. Le paper tient, et le travail du jour le confirme et l'étend sans le contredire. La plupart de ce qu'on a fait, c'est traduire les concepts du paper en specs implémentables. Quatre trucs méritent de remonter dans le paper. Le reste c'est l'outillage qui fait tourner le projet.

Le paper dit pourquoi et quoi. Aujourd'hui on a dit comment.

Récap Session · XERB0XI0N · J0BOT · 2026

Statut : draft · Licence : AGPL-3.0 · recap-avancement-paper