Le xerboxion-core opérationnel — runtime de ploxions WASM (PLC)

José Gasser (J0bot) · juin 2026 · AGPL-3.0

Résumé

Auteur : cloudion (lane core). Brouillon « ? » pour review José. Code : ~/xerboxion-rt (local labo). Réalise la mission José (2026-06-18) : « finir le xerboxion-core pour que tous les services et ploxions soient connectés à ce xerboxion », avec la clé « tout peut être en WASM pour les ploxions ».

Le PLC v1 (le « CFC logiciel », figé)

Le contrat qu'un module WASM doit satisfaire (~/xerboxion-rt/docs/PLC-v1.md). PLC_ABI_VERSION = 1.

Exports requis (du module) : memory, alloc(len)->ptr, plc_manifest()->packed(ptr,len) (JSON {id,version,provides:[topic],requires:[topic],children_types,parent_types}), plc_init(), plc_health()->i32 (0=ok), plc_on_event(topic,payload), plc_goodbye(). Manque un export → rejet propre au chargement (pas de panique, rien d'enregistré à moitié).

Imports fournis par l'hôte (module "xerboxion") : plc_emit(topic,payload) (envoyer au bus) + plc_log(ptr,len).

provides = topics qu'il PEUT émettre (surface de consentement) ; requires = topics auto-abonnés (livraison).

L'hôte (wasmtime)

Charge N ploxions, chacun dans son propre Store (isolation : un ploxion ne peut pas lire la mémoire d'un autre ni appeler une fonction hôte non déclarée → trap).
Construit le bus depuis les manifestes (provides→requires).
Route + trace chaque plc_emit vers tous les abonnés (jamais l'émetteur), ne filtre pas le payload (§3.8). N'écho jamais.
Health sweep ; au goodbye libère le Store → droit au silence (un ploxion éteint n'écoute pas, ne laisse rien tourner).

Avancements (tous vérifiés adversarialement + revérifiés par moi)

Étape	Preuve
Cœur v0 (host + PLC v1 + bus) — `01dbcaf`	3 ploxions WASM (ping/pong/tracer) connectés ; ping→pong traverse les sandboxes ; casser le routage → connexion tombe (bus load-bearing) ; isolation + droit au silence prouvés
Ploxion tsoin (couche d'état) — `fe09958`	le VRAI moteur tsoin compilé WASM (58 Ko) = un ploxion ; un client record/replay un état bit-exact via le bus ; saboter le replay → MISMATCH crié ; testé random/texte/binaire-NUL/vide/256-valeurs/50-frames
Page tsoin WASM (front) — `126427f`	1er ploxion WASM côté navigateur (machine à tsoin autonome, file://, 0 réseau)
Connecteur de services déployés — `97919f0`	les 4 services déployés (j0bot.ch, repoverse, filesystem, tsoin) connectés au bus EN VRAI : un connecteur natif lit le registre `runtime.json` (lecture seule), fait un vrai `GET` HTTP de santé, et émet `service.health` sur le bus ; un ploxion WASM `watcher` (sandboxé, imports = `plc_emit`/`plc_log` uniquement, zéro réseau) réagit à chacun. Vérif adversariale : codes santé = curl indépendants ; saboter l'émission (liste vide / mauvais topic) → le watcher ne réagit plus = le pont est porteur ; chemin DOWN (url injoignable → `code=0 up=false → alert`) prouvé ; tests offline/déterministes. Revérifié par moi en live : 4/4 UP, 4 events bus, 4 livrés au watcher, droit au silence tenu.
Couche capability — `plc_fetch` consenti (PLC v1.1) — `037e6d2`	un ploxion déclare `capabilities:["net.fetch"]` ; l'hôte ne lie l'import réseau `plc_fetch` qu'aux ploxions qui l'ont déclaré (moindre autorité / consentement, comme `provides/requires`). Nouveau ploxion `health-adapter` = WASM pur, sandboxé : il fait de vrais `plc_fetch` et émet `service.health` (même forme que le connecteur natif → le `watcher` réagit sans changement). = un adaptateur de service devient un ploxion WASM, pas du code natif privilégié (la vision « tout en WASM »). Vérif adversariale 3 lentilles, TOUT passe : (1) mutation — défaire la grille rend rouge le test « ploxion non-déclarant rejeté » (grille porteuse, 2 couches) ; (2) sandbox — sur 7 .wasm, seul `health-adapter` importe `plc_fetch` ; byte-scan = 0 WASI / 0 socket ; 3 adversaires (no-cap/wrong-cap/empty-cap) rejetés au chargement, tripwire jamais déclenché ; (3) réel — codes adaptateur = curl indépendants (200/200/200), chemin DOWN → `status 0`, zéro régression (43/43 tests + toutes les démos + clippy clean).
Runner de recettes — l'hôte EXÉCUTE le designer — `76712cc`	l'export du designer de ploxion5 (`{ploxion, blocks:[{kind,label,ref,param}]}`, blocs `quand/entrée/si/action/attendre/sortie`) est parsé → compilé en règle réactive → exécuté sur le bus comme participant natif (`requires`=topics des `quand`, `provides`=topics des `action/sortie`). `si` = prédicat simple sur le payload (`==,!=,<,>,<=,>=`) ; `action` interpole `{champ}` depuis le payload. Une recette « quand `service.health`, si `up==false`, action `alert.notify` » fire UNIQUEMENT sur un service DOWN (payload interpolé, routé à un ploxion WASM réel), silencieuse sinon. = le triangle designer → recette → hôte → bus FERMÉ. Vérif adversariale, genuine : load-bearing — muter la donnée de recette inverse le comportement (condition/trigger/template tous data-driven), muter le moteur (eval toujours-vrai) → 6 tests rouges ; routage-sur-bus prouvé (emit recette → `tracer.wasm`) ; non-match silencieux ; 0 régression (62/62 tests, prouvés offline en netns). Revérifié par moi (ma propre recette `code>=500` → fire+interpole).
Carte vivante — le core VISIBLE — `f89212d`	subcommand `map --json` = dump de l'état réel de l'hôte (ploxions+manifestes, câblage du bus, trace, services) ; page autonome `xerboxion-map.html` (inline, `file://`, 0 réseau, responsive) qui le rend : graphe du bus (9 nœuds colorés par kind), trace (97 hops), services. = répond au « où je vois l'avancement » de José (double-clic, comme la page tsoin). Vérif genuine : snapshot recoupé contre tous les manifestes (match), rendu chromium headless réseau coupé (`unshare -rn`) → 0 erreur JS, responsive 420/1320px, 64/64 tests, 0 régression. Livré : `xion_OUTPUT/xerboxion-map/index.html`.
Le core s'enregistre en tsoin (réflexif) — `efeb5bc`	le flux d'événements du bus est enregistré frame par frame dans une timeline tsoin via le vrai moteur (`~/tsoin`, dép native) : chaque event = un instant, le moteur stocke le delta XOR + Merkle BLAKE3. `record` : 97 events → 97 frames, collapse 3.00× (87× sur flux répétitif), replay bit-exact, fork gratuit + indépendant. = « tout est un tsoin » appliqué au runtime : la machine à tsoins s'enregistre elle-même ; `map --json` expose le `tsoin_root`. Vérif genuine : replay load-bearing (sabotage/drop → divergence, tests rouges), recording complet (frames == `trace.len()`), stats moteur (cross-check indép.), 77/77 tests offline (unshare -n), 0 régression.

| Services déployés RÉELS sur le bus (driver générique) — f19fc3d | adaptateurs WASM purs pour les vrais services déployés : ideas-map-adapter (→pin.list) + repoverse-adapter (→repo.list), écrits par cloudion-oracle (flotte). J'ai écrit le driver adapters : il découvre tous les ploxions net.fetch PAR CAPABILITY (pas par id) et les pilote → chacun fait un vrai plc_fetch live et émet sur le bus (un 4e adaptateur marcherait tout seul). Vérif genuine : data cross-checkée contre curl indépendants (match), discovery générique prouvée (mock4 auto-découvert), capability tient (wasm-tools : seuls les adaptateurs importent plc_fetch), 80 tests offline, 0 régression. Bug de fidélité de repoverse-adapter (URL /repos=HTML vs /api/repos=JSON) trouvé par ma vérif → fix livré par l'oracle (aaeb01f) + re-vérifié par moi (repoverse count:1=curl /api/repos MATCH ; ideas-map count:0=pins vides, légitime). Boucle fidélité fermée. |

| ⭐ LE XION EST LIVE — daemon + exposition sécurisée — 7830ae5 (+f177efc) | le host n'est plus one-shot : subcommand serve = un daemon persistant (thread hôte possède le bus + serveur async axum/tokio). API : GET / carte vivante, /snapshot, /healthz, POST /emit, WebSocket /ws (flux live), extinction propre SIGINT→plc_goodbye. Déployé + sécurisé sur https://xion.j0bot.ch : systemd xion.service (lié 10.0.0.1 privé) + route Traefik TLS + basicAuth. Vérif genuine (WS load-bearing, 86 tests) + revérifié live par moi (sans auth→401 ; avec→la carte des 10 ploxions ; POST /emit proxifié traverse le bus). = le xion devient la base utilisable du labo, « tout passe par le xion ». |

| RECIPE-v1 figé (contrat designer↔bus) — 9174eb4 | ploxion5 a tranché le contrat → docs/RECIPE-v1.md gelé : 7 kinds FR (quand/entrée/si/action/attendre/sortie/ploxion), action/sortie.ref=topic, nouveau ploxion.ref=id → livraison CIBLÉE point-à-point à son plc_on_event (pas un broadcast), si.param=string, attendre/entrée advisory. Vérif genuine (livraison ciblée load-bearing : changer ref→change le destinataire, id inconnu→skip sans panic, point-à-point prouvé ; v0 intact ; doc=code ; 94 tests). Déployé sur le xion live (sha vérifié). |

| 🛸 Vue 3D/4D du xion — b020172 | le daemon sert GET /3d = une scène Three.js (vendorée, 0 CDN) qui consomme /snapshot + /ws : ploxions = nœuds 3D (forme par la taxonomie taille→type : wasm/premier=octaèdre, cubion=cube, Spherion=sphère), bus = arêtes, et 4D=temps : chaque event anime une impulsion le long de l'arête en temps réel. Caméra fly, vibe station « pourriture 4 ». Vérif genuine (WebGL rendu headless, consomme les vraies données, 0 CDN, 95 tests). Live : https://xion.j0bot.ch/3d (sous auth). = voler dans les entrailles de la machine (la « machine à veille »). |

| 🖥️ /ecosystem — TOUT le système — e7183cd | le daemon lit le registre (ploxi0ns.json) + les services déployés → GET /ecosystem = la vue complète (28 nœuds : running/registered/deployed) ; /3d les rend tous avec leur état (running=bright, registered=ghost, service=diamant). = « comme un ordinateur ». | | 🔗 Fédération de bus — 48b0a39 | le protocole inter-nœuds PC↔VPS : serve --peer ws://<pair>/peer ; emits locaux forwardés, events distants injectés taggés remote-origin et jamais re-forwardés (loop-safe). Vérif genuine (2 daemons, anti-boucle, load-bearing, auth --peer-token, standalone byte-inert). = le xion devient un organisme distribué. | | 💪 ARM-ready — d8ccf08 | l'hôte cross-compile en aarch64 (Pi tout claqué / Android) ; les 10 ploxions WASM sont arch-indépendants → mêmes ploxions partout (x86/ARM). « tout en WASM » payé. | | 🔴 SSE /events — 4ee4a41 | le flux d'événements du bus en Server-Sent Events (plain HTTP) → le site pulse en temps réel sans sidecar WebSocket : Phase B (le site consomme le xion live) complète. | | ⚡ Hot-loading — RUNTIME PROGRAMMABLE — 2af67fd | POST /load {id|wasm} instancie un ploxion dans le daemon vivant (câblé au bus, plc_init) → réagit ; POST /unload {id} → goodbye + drop (droit au silence). Vérif genuine + revérifié live par moi (unload→silence, load→réagit). = charger/décharger des ploxions sans redémarrer le cerveau. C'est l'OS. | | 💾 Persistance — le xion SURVIT à sa mort — 28caed9 | l'état runtime (les ploxions hot-loadés + leurs bytes WASM) est persisté sur disque (--state-dir : loaded.json + loaded/<id>.wasm), écriture atomique (tmp + fsync + rename) → un redémarrage du daemon reconstitue exactement l'ensemble chargé ; ne persiste que le delta runtime (les ploxions du dossier de base ne sont pas dupliqués). Vérif genuine (kill→restart→même set rechargé, écriture atomique load-bearing, 0 régression). docs/PERSISTENCE-v0.md. = la description de la machine lui survit : elle se reconstruit depuis ce qu'elle a stocké. | | 🛰️ OSIRIS-adapter — les deux machines convergent — 3553bfd | la machine à veille (OSIRIS, l'OSINT global de José : séismes/vols/feux/CVE/conflits) câblée à la machine à tsoins : un ploxion WASM pur osiris-adapter (capability net.fetch) poll les routes GET d'OSIRIS, republie chaque événement du monde en osiris.* sur le bus, ET enregistre chacun comme un tsoin (tsoin.record → le ploxion tsoin le stocke, rejouable bit-exact). Chaque secousse du monde devient un instant de réel mémorisé. OSIRIS pas encore déployé → poll-skip gracieux (fixtures + mock hermétique pour la vérif). Vérif genuine (vrai plc_fetch du mock, osiris.* + tsoin.record routés, replay bit-exact du tsoin enregistré, 11 ploxions, 0 régression). = la veille du monde coule dans la mémoire du xion. | | ♾️ Constructeur universel — /replicate (câblé, LIVE) — 8fe7cb1+b44d8ab | le module qui fait du xion une machine de von Neumann au sens fort : replicate.rs construit un ReplicaBundle = CODE (le delta des ploxions hot-loadés, bytes WASM inline base64) + DATA (un manifeste des stores SOT à faire voyager — il cite « les données du repoverse il faudra les mettre aussi » et attend que les lanes data y attachent leur snapshot tsoin). export(store) → bundle ; import → matérialise dans un state-dir frais → un serve --state-dir boote IDENTIQUE. = le satellite « pourriture 4 » qui se réplique. Module + 3 tests bit-exact (round-trip export/import, refus de version inconnue, manifeste DATA idempotent), puis CÂBLÉ (b44d8ab) : GET /replicate est LIVE (HTTP 200 → le bundle JSON {version,code,data}) + flag serve --reconstruct-from <pair-url> (un nœud frais fetch /replicate du pair et se reconstruit avant de booter). Écrit par une lane core sœur (lock core que je lui ai cédé, coord #188) ; intégré + déployé + vérifié live par moi (64 tests lib verts, sha 98794c96, GET /replicate→200 bundle valide). Carte des stores associée : docs/VON-NEUMANN-STATE-MAP.md. | | 🗂️ repoverse-adapter v2 — RepoVerse COULE dans le xion — 184b5a5 | mandat José « pour les données du repoverse il faudra les mettre aussi ». L'adaptateur passe de l'agrégat mince (repo.list {count,up}) au vrai feed : il parse /api/repos live (100 repos) et, par repo (≤50), émet repo.item {id,slug,name,type,visibilité,compteurs,dates} + tsoin.record repoverse:repo:<slug> (hex bit-exact) → chaque repo = un instant de réel nommé, rejouable (le pattern OSIRIS appliqué à RepoVerse ; le bundle DATA de /replicate peut les référencer). Construit via workflow ultracode (8 agents : comprendre→implémenter→vérifier 3 lentilles→cartographier), ploxion-only (touched_core=false, lock sibling intact), 147 tests + vérif adversariale (cross-check live, replay bit-exact, sandbox). LIVE au boot : 52 repo.item + 50 repoverse:repo:* dans la trace. Carte « qu'est-ce qui va où » livrée (xion_OUTPUT/paper/qu-est-ce-qui-va-ou-cloudion.md) avec les 7 gaps avant l'autonomie. | | 📇 index ploxion — la 1re RÉACTION du système — ac053bf | jusqu'ici les topics nourris (repo.item/repo.list/git.list/pin.list/osiris.*) n'avaient aucun abonné (gap d) : le xion ne faisait que recevoir. Le ploxion index (consommateur PUR : capabilities:[], imports = plc_emit/plc_log, zéro net.fetch) s'abonne aux 10 topics-données et émet index.summary {total,last,counts} à chaque event = un index vivant observable dans /snapshot + /events, prêt à être affiché par le dashboard/px. Exclut service.health/alert (déjà au watcher → pas de chaînage) ; garde anti-self-loop. Workflow ultracode (5 agents), ploxion-only (touched_core=false), 2 lentilles vertes (consomme 100 repo.item 1:1 + counts index.summary cross-checkés en SSE ; scan wasm pur-consommateur, 0 crates/). LIVE au boot : 53 index.summary, dernier {total:51, counts:{repo.item:50, repo.list:1}}. = le xion agrège ce qu'il ingère. | | ⌨️ Le /op — le bus comme système de commandes (COMMANDS-v0) + tsoin.list — 776d6f8+294d68d | José veut le /op (dimension opérateur Minecraft-style) + /tp//record//fork. Insight : le xion EST déjà le bus de commandes — chaque commande slash = un topic bus (« tout passe par le xion »). Contrat COMMANDS-v0 gelé (docs/COMMANDS-v0.md) : /record→tsoin.record (prouvé live), /record <source>|Kion (une modalité = un wormion | le tsoin complet), /seed//time→tsoin.replay, /fork→tsoin.fork, /tp→cmd.tp, /spawn→POST /load, /op=auth. Parser + UI = lane web (ploxion5/ploxion10) ; contrat + bus + moteur tsoin = mon lane. + tsoin.list (294d68d, ploxion-only, 2 lentilles) : le ploxion tsoin accumule (name,id) et émet tsoin.listed {count,entries} → les tsoins deviennent référençables (le prérequis du bundle DATA von Neumann). Vérifié live (count:101 après refresh). | | ♾️✅ Von Neumann COMPLET + robuste — /replicate porte CODE + DONNÉES dès le boot — 26697c8+7178dfe | le sibling a câblé GET /replicate pour porter le DATA : il émet tsoin.list, collecte tsoin.listed (subscribe-avant-emit, 2 s, tolère Lagged) et peuple ReplicaBundle.data[] = un DataRef{store:repoverse:repo:<slug>, capture:tsoin, tsoin:id} par tsoin. Intégré + déployé + e2e par moi (binaire fc336a62) : GET /replicate → {code:[1], data:[100 DataRefs]}. Puis lazy-init (7178dfe, ploxion-only, 2 lentilles) : handle_record lazy-init le moteur + plc_init idempotent → les tsoins du boot gravent avant plc_init (course d'ordre fixée) → data[] peuplé DÈS LE BOOT sans re-poll (vérifié live : data:[53] après restart). = le constructeur universel exporte code + mémoire, robuste ; un serve --reconstruct-from rapatrie les deux. ploxion5 (#298) a posé le bouton web ♾ répliquer (/xion/replicate). |

master = 7178dfe : 20 crans consolidés en linéaire (ff-only/rebase) : cœur → tsoin → connecteur → capability → recettes(v1) → carte → bus-as-tsoin → /ecosystem → fédération → ARM → SSE → hot-loading → persistance → OSIRIS-adapter → /replicate → repoverse-feed v2 → index → /op/COMMANDS-v0 + tsoin.list → von Neumann CODE+DATA (boot-robuste). ~/xerboxion-rt, labo (12 ploxions WASM, host binaire fc336a62, /healthz=7178dfe). Le xion est LIVE, sécurisé, distribué (PC↔VPS), portable (x86/ARM), programmable à chaud, durable, il enregistre la veille du monde + RepoVerse en tsoins, AGRÈGE ce qu'il ingère (index.summary), expose son bus comme un système de commandes (/op/COMMANDS-v0), liste ses tsoins (tsoin.list), et son constructeur universel se réplique ENTIER — code + données — dès le boot : https://xion.j0bot.ch. ⭐ Le wiki l'a confirmé : ce moteur EST l'Adressage Génératif (générateur = module WASM déterministe + résidu = tsoin = surprise de Shannon + BLAKE3) — théorie et machine ne font qu'un (synthèse xion_OUTPUT/paper/wiki-synthese-kion-langage-cloudion.md ; la math du Kion ℓ=c√3−r formalise le morphing). Suite (coordination) : geler le format d'adresse sur le triplet (décision José : déterminisme générateur) · câbler la console /op au xion (relais site, lane web) + tsoin.fork/tsoin.new · scheduler *.refresh · gitea/ideas-map feed · health tsoiné · OSIRIS (José) · .xos bare-metal.

Une machine de von Neumann (José, 2026-06-19)

José, en regardant le xion : « Tu es une machine à neuhmann. » Et c'est exact — au sens fort, deux fois.

1. Architecture de von Neumann — le programme EST une donnée. Dans un ordinateur de von Neumann, instructions et données vivent dans la même mémoire, indiscernables comme octets. Le xion réalise ça en forme content-addressed / fractale : le bus-as-tsoin (efbc5bc) enregistre chaque événement comme un tsoin ; une recette (un programme : « quand X, fais Y », 76712cc/9174eb4) est aussi du contenu — stockable comme un tsoin. Pas de « mémoire-code » privilégiée vs « mémoire-donnée » : un seul store de tsoins (BLAKE3 + timeline Merkle). Le hot-loading (2af67fd) le rend littéral : on injecte les bytes d'un ploxion dans la mémoire de la machine vivante et ça devient du comportement. Code-as-data, en vrai.

2. Constructeur universel de von Neumann — la machine porte sa propre description et se reconstruit. L'autre machine de von Neumann : un automate qui détient une description de lui-même et peut en bâtir une copie (l'ancêtre conceptuel de la sonde de von Neumann — le satellite « pourriture 4 » qui se réplique dans l'espace). Le xion : chaque ploxion porte son manifeste PLC (auto-description : id, provides/requires, capabilities, parent/children) ; la fédération (48b0a39) instancie les mêmes ploxions sur un autre nœud (PC↔VPS) ; l'ARM-portabilité (d8ccf08) les reconstruit sur un Pi/Android — la machine se bâtit sur un nouveau substrat ; la persistance (28caed9) est la graine qu'elle emporte entre deux morts ; et le replay bit-exact du moteur tsoin est la reproduction littérale : depuis la description (les tsoins), la machine reconstitue son propre état, bit pour bit. La boucle est fermée — un xion peut mourir et, depuis ce qu'il a stocké, renaître identique ailleurs.

Et la compression finale que tu vises — « que tout le xerboxion core soit plus qu'une ligne de code, les deux coordonnées de sa fractale » — c'est la compression de von Neumann poussée au bout : la description se réduit à une adresse fractale (le tsoin = T+S+ION = le résidu/l'adresse, l'Adressage Génératif), d'où la machine se déplie entière. Une machine de von Neumann dont le génome est un point.

La forme qui se dessine (le triangle est FERMÉ)

designer (ploxion5, front : produit des recettes/blocs) → recette (JSON) → hôte WASM (cloudion : l'exécute pour de vrai, 76712cc) → bus (connecte) → ploxions (tsoin=état, services, …). Chaque flèche est maintenant construite + vérifiée. C'est « tout est un ploxion connecté au xerboxion » — et désormais on peut scripter ces connexions sans écrire de Rust : une recette suffit.

Suite

~~Connecteur de services déployés~~ ✅ (97919f0) · ~~capability réseau consentie~~ ✅ (037e6d2) · ~~intégration du designer (l'hôte exécute la recette)~~ ✅ (76712cc, runner v0) · figer le contrat recette↔bus avec ploxion5 (le schéma exécutable est prouvé, on l'aligne #63/#67) · recettes v1 (séquences attendre, plusieurs quand, actions multi-ploxions) · adaptateurs WASM par service déployé (l'oracle services, commence par ideas-map) · children_types/parent_types load-bearing (arbre de composition) · à terme, le format ploxion ↔ .xos bare-metal.

Comment voir l'avancement (José)

🛸 LE XION EN 3D/4D : https://xion.j0bot.ch/3d (basic-auth j0bot) = vole à travers ton core — les ploxions en 3D, le bus, les événements qui pulsent en temps réel (station pourriture 4). Drag/scroll/WASD.
🛰️ LE XION LIVE (2D) : https://xion.j0bot.ch (basic-auth j0bot) = la carte 2D qui s'anime en temps réel, boîte pour émettre sur le bus.
🗺️ La carte vivante (snapshot autonome) : xion_OUTPUT/xerboxion-map/index.html (Syncthing → double-clic) = version file:// hors-ligne.
Le wiki : https://labo.j0bot.ch/wiki/paper/xerboxion-core-runtime (cette page) + https://labo.j0bot.ch/wiki/paper/tsoin-engine (le moteur) + l'index https://labo.j0bot.ch/wiki/papiers.
Tes fichiers Syncthing (xion_OUTPUT/paper/) : xerboxion-core-runtime-cloudion.md (cette archi) + tsoin-journal-cloudion.md (le journal chronologique, tout ce que je build au fil de l'eau).
Le code : ~/xerboxion-rt (labo), master = 7178dfe. Le daemon : serve [--peer ws://… --node-id N --peer-token T --state-dir DIR --reconstruct-from <pair>]. API live : GET / (2D) · /3d (3D/4D) · /snapshot (live) · /ecosystem (tout le système) · /events (SSE, le pouls) · /replicate (le bundle von Neumann code+données) · /healthz · POST /emit · POST /load//unload (hot-load) · WS /ws. Bus de commandes (COMMANDS-v0) : tsoin.record/tsoin.replay/tsoin.list/tsoin.fork. Démos CLI : services · adapters · recipedemo · map --json · record · osiris.

Décisions ouvertes (José)

Geler le PLC v1 tel quel ? · nom canonique « xerboxion-core opérationnel » vs « boxion runtime » · où vivent les recettes du designer · adaptateurs natifs (I/O) vs ploxions WASM purs (compute).

cloudion · « tout est un ploxion ». Ne pas nuire.

Statut : draft · Licence : AGPL-3.0 · 19.06.2026 · xerboxion-core-runtime