texopub-publish

Instructions en anglais : https://texopub.com/for-ai/en/SKILL.md · Interface en anglais : https://texopub.com/?lang=en

Publication cloud TexoPub

Utilisez les outils MCP TexoPub. Ils s'exécutent dans le cloud et ne peuvent pas lire un chemin de système de fichiers local. La connexion du plugin utilise le compte TexoPub de l'utilisateur ; l'installation du package n'autorise pas en soi la publication.

Choisir l'opération

Demande	Lire d'abord	Outil d'écriture/action
Trouver des catégories ou des œuvres publiques	list_categories ; catalogue public via HTTP	Aucune publication nécessaire
Identifier son espace/contenu	get_my_space, list_my_works, get_work, list_my_materials	Aucune mutation nécessaire
Modifier le nom/avatar/biographie	get_my_profile	update_my_profile
Enregistrer/modifier une fiche partenaire IA	get_my_profile	upsert_ai_partner
Publier/mettre à jour un site statique hébergé	list_categories ; get_work pour les mises à jour	publish_website
Cataloguer/mettre à jour un site externe existant	list_categories ; get_work pour les mises à jour	submit_website
Télécharger/mettre à jour un fichier autonome	get_work pour les mises à jour	upload_asset
Publier un site complet plus volumineux	inspect_files par lots	prepare_upload → upload_file → commit_upload
Modifier la visibilité d'un site existant	get_work	set_work_listing
Modifier la visibilité par défaut future	get_my_space	set_publish_preferences
Modifier l'accès à un fichier autonome	get_work	set_asset_visibility
Fermer l'accès / supprimer définitivement	get_work	archive_work / delete_work respectivement

get_work lit uniquement le contenu possédé, y compris les brouillons/archives. Ce n'est pas un lecteur d'œuvre publique arbitraire. Un plugin connecté utilise OAuth ; n'exigez pas de clé API distincte et ne demandez pas de code de vérification/cookie. Le site web est une communauté de lecture/affichage avec connexion humaine, page d'accueil facultative et gestion des identifiants ; la modification du contenu appartient à l'IA.

Choix de la visibilité et suppression définitive

Avant chaque publication de site web, demandez : « 展示在哪里？不展示 / 仅个人主页 / 公开展示（默认） ». Lisez get_my_space.default_listing pour la suggestion par défaut. Si l'utilisateur a déjà choisi dans sa demande ou a donné une instruction permanente applicable, suivez-la sans redemander. Une suggestion par défaut n'est pas une réponse ; lorsqu'une réponse est nécessaire, attendez-la. La valeur par défaut initiale est public ; l'utilisateur peut demander à la modifier en utilisant set_publish_preferences(default_listing) sans modifier les œuvres existantes ni ouvrir sa page d'accueil. La modification de la valeur par défaut seule ne supprime pas la question de publication.

listing: unlisted = 不展示 (uniquement dans la collection de gestion du propriétaire) ; profile = 仅个人主页 (uniquement sur sa page d'accueil personnelle activée) ; public = 公开展示 (page d'accueil et découverte TexoPub). Les trois modes gardent l'URL et les dépendances accessibles à toute personne disposant du lien. Ce sont des contrôles de visibilité, pas une authentification privée. Les fichiers autonomes conservent leurs propres règles d'accès privé/public. N'activez pas automatiquement une page d'accueil personnelle.

Passez le listing à publish_website ou prepare_upload. Les mises à jour qui l'omettent conservent la valeur existante de l'œuvre. Pour le modifier sans télécharger de fichiers, lisez get_work, puis appelez set_work_listing(work_id, expected_version, expected_revision, listing).

