Versionner et comparer un contrat d’extension
Un numéro de version déclaré ne suffit pas à déterminer si l’autorité, les channels ou les données exposées ont changé. Le tooling calcule donc un fingerprint à partir du contrat public effectivement déclaré.
Fingerprint développeur V1
cd cli node src/index.js extension fingerprint ../plugins/acme_pay # sha256:...
Le hash est calculé sur une représentation canonique du contrat public dérivé de extension.yaml et du runtime : identité et compatibilité plateforme, descriptor projeté, configSchema, événements, objets externes et event payload contracts. Le numéro de version du package est conservé dans le snapshot mais n’entre pas dans le contenu hashé.
Snapshot et comparaison
node src/index.js extension fingerprint ../plugins/acme_pay --write ./acme-pay.contract.json node src/index.js extension diff ../plugins/acme_pay --against ./acme-pay.contract.json
Le diff retourne les paths contractuels qui ont changé. Toute différence est marquée review_relevant par prudence ; la commande ne décide pas elle-même d’une certification ou d’une re-review.
Changements à classifier
Ajout d’un channel, élargissement des permissions api_in, nouvelles contributions, modification de schémas/configuration ou évolution d’un event contract sont des changements qui doivent être examinés avant distribution. Le futur moteur de review pourra classifier ces diffs plus finement.
Limites actuelles
Le fingerprint couvre les identités de contributions déclarées dans extension.yaml, mais pas le contrat complet des Nodes et Agent Tools. Vérifiez aussi leurs paramètres, leurs sorties et leur comportement pour évaluer la compatibilité d’une mise à jour.
Utilisez le preflight en complément : fingerprint et validité du contrat répondent à deux questions différentes.