Skip to main content
OpenClaw a remplacé une vaste couche de rétrocompatibilité par une architecture de plugins moderne fondée sur de petits imports ciblés. Si votre plugin est antérieur à ce changement, ce guide vous aide à adopter les contrats actuels.

Ce qui a changé

Deux surfaces d’import très permissives permettaient auparavant aux plugins d’accéder à presque tout depuis un point d’entrée unique :
  • openclaw/plugin-sdk/compat - réexportait des dizaines d’utilitaires pour maintenir le fonctionnement des anciens plugins fondés sur des hooks pendant la construction de la nouvelle architecture.
  • openclaw/plugin-sdk/infra-runtime - un vaste module d’agrégation mêlant événements système, état Heartbeat, files d’attente de livraison, utilitaires de récupération/proxy, utilitaires de fichiers, types d’approbation et utilitaires sans rapport entre eux.
  • openclaw/plugin-sdk/config-runtime - un vaste module d’agrégation de configuration qui contenait encore des utilitaires directs obsolètes de chargement/écriture pendant la période de migration.
  • openclaw/extension-api - une passerelle donnant aux plugins un accès direct aux utilitaires côté hôte, comme l’exécuteur d’agent intégré.
  • api.registerEmbeddedExtensionFactory(...) - un hook supprimé, propre à l’exécuteur intégré, qui observait ses événements tels que tool_result. Utilisez plutôt l’intergiciel de résultats d’outils d’agent (voir Migrer les extensions de résultats d’outils intégrées vers l’intergiciel).
Ces surfaces sont obsolètes : elles fonctionnent encore, mais les nouveaux plugins ne doivent pas les utiliser et les plugins existants doivent migrer avant leur suppression dans la prochaine version majeure. registerEmbeddedExtensionFactory a déjà été supprimé ; les anciens enregistrements ne sont plus chargés.
La couche de rétrocompatibilité sera supprimée dans une future version majeure. Les plugins qui importent encore depuis ces surfaces cesseront alors de fonctionner.
OpenClaw ne supprime ni ne réinterprète un comportement de plugin documenté dans le même changement que celui qui introduit son remplacement. Les modifications de contrat incompatibles passent d’abord par un adaptateur de compatibilité, des diagnostics, de la documentation et une période d’obsolescence. Cela s’applique aux imports du SDK, aux champs du manifeste, aux API de configuration, aux hooks et au comportement d’enregistrement à l’exécution.

Pourquoi

  • Démarrage lent - l’import d’un seul utilitaire chargeait des dizaines de modules sans rapport.
  • Dépendances circulaires - les vastes réexportations facilitaient la création de cycles d’import.
  • Surface d’API peu claire - rien ne permettait de distinguer les exports stables des exports internes.
Chaque openclaw/plugin-sdk/<subpath> est désormais un petit module autonome doté d’un contrat documenté. Les anciennes interfaces pratiques de fournisseurs pour les canaux intégrés ont également disparu : les raccourcis d’utilitaires propres aux canaux étaient des commodités privées du monorepo, et non des contrats de plugin stables. Utilisez plutôt des sous-chemins génériques et ciblés du SDK. Dans l’espace de travail des plugins intégrés, conservez les utilitaires appartenant au fournisseur dans le fichier api.ts ou runtime-api.ts de ce plugin :
  • Anthropic conserve les utilitaires de flux propres à Claude dans son interface api.ts / contract-api.ts.
  • OpenAI conserve les constructeurs de fournisseurs, les utilitaires de modèle par défaut et les constructeurs de fournisseurs en temps réel dans son fichier api.ts.
  • OpenRouter conserve le constructeur de fournisseur et les utilitaires d’intégration/configuration dans son fichier api.ts.

Politique de compatibilité

Les travaux de compatibilité des plugins externes suivent cet ordre :
  1. Ajouter le nouveau contrat.
  2. Maintenir l’ancien comportement au moyen d’un adaptateur de compatibilité.
  3. Émettre un diagnostic ou un avertissement indiquant l’ancien chemin et son remplacement.
  4. Couvrir les deux chemins dans les tests.
  5. Documenter l’obsolescence et la procédure de migration.
  6. Ne supprimer qu’après la période de migration annoncée, généralement dans une version majeure.
