Le Ploxion Xerxion — la couche agents de XERB0XI0N
Résumé
Le xerxion (terme canon) = un xerion digitalisé : un cerveau qui vit dans le xion comme pattern d'information. Le ploxion xerxion est l'interface qui rend ça opérationnel : c'est la couche agents de XERB0XI0N — là où chaque IA se connecte pour travailler dans le repoverse, et où on voit, pilote et parle à la flotte d'agents qui construit le système. Il contient le ploxion Claude Code (une instance en tmux sur le boxion). Cible : xerxion.j0bot.ch (ex-agents.j0bot.ch).
Document de design + recherche — ploxion5 (coordinateur), 2026-06-18. Statut : draft.
Ce que le ploxion montre
Le dashboard des agents (vision José, ploxions.j0bot.ch / fenêtre dans le xer) :
- le statut de tous les agents qui tournent, avec barres de progression ;
- en ajouter un (via tmux) ;
- voir leurs logs ;
- leur parler ;
- accepter ou refuser ce qu'ils proposent ;
- activer / désactiver les ploxions.
C'est une UI pour Claude Code, intégrée à l'écosystème comme un ploxion, et remontée dans le dashboard global.
Architecture — quatre couches
- Substrat : des instances Claude Code en tmux sur le boxion (VPS). La flotte existe déjà — sessions
ploxion3/4/5/6,manager, plus les agentscore/cloudion/runtime. « Le seul truc c'est qu'il faut une instance de Claude code en tmux dans le vps et c'est bon. » - Bus de coordination : le canal /coord (table
claude_messages) = le bus inter-agents. Alimenté parcoord:say, lu parcoord:tail, exposé en JSON par/coord/feed. C'est là que les agents claim, se synchronisent, évitent les collisions. - Backend xerxion : agrège le substrat (tmux) + le bus (/coord) en un statut de flotte. Livré v0 = le script
xerxion(bi0ns/ploxi0ns/xerxion/output/xerxion) : table humaine (agent · lane · quand · dernier statut · ● live/○) + mode--jsonpour l'UI. - UI (le xer) : un écran client-side dans le window-manager (même patron que les ploxions repoverse / ideas-map) qui consomme le statut + le feed /coord et affiche la flotte, permet de parler (poster sur /coord) et d'accepter/refuser.
La boucle braindump → live
La vision opérationnelle, l'accélérateur du labo : tu braindump sur une page (cf ploxion braindump) → le xerxion (Claude en tmux branché repoverse) lit le tsoin / le screenshot → la page ou le ploxion s'améliore tout seul, en preview. On parle au xerxion, on voit le ploxion évoluer. À terme : « je braindump et direct ça se crée dedans, dans le labo, dans une preview ».
Connexion repoverse
À terme, chaque agent (xerxion) se connecte au repoverse — compte j0bot + API, pas de GitHub — pour bosser : chaque truc cliquable a son lien de code, on voit et on édite le source en live. Le xerxion vit dans le nexus / le repoverse. Au début c'est GitHub, ensuite tout passe par repoverse (plus simple, rien à installer).
État — 2026-06-18
- ✅ Backend v0 : le script
xerxion(fleet dashboard tmux + /coord, sortie table +--json). Lecture seule, testé. - ✅ Substrat actif : 7 sessions tmux + agents core/cloudion/runtime/ploxion5 sur /coord.
- ✅ Bus : /coord opérationnel (table
claude_messages+ feed JSON). - ⏳ UI : à câbler côté lane web (fenêtre window-manager consommant
/coord/feed+ un endpoint statut-flotte). Le backend tmux nécessite un accès shell serveur → endpoint dédié à prévoir. - ⏳ Sous-domaine
xerxion.j0bot.chà mapper (lane Coolify/Traefik).
Le fil
Le xerxion, c'est comment les agents deviennent un ploxion observable et pilotable dans le xer. Substrat tmux + bus /coord + backend d'agrégation + écran client-side, branché à terme sur le repoverse. La flotte qui construit XERB0XI0N — rendue visible, adressable, et capable de s'améliorer en boucle depuis un simple braindump.
Statut : draft · Licence : AGPL-3.0
· 18.06.2026 · ploxion-xerxion