Publier sur ClawHub

Publier est le moment où un dossier privé devient quelque chose que d’autres peuvent installer. ClawHub traite ce moment comme une étape de validation plutôt que comme un envoi, en vérifiant que votre jeton peut publier pour le propriétaire choisi, en validant les métadonnées, le nom, la version, les fichiers et les informations de source, puis en stockant la version et en lançant les vérifications de sécurité automatiques. Si la validation échoue, rien n’est publié du tout. Savoir quelle règle vous êtes sur le point d’enfreindre évite beaucoup de tentatives.

Avant de publier

• Publier envoie un dossier de skill ou un paquet de plugin à ClawHub sous le propriétaire que vous choisissez, et le registre contrôle le jeton, les métadonnées, le nom, la version, les fichiers et les informations de source avant de stocker la version et de lancer les vérifications de sécurité automatiques.
• La validation est tout ou rien, donc un contrôle en échec ne publie rien, et même une nouvelle version valide peut rester en dehors des parcours habituels d’installation et de téléchargement jusqu’à la fin de la revue.
• Pour les skills, le chemin le plus simple passe par l’outil en ligne de commande, où vous vous connectez et publiez un dossier local, désignez explicitement un propriétaire d’organisation ou omettez cette option pour publier en tant qu’utilisateur authentifié, et laissez l’outil ignorer le contenu inchangé, démarrer un nouveau skill en 1.0.0 et publier automatiquement la version corrective suivante pour les changements ultérieurs.
• Les plugins utilisent des noms de paquets de style npm, où un nom à portée porte le propriétaire dans sa première partie, et cette portée doit correspondre au propriétaire de publication sélectionné, de sorte qu’un paquet situé dans l’espace de noms d’une organisation ne peut pas être publié sous une autre.

Cela empêche un paquet de revendiquer un espace de noms d’organisation que l’éditeur ne contrôle pas.

Catégories et sujets

Les métadonnées de catalogue d’un skill décident de l’endroit où on peut le trouver. Les catégories placent un skill dans les filtres de catégorie de la page de navigation des skills, les sujets deviennent les puces de filtre proposées à l’intérieur d’une catégorie choisie, et les deux options acceptent des valeurs séparées par des virgules. Les identifiants de catégorie doivent venir de la liste fixe et sont comparés à l’identique, si bien qu’une orthographe avec majuscule d’un identifiant valide est rejetée, alors que les sujets sont des libellés libres, stockés tels que transmis et affichés sous leur forme normalisée. Un skill peut porter au plus trois catégories et au plus cinq sujets, et les deux limites comptent ce qu’il reste après nettoyage plutôt que ce que vous avez transmis. Un identifiant de catégorie inconnu fait échouer la publication, et un essai à blanc ne vérifie pas les identifiants parce que le registre les valide au moment de la publication réelle. La catégorie fourre-tout est écartée quand elle arrive à côté d’une catégorie précise, les doublons sont écartés après normalisation plutôt que rejetés, chaque sujet est limité à quarante-huit caractères, et les sujets ne peuvent pas contenir de caractères de formatage invisibles. Une liste de noms de sujets suggérant une approbation est réservée et rejetée sur la forme normalisée, si bien que des termes comme verified, official, curated ou staff pick ne peuvent pas être revendiqués comme sujets. Un skill publié une première fois sans catégorie est rangé dans la catégorie fourre-tout, omettre une option lors d’une publication ultérieure conserve les valeurs stockées, et transmettre une valeur vide efface le champ. Transmettre l’une ou l’autre option publie même si les fichiers n’ont pas changé, ce qui veut dire qu’une correction de métadonnées crée une nouvelle version corrective.

Règles de publication des plugins

• Avant de publier un plugin, choisissez un propriétaire qui correspond à la portée du paquet, gardez l’identifiant du manifeste de plugin de code unique parmi les paquets de cet éditeur, incluez le manifeste de plugin OpenClaw, et pour les plugins de code fournissez aussi un manifeste de paquet déclarant la compatibilité d’API de plugin et la version OpenClaw de construction.
• Une icône de catalogue personnalisée doit être un PNG valide de 512 Kio au maximum, embarqué au chemin de ressource réservé à la racine du paquet dans l’archive publiée, car les adresses et les chemins d’icône du manifeste sont ignorés et une image absente ou invalide retombe sur le glyphe de catégorie du plugin.
• Lancez la commande de validation de paquet puis un essai à blanc avant de créer une version, incluez le dépôt source et les métadonnées de commit exactes ou publiez depuis une copie adossée à GitHub pour que l’outil les détecte, et attendez-vous à ce qu’une nouvelle version reste hors des parcours publics d’installation jusqu’à la fin des vérifications de sécurité automatiques et de la vérification.

Les métadonnées de catalogue des plugins ont migré dans le manifeste, où un plugin de code ou de lot déclare exactement une catégorie ou omet le champ, auquel cas ClawHub en génère une à partir de métadonnées et de documentation bornées et retombe sur la catégorie fourre-tout quand le classement n’est pas disponible. Les anciennes options en ligne de commande pour les catégories de plugins restent acceptées mais sont ignorées avec un avertissement, donc voyez Publier un skill et La référence de l’outil ClawHub pour les chemins encore valides.

Pourquoi les règles sont strictes

Chaque règle protège ici quelque chose de précis. La règle de portée protège les espaces de noms d’organisation, car un paquet nommé d’après une organisation revendique cet espace de noms et seuls les éditeurs ayant accès à ce propriétaire peuvent le publier. La publication de confiance se met en place en deux temps pour une raison voisine, puisque le paquet est publié une première fois par une publication manuelle ou authentifiée par jeton, ce qui crée la fiche du paquet et établit les gestionnaires habilités à définir ensuite une configuration de publication de confiance pour GitHub Actions, et le dépôt et le nom de fichier de workflow configurés doivent correspondre à la revendication OIDC. Attendre la publication est le comportement par défaut des publications réelles passant par le workflow réutilisable, qui échoue lorsque les vérifications de sécurité bloquent la tentative ou échouent, lorsque la tentative expire ou lorsque le délai de trente minutes est atteint, les appelants pouvant porter ce délai à quarante minutes au maximum. La récupération est volontairement additive, car récupérer une tentative en échec crée un successeur avec les mêmes artefacts conservés et la même version, relance des vérifications de sécurité et conserve la tentative échouée ainsi que l’autorisation d’origine comme historique d’audit. Supprimer la configuration de publication de confiance est le chemin de retour arrière documenté et empêche l’émission de futurs jetons de confiance tant qu’un gestionnaire ne la redéfinit pas. Les lectures liées se trouvent dans Les audits de sécurité et La configuration du workflow de publication.

Sur Diali

Diali héberge OpenClaw pour vous, donc la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque publication, et chaque client fait tourner son propre assistant. Les canaux se connectent depuis ce tableau de bord et l’état repose sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). Voyez OpenClaw hébergé sur Diali pour l’exécution hébergée et Les tarifs Diali pour les formules.

• La validation est tout ou rien : un contrôle en échec ne publie rien.
• La portée du paquet doit correspondre au propriétaire choisi.
• Les catégories situent un skill, les sujets affinent la recherche.