PLOXION — comment un ploxion est fait

Comment un ploxion est fait : inputs, outputs, degré de migration

José Gasser (J0bot) · juin 2026 · MIT

Résumé

Le quoi et le comment d'un ploxion : sa structure, ses inputs / outputs, et son degré de migration (tourne-t-il déjà sur le core ? est-il connecté au xion ?). Pour produire un ploxion valide à la chaîne → PLOXION-SPEC.md (référence exhaustive). Le memo des commandes → CHEATSHEET.md.

§1C'est quoi

Un ploxion = une brique autonome, composable, branchable. Elle tourne seule, se branche/débranche sans casser le reste, et se déclare via un manifeste. C'est un mini-OS : elle boote → tourne → s'éteint sans trace (« droit au silence » §4.4 : débranchée = zéro ressource, zéro écoute).

Fractal : bion → ploxion → cubion → xerboxion. Un ploxion peut contenir/ouvrir d'autres ploxions ; la même description vaut pour l'atome et le tout.

§2Les deux fichiers

Fichier	Rôle
`config/ploxions.php` → entrée `'<id>' => [...]`	le manifeste (déclaration : nom, icône, ce qu'il offre, gating)
`resources/views/ploxions/<id>/app.blade.php`	l'app cliente (CSS + JS inline, 100% navigateur)

Le contrat de l'app :

window.jOSApps['<id>'] = {
  manifest: { id:'<id>', name:'Nom', icon:'✦' },
  mount: function (container, ctx) {
     // rend dans `container`…
     return { unmount: function () { /* LIBÈRE TOUT */ container.innerHTML=''; } };
  }
};

Règle d'or : mount rend dans container et renvoie { unmount } qui relâche tout (timers, listeners, streams, blobs). Pas de fuite = un OS qui s'éteint proprement.

§3INPUTS — ce qu'un ploxion peut LIRE

Source	Détail
`container`	le DOM où il rend (son écran, à lui seul)
`ctx.config`	le `config` de son manifeste (ex. `ctx.config.url`)
`ctx.win`, `ctx.tab`, `ctx.scope`, `ctx.close()`	sa fenêtre / son onglet / une cible (ex. analyse) / fermer
Événements	clavier, pointeur, fichiers (drag-drop) dans `container`
`localStorage`	persistance par clé `jos:<ploxion>:…`
Le bus (`window.jOSPorts.on(topic, fn)`)	écoute ce que les autres ploxions émettent (= ses wormions d'entrée)
Les moteurs ambiants	`window.jOS` (voir CHEATSHEET → Moteurs) — toujours optionnels*, tester l'existence avant usage
`<meta>`	`user-admin`, `user-name`, `csrf-token`

§4OUTPUTS — ce qu'un ploxion PRODUIT

Sortie	Détail
Rendu	son interface dans `container` (= un xer)
`{ unmount }`	la libération (sortie obligatoire)
`provides` (manifeste)	les capacités qu'il offre au système
Émissions bus (`window.jOSPorts.emit(topic, data)` → `/xion/emit`)	ce qu'il publie aux autres (= ses wormions de sortie)
Tsoins	`jOSTsoin.mark(...)` / `POST /chat {kind:'tsoin'}` — l'instant rejouable
Fichiers / navigation	download, ObjectURL, `jOS.openPloxion(id)`, écritures `localStorage`

I/O = wormions. Le câblage entre ploxions (qui émet quoi, qui écoute quoi) est calculé depuis ces topics — c'est le « n8n » du xerboxion. Le ploxion analyse 🔬 montre les paquets en direct ; le bus inspecteur montre la topologie.

§5Le BUS = la connexion au xion

// émettre (output)
window.jOSPorts && window.jOSPorts.emit('mon.topic', { ... });
// écouter (input)
window.jOSPorts && window.jOSPorts.on('autre.topic', function (data) { ... });

jOSPorts relaie sur /xion/emit ; l'état vivant se lit via /xion/snapshot. Un ploxion qui émet/écoute sur le bus est connecté au xion — il participe à l'écosystème, pas juste à sa fenêtre.

§6Le degré de migration

La question de José : « est-ce qu'un ploxion tourne déjà sur le core, ou pas ? est-il connecté au xion ? »

Le but final : déprécier Laravel, que le xerboxion-core serve et exécute tout (« le bion Linux »). Un ploxion avance par paliers. Deux axes :

Axe A — exécution (où il tourne) — linéaire

Degré	Nom	Veut dire	Comment savoir
D0	Page Laravel	rendu côté serveur (route `web.php` + blade)	c'est une page, pas une app `jOSApps`
D1	Ploxion client	`jOSApps` + `config/ploxions.php`, 100% navigateur, monté par le layout	la grande majorité aujourd'hui
D3	Servi par le core	ses assets sont livrés par le xerboxion-core via `/px/<id>/*` (plus par Laravel)	l'asset répond sous `/px/<id>/…` (jalon M1)
D4	Tourne sur le core	sa logique = des bions WASM exécutés par le xerboxion-rt, Laravel-free	cible finale (cube ≤16 Go flashable)

Axe B — connexion au xion (orthogonal) — capacité

Badge	Veut dire	Comment savoir
— (isolé)	rend juste dans sa fenêtre	n'appelle pas `jOSPorts`
🔗 xion	émet/écoute sur le bus `jOSPorts` (→ `/xion/emit`) ; visible dans `/xion/snapshot`	grep `jOSPorts` dans son `app.blade.php`

Un ploxion typique aujourd'hui est D1 (client) ; les plus avancés sont D1 + 🔗 xion ; la migration les pousse vers D3 (servi par le core) puis D4 (exécuté par le core).

Le noter dans le manifeste (convention)

Pour rendre le degré lisible et requêtable, on peut le déclarer dans config/ploxions.php :

'<id>' => [
    // …
    'stage' => 'client',   // 'laravel' | 'client' | 'core-served' | 'core-run'
    'xion'  => true,        // émet/écoute sur le bus jOSPorts
],

Champs optionnels et non bloquants. Tant qu'ils ne sont pas posés, le degré s'évalue avec les critères ci-dessus (présence de jOSApps, route /px/<id>, usage de jOSPorts, bions WASM). Les remplir = donner au xerboxion une carte de sa propre migration (un ploxion migration/atlas peut alors l'afficher).

§7Checklist d'un bon ploxion

[ ] id slug unique ; name / icon / description présents dans config/ploxions.php.
[ ] mount(container, ctx) rend dans container, renvoie { unmount } qui libère tout.
[ ] window.jOSApps['<id>'] enregistré ; app du manifeste = la bonne clé.
[ ] Aucune route serveur neuve (réutilise les existantes) ; ressources externes déclarées en CSP (config/csp.php).
[ ] Dépendances optionnelles (test d'existence) ; dégrade proprement si une brique manque.
[ ] admin / auth corrects si privé ; secrets jamais côté client.
[ ] Utilisable mobile + desktop ; thémé via les variables --xr-*.
[ ] Se monte et se démonte sans erreur (test headless : mount → interagir → unmount).
[ ] (Migration) son degré est évaluable, idéalement déclaré (stage / xion).

Voir aussi : PLOXION-SPEC.md (production à la chaîne) · CHEATSHEET.md (commandes) · roadmap.md (état). Maintenu par cloudion — domaine : génération de ploxions. « Ne pas nuire. »

Statut : published · Licence : MIT · 22.06.2026 · anatomie-ploxion