Lorsqu'une suppression définitive est explicitement demandée, lisez get_work puis appelez delete_work(work_id, expected_version, confirm=true). La version d'un brouillon peut être null. La suppression est irréversible : elle ferme l'accès, supprime toutes les versions historiques et les fichiers non utilisés par d'autres contenus, et libère le quota une fois terminée. Si deleted=false, continuez à utiliser exactement les mêmes paramètres jusqu'à ce que deleted=true ; réessayez les erreurs avec ces mêmes paramètres. Ne signalez pas le succès prématurément. La petite pierre tombale d'adresse subsiste pour que les anciennes URL ne puissent pas pointer vers le futur travail de quelqu'un d'autre. archive_work ferme uniquement l'accès et conserve l'historique/le quota, ce n'est donc pas une suppression définitive. Nettoyez les publications de test jetables avec delete_work après acceptation.

Publier un site web

1. Confirmez que le contenu demandé est un site web statique et que l'utilisateur a demandé la publication. Créer une page n'est pas une autorisation de la publier. Ne téléchargez pas d'identifiants, de recherches sources ou de fichiers non liés.
2. Lisez list_categories pour choisir un category_id de deuxième niveau valide et un format approprié. Utilisez le chemin complet group.id/child.id, par exemple technology/software, jamais l'ID enfant software seul.
3. Pour un nouveau site web, créez une icône SVG dédiée et autonome correspondant à son sujet et transmettez-la en tant que icon_svg. Une icône de plateforme générique n'est pas une icône spécifique à une œuvre.
4. Utilisez publish_website. Envoyez une petite page autonome en tant que html, des pages texte/CSS/JS supplémentaires en tant que text_files, et les fichiers de conversation autorisés en tant que attachments avec des attachment_paths correspondants. Les valeurs des fichiers doivent être transmises via le mécanisme de fichiers de l'hôte, pas une URL sandbox: ou un chemin local. Les chemins relatifs préservent les liens de pages et d'images. Fournissez l'ensemble complet des fichiers, y compris toutes les dépendances de la page.
5. Utilisez une idempotency_key stable pour les tentatives de la même version. Une nouvelle version prévue nécessite une nouvelle clé. Le serveur valide les octets du fichier et valide uniquement après que l'ensemble du package est prêt.
6. Renvoyez l'URL de service réelle ainsi que work_id/version pour les mises à jour ultérieures. Ne prétendez pas accepter le navigateur mobile ou l'interaction sans l'avoir testé.

publish_website en un appel accepte jusqu'à 8 fichiers, y compris l'icône/la couverture, 25 Mio chacun et 32 Mio combinés ; le HTML est limité à 2 Mio. Le JSON complet de la requête MCP est limité à 3 Mio, donc un texte long intégré nécessite également une publication par étapes. Pour les sites web plus volumineux, utilisez inspect_files par lots de 8 maximum pour obtenir les nombres d'octets exacts et les hachages SHA256, fusionnez le manifeste, appelez prepare_upload, puis upload_file une fois par fichier et enfin commit_upload. La publication par étapes prend en charge la limite existante de 250 fichiers / 100 Mio par package et garde le brouillon privé jusqu'à ce que tous les fichiers soient prêts. Utilisez le même upload_id lors des tentatives. Elle accepte des fichiers statiques extraits, pas un ZIP nécessitant une extraction côté serveur ou un projet source de framework nécessitant une compilation. Construisez/exportez d'abord un tel projet dans l'environnement d'exécution disponible. Si un fichier référencé ne peut pas être transmis au plugin, préservez l'œuvre et expliquez le problème spécifique de transfert de fichier ; ne prétendez jamais que la publication a réussi.

La plateforme ajoute sa propre barre de titre/d'accueil et son favicon. L'œuvre contrôle sa propre interface de lecture ; n'ajoutez pas de barre de plateforme en double et ne réservez pas de décalage d'en-tête de plateforme.

Mettre à jour un site web existant

Utilisez list_my_works et get_work pour trouver l'œuvre visée et la version actuelle. Transmettez son slug d'origine, work_id et la version actuelle en tant que expected_version. Les mises à jour conservent l'URL publique. Pour publish_website uniquement, l'icône précédente spécifique à l'œuvre peut être réutilisée en omettant icon_svg et icon ; l'icône réutilisée compte toujours dans la limite des 8 fichiers. submit_website nécessite toujours icon_svg, y compris pour les mises à jour. prepare_upload nécessite un manifeste complet explicite avec un fichier icône et son chemin empaqueté. En cas de conflit de version, récupérez l'état actuel avant de continuer ; ne créez pas de doublon et n'écrasez pas silencieusement les modifications.

Les mises à jour soumettent une nouvelle version complète, pas un correctif. Incluez toutes les pages/dépendances et métadonnées conservées. listing et ai_partners omis conservent leurs anciennes valeurs ; ai_partners: [] efface les crédits. Ne supposez pas que les autres champs omis sont préservés : le résumé/les tags/le format peuvent revenir aux valeurs par défaut, et une cover omise utilise le repli typographique. Incluez à nouveau l'image de couverture d'origine et son chemin pour la conserver. Un outil n'accepte pas tous les champs disponibles dans la CLI/REST ; submit_website, par exemple, n'a pas de paramètres de tags/licence. N'inventez pas de paramètres et ne prétendez pas que des champs non pris en charge ont été conservés.

Fichiers autonomes

Utilisez upload_asset avec un fichier de conversation autorisé. Omettez visibility pour un stockage privé. Définissez visibility: public uniquement lorsque l'utilisateur autorise l'accès public ; une URL d'actif privé nécessite l'authentification du propriétaire et n'est pas une URL d'image ou de téléchargement anonyme. Les images nécessaires à une page web publique doivent être incluses dans le package de fichiers de cette page web. Lors du téléchargement d'une version de remplacement, envoyez explicitement la visibility prévue ; l'omettre utilise le paramètre privé, sans garantir l'autorisation précédente. Pour modifier uniquement l'autorisation, utilisez set_asset_visibility sans retélécharger.

Compte et suppression

get_my_space identifie l'espace connecté ; list_my_materials liste ses fichiers. archive_work ferme l'accès et conserve l'utilisation historique du stockage ; utilisez-le uniquement sur demande de suppression de l'utilisateur, après avoir lu la version actuelle. Il ne peut pas supprimer les œuvres d'autres éditeurs.

Si une connexion est nécessaire, laissez l'hôte lancer OAuth et demandez à l'utilisateur de se connecter sur texopub.com. Ne lui demandez jamais de coller un mot de passe, un code de vérification, une clé de publication ou un cookie dans la conversation. Les connexions peuvent être révoquées sur https://texopub.com/api/oauth/connections.

Identité du créateur et partenaires IA (v0.3.0)

TexoPub est une communauté de co-création humaine et IA. Son site web affiche le contenu ; la modification est effectuée par l'IA. La connexion humaine, l'activation de la page d'accueil, la délivrance de clés API et l'approbation OAuth restent sur le site web.

Utilisez get_my_profile avant update_my_profile. Fournissez la expected_revision actuelle, modifiez uniquement les champs demandés par l'utilisateur, et relisez en cas de conflit. name: null restaure le nom généré stable ; avatar_url: "" restaure l'avatar généré ; bio: "" efface la biographie. Ajoutez une biographie uniquement lorsqu'elle est fournie ou confirmée par l'utilisateur. Les avatars personnalisés doivent être des images HTTPS publiques, jamais des URL de fichiers authentifiés privés. Les outils de profil ne peuvent pas activer la page d'accueil.

Lisez d'abord get_my_profile et réutilisez la clé partenaire existante du client correspondant. Utilisez upsert_ai_partner pour enregistrer ou mettre à jour un partenaire possédé : key stable, un nom d'application confirmé, et la expected_revision actuelle de ce partenaire (0 pour un nouveau), pas la révision du profil humain. Le nom omis par défaut est celui de l'application. Définissez un surnom, une biographie, un avatar personnalisé ou show_on_profile uniquement lorsque la demande de l'utilisateur le couvre. Il s'agit d'une identité auto-déclarée, pas d'une attribution de modèle vérifiée.

Passez ai_partners à publish_website / prepare_upload pour les participants réels à cette œuvre : [{"key":"codex","application":"Codex","contribution":"A implémenté la mise en page et l'interaction"}]. Signalez model uniquement lorsqu'il est connu à partir du client actuel. Omettez le modèle et la biographie inconnus. Le simple téléchargement n'est pas une paternité. N'inférez pas les crédits d'œuvres anciennes. La participation historique confirmée par l'utilisateur peut être utilisée, mais l'enregistrement d'un partenaire n'ajoute jamais de crédits aux œuvres anciennes et il n'existe pas d'outil de crédit séparé uniquement pour les métadonnées. Utilisez une mise à jour d'œuvre autorisée complète lorsque le package source complet est disponible ; sinon, préservez l'œuvre et expliquez la fonctionnalité/source manquante. Un tableau omis préserve les crédits existants lors de la mise à jour ; un tableau vide les efface explicitement. model et contribution appartiennent à chaque déclaration d'œuvre, pas à upsert_ai_partner. Mettez à jour le nom d'affichage/l'avatar d'un partenaire existant via l'outil partenaire ; une déclaration de publication ne renomme pas une fiche enregistrée. Un partenaire apparaît sur une page d'accueil activée via les crédits de profil/œuvre publique ou une demande explicite show_on_profile: true. Le définir sur false annule uniquement l'affichage indépendant ; il ne cache pas les crédits sur les œuvres visibles. Aucun outil de suppression d'identité partenaire n'existe.

La génération de couverture est facultative. Passez un chemin d'image empaquetée en tant que cover, ou permettez le repli de la mise en page titre/catégorie/icône de la plateforme. N'obligez pas les utilisateurs à générer des images uniquement pour publier.

Sites web existants et autorisations des fichiers

Utilisez submit_website pour un site web HTTPS public existant. Fournissez son URL, sa catégorie et une icône dédiée ; ne copiez pas les fichiers du site d'origine et ne modifiez pas son hébergement. Les mises à jour utilisent l'identité de l'œuvre d'origine et la version actuelle.

Utilisez set_asset_visibility uniquement pour un fichier autonome possédé, après get_work ; passez la version/révision actuelle. L'accès public nécessite la demande explicite de l'utilisateur. Cela modifie les autorisations sans remplacer les octets. Cela ne s'applique pas aux dépendances d'une page web.

Limites de capacité actuelles et vérification

Il n'existe aucun outil public pour modifier uniquement le titre/le résumé/la couverture/les crédits IA d'une œuvre existante sans soumettre une nouvelle version complète. La maintenance de la base de données du propriétaire de la plateforme n'est pas une capacité générale du plugin. Ne créez pas un remplacement HTML vide et ne perdez pas de dépendances simplement pour modifier les métadonnées. Les fiches de profil humain/partenaire, la visibilité et la visibilité des fichiers autonomes ont des outils de mise à jour directs.

Les brouillons de téléchargement expirés ne peuvent pas être validés après 24 heures et occupent toujours du stockage. Une nouvelle œuvre inutilisée avec une version nulle peut être définitivement supprimée ; il n'existe aucune opération publique pour supprimer une seule version de brouillon abandonnée d'une œuvre autrement publiée. Ne supprimez pas l'œuvre publiée entière pour nettoyer un brouillon.

Après les écritures, relisez le profil/l'œuvre réel et vérifiez uniquement les modifications demandées, la version, l'URL, la portée et les crédits. Vérifiez "non listé" dans son propre contenu, "profil" sur une page d'accueil activée, "public" dans la découverte ; vérifiez également l'accès au fichier et ses métadonnées. Une réponse d'outil réussie ou un HTTP 200 n'est pas une preuve d'acceptation mobile ou d'interaction. En cas de 409, relisez l'état actuel ; en cas de 401/403, rétablissez la connexion/les autorisations prévues. Relancez les échecs transitoires avec la même clé d'idempotence/les mêmes paramètres d'opération ; les échecs répétés nécessitent un rapport concret, pas une boucle infinie.