impact-plugin-sdk

Impact du Plugin SDK

Combinez les inventaires actuels de ClawHub avec une analyse source de chaque plugin OpenClaw intégré, y compris les plugins absents de ClawHub, pour éclairer les décisions de compatibilité. L'utilisation statique identifie les dépendances ; elle ne prouve pas l'exécution ou la dépendance à un comportement particulier. Considérez les règles d'approbation et de dépréciation dans le guide des limites du SDK comme faisant autorité.

Enquêter

1. Identifiez chaque surface publique concernée à partir du code source, y compris les exports SDK alternatifs et les chemins d'exécution. Vérifiez l'orthographe par rapport à la définition et aux appelants connus ; une clé incorrecte peut renvoyer un zéro convaincant. Tracez également les façades groupées, les assistants SDK et les lecteurs d'enregistrement : un alias plat peut avoir zéro appel direct de plugin tout en implémentant une méthode groupée prise en charge.

2. Analysez chaque plugin intégré dans un checkout OpenClaw propre à l'aide de l'analyse statique de Plugin Inspector. Réutilisez un Inspector 0.4.3 ou plus récent installé ; sinon, installez-le dans un répertoire temporaire séparé, sans scripts de cycle de vie :

   inspector_dir=$(mktemp -d)
   npm install --prefix "$inspector_dir" --ignore-scripts @openclaw/[email protected]
   node {baseDir}/scripts/scan-bundled.mjs \
     --inspector "$inspector_dir/node_modules/@openclaw/plugin-inspector" \
     --out /tmp/openclaw-bundled-sdk-usage.json
   

   Le scanner utilise par défaut le checkout de cette compétence ; --root <checkout> en sélectionne un autre. Il découvre extensions/*/openclaw.plugin.json, n'exécute jamais le code du plugin, et enregistre le commit, l'empreinte d'entrée, la version d'Inspector, chaque plugin, et les analyses incomplètes. Une analyse échouée ou expirée reste une lacune. Les plugins sans points d'entrée déclarés restent également des lacunes de couverture, car Inspector peut manquer les points d'entrée implicites. Un corpus interrompu ne peut pas être utilisé comme inventaire terminé. Réutilisez le rapport pour plusieurs requêtes tant que sa source reste inchangée. Un changement de commit, de liste de plugins ou de source non validée l'invalide ; re-scanner plutôt que de modifier le reçu.

3. Interrogez chaque clé canonique avec les deux sources :

   node {baseDir}/scripts/query.mjs 'api-member:api.registerTool' \
     --bundled /tmp/openclaw-bundled-sdk-usage.json
   

   Pour "mis à jour au cours des trois derniers mois", ajoutez --months 3. Cela signifie que la dernière version publique éligible a été téléchargée dans les trois mois calendaires précédant maintenant, mesuré en UTC (les fins de mois sont arrondies). Les modifications de liste et les re-scans ne comptent pas comme des mises à jour. La date de publication stockée est sa date de création/téléchargement ; l'approbation publique peut avoir lieu plus tard. --since 2026-07-16T12:00:00Z accepte un seuil explicite. Signalez le seuil exact et inclusif de releaseWindow, pas une date devinée. Les consommateurs publics et la couverture utilisent la même fenêtre sur chaque page. La source intégrée n'a pas de date de téléchargement comparable : signalez-la séparément, non filtrée, même pour une question sur une version récente. Le nombre combiné est l'union de cette fenêtre de publication publique et de la source intégrée actuelle, pas un nombre de versions récentes.

   L'assistant suit toutes les pages d'utilisation et de couverture, y compris les pages intermédiaires vides. Les comptages et la couverture incluent chaque résultat ; items, gaps, et warnings contiennent des exemples limités avec des comptages omis dans output.omitted. Les références mixtes comptent dans les totaux d'exécution et de type. Pour une enquête nécessitant chaque consommateur ou lacune, enregistrez la sortie --full dans un fichier et lisez-la par sections :

   node {baseDir}/scripts/query.mjs 'api-member:api.registerTool' \
     --bundled /tmp/openclaw-bundled-sdk-usage.json --full > sdk-usage.json
   

   --help documente les limites locales des points de terminaison et de parcours.

4. Inspectez les preuves correspondantes par rapport au changement proposé. Un appel de méthode peut ne pas utiliser le comportement en cours de modification. Les consommateurs de type uniquement comptent toujours pour la suppression de type/exportation. Interrogez les membres liés séparément ; une importation de module ne prouve pas l'utilisation de chaque exportation. Les références répétées dans un plugin comptent comme un seul consommateur.

5. Pour une question de comptage d'utilisation, signalez la clé, l'heure de la requête, la fenêtre de publication exacte (si demandée), les comptages ClawHub et intégré, leur nombre combiné, le commit intégré, et les deux lacunes de couverture. Les distinctPlugins et coverage de niveau supérieur restent propres à ClawHub ; bundled décrit les résultats source ; combined fusionne les identités de package exactes une fois. Certains plugins intégrés n'ont pas de nom de package : lorsqu'ils pourraient chevaucher des correspondances publiques, combined.distinctPlugins est nul et distinctPluginBounds signale la plage possible. observedPluginIdentities compte les identités source avant ce chevauchement incertain. Signalez la plage, pas sa borne supérieure comme un comptage exact. Des noms différents restent distincts ; ne devinez jamais d'alias à partir de noms affiches. L'absence de preuves intégrées rend l'impact combiné indisponible. Pour un changement SDK proposé, signalez également les preuves correspondantes, les appelants indirects, et votre recommandation de compatibilité. Terminez les enquêtes de changement par la décision du mainteneur : préserver le comportement, déprécier avec migration, ou procéder sous la politique existante. N'inférez jamais la permission à partir du nombre.

Clés canoniques

Surface	Exemple
Module SDK	sdk-module:openclaw/plugin-sdk/core
Export SDK nommé	sdk-export:openclaw/plugin-sdk/core#OpenClawPluginApi
Méthode API Plugin	api-member:api.registerTool
Membre runtime hôte	runtime-member:runtime.channel.reply.dispatchReplyFromConfig
Hook nommé	hook:hook.before_agent_start
Contrat manifest	manifest-contract:manifest.contracts.tools:example_tool

Les clés décrivent les identités SDK, pas les alias locaux. Les membres api.runtime sont normalisés en runtime.*. L'inventaire inclut les références prises en charge et dépréciées ; deprecationCodes non vide sélectionne les entrées associées aux avertissements existants. L'inspection par plugin est disponible à https://clawhub.ai/api/v1/sdk-usage/plugin?package=<nom-encodé> ; suivez son nextCursor jusqu'à nul pour obtenir l'inventaire complet.

Interpréter le résultat

Résultat	Rapport
Consommateurs observés	Signalez les comptages public, intégré et combinés avec leurs périmètres distincts. Inspectez les preuves avant de juger un changement de comportement.
Aucun consommateur observé, couverture complète	"Aucune référence statique détectée parmi N identités de plugins publics/intégrés." Nécessite les deux analyses ; exclut les plugins privés non intégrés et les dépendances non intégrées. Ne prouve pas que personne n'utilise l'API.
Analyse partielle, échouée, manquante, incompatible ou non résolue	Indiquez les correspondances observées, le nombre de lacunes et les lacunes représentatives. Zéro correspondance laisse l'impact inconnu.
Corpus vide	Aucun plugin éligible observé ; cela ne fournit aucune assurance au niveau de l'écosystème.
Point de terminaison indisponible, résultat mal formé ou parcours incomplet	L'impact est inconnu. Conservez l'erreur et utilisez les preuves locales ; ne substituez jamais zéro.

La couverture est liée à la version actuelle de publication/artefact et à la version d'analyse. Les rapports ClawHub éligibles ont inputKind: "artifact" ; les rapports intégrés utilisent "source". Un benchmark de checkout source ne peut pas établir ce que contient un package publié. Les références de type uniquement provenant de la source comptent toujours pour la suppression de type et d'exportation du SDK ; conservez la source de chaque correspondance. Un ancien horodatage d'analyse ne rend pas à lui seul un artefact immuable obsolète. Les preuves sont échantillonnées ; chaque analyse signale ses limites d'évidence/inconnu. Les pages sont des lectures en direct, pas un instantané : relancez si les versions ou la visibilité changent pendant l'enquête. L'assistant signale les changements qu'il observe mais ne peut pas établir d'instantané transactionnel.

N'écartez pas un problème de sécurité simplement parce qu'aucun consommateur n'a été observé. Décrivez comment les preuves d'utilisation affectent le risque de compatibilité ; les propriétaires de sécurité et du SDK décident toujours du correctif et de toute exception à la fenêtre de migration normale.