Si un champ de manifeste est encore accepté, continuez à l’utiliser jusqu’à ce que la documentation et les diagnostics indiquent le contraire. Le nouveau code doit privilégier le remplacement documenté ; les plugins existants ne doivent pas cesser de fonctionner lors de versions mineures ordinaires. Auditez la file de migration actuelle avec pnpm plugins:boundary-report : pnpm plugins:boundary-report:ci s’exécute avec les trois options d’échec. Chaque enregistrement de compatibilité possède une date removeAfter explicite (et non une vague « prochaine version majeure ») : le rapport regroupe les enregistrements obsolètes selon cette date, compte les références locales dans le code et la documentation, signale les imports SDK réservés entre propriétaires et résume la passerelle SDK privée de l’hôte de mémoire. Les sous-chemins SDK réservés doivent être associés à un usage suivi par leur propriétaire ; les exports réservés inutilisés doivent être supprimés du SDK public.

Procédure de migration

1

Migrer les utilitaires de chargement/écriture de la configuration d’exécution

Les plugins intégrés doivent cesser d’appeler directement api.runtime.config.loadConfig() et api.runtime.config.writeConfigFile(...). Privilégiez la configuration déjà transmise au chemin d’appel actif. Les gestionnaires à longue durée de vie qui ont besoin de l’instantané actuel du processus peuvent utiliser api.runtime.config.current(). Les outils d’agent à longue durée de vie doivent lire ctx.getRuntimeConfig() dans execute, afin qu’un outil créé avant une écriture de configuration voie tout de même la configuration actualisée.Les écritures de configuration passent par l’utilitaire transactionnel avec une politique explicite après écriture :
Utilisez afterWrite: { mode: "restart", reason: "..." } lorsque le changement nécessite un redémarrage propre du Gateway, et afterWrite: { mode: "none", reason: "..." } uniquement lorsque l’appelant prend en charge la suite et désactive délibérément le planificateur de rechargement. Les résultats de mutation incluent un résumé followUp typé pour les tests et la journalisation ; le Gateway reste responsable de l’application ou de la planification du redémarrage.loadConfig et writeConfigFile restent disponibles comme utilitaires de compatibilité obsolètes pour les plugins externes et émettent un avertissement unique avec le code de compatibilité runtime-config-load-write. Les plugins intégrés et le code d’exécution du dépôt sont protégés par pnpm check:deprecated-api-usage et pnpm check:no-runtime-action-load-config : toute nouvelle utilisation dans le code de production d’un plugin échoue immédiatement, les écritures directes de configuration échouent, les méthodes du serveur Gateway doivent utiliser l’instantané d’exécution de la requête, les utilitaires d’envoi, d’action et de client des canaux d’exécution doivent recevoir la configuration depuis leur frontière, et les modules d’exécution à longue durée de vie n’autorisent aucun appel ambiant à loadConfig().Le nouveau code de plugin doit éviter le vaste module d’agrégation openclaw/plugin-sdk/config-runtime. Utilisez le sous-chemin ciblé correspondant au besoin :Les plugins intégrés et leurs tests sont protégés par une analyse contre ce vaste module d’agrégation, afin que les imports et les simulations restent locaux au comportement dont ils ont besoin. Le module d’agrégation existe toujours pour la compatibilité externe, mais le nouveau code ne doit pas en dépendre.
2

Migrer les extensions de résultats d’outils intégrées vers l’intergiciel

Les plugins intégrés doivent remplacer les gestionnaires de résultats d’outils propres à l’exécuteur intégré api.registerEmbeddedExtensionFactory(...) par un intergiciel indépendant de l’environnement d’exécution :
Mettez à jour le manifeste du plugin en même temps :
Les plugins installés peuvent également enregistrer un intergiciel de résultats d’outils lorsqu’il est explicitement activé et que chaque environnement d’exécution ciblé est déclaré dans contracts.agentToolResultMiddleware. Les enregistrements d’intergiciels installés non déclarés sont rejetés.
3

Migrer les gestionnaires d’approbation natifs vers les faits de capacité

Les plugins de canaux prenant en charge les approbations exposent le comportement d’approbation natif au moyen de approvalCapability.nativeRuntime et du registre partagé de contexte d’exécution :
  • Remplacez approvalCapability.handler.loadRuntime(...) par approvalCapability.nativeRuntime.
  • Déplacez l’authentification et la livraison propres aux approbations hors de l’ancien câblage plugin.auth / plugin.approvals vers approvalCapability.
  • ChannelPlugin.approvals a été supprimé du contrat public des plugins de canaux ; déplacez les champs de livraison, natifs et de rendu vers approvalCapability.
  • plugin.auth ne sert plus qu’aux flux de connexion/déconnexion des canaux ; le cœur n’y lit plus les hooks d’authentification des approbations.
  • Enregistrez les objets d’exécution appartenant au canal (clients, jetons, applications Bolt) au moyen de openclaw/plugin-sdk/channel-runtime-context.
  • N’envoyez pas de notifications de réacheminement appartenant au plugin depuis les gestionnaires d’approbation natifs ; le cœur gère les notifications d’acheminement vers un autre emplacement à partir des résultats de livraison réels.
  • Lorsque vous transmettez channelRuntime à createChannelManager(...), fournissez une véritable surface createPluginRuntime().channel ; les simulations partielles sont rejetées.
