Écrivez le module que
votre logement attend.
Un module Portaki, c'est un bout de séjour que personne n'a encore écrit : une borne de recharge, un écran e‑ink dans l'entrée, la tournée du ménage. Le SDK et le catalogue sont ouverts aujourd'hui. Le portail qui les réunit — éditeur, bac à sable, publication — se construit.
query("module-checklist-depart", "render")200 · 6,2 msrepo.find"stay", { id: … }1,4 mskv.get"checklist:etat"0,3 mskv.set"checklist:etat", …0,4 msemail.send"depart-confirme", …2,1 msCe que vous voyez n'existe pas encore. C'est la maquette de travail du portail : la trace d'exécution, les régimes d'appel et la conformité sont déjà la façon dont le bac à sable raisonne — l'écran, lui, reste à construire.
Suivre l'avancement
Ce qui est vrai aujourd'hui. Ce qui arrive.
Une page « développeur » qui promet un portail qu'on ne peut pas ouvrir, ça se voit tout de suite. Voici la ligne exacte entre les deux.
Aujourd'hui, au présent
- Le SDK est publié sous Apache‑2.0, sur GitHub, utilisable maintenant.
- Le catalogue des modules est open source — chaque module est lisible, forkable.
- Le schéma des manifestes est versionné : ce que vous écrivez aujourd'hui restera lisible demain.
- La CLI fait init, build, lint, test et publish depuis votre machine.
- Le bac à sable Wasm exécute les modules en local, sans infrastructure.
À venir — par phases
- Un portail développeur dans le dashboard, avec vos modules et leurs versions.
- Un bac à sable hébergé, qui rejoue une surface sur les trois rendus.
- La publication depuis votre CI, sans secret à copier.
- Un marketplace communautaire, avec revue publique.
Rien ici n'est cliquable aujourd'hui — c'est voulu. — feuille de route.
Sandboxé par construction.
Un module Portaki ne s'exécute pas « à côté » du serveur : il tourne dans une machine Wasm qui ne connaît rien du monde extérieur. Pas de socket, pas de disque, pas de variable d'environnement. Il ne peut faire que ce que l'hôte lui tend explicitement.
Ce que l'hôte lui tend, c'est une surface d'appel — une liste finie de fonctions, déclarées dans le manifeste et accordées par l'hôte du logement. Un module qui n'a pas demandé l'accès aux e‑mails ne peut pas en envoyer : l'appel n'existe pas pour lui.
La surface d'appel — en entier
kveventsconnectorsemailgeonotifyrepoi18ntimelogDix familles. Pas de réseau libre, pas de système de fichiers, pas d'accès aux autres logements.
Un arbre. Trois rendus natifs.
Vous décrivez une intention — un titre, une valeur, un bouton. Le dashboard, le livret voyageur et l'app mobile la rendent chacun avec leurs propres composants, leurs propres tokens, leurs propres conventions. L'auteur du module n'a écrit aucun des trois.
Wi‑Fi
Wi‑Fi
Wi‑Fi
Le même arbre, rendu par trois moteurs différents — son auteur n'a écrit aucun des trois.
$ portaki init module-menage
$ portaki build
# → module.wasm
$ portaki test
✓ 14 tests
$ portaki lint
✓ manifeste · i18n · permissions
le mode watch, qui rejoue la surface à chaque sauvegarde, fait partie du portail à venir
Une CLI aujourd'hui, la provenance demain.
La boucle locale fonctionne : vous écrivez, vous compilez, vous testez, vous vérifiez le manifeste. Tout tient sur votre machine, sans compte et sans clé.
L'expédition, elle, reste à écrire. L'identité d'un module viendra de GitHub — pas d'un jeton copié dans un fichier : le portail lira la provenance de l'artefact, et la version publiée sera immuable, désignée par son digest. Un module ne pourra pas changer sous vos pieds entre deux installations.
Rien de tout cela n'est figé. Le format du manifeste, les familles d'appel, la façon dont la revue se fait : si vous écrivez des modules, c'est le bon moment pour dire ce qui manque — le SDK est sur GitHub, les issues sont ouvertes.
Le portail arrive.
Soyez du premier cercle.
Les premiers auteurs de modules seront des hôtes qui codent — des gens qui ont un besoin précis dans leur logement et savent l'écrire. Si c'est vous, dites‑le maintenant : les accès partent dans l'ordre d'inscription.