Compatibilité des plugins OxideTerm
Lisez l'implémentation concernée avant d'assigner une limite de compatibilité :
crates/oxideterm-plugin-manifest/src/registry.rs: données de version et de correction du catalogue.crates/oxideterm-plugin-registry/src/registry.rsetcompatibility.rs: sélection de version, exigences mises en cache et découverte au démarrage.crates/oxideterm-plugin-registry/src/install.rs: vérifications d'installation de paquets.crates/oxideterm-gpui-app/src/workspace/plugin_entity.rs: rafraîchissement, gating d'activation et propriété des tâches.- L'API hôte, l'environnement d'exécution ou le chargeur de grammaire spécifique affecté par le changement.
crates/oxideterm-editor-syntax/src/plugin.rsetcrates/oxideterm-gpui-editor/src/languages.rspour le chargement paresseux des grammaires et le rafraîchissement des documents ouverts.
Contrat côté hôte
Sélectionnez la version la plus élevée prise en charge à la fois par l'hôte et par la plateforme. Proposez une mise à jour uniquement lorsque cette version compatible est plus récente que le plugin installé expliquez séparément une version incompatible supérieure. Ne jamais rétrograder silencieusement.
Revérifiez les plugins installés au démarrage après les mises à niveau et les rétrogradations de l'application. Appliquez la correction mise en cache la plus récente pour l'ID et la version exacte du plugin sans réécrire les fichiers de paquets. Conservez les fichiers, paramètres et préférences d'activation tout en bloquant l'activation incompatible. Gardez le rafraîchissement au démarrage limité et possédé par l'entité du plugin ; un démarrage hors ligne utilise le dernier cache valide.
Le client officiel utilise le catalogue de résumé v2 et charge les historiques liés par somme de contrôle pour les plugins installés et la page actuelle du marché. Un historique doit correspondre à son identité de résumé, sa version la plus récente, sa plage hôte effective, sa taille et SHA-256. Préservez le point de terminaison v1 figé, l'instantané historique exact, les ressources référencées et le lecteur de cache v1. Tous les plugins, versions et corrections suivants appartiennent uniquement à v2 ; les clients existants doivent mettre à niveau l'hôte pour les recevoir. Les nouveaux clients ne récupèrent que v2 ; en cas d'échec, conservez le dernier cache valide plutôt que de le remplacer par v1 figé. Publiez v2 avant de livrer un hôte qui en a besoin. Enregistrez les historiques bruts vérifiés avant de remplacer le cache racine compact ; le démarrage et l'installation manuelle doivent résoudre les corrections pour la version installée exacte. Annulez les demandes de page obsolètes et rejetez les résultats d'une autre page ou d'un instantané de catalogue. La maintenance et la génération du catalogue appartiennent aux enregistrements sources par plugin du marché et à l'automatisation des versions.
Pour l'extraction de langues, vérifiez le chargeur de grammaire, l'ABI Tree-sitter et le comportement réel de l'ancien client. Une plage hôte ne peut pas remplacer ces vérifications. N'attribuez pas de limite supérieure aux anciens plugins simplement parce qu'une nouvelle version de plugin ou d'application a été publiée.
Depuis 2.2.2, les manifestes de langues peuvent déclarer displayName, grammarName, extensions
et les fileNames littéraux. Les nouveaux ID sont dynamiques ; n'étendez pas l'énumération héritée ni les
tables d'association de fichiers pour eux. Les paquets de langues publiés conservent leurs associations
de repli. Les déclarations du catalogue sont tirées des archives vérifiées et liées aux
historiques v2, les manifestes installés prévalant sur les indices de catalogue compatibles. Les nouvelles
déclarations nécessitent >=2.2.2 ; les corrections de requêtes ordinaires pour les paquets hérités conservent leur
plage hôte existante. Maintenez la cohérence de la re-détection des documents ouverts, du routage des plugins manquants et des
indices de catalogue hors ligne dans les aperçus IDE, locaux et SFTP.
Depuis 2.2.2, un paquet de langue peut regrouper des grammaires embarquées dans injections.
Vérifiez chaque analyseur, requête de surlignage et sélecteur parent par sa somme de contrôle déclarée ;
les sélecteurs capturent injection.content. Le document possède chaque analyseur embarqué,
sa cancellation et sa suppression. Conservez les coordonnées d'octets originales à travers les modifications et
limitez les surlignages enfants aux régions incluses, en remplaçant les captures parentes là
pour que les captures de template ne puissent pas masquer les jetons de script. Les grammaires regroupées sont privées pour
leur paquet parent et n'enregistrent pas d'associations de fichiers séparées.
Pour l'extraction d'agents ACP, conservez le client ACP, les décisions de permission et la propriété
du processus dans l'hôte. Les manifestes acp publiés restent pris en charge et normalisent
le plan d'assistance commun. Les nouveaux manifestes d'assistance déclarent la fonctionnalité acp, le protocole
acp et la version 1. Les agents parlent directement via ACP stdio ; ne faites pas transiter leur trafic
par le superviseur de plugin ordinaire. Vérifiez registry.acp_agents,workspace/acp_plugins.rs, et
workspace/acp_workspace.rs pour le gating au démarrage, la résolution du lancement et le nettoyage.
Les hôtes jusqu'à 2.2.1 ne peuvent pas charger cet environnement d'exécution. Préservez les identités d'agent existantes
et les options utilisateur lors de la migration des adaptateurs groupés vers les liaisons de plugin.
Les manifestes Mosh publiés utilisent terminal-transport ; les nouveaux manifestes d'assistance déclarent
la fonctionnalité terminal-transport, le protocole oxideterm-mosh et la version 1. Conservez le bootstrap SSH,
le rendu du terminal et la prédiction locale dans l'hôte ; UDP, SSP et
le chiffrement appartiennent au plugin moteur. Les hôtes jusqu'à 2.2.1 ne peuvent pas le charger.
Vérifiez oxideterm-mosh et ses MoshPluginSessions possédées par l'espace de travail pour le gating
de lancement et la mise hors service du processus avant le remplacement du paquet. Les deux directions de tuyau
doivent rester indépendantes sous la contre-pression de sortie. RDP, VNC et Mosh partagent
la catégorie de catalogue remote-connections.
Publication coordonnée
Les manifestes de bureau distant publiés utilisent remote-desktop ; les nouveaux manifestes d'assistance
déclarent la fonctionnalité remote-desktop, le protocole oxideterm-remote-desktop et la version 1.
Les deux sont normalisés dans le plan d'assistance commun, en dehors du superviseur de plugin ordinaire.
Conservez la visionneuse native, l'entrée, les identifiants et la propriété du tunnel SSH dans l'hôte.
Exigez un contributes.remoteDesktop.protocolVersion pris en charge et résolvez uniquement les
exécutables installés, fiables, activés et compatibles. Arrêtez et récupérez les processus d'assistance
avant de mettre à jour ou de supprimer leurs fichiers ; désactivez la reconnexion automatique jusqu'à ce qu'un
fournisseur compatible soit disponible. Conservez le format stdio binaire existant inchangé
lors de l'extraction des assistants. Les hôtes jusqu'à 2.2.1 ne peuvent pas charger cet environnement d'exécution.
Les manifestes helper génériques nécessitent des hôtes à partir de 2.2.2. Préservez les types de manifestes publiés,
les limites d'approbation de capacité et les charges utiles de protocole lors de leur normalisation.
L'unification des plans d'exécution ne transfère pas la propriété de l'enfant au superviseur de plugin.
FIDO déclare la fonctionnalité ssh-authentication, le protocole oxideterm-security-key et
la version 1 ; sa tâche d'authentification possède l'annulation et la récupération.
La création de plugins, les enregistrements de version et les corrections de compatibilité appartiennent au
dépôt AnalyseDeCircuit/oxideterm-plugins. Localisez sa copie de travail réelle par
l'identité du dépôt plutôt que de supposer un nom de répertoire local. Lisez son
.agents/skills/oxideterm-plugin-release/SKILL.md et utilisez ses scripts de publication.
Le skill canonique est également disponible à l'adresse :
Utilisez une copie de travail locale lorsque ce skill ou ses scripts ne sont pas encore publiés. N'inventez pas de processus de publication alternatif lorsque l'outillage requis est manquant. Les modifications d'implémentation hôte seules n'autorisent pas la publication de plugins.
Pour les changements de comportement, utilisez les tests existants du registre et de l'entité de plugin à la limite qui les possède. Couvrez les risques affectés : sélection de version compatible, rejet de mise à niveau/rétrogradation, récupération de correction ou démarrage hors ligne. Ne relancez pas de suites non liées simplement parce qu'un fichier de compatibilité de plugin a changé.