Consultez Plugins de canaux pour connaître la structure actuelle des capacités d’approbation.
4

Auditer le comportement de repli des wrappers Windows

Si votre plugin utilise openclaw/plugin-sdk/windows-spawn, les wrappers Windows .cmd/.bat non résolus échouent désormais de manière fermée, sauf si vous transmettez explicitement allowShellFallback: true :
Si votre appelant ne dépend pas intentionnellement du repli via le shell, ne définissez pas allowShellFallback et gérez plutôt l’erreur levée.
5

Rechercher les imports obsolètes

6

Les remplacer par des imports ciblés

Chaque export de l’ancienne surface correspond à un chemin d’import moderne spécifique :
Pour les fonctions auxiliaires côté hôte, utilisez l’environnement d’exécution du plugin injecté au lieu d’effectuer une importation directe :
Appliquez le même modèle aux autres fonctions auxiliaires de pont héritées :
7

Remplacer les importations générales d’infra-runtime

openclaw/plugin-sdk/infra-runtime existe toujours pour assurer la compatibilité externe, mais le nouveau code doit importer la surface ciblée dont il a réellement besoin :Un analyseur empêche les plugins intégrés d’utiliser infra-runtime, afin que le code du dépôt ne puisse pas revenir à ce barrel général.
8

Migrer les fonctions auxiliaires de routage des canaux

Le nouveau code de routage des canaux utilise openclaw/plugin-sdk/channel-route. Les anciens noms de clés de routage et de cibles comparables restent disponibles comme alias de compatibilité :Les fonctions auxiliaires de routage modernes normalisent { channel, to, accountId, threadId } de manière cohérente pour les approbations natives, la suppression des réponses, la déduplication des messages entrants, la livraison Cron et le routage des sessions.N’ajoutez pas de nouvelles utilisations de ChannelMessagingAdapter.parseExplicitTarget, des fonctions auxiliaires de routage chargé reposant sur l’analyseur (parseExplicitTargetForLoadedChannel, resolveRouteTargetForLoadedChannel) ni de resolveChannelRouteTargetWithParser(...) provenant de plugin-sdk/channel-route : elles sont obsolètes et ne subsistent que pour les anciens plugins. Les nouveaux plugins de canal doivent utiliser messaging.targetResolver.resolveTarget(...) pour normaliser l’identifiant de cible et fournir une solution de repli en cas d’absence dans l’annuaire, messaging.inferTargetChatType(...) lorsque le cœur a besoin de connaître rapidement le type de pair, et messaging.resolveOutboundSessionRoute(...) pour déterminer l’identité native du fournisseur pour la session et le fil de discussion.
9

Compiler et tester

Référence des chemins d’importation

Ce tableau présente le sous-ensemble commun pour la migration, et non l’intégralité de la surface du SDK. L’inventaire des points d’entrée du compilateur se trouve dans scripts/lib/plugin-sdk-entrypoints.json ; les exportations de paquet sont générées à partir du sous-ensemble public. Les interfaces d’assistance réservées aux plugins intégrés ont été retirées de la carte d’exportation du SDK public, à l’exception des façades de compatibilité explicitement documentées, telles que le shim plugin-sdk/discord obsolète, conservé pour les plugins externes qui importent encore directement le paquet publié @openclaw/discord. Les assistants propres à un propriétaire résident dans le paquet du plugin concerné ; le comportement partagé de l’hôte passe par des contrats SDK génériques tels que plugin-sdk/gateway-runtime, plugin-sdk/security-runtime et plugin-sdk/plugin-config-runtime. Utilisez l’importation la plus ciblée correspondant à la tâche. Si vous ne trouvez pas une exportation, consultez le code source dans src/plugin-sdk/ ou demandez aux responsables quel contrat générique doit en être propriétaire.

Dépréciations actives

