Évaluation de Plugin

Validez les fichiers Base MCP plugin contre la spécification Plugin actuelle. Produit un rapport de conformité avec des constats actionnables.

Fonctionne pour les auteurs (auto-vérification avant soumission d'une PR) et les reviewers (évaluation d'une PR entrante).

Workflow

1. Récupérez la spec actuelle (elle change — ne vous fiez jamais à une copie obsolète) :

   curl -s https://raw.githubusercontent.com/base/skills/master/skills/base-mcp/references/plugin-spec.md

   Docs connexes à lire : references/custom-plugins.md, references/approval-mode.md, references/batch-calls.md, et SKILL.md (la skill racine). Les plugins natifs existants sous skills/base-mcp/plugins/ constituent le précédent pour les conventions.

2. Lisez le fichier plugin en entier. Si vous reviewez une PR :

   gh pr view <n> --repo base/skills --json title,body,number,headRefName,files,additions,deletions
   gh pr diff <n> --repo base/skills
   # fichier plugin brut (le diff peut être tronqué) :
   gh api "repos/base/skills/pulls/<n>/files" --jq '.[] | select(.filename|endswith(".md")) | .raw_url'

3. Évaluation statique de conformité — évaluez selon chaque dimension dans references/evaluation-criteria.md (inclut les vérifications de conformité/langue et les portes de catégorie à haut risque). Rédigez le rapport en utilisant references/report-template.md.

4. (Optionnel) Vérification API / SDK en direct — testez les endpoints documentés/SDK/contrats avec des appels en lecture seule. Voir references/live-testing.md. Pour les plugins de perps/marchés prédictifs/jeux d'argent, exécutez également la vérification de géoblocage (comparez les restrictions d'accès frontend vs API). Ajoutez une section ## Live API / SDK Verification au rapport. Ceci renverse régulièrement les affirmations de la doc (endpoints fabriqués/verrouillés, hôtes cassés, formes de réponse incorrectes).

5. Sauvegardez le rapport. Si vous reviewez une PR et qu'on vous demande de commenter, rédigez un commentaire PR à partir du rapport en utilisant references/comment-guidelines.md et postez avec : gh pr comment <n> --repo base/skills --body-file <comment-file>.

Plusieurs PRs

Évaluez les PRs en parallèle en créant un sub-agent par PR (chacun rédige son propre rapport + retourne un court résumé du verdict). Transmettez à chaque sub-agent : la spec (ou son URL brute), le numéro de PR, les critères d'évaluation, le modèle de rapport, et les guidelines de commentaire.

Pièges critiques

Ceux-ci reviennent régulièrement et sont faciles à se tromper — détails complets dans references/evaluation-criteria.md :

• Les signatures de smart-account cassent la signature naïve. Le wallet Base MCP par défaut est un smart contract ; sign retourne une signature ERC-1271/6492 de longueur variable (>200 octets), pas une signature EOA de 65 octets. Tout plugin qui épisse une signature dans un slot calldata de largeur fixe, ou intègre une signature EIP-712 hors-chaîne dans le calldata (ex. Permit2 buildCallWithPermit2), est cassé pour ce wallet. Pattern correct : allowance grants onchain.
• Le risque irreversible n'est PAS pour chaque écriture onchain. La spec dit « marquer quand ça vaut le coup d'être mis en avant ». Les swaps purs utilisent slippage (précédent : Uniswap, Aerodrome portent [slippage], pas irreversible). Réservez irreversible pour les cas asymétriques/graves (perps/liquidation, lancements de token/rug). Ne l'exigez pas sur les swaps.
• Ne vous auto-enregistrez pas. Une PR de plugin ne doit PAS éditer la table de plugins de SKILL.md, la cellule « Examples » des Integration Types, ou la table « Existing Plugin Conformance » — celles-ci sont gérées par les mainteneurs (codifiées dans « Contribution Scope » de plugin-spec.md). La seule édition de fichier partagé sanctionnée est l'ajout d'un tag véritablement nouveau à la liste de vocabulaire. Limitez le diff à plugins/<slug>.md (+ cette ligne de tag).
• version est la version du plugin-doc — pas la version npm/package et pas une version de spec globale. La spec ne mandate aucun numéro de départ spécifique.
• Vérifiez les affirmations, ne leur faites pas confiance. Les modèles d'auth, l'exhaustivité des allowlists, les formes de réponse, et les adresses de contrat sont fréquemment erronés dans la doc. Sondez-les (test en direct).
• Les liens de référence depuis un fichier plugin doivent utiliser ../references/... (les fichiers de plugin vivent dans plugins/, les refs dans references/).
• Le langage neutre est obligatoire. Pas d'affirmations sur rendement/taux/performance, pas de « vous devriez acheter X », pas de « déposez toujours ici », pas de défaut pour des tokens spécifiques. Le langage directif est un bloquant.
• Les plugins de perps, marchés prédictifs, et confidentialité nécessitent un examen juridique avant inclusion en tant que plugins natifs. Signalez ceci comme une porte de processus pré-fusion dans le rapport.
• Parité de géoblocage API. Si le frontend du protocole géobloque les IPs américaines (ou autres), l'API doit appliquer des restrictions équivalentes. Si ce n'est pas le cas, Base MCP risque d'être un outil de contournement — signalez comme bloquant.