Dépréciations plus ciblées dans le SDK des plugins, le contrat des fournisseurs, la surface d’exécution et le manifeste. Chacune fonctionne encore actuellement, mais sera supprimée dans une prochaine version majeure. Chaque entrée associe l’ancienne API à son remplacement canonique.
Ancien (openclaw/plugin-sdk/command-auth) : buildCommandsMessage, buildCommandsMessagePaginated, buildHelpMessage.Nouveau (openclaw/plugin-sdk/command-status) : mêmes signatures, mêmes exportations ; seule l’importation se fait depuis le sous-chemin plus ciblé. command-auth les réexporte comme stubs de compatibilité.
Ancien : resolveMentionGating(params) et resolveMentionGatingWithBypass(params) depuis openclaw/plugin-sdk/channel-inbound ou openclaw/plugin-sdk/channel-mention-gating.Nouveau : resolveInboundMentionDecision({ facts, policy }) — un seul objet de décision au lieu de deux formes d’appel distinctes.Adopté dans Discord, iMessage, Matrix, MS Teams, QQBot, Signal, Telegram, WhatsApp et Zalo. Le modèle d’événement app_mention propre à Slack n’utilise pas cet assistant.
openclaw/plugin-sdk/channel-runtime est un shim de compatibilité destiné aux anciens plugins de canal. Ne l’importez pas dans du nouveau code ; utilisez openclaw/plugin-sdk/channel-runtime-context pour enregistrer les objets d’exécution.Les assistants channelActions* de openclaw/plugin-sdk/channel-actions sont obsolètes, tout comme les exportations brutes d’« actions » de canal. Exposez plutôt les capacités par l’intermédiaire de la surface sémantique presentation : les plugins de canal déclarent ce qu’ils affichent (cartes, boutons, sélecteurs), plutôt que les noms d’actions brutes qu’ils acceptent.
Ancien : fabrique tool() de openclaw/plugin-sdk/provider-web-search.Nouveau : implémentez createTool(...) directement sur le plugin fournisseur. OpenClaw n’a plus besoin de l’assistant du SDK pour enregistrer l’enveloppe de l’outil.
Ancien : api.runtime.channel.reply.formatInboundEnvelope(...) (ainsi que le champ channelEnvelope des objets de message entrants) pour construire une enveloppe d’invite plate en texte brut à partir des messages entrants du canal.Nouveau : BodyForAgent accompagné de blocs structurés de contexte utilisateur. Les plugins de canal joignent les métadonnées de routage (fil, sujet, réponse à, réactions) sous forme de champs typés, au lieu de les concaténer dans une chaîne d’invite. L’assistant formatAgentEnvelope(...) reste pris en charge pour les enveloppes synthétisées destinées à l’assistant, mais les enveloppes entrantes en texte brut sont en voie de suppression.Zones concernées : inbound_claim, message_received et tout plugin de canal personnalisé qui post-traitait l’ancien texte de l’enveloppe.
Ancien : api.on("deactivate", handler).Nouveau : api.on("gateway_stop", handler). Même contrat de nettoyage lors de l’arrêt ; seul le nom du hook change.
deactivate reste connecté comme alias de compatibilité obsolète jusqu’à sa suppression après le 2026-08-16.
Ancien : api.on("subagent_spawning", handler) renvoyant threadBindingReady ou deliveryOrigin.Nouveau : laissez le cœur préparer les liaisons de sous-agent thread: true via l’adaptateur de liaison de session du canal. Utilisez api.on("subagent_spawned", handler) uniquement pour l’observation après le lancement.
subagent_spawning, PluginHookSubagentSpawningEvent, PluginHookSubagentSpawningResult et SubagentLifecycleHookRunner.runSubagentSpawning(...) ne subsistent que comme surfaces de compatibilité obsolètes pendant la migration des plugins externes, et seront supprimés après le 2026-08-30.
Quatre alias de type de découverte sont désormais de fines enveloppes autour des types de l’ère du catalogue :S’y ajoute l’ancien conteneur statique ProviderCapabilities : les plugins fournisseurs doivent utiliser des hooks de fournisseur explicites tels que buildReplayPolicy, normalizeToolSchemas et wrapStreamFn, plutôt qu’un objet statique.
Ancien (trois hooks distincts sur ProviderThinkingPolicy) : isBinaryThinking(ctx), supportsXHighThinking(ctx) et resolveDefaultThinkingLevel(ctx).Nouveau : un unique resolveThinkingProfile(ctx) qui renvoie un ProviderThinkingProfile avec l’id canonique, un label facultatif et une liste ordonnée de niveaux. OpenClaw rétrograde automatiquement les anciennes valeurs enregistrées selon le rang du profil.Le contexte comprend provider, modelId, un reasoning fusionné facultatif et des informations compat facultatives fusionnées concernant le modèle. Les plugins fournisseurs peuvent utiliser ces informations du catalogue pour exposer un profil propre au modèle uniquement lorsque le contrat de requête configuré le prend en charge.Implémentez un seul hook au lieu de trois. Les anciens hooks continuent de fonctionner pendant la période de dépréciation, mais ne sont pas composés avec le résultat du profil.
Ancien : implémentation de hooks d’authentification externes sans déclarer le fournisseur dans le manifeste du plugin.Nouveau : déclarez contracts.externalAuthProviders dans le manifeste du plugin et implémentez resolveExternalAuthProfiles(...).
Ancien champ du manifeste : providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Nouveau : reproduisez la même recherche de variables d’environnement dans setup.providers[].envVars au sein du manifeste. Cela regroupe au même endroit les métadonnées d’environnement de configuration et d’état et évite de démarrer l’environnement d’exécution du plugin uniquement pour répondre aux recherches de variables d’environnement.providerAuthEnvVars reste pris en charge par un adaptateur de compatibilité jusqu’à la fin de la période de dépréciation.
Ancien : trois appels distincts — api.registerMemoryPromptSection(...), api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Nouveau : un seul appel sur l’API d’état de la mémoire — registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Mêmes emplacements, un seul appel d’enregistrement. Les assistants additifs d’invite et de corpus (registerMemoryPromptSupplement, registerMemoryCorpusSupplement) ne sont pas concernés.
Ancien : api.registerMemoryEmbeddingProvider(...) et contracts.memoryEmbeddingProviders.Nouveau : api.registerEmbeddingProvider(...) et contracts.embeddingProviders.Le contrat générique du fournisseur de plongements est réutilisable en dehors de la mémoire et constitue la voie prise en charge pour les nouveaux fournisseurs. L’API d’enregistrement propre à la mémoire reste connectée comme compatibilité obsolète pendant la migration des fournisseurs existants. L’inspection des plugins signale l’utilisation par des plugins non intégrés comme une dette de compatibilité.
Deux anciens alias de type sont toujours exportés depuis src/plugins/runtime/types.ts :La méthode d’exécution readSession est obsolète au profit de getSessionMessages. Même signature ; l’ancienne méthode appelle la nouvelle.
Le passage des sessions et transcriptions à SQLite supprime ou rend obsolètes les API destinées aux plugins qui exposaient des magasins sessions.json actifs, des chemins de transcription JSONL ou des listes de fichiers de session. Les plugins d’exécution doivent utiliser l’identité de session et les assistants d’exécution du SDK au lieu de résoudre ou de modifier les fichiers actifs.Les anciens fichiers de transcription JSONL restent valides comme artefacts d’importation, d’archivage, d’exportation et d’assistance. Ils ne constituent plus le contrat d’exécution permanent des sessions actives.Les plugins officiels publiés avec v2026.7.1-beta.5 importaient les quatre assistants obsolètes ci-dessus. openclaw/plugin-sdk/session-store-runtime conserve exactement cette passerelle jusqu’au 2026-10-12 ; les nouveaux plugins doivent utiliser les remplacements. resolveStorePath(...) reste un assistant SDK pris en charge et ne fait pas partie de cette dépréciation.openclaw plugins inspect --all --runtime signale les plugins non intégrés dont les erreurs de chargement ou les diagnostics font encore référence à ces API de fichiers supprimées. L’analyse consultative @openclaw/plugin-inspector doit utiliser la version 0.3.17 ou une version ultérieure afin que les analyses de paquets externes signalent également, avant la publication, les assistants de session portant sur l’ensemble du stockage, les assistants de chemin de fichier de session, les anciennes cibles de fichier de transcription et les assistants de transcription de bas niveau.
Ancien : runtime.tasks.flow (au singulier) renvoyait un accesseur TaskFlow actif.Nouveau : runtime.tasks.managedFlows conserve l’environnement d’exécution de mutation TaskFlow géré pour les plugins qui créent, mettent à jour, annulent ou exécutent des tâches enfants à partir d’un flux. Utilisez runtime.tasks.flows lorsque le plugin nécessite uniquement des lectures fondées sur des DTO.
Supprimé après le 2026-07-26.
Traité dans Procédure de migration ci-dessus. Inclus ici par souci d’exhaustivité : le chemin supprimé api.registerEmbeddedExtensionFactory(...), réservé à l’ancien exécuteur intégré, est remplacé par api.registerAgentToolResultMiddleware(...) avec une liste explicite d’environnements d’exécution dans contracts.agentToolResultMiddleware.
OpenClawSchemaType, réexporté depuis openclaw/plugin-sdk, est désormais un alias d’une ligne pour OpenClawConfig. Préférez le nom canonique.
Les dépréciations propres aux extensions (dans les plugins de canal/fournisseur intégrés sous extensions/) sont suivies dans leurs propres fichiers d’exportation api.ts et runtime-api.ts. Elles n’affectent pas les contrats des plugins tiers et ne sont pas répertoriées ici. Si vous utilisez directement le fichier d’exportation local d’un plugin intégré, lisez ses commentaires de dépréciation avant d’effectuer la mise à niveau.

Migration de Talk et de la voix en temps réel

Le code de voix en temps réel, de téléphonie, de réunion et de Talk dans le navigateur partage un contrôleur de session Talk exporté par openclaw/plugin-sdk/realtime-voice. Le contrôleur possède l’enveloppe commune des événements Talk, l’état du tour actif, l’état de capture, l’état de la sortie audio, l’historique récent des événements et le rejet des tours obsolètes. Les plugins fournisseurs possèdent les sessions en temps réel propres à chaque fournisseur ; les plugins de surface possèdent les particularités de la capture, de la lecture, de la téléphonie et des réunions. Toutes les surfaces intégrées s’exécutent sur le contrôleur partagé : relais du navigateur, transfert vers une salle gérée, appel vocal en temps réel, reconnaissance vocale en continu pour les appels vocaux, Google Meet en temps réel et mode natif « appuyer pour parler ». Le Gateway annonce un seul canal d’événements Talk en direct dans hello-ok.features.events : talk.event. Le nouveau code ne doit pas appeler directement createTalkEventSequencer(...), sauf pour implémenter un adaptateur de bas niveau ou un dispositif de test. Utilisez le contrôleur partagé afin que les événements limités à un tour ne puissent pas être émis sans identifiant de tour, que les appels turnEnd / turnCancel obsolètes ne puissent pas effacer un tour actif plus récent et que les événements du cycle de vie de la sortie audio restent cohérents entre la téléphonie, les réunions, le relais du navigateur, le transfert vers une salle gérée et les clients Talk natifs. Forme de l’API publique :
Les sessions WebRTC/WebSocket fournisseur détenues par le navigateur utilisent talk.client.create, car le navigateur prend en charge la négociation avec le fournisseur et le transport des médias, tandis que le Gateway possède les identifiants, les instructions et la politique des outils. talk.session.* est la surface commune gérée par le Gateway pour le temps réel via relais du Gateway, la transcription via relais du Gateway et les sessions STT/TTS natives en salle gérée. Les anciennes configurations qui placent les sélecteurs en temps réel à côté de talk.provider / talk.providers doivent être réparées avec openclaw doctor --fix ; l’environnement d’exécution Talk ne réinterprète pas la configuration du fournisseur de parole/TTS comme une configuration de fournisseur en temps réel. Les combinaisons prises en charge par talk.session.create sont intentionnellement peu nombreuses : Correspondance des méthodes pour les lecteurs migrant depuis les anciennes familles talk.realtime.* / talk.transcription.* / talk.handoff.* (toutes supprimées) : Le vocabulaire de contrôle unifié est lui aussi volontairement restreint : N’introduisez pas de cas particuliers propres à un fournisseur ou à une plateforme dans le cœur pour assurer ce fonctionnement. Le cœur gère la sémantique des sessions Talk. Les plugins de fournisseur gèrent la configuration des sessions propres aux fournisseurs. Voice-call et Google Meet gèrent les adaptateurs de téléphonie et de réunion. Le navigateur et les applications natives gèrent l’expérience utilisateur de capture et de lecture sur l’appareil.

Calendrier de suppression

Tous les plugins du cœur ont déjà été migrés. Les plugins externes doivent migrer avant la prochaine version majeure. Exécutez pnpm plugins:boundary-report pour savoir quelles entrées de compatibilité arriveront le plus tôt à échéance pour les surfaces utilisées par votre plugin.

Suppression temporaire des avertissements

Il s’agit d’une solution de contournement temporaire, et non d’une solution permanente.

Ressources connexes