​

Internos de plugins

​

Modelo público de capacidades

​

Postura de compatibilidad externa

• plugins externos existentes: mantén funcionando las integraciones basadas en hooks; trátalo como la línea base de compatibilidad
• nuevos plugins agrupados/nativos: prefiere el registro explícito de capacidades en lugar de accesos específicos de proveedor o nuevos diseños solo de hooks
• plugins externos que adopten el registro de capacidades: está permitido, pero trata las superficies auxiliares específicas de capacidades como evolutivas, a menos que la documentación marque explícitamente un contrato como estable

• las API de registro de capacidades son la dirección prevista
• los hooks heredados siguen siendo la ruta más segura para evitar incompatibilidades para los plugins externos durante la transición
• no todos los subpaths auxiliares exportados son iguales; prefiere el contrato documentado y acotado, no exportaciones auxiliares incidentales

​

Formas de plugins

• plain-capability — registra exactamente un tipo de capacidad (por ejemplo, un plugin solo de proveedor como mistral)
• hybrid-capability — registra múltiples tipos de capacidad (por ejemplo, openai es propietario de la inferencia de texto, voz, comprensión de medios y generación de imágenes)
• hook-only — registra solo hooks (tipados o personalizados), sin capacidades, herramientas, comandos ni servicios
• non-capability — registra herramientas, comandos, servicios o rutas, pero no capacidades

​

Hooks heredados

• mantenerlo funcionando
• documentarlo como heredado
• preferir before_model_resolve para trabajo de reemplazo de modelo/proveedor
• preferir before_prompt_build para trabajo de mutación de prompts
• eliminarlo solo después de que baje el uso real y la cobertura de fixtures demuestre la seguridad de la migración

​

Señales de compatibilidad

​

Descripción general de la arquitectura

1. Manifest + descubrimiento OpenClaw encuentra plugins candidatos a partir de rutas configuradas, raíces del workspace, raíces globales de extensiones y extensiones agrupadas. El descubrimiento lee primero los manifests nativos openclaw.plugin.json junto con los manifests de bundles compatibles.
2. Habilitación + validación El core decide si un plugin descubierto está habilitado, deshabilitado, bloqueado o seleccionado para un slot exclusivo como memory.
3. Carga en tiempo de ejecución Los plugins nativos de OpenClaw se cargan dentro del proceso mediante jiti y registran capacidades en un registro central. Los bundles compatibles se normalizan en registros del registro sin importar código de tiempo de ejecución.
4. Consumo de superficies El resto de OpenClaw lee el registro para exponer herramientas, canales, configuración de proveedor, hooks, rutas HTTP, comandos de CLI y servicios.

• los metadatos en tiempo de análisis provienen de registerCli(..., { descriptors: [...] })
• el módulo real de la CLI del plugin puede permanecer diferido y registrarse en la primera invocación

• el descubrimiento y la validación de configuración deben funcionar a partir de metadatos de manifest/esquema sin ejecutar código del plugin
• el comportamiento nativo en tiempo de ejecución proviene de la ruta register(api) del módulo del plugin

​

Plugins de canal y la herramienta de mensajes compartida

• el core es propietario del host de la herramienta message compartida, la integración con prompts, el mantenimiento de sesiones/hilos y el despacho de ejecución
• los plugins de canal son propietarios del descubrimiento de acciones por alcance, el descubrimiento de capacidades y cualquier fragmento de esquema específico del canal
• los plugins de canal son propietarios de la gramática de conversación de sesión específica del proveedor, como cómo los ID de conversación codifican los ID de hilo o heredan de conversaciones padre
• los plugins de canal ejecutan la acción final a través de su adaptador de acciones

• accountId
• currentChannelId
• currentThreadTs
• currentMessageId
• sessionKey
• sessionId
• agentId
• requesterSenderId entrante de confianza

• outbound.sendPoll es la base compartida para canales que encajan en el modelo común de encuestas
• actions.handleAction("poll") es la ruta preferida para la semántica de encuestas específica del canal o parámetros adicionales de encuestas

​

Modelo de propiedad de capacidades

• un plugin de empresa normalmente debe ser propietario de todas las superficies de OpenClaw orientadas a esa empresa
• un plugin de función normalmente debe ser propietario de la superficie completa de la función que introduce
• los canales deben consumir capacidades compartidas del core en lugar de volver a implementar comportamiento de proveedor de forma ad hoc

• el plugin agrupado openai es propietario del comportamiento del proveedor de modelos de OpenAI y del comportamiento de OpenAI de voz + voz en tiempo real + comprensión de medios + generación de imágenes
• el plugin agrupado elevenlabs es propietario del comportamiento de voz de ElevenLabs
• el plugin agrupado microsoft es propietario del comportamiento de voz de Microsoft
• el plugin agrupado google es propietario del comportamiento del proveedor de modelos de Google más el comportamiento de Google de comprensión de medios + generación de imágenes + búsqueda web
• el plugin agrupado firecrawl es propietario del comportamiento de obtención web de Firecrawl
• los plugins agrupados minimax, mistral, moonshot y zai son propietarios de sus backends de comprensión de medios
• el plugin agrupado qwen es propietario del comportamiento del proveedor de texto de Qwen más el comportamiento de comprensión de medios y generación de video
• el plugin voice-call es un plugin de función: es propietario del transporte de llamadas, herramientas, CLI, rutas y el puente de flujo de medios de Twilio, pero consume capacidades compartidas de voz más transcripción en tiempo real y voz en tiempo real en lugar de importar directamente plugins de proveedor

• OpenAI vive en un solo plugin aunque abarque modelos de texto, voz, imágenes y video futuro
• otro proveedor puede hacer lo mismo para su propia área de superficie
• los canales no se preocupan por qué plugin del proveedor es propietario del proveedor; consumen el contrato de capacidad compartida expuesto por el core

• plugin = límite de propiedad
• capacidad = contrato del core que múltiples plugins pueden implementar o consumir

1. definir la capacidad faltante en el core
2. exponerla a través de la API/tiempo de ejecución del plugin de forma tipada
3. conectar canales/funciones a esa capacidad
4. dejar que los plugins de proveedor registren implementaciones

​

Capas de capacidades

• capa de capacidades del core: orquestación compartida, política, fallback, reglas de combinación de configuración, semántica de entrega y contratos tipados
• capa de plugins de proveedor: APIs específicas del proveedor, autenticación, catálogos de modelos, síntesis de voz, generación de imágenes, futuros backends de video, endpoints de uso
• capa de plugins de canal/función: integración con Slack/Discord/voice-call/etc. que consume capacidades del core y las presenta en una superficie

• el core es propietario de la política de TTS en el momento de la respuesta, el orden de fallback, las preferencias y la entrega por canal
• openai, elevenlabs y microsoft son propietarios de las implementaciones de síntesis
• voice-call consume el asistente de tiempo de ejecución de TTS para telefonía

​

Ejemplo de plugin de empresa con múltiples capacidades

import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
import {
  describeImageWithModel,
  transcribeOpenAiCompatibleAudio,
} from "openclaw/plugin-sdk/media-understanding";

const plugin: OpenClawPluginDefinition = {
  id: "exampleai",
  name: "ExampleAI",
  register(api) {
    api.registerProvider({
      id: "exampleai",
      // auth/model catalog/runtime hooks
    });

    api.registerSpeechProvider({
      id: "exampleai",
      // vendor speech config — implement the SpeechProviderPlugin interface directly
    });

    api.registerMediaUnderstandingProvider({
      id: "exampleai",
      capabilities: ["image", "audio", "video"],
      async describeImage(req) {
        return describeImageWithModel({
          provider: "exampleai",
          model: req.model,
          input: req.input,
        });
      },
      async transcribeAudio(req) {
        return transcribeOpenAiCompatibleAudio({
          provider: "exampleai",
          model: req.model,
          input: req.input,
        });
      },
    });

    api.registerWebSearchProvider(
      createPluginBackedWebSearchProvider({
        id: "exampleai-search",
        // credential + fetch logic
      }),
    );
  },
};

export default plugin;

• un solo plugin es propietario de la superficie del proveedor
• el core sigue siendo propietario de los contratos de capacidad
• los plugins de canal y de función consumen asistentes api.runtime.*, no código del proveedor
• las pruebas de contrato pueden afirmar que el plugin registró las capacidades de las que dice ser propietario

​

Ejemplo de capacidad: comprensión de video

1. el core define el contrato de comprensión de medios
2. los plugins de proveedor registran describeImage, transcribeAudio y describeVideo según corresponda
3. los plugins de canal y de función consumen el comportamiento compartido del core en lugar de conectarse directamente al código del proveedor

​

Contratos y cumplimiento

• los autores de plugins obtienen un estándar interno estable
• el core puede rechazar propiedad duplicada, como dos plugins que registran el mismo id de proveedor
• el inicio puede mostrar diagnósticos accionables para registros malformados
• las pruebas de contrato pueden aplicar la propiedad de plugins agrupados y evitar desvíos silenciosos

1. cumplimiento de registro en tiempo de ejecución El registro de plugins valida los registros a medida que se cargan los plugins. Ejemplos: id de proveedor duplicados, id de proveedor de voz duplicados y registros malformados producen diagnósticos de plugin en lugar de comportamiento indefinido.
2. pruebas de contrato Los plugins agrupados se capturan en registros de contrato durante las ejecuciones de prueba para que OpenClaw pueda afirmar explícitamente la propiedad. Hoy esto se usa para proveedores de modelos, proveedores de voz, proveedores de búsqueda web y propiedad de registro agrupado.

​

Qué pertenece a un contrato

• tipados
• pequeños
• específicos de capacidades
• propiedad del core
• reutilizables por múltiples plugins
• consumibles por canales/funciones sin conocimiento del proveedor

• política específica del proveedor oculta en el core
• vías de escape puntuales de plugins que evitan el registro
• código de canal que entra directamente en una implementación del proveedor
• objetos ad hoc de tiempo de ejecución que no forman parte de OpenClawPluginApi ni de api.runtime

​

Modelo de ejecución

• un plugin nativo puede registrar herramientas, controladores de red, hooks y servicios
• un error en un plugin nativo puede bloquear o desestabilizar el gateway
• un plugin nativo malicioso equivale a ejecución arbitraria de código dentro del proceso de OpenClaw

• plugins.allow confía en ids de plugin, no en la procedencia del origen.
• Un plugin del workspace con el mismo id que un plugin agrupado sombrea intencionadamente la copia agrupada cuando ese plugin del workspace está habilitado/en la allowlist.
• Esto es normal y útil para desarrollo local, pruebas de parches y hotfixes.

​

Límite de exportación

• subpaths auxiliares específicos de plugins agrupados
• subpaths de plomería de tiempo de ejecución no pensados como API pública
• asistentes de conveniencia específicos del proveedor
• asistentes de configuración/incorporación que son detalles de implementación

​

Canalización de carga

1. descubre raíces candidatas de plugins
2. lee manifests nativos o de bundles compatibles y metadatos de paquetes
3. rechaza candidatos inseguros
4. normaliza la configuración de plugins (plugins.enabled, allow, deny, entries, slots, load.paths)
5. decide la habilitación de cada candidato
6. carga módulos nativos habilitados mediante jiti
7. llama a los hooks nativos register(api) (o activate(api) — un alias heredado) y recopila los registros en el registro de plugins
8. expone el registro a las superficies de comandos/tiempo de ejecución

​

Comportamiento centrado en el manifest

• identificar el plugin
• descubrir canales/Skills/esquema de configuración declarados o capacidades del bundle
• validar plugins.entries.<id>.config
• ampliar etiquetas/placeholders de Control UI
• mostrar metadatos de instalación/catálogo
• preservar descriptores económicos de activación y configuración sin cargar el tiempo de ejecución del plugin

​

Qué almacena en caché el cargador

• resultados de descubrimiento
• datos del registro de manifests
• registros de plugins cargados

• Establece OPENCLAW_DISABLE_PLUGIN_DISCOVERY_CACHE=1 o OPENCLAW_DISABLE_PLUGIN_MANIFEST_CACHE=1 para desactivar estas cachés.
• Ajusta las ventanas de caché con OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS y OPENCLAW_PLUGIN_MANIFEST_CACHE_MS.

​

Modelo de registro

• registros de plugins (identidad, origen, procedencia, estado, diagnósticos)
• herramientas
• hooks heredados y hooks tipados
• canales
• proveedores
• controladores RPC del gateway
• rutas HTTP
• registradores de CLI
• servicios en segundo plano
• comandos propiedad del plugin

• módulo del plugin -> registro en el registro
• tiempo de ejecución del core -> consumo del registro

​

Callbacks de asociación de conversaciones

export default {
  id: "my-plugin",
  register(api) {
    api.onConversationBindingResolved(async (event) => {
      if (event.status === "approved") {
        // A binding now exists for this plugin + conversation.
        console.log(event.binding?.conversationId);
        return;
      }

      // The request was denied; clear any local pending state.
      console.log(event.request.conversation.conversationId);
    });
  },
};

• status: "approved" o "denied"
• decision: "allow-once", "allow-always" o "deny"
• binding: la asociación resuelta para solicitudes aprobadas
• request: el resumen de la solicitud original, sugerencia de desvinculación, id del remitente y metadatos de la conversación

​

Hooks de tiempo de ejecución del proveedor

• metadatos del manifest: providerAuthEnvVars para búsquedas económicas de autenticación del proveedor mediante variables de entorno antes de cargar el tiempo de ejecución, providerAuthAliases para variantes de proveedor que comparten autenticación, channelEnvVars para búsquedas económicas de entorno/configuración del canal antes de la carga del tiempo de ejecución, además de providerAuthChoices para etiquetas económicas de incorporación/opciones de autenticación y metadatos de flags de CLI antes de cargar el tiempo de ejecución
• hooks en tiempo de configuración: catalog / discovery heredado más applyConfigDefaults
• hooks de tiempo de ejecución: normalizeModelId, normalizeTransport, normalizeConfig, applyNativeStreamingUsageCompat, resolveConfigApiKey, resolveSyntheticAuth, resolveExternalAuthProfiles, shouldDeferSyntheticProfileAuth, resolveDynamicModel, prepareDynamicModel, normalizeResolvedModel, contributeResolvedModelCompat, capabilities, normalizeToolSchemas, inspectToolSchemas, resolveReasoningOutputMode, prepareExtraParams, createStreamFn, wrapStreamFn, resolveTransportTurnState, resolveWebSocketSessionPolicy, formatApiKey, refreshOAuth, buildAuthDoctorHint, matchesContextOverflowError, classifyFailoverReason, isCacheTtlEligible, buildMissingAuthMessage, suppressBuiltInModel, augmentModelCatalog, isBinaryThinking, supportsXHighThinking, resolveDefaultThinkingLevel, isModernModelRef, prepareRuntimeAuth, resolveUsageAuth, fetchUsageSnapshot, createEmbeddingProvider, buildReplayPolicy, sanitizeReplayHistory, validateReplayTurns, onModelSelected

​

Orden y uso de hooks

​

Ejemplo de proveedor

api.registerProvider({
  id: "example-proxy",
  label: "Example Proxy",
  auth: [],
  catalog: {
    order: "simple",
    run: async (ctx) => {
      const apiKey = ctx.resolveProviderApiKey("example-proxy").apiKey;
      if (!apiKey) {
        return null;
      }
      return {
        provider: {
          baseUrl: "https://proxy.example.com/v1",
          apiKey,
          api: "openai-completions",
          models: [{ id: "auto", name: "Auto" }],
        },
      };
    },
  },
  resolveDynamicModel: (ctx) => ({
    id: ctx.modelId,
    name: ctx.modelId,
    provider: "example-proxy",
    api: "openai-completions",
    baseUrl: "https://proxy.example.com/v1",
    reasoning: false,
    input: ["text"],
    cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
    contextWindow: 128000,
    maxTokens: 8192,
  }),
  prepareRuntimeAuth: async (ctx) => {
    const exchanged = await exchangeToken(ctx.apiKey);
    return {
      apiKey: exchanged.token,
      baseUrl: exchanged.baseUrl,
      expiresAt: exchanged.expiresAt,
    };
  },
  resolveUsageAuth: async (ctx) => {
    const auth = await ctx.resolveOAuthToken();
    return auth ? { token: auth.token } : null;
  },
  fetchUsageSnapshot: async (ctx) => {
    return await fetchExampleProxyUsage(ctx.token, ctx.timeoutMs, ctx.fetchFn);
  },
});

​

Ejemplos integrados

• Anthropic usa resolveDynamicModel, capabilities, buildAuthDoctorHint, resolveUsageAuth, fetchUsageSnapshot, isCacheTtlEligible, resolveDefaultThinkingLevel, applyConfigDefaults, isModernModelRef y wrapStreamFn porque es propietario de la compatibilidad futura de Claude 4.6, de las sugerencias de familia de proveedor, de la guía de reparación de autenticación, de la integración del endpoint de uso, de la elegibilidad de caché de prompts, de los valores predeterminados de configuración conscientes de autenticación, de la política predeterminada/adaptativa de pensamiento de Claude y del modelado de stream específico de Anthropic para encabezados beta, /fast / serviceTier y context1m.
• Los asistentes de stream específicos de Claude de Anthropic permanecen por ahora en el seam público propio api.ts / contract-api.ts del plugin agrupado. Esa superficie del paquete exporta wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier y los builders de wrappers de Anthropic de más bajo nivel en lugar de ampliar el SDK genérico en torno a las reglas de encabezados beta de un solo proveedor.
• OpenAI usa resolveDynamicModel, normalizeResolvedModel y capabilities, además de buildMissingAuthMessage, suppressBuiltInModel, augmentModelCatalog, supportsXHighThinking e isModernModelRef porque es propietario de la compatibilidad futura de GPT-5.4, de la normalización directa de OpenAI openai-completions -> openai-responses, de las sugerencias de autenticación conscientes de Codex, de la supresión de Spark, de las filas sintéticas de lista de OpenAI y de la política de pensamiento/modelo en vivo de GPT-5; la familia de streams openai-responses-defaults es propietaria de los wrappers compartidos nativos de OpenAI Responses para encabezados de atribución, /fast/serviceTier, verbosidad de texto, búsqueda web nativa de Codex, modelado de carga útil compatible con razonamiento y gestión del contexto de Responses.
• OpenRouter usa catalog, además de resolveDynamicModel y prepareDynamicModel, porque el proveedor es de paso y puede exponer nuevos ids de modelo antes de que se actualice el catálogo estático de OpenClaw; también usa capabilities, wrapStreamFn e isCacheTtlEligible para mantener fuera del core los encabezados de solicitud específicos del proveedor, los metadatos de enrutamiento, los parches de razonamiento y la política de caché de prompts. Su política de replay proviene de la familia passthrough-gemini, mientras que la familia de streams openrouter-thinking es propietaria de la inyección de razonamiento proxy y de las omisiones de modelos no compatibles / auto.
• GitHub Copilot usa catalog, auth, resolveDynamicModel y capabilities, además de prepareRuntimeAuth y fetchUsageSnapshot, porque necesita inicio de sesión de dispositivo propiedad del proveedor, comportamiento de fallback de modelo, particularidades de transcripción de Claude, un intercambio de token de GitHub -> token de Copilot y un endpoint de uso propiedad del proveedor.
• OpenAI Codex usa catalog, resolveDynamicModel, normalizeResolvedModel, refreshOAuth y augmentModelCatalog, además de prepareExtraParams, resolveUsageAuth y fetchUsageSnapshot, porque sigue ejecutándose sobre los transportes centrales de OpenAI, pero es propietario de su normalización de transporte/base URL, de la política de fallback de actualización de OAuth, de la elección de transporte predeterminada, de las filas sintéticas de catálogo de Codex y de la integración del endpoint de uso de ChatGPT; comparte la misma familia de streams openai-responses-defaults que OpenAI directo.
• Google AI Studio y Gemini CLI OAuth usan resolveDynamicModel, buildReplayPolicy, sanitizeReplayHistory, resolveReasoningOutputMode, wrapStreamFn e isModernModelRef porque la familia de replay google-gemini es propietaria del fallback de compatibilidad futura de Gemini 3.1, de la validación nativa de replay de Gemini, de la sanitización de replay de bootstrap, del modo de salida de razonamiento etiquetado y de la coincidencia de modelos modernos, mientras que la familia de streams google-thinking es propietaria de la normalización de la carga útil de pensamiento de Gemini; Gemini CLI OAuth también usa formatApiKey, resolveUsageAuth y fetchUsageSnapshot para el formateo de tokens, el análisis de tokens y la conexión del endpoint de cuota.
• Anthropic Vertex usa buildReplayPolicy a través de la familia de replay anthropic-by-model para que la limpieza de replay específica de Claude quede acotada a ids de Claude en lugar de a cada transporte anthropic-messages.
• Amazon Bedrock usa buildReplayPolicy, matchesContextOverflowError, classifyFailoverReason y resolveDefaultThinkingLevel porque es propietario de la clasificación de errores específicos de Bedrock de limitación/no listo/desbordamiento de contexto para tráfico Anthropic-on-Bedrock; su política de replay sigue compartiendo la misma protección solo para Claude anthropic-by-model.
• OpenRouter, Kilocode, Opencode y Opencode Go usan buildReplayPolicy a través de la familia de replay passthrough-gemini porque hacen proxy de modelos Gemini mediante transportes compatibles con OpenAI y necesitan sanitización de firmas de pensamiento de Gemini sin validación nativa de replay de Gemini ni reescrituras de bootstrap.
• MiniMax usa buildReplayPolicy a través de la familia de replay hybrid-anthropic-openai porque un solo proveedor es propietario tanto de semántica de mensajes Anthropic como de compatibilidad con OpenAI; mantiene la eliminación de bloques de pensamiento exclusivos de Claude en el lado Anthropic mientras reemplaza el modo de salida de razonamiento de vuelta a nativo, y la familia de streams minimax-fast-mode es propietaria de las reescrituras de modelos de modo rápido en la ruta de stream compartida.
• Moonshot usa catalog, además de wrapStreamFn, porque sigue usando el transporte compartido de OpenAI pero necesita normalización de carga útil de pensamiento propiedad del proveedor; la familia de streams moonshot-thinking asigna config más estado /think a su carga útil nativa de pensamiento binario.
• Kilocode usa catalog, capabilities, wrapStreamFn e isCacheTtlEligible porque necesita encabezados de solicitud propiedad del proveedor, normalización de carga útil de razonamiento, sugerencias de transcripción de Gemini y control de TTL de caché de Anthropic; la familia de streams kilocode-thinking mantiene la inyección de pensamiento de Kilo en la ruta de stream proxy compartida mientras omite kilo/auto y otros ids de modelo proxy que no admiten cargas útiles explícitas de razonamiento.
• Z.AI usa resolveDynamicModel, prepareExtraParams, wrapStreamFn, isCacheTtlEligible, isBinaryThinking, isModernModelRef, resolveUsageAuth y fetchUsageSnapshot porque es propietario del fallback de GLM-5, de los valores predeterminados de tool_stream, de la UX de pensamiento binario, de la coincidencia de modelos modernos y tanto de la autenticación de uso como de la obtención de cuota; la familia de streams tool-stream-default-on mantiene el wrapper predeterminado activado tool_stream fuera del pegamento manuscrito por proveedor.
• xAI usa normalizeResolvedModel, normalizeTransport, contributeResolvedModelCompat, prepareExtraParams, wrapStreamFn, resolveSyntheticAuth, resolveDynamicModel e isModernModelRef porque es propietario de la normalización nativa de transporte xAI Responses, de las reescrituras de alias de modo rápido de Grok, del valor predeterminado tool_stream, de la limpieza estricta de herramientas / carga útil de razonamiento, de la reutilización de autenticación de fallback para herramientas propiedad del plugin, de la resolución de modelos Grok con compatibilidad futura y de parches de compatibilidad propiedad del proveedor, como el perfil de esquema de herramientas de xAI, palabras clave de esquema no compatibles, web_search nativo y la decodificación de argumentos de llamadas a herramientas con entidades HTML.
• Mistral, OpenCode Zen y OpenCode Go usan solo capabilities para mantener fuera del core las particularidades de transcripción/herramientas.
• Los proveedores agrupados solo de catálogo como byteplus, cloudflare-ai-gateway, huggingface, kimi-coding, nvidia, qianfan, synthetic, together, venice, vercel-ai-gateway y volcengine usan solo catalog.
• Qwen usa catalog para su proveedor de texto, además de registros compartidos de comprensión de medios y generación de video para sus superficies multimodales.
• MiniMax y Xiaomi usan catalog, además de hooks de uso, porque su comportamiento /usage es propiedad del plugin aunque la inferencia siga ejecutándose a través de los transportes compartidos.

​

Asistentes de tiempo de ejecución

const clip = await api.runtime.tts.textToSpeech({
  text: "Hello from OpenClaw",
  cfg: api.config,
});

const result = await api.runtime.tts.textToSpeechTelephony({
  text: "Hello from OpenClaw",
  cfg: api.config,
});

const voices = await api.runtime.tts.listVoices({
  provider: "elevenlabs",
  cfg: api.config,
});

• textToSpeech devuelve la carga útil de salida TTS normal del core para superficies de archivo/nota de voz.
• Usa la configuración del core messages.tts y la selección de proveedor.
• Devuelve buffer de audio PCM + frecuencia de muestreo. Los plugins deben remuestrear/codificar para los proveedores.
• listVoices es opcional por proveedor. Úsalo para selectores de voz o flujos de configuración propiedad del proveedor.
• Los listados de voces pueden incluir metadatos más ricos como configuración regional, género y etiquetas de personalidad para selectores conscientes del proveedor.
• OpenAI y ElevenLabs admiten telefonía hoy. Microsoft no.

api.registerSpeechProvider({
  id: "acme-speech",
  label: "Acme Speech",
  isConfigured: ({ config }) => Boolean(config.messages?.tts),
  synthesize: async (req) => {
    return {
      audioBuffer: Buffer.from([]),
      outputFormat: "mp3",
      fileExtension: ".mp3",
      voiceCompatible: false,
    };
  },
});

• Mantén la política de TTS, el fallback y la entrega de respuestas en el core.
• Usa proveedores de voz para comportamiento de síntesis propiedad del proveedor.
• La entrada heredada edge de Microsoft se normaliza al id de proveedor microsoft.
• El modelo de propiedad preferido está orientado por empresa: un solo plugin de proveedor puede ser propietario de texto, voz, imagen y futuros proveedores de medios a medida que OpenClaw agregue esos contratos de capacidad.

api.registerMediaUnderstandingProvider({
  id: "google",
  capabilities: ["image", "audio", "video"],
  describeImage: async (req) => ({ text: "..." }),
  transcribeAudio: async (req) => ({ text: "..." }),
  describeVideo: async (req) => ({ text: "..." }),
});

• Mantén la orquestación, el fallback, la configuración y la conexión con canales en el core.
• Mantén el comportamiento del proveedor en el plugin del proveedor.
• La expansión aditiva debe seguir siendo tipada: nuevos métodos opcionales, nuevos campos opcionales de resultado, nuevas capacidades opcionales.
• La generación de video ya sigue el mismo patrón:
  • el core es propietario del contrato de capacidad y del asistente de tiempo de ejecución
  • los plugins de proveedor registran api.registerVideoGenerationProvider(...)
  • los plugins de función/canal consumen api.runtime.videoGeneration.*

const image = await api.runtime.mediaUnderstanding.describeImageFile({
  filePath: "/tmp/inbound-photo.jpg",
  cfg: api.config,
  agentDir: "/tmp/agent",
});

const video = await api.runtime.mediaUnderstanding.describeVideoFile({
  filePath: "/tmp/inbound-video.mp4",
  cfg: api.config,
});

const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
  filePath: "/tmp/inbound-audio.ogg",
  cfg: api.config,
  // Optional when MIME cannot be inferred reliably:
  mime: "audio/ogg",
});

• api.runtime.mediaUnderstanding.* es la superficie compartida preferida para comprensión de imagen/audio/video.
• Usa la configuración de audio de comprensión de medios del core (tools.media.audio) y el orden de fallback del proveedor.
• Devuelve { text: undefined } cuando no se produce salida de transcripción (por ejemplo, entrada omitida/no compatible).
• api.runtime.stt.transcribeAudioFile(...) permanece como alias de compatibilidad.

const result = await api.runtime.subagent.run({
  sessionKey: "agent:main:subagent:search-helper",
  message: "Expand this query into focused follow-up searches.",
  provider: "openai",
  model: "gpt-4.1-mini",
  deliver: false,
});

• provider y model son reemplazos opcionales por ejecución, no cambios persistentes de sesión.
• OpenClaw solo respeta esos campos de reemplazo para llamadores de confianza.
• Para ejecuciones de fallback propiedad del plugin, los operadores deben habilitarlo explícitamente con plugins.entries.<id>.subagent.allowModelOverride: true.
• Usa plugins.entries.<id>.subagent.allowedModels para restringir los plugins de confianza a objetivos canónicos específicos provider/model, o "*" para permitir explícitamente cualquier objetivo.
• Las ejecuciones de subagentes de plugins no confiables siguen funcionando, pero las solicitudes de reemplazo se rechazan en lugar de recurrir silenciosamente al fallback.

const providers = api.runtime.webSearch.listProviders({
  config: api.config,
});

const result = await api.runtime.webSearch.search({
  config: api.config,
  args: {
    query: "OpenClaw plugin runtime helpers",
    count: 5,
  },
});

• Mantén en el core la selección de proveedor, la resolución de credenciales y la semántica compartida de solicitudes.
• Usa proveedores de búsqueda web para transportes de búsqueda específicos del proveedor.
• api.runtime.webSearch.* es la superficie compartida preferida para plugins de función/canal que necesitan comportamiento de búsqueda sin depender del wrapper de la herramienta del agente.

​

api.runtime.imageGeneration

const result = await api.runtime.imageGeneration.generate({
  config: api.config,
  args: { prompt: "A friendly lobster mascot", size: "1024x1024" },
});

const providers = api.runtime.imageGeneration.listProviders({
  config: api.config,
});

• generate(...): genera una imagen usando la cadena configurada de proveedores de generación de imágenes.
• listProviders(...): enumera los proveedores de generación de imágenes disponibles y sus capacidades.

​

Rutas HTTP del Gateway

api.registerHttpRoute({
  path: "/acme/webhook",
  auth: "plugin",
  match: "exact",
  handler: async (_req, res) => {
    res.statusCode = 200;
    res.end("ok");
    return true;
  },
});

• path: ruta bajo el servidor HTTP del gateway.
• auth: obligatorio. Usa "gateway" para requerir autenticación normal del gateway, o "plugin" para autenticación/verificación de webhook administrada por el plugin.
• match: opcional. "exact" (predeterminado) o "prefix".
• replaceExisting: opcional. Permite que el mismo plugin reemplace su propio registro de ruta existente.
• handler: devuelve true cuando la ruta manejó la solicitud.

• api.registerHttpHandler(...) fue eliminado y causará un error de carga del plugin. Usa api.registerHttpRoute(...) en su lugar.
• Las rutas de plugins deben declarar auth explícitamente.
• Los conflictos exactos de path + match se rechazan salvo que replaceExisting: true, y un plugin no puede reemplazar la ruta de otro plugin.
• Las rutas superpuestas con diferentes niveles de auth se rechazan. Mantén las cadenas de continuidad exact/prefix solo en el mismo nivel de autenticación.
• Las rutas auth: "plugin" no reciben automáticamente ámbitos de tiempo de ejecución del operador. Son para webhooks/verificación de firmas administrados por el plugin, no para llamadas auxiliares privilegiadas del Gateway.
• Las rutas auth: "gateway" se ejecutan dentro de un ámbito de tiempo de ejecución de solicitud del Gateway, pero ese ámbito es intencionalmente conservador:
  • la autenticación bearer de secreto compartido (gateway.auth.mode = "token" / "password") mantiene los ámbitos de tiempo de ejecución de rutas de plugin fijados en operator.write, incluso si quien llama envía x-openclaw-scopes
  • los modos HTTP confiables con identidad (por ejemplo trusted-proxy o gateway.auth.mode = "none" en un ingreso privado) respetan x-openclaw-scopes solo cuando el encabezado está presente explícitamente
  • si x-openclaw-scopes no está presente en esas solicitudes de ruta de plugin con identidad, el ámbito de tiempo de ejecución vuelve a operator.write
• Regla práctica: no asumas que una ruta de plugin con autenticación de gateway es implícitamente una superficie de administrador. Si tu ruta necesita comportamiento exclusivo de administrador, exige un modo de autenticación con identidad y documenta el contrato explícito del encabezado x-openclaw-scopes.

​

Rutas de importación del SDK de plugins

• openclaw/plugin-sdk/plugin-entry para primitivas de registro de plugins.
• openclaw/plugin-sdk/core para el contrato genérico compartido orientado a plugins.
• openclaw/plugin-sdk/config-schema para la exportación del esquema Zod raíz de openclaw.json (OpenClawSchema).
• Primitivas estables de canal como openclaw/plugin-sdk/channel-setup, openclaw/plugin-sdk/setup-runtime, openclaw/plugin-sdk/setup-adapter-runtime, openclaw/plugin-sdk/setup-tools, openclaw/plugin-sdk/channel-pairing, openclaw/plugin-sdk/channel-contract, openclaw/plugin-sdk/channel-feedback, openclaw/plugin-sdk/channel-inbound, openclaw/plugin-sdk/channel-lifecycle, openclaw/plugin-sdk/channel-reply-pipeline, openclaw/plugin-sdk/command-auth, openclaw/plugin-sdk/secret-input y openclaw/plugin-sdk/webhook-ingress para la integración compartida de configuración/autenticación/respuesta/webhook. channel-inbound es el hogar compartido para debounce, coincidencia de menciones, asistentes de política de menciones entrantes, formato de sobres y asistentes de contexto de sobres entrantes. channel-setup es el seam acotado de configuración de instalación opcional. setup-runtime es la superficie de configuración segura en tiempo de ejecución usada por setupEntry / inicio diferido, incluidos los adaptadores de parche de configuración seguros para importación. setup-adapter-runtime es el seam de adaptador de configuración de cuentas sensible al entorno. setup-tools es el seam pequeño de asistentes de CLI/archivo/docs (formatCliCommand, detectBinary, extractArchive, resolveBrewExecutable, formatDocsLink, CONFIG_DIR).
• Subpaths de dominio como openclaw/plugin-sdk/channel-config-helpers, openclaw/plugin-sdk/allow-from, openclaw/plugin-sdk/channel-config-schema, openclaw/plugin-sdk/telegram-command-config, openclaw/plugin-sdk/channel-policy, openclaw/plugin-sdk/approval-gateway-runtime, openclaw/plugin-sdk/approval-handler-adapter-runtime, openclaw/plugin-sdk/approval-handler-runtime, openclaw/plugin-sdk/approval-runtime, openclaw/plugin-sdk/config-runtime, openclaw/plugin-sdk/infra-runtime, openclaw/plugin-sdk/agent-runtime, openclaw/plugin-sdk/lazy-runtime, openclaw/plugin-sdk/reply-history, openclaw/plugin-sdk/routing, openclaw/plugin-sdk/status-helpers, openclaw/plugin-sdk/text-runtime, openclaw/plugin-sdk/runtime-store y openclaw/plugin-sdk/directory-runtime para asistentes compartidos de tiempo de ejecución/configuración. telegram-command-config es el seam público acotado para la normalización/validación de comandos personalizados de Telegram y sigue disponible aunque la superficie de contrato agrupada de Telegram no esté disponible temporalmente. text-runtime es el seam compartido de texto/markdown/logging, que incluye eliminación de texto visible para el asistente, asistentes de renderizado/fragmentación de markdown, asistentes de redacción, asistentes de etiquetas de directivas y utilidades de texto seguro.
• Los seams de canal específicos de aprobación deben preferir un único contrato approvalCapability en el plugin. Luego el core lee autenticación, entrega, renderizado, enrutamiento nativo y comportamiento diferido del controlador nativo a través de esa única capacidad en lugar de mezclar comportamiento de aprobación en campos no relacionados del plugin.
• openclaw/plugin-sdk/channel-runtime está obsoleto y permanece solo como un shim de compatibilidad para plugins antiguos. El código nuevo debe importar las primitivas genéricas más acotadas en su lugar, y el código del repo no debe agregar nuevas importaciones del shim.
• Los internos de extensiones agrupadas siguen siendo privados. Los plugins externos deben usar solo subpaths openclaw/plugin-sdk/*. El código core/de prueba de OpenClaw puede usar los puntos de entrada públicos del repo bajo la raíz de un paquete de plugin como index.js, api.js, runtime-api.js, setup-entry.js y archivos de alcance reducido como login-qr-api.js. Nunca importes src/* de un paquete de plugin desde el core ni desde otra extensión.
• División de puntos de entrada del repo: <plugin-package-root>/api.js es el barril de asistentes/tipos, <plugin-package-root>/runtime-api.js es el barril solo de tiempo de ejecución, <plugin-package-root>/index.js es el punto de entrada del plugin agrupado, y <plugin-package-root>/setup-entry.js es el punto de entrada del plugin de configuración.
• Ejemplos actuales de proveedores agrupados:
  • Anthropic usa api.js / contract-api.js para asistentes de stream de Claude como wrapAnthropicProviderStream, asistentes de encabezados beta y análisis de service_tier.
  • OpenAI usa api.js para builders de proveedores, asistentes de modelo predeterminado y builders de proveedores en tiempo real.
  • OpenRouter usa api.js para su builder de proveedor más asistentes de incorporación/configuración, mientras register.runtime.js puede seguir reexportando asistentes genéricos plugin-sdk/provider-stream para uso local del repo.
• Los puntos de entrada públicos cargados por fachada prefieren la instantánea de configuración activa de tiempo de ejecución cuando existe una; luego recurren al archivo de configuración resuelto en disco cuando OpenClaw aún no está sirviendo una instantánea de tiempo de ejecución.
• Las primitivas genéricas compartidas siguen siendo el contrato público preferido del SDK. Aún existe un pequeño conjunto de compatibilidad reservado de seams auxiliares de canal con marca agrupada. Trátalos como seams de mantenimiento/compatibilidad agrupados, no como nuevos objetivos de importación para terceros; los nuevos contratos entre canales deben seguir llegando a subpaths genéricos plugin-sdk/* o a los barriles locales del plugin api.js / runtime-api.js.

• Evita el barril raíz openclaw/plugin-sdk en código nuevo.
• Prefiere primero las primitivas estables y acotadas. Los subpaths más recientes de configuración/asociación/respuesta/ feedback/contrato/entrada/hilos/comando/secret-input/webhook/infra/ allowlist/status/message-tool son el contrato previsto para trabajo nuevo con plugins agrupados y externos. El análisis/coincidencia de objetivos pertenece a openclaw/plugin-sdk/channel-targets. Las compuertas de acciones de mensajes y los asistentes de id de mensaje para reacciones pertenecen a openclaw/plugin-sdk/channel-actions.
• Los barriles auxiliares específicos de extensiones agrupadas no son estables de forma predeterminada. Si un asistente solo lo necesita una extensión agrupada, mantenlo detrás del seam local api.js o runtime-api.js de la extensión en lugar de promoverlo a openclaw/plugin-sdk/<extension>.
• Los nuevos seams de asistentes compartidos deben ser genéricos, no de marca de canal. El análisis compartido de objetivos pertenece a openclaw/plugin-sdk/channel-targets; los internos específicos del canal permanecen detrás del seam local api.js o runtime-api.js del plugin propietario.
• Subpaths específicos de capacidades como image-generation, media-understanding y speech existen porque los plugins agrupados/nativos los usan hoy. Su presencia no significa por sí sola que cada asistente exportado sea un contrato externo congelado a largo plazo.

​

Esquemas de la herramienta de mensajes

• createMessageToolButtonsSchema() para cargas útiles de estilo cuadrícula de botones
• createMessageToolCardSchema() para cargas útiles de tarjeta estructurada

​

Resolución de objetivos de canal

• messaging.inferTargetChatType({ to }) decide si un objetivo normalizado debe tratarse como direct, group o channel antes de la búsqueda en directorio.
• messaging.targetResolver.looksLikeId(raw, normalized) le dice al core si una entrada debe ir directamente a resolución tipo id en lugar de búsqueda en directorio.
• messaging.targetResolver.resolveTarget(...) es el fallback del plugin cuando el core necesita una resolución final propiedad del proveedor tras la normalización o tras un fallo en el directorio.
• messaging.resolveOutboundSessionRoute(...) es propietario de la construcción específica del proveedor de rutas de sesión de salida una vez que se resuelve un objetivo.

• Usa inferTargetChatType para decisiones de categoría que deban ocurrir antes de buscar pares/grupos.
• Usa looksLikeId para comprobaciones de “tratar esto como un id de objetivo explícito/nativo”.
• Usa resolveTarget para fallback de normalización específico del proveedor, no para búsqueda amplia en directorio.
• Mantén ids nativos del proveedor como ids de chat, ids de hilo, JID, handles e ids de sala dentro de valores target o parámetros específicos del proveedor, no en campos genéricos del SDK.

​

Directorios respaldados por configuración

• pares de DM controlados por allowlist
• mapas configurados de canal/grupo
• fallbacks estáticos de directorio con alcance por cuenta

• filtrado de consultas
• aplicación de límites
• asistentes de deduplicación/normalización
• construcción de ChannelDirectoryEntry[]

​

Catálogos de proveedores

• { provider } para una entrada de proveedor
• { providers } para múltiples entradas de proveedor

• simple: proveedores simples con clave API o impulsados por entorno
• profile: proveedores que aparecen cuando existen perfiles de autenticación
• paired: proveedores que sintetizan múltiples entradas de proveedor relacionadas
• late: pasada final, después de otros proveedores implícitos

• discovery sigue funcionando como alias heredado
• si se registran catalog y discovery, OpenClaw usa catalog

​

Inspección de canal de solo lectura

• resolveAccount(...) es la ruta de tiempo de ejecución. Puede asumir que las credenciales están completamente materializadas y puede fallar rápidamente cuando faltan secretos requeridos.
• Las rutas de comandos de solo lectura como openclaw status, openclaw status --all, openclaw channels status, openclaw channels resolve y los flujos de doctor/reparación de configuración no deberían necesitar materializar credenciales de tiempo de ejecución solo para describir la configuración.

• Devuelve solo el estado descriptivo de la cuenta.
• Conserva enabled y configured.
• Incluye campos de origen/estado de credenciales cuando sea relevante, como:
  • tokenSource, tokenStatus
  • botTokenSource, botTokenStatus
  • appTokenSource, appTokenStatus
  • signingSecretSource, signingSecretStatus
• No necesitas devolver valores de token sin procesar solo para informar disponibilidad de solo lectura. Devolver tokenStatus: "available" (y el campo de origen correspondiente) es suficiente para comandos de tipo estado.
• Usa configured_unavailable cuando una credencial esté configurada mediante SecretRef pero no disponible en la ruta actual del comando.

​

Paquetes agrupadores

{
  "name": "my-pack",
  "openclaw": {
    "extensions": ["./src/safety.ts", "./src/tools.ts"],
    "setupEntry": "./src/setup-entry.ts"
  }
}

• el propio registro del canal
• cualquier ruta HTTP que deba estar disponible antes de que el gateway empiece a escuchar
• cualquier método, herramienta o servicio del gateway que deba existir durante esa misma ventana

• singleAccountKeysToMove
• namedAccountPromotionKeys
• resolveSingleAccountPromotionTarget(...)

{
  "name": "@scope/my-channel",
  "openclaw": {
    "extensions": ["./index.ts"],
    "setupEntry": "./setup-entry.ts",
    "startup": {
      "deferConfiguredChannelFullLoadUntilAfterListen": true
    }
  }
}

​

Metadatos del catálogo de canales

{
  "name": "@openclaw/nextcloud-talk",
  "openclaw": {
    "extensions": ["./index.ts"],
    "channel": {
      "id": "nextcloud-talk",
      "label": "Nextcloud Talk",
      "selectionLabel": "Nextcloud Talk (self-hosted)",
      "docsPath": "/channels/nextcloud-talk",
      "docsLabel": "nextcloud-talk",
      "blurb": "Self-hosted chat via Nextcloud Talk webhook bots.",
      "order": 65,
      "aliases": ["nc-talk", "nc"]
    },
    "install": {
      "npmSpec": "@openclaw/nextcloud-talk",
      "localPath": "<bundled-plugin-local-path>",
      "defaultChoice": "npm"
    }
  }
}

• detailLabel: etiqueta secundaria para superficies más ricas de catálogo/estado
• docsLabel: reemplaza el texto del enlace para el enlace de documentación
• preferOver: ids de plugin/canal de menor prioridad que esta entrada de catálogo debe superar
• selectionDocsPrefix, selectionDocsOmitLabel, selectionExtras: controles de texto para superficies de selección
• markdownCapable: marca el canal como compatible con markdown para decisiones de formato de salida
• exposure.configured: oculta el canal de las superficies de listado de canales configurados cuando se establece en false
• exposure.setup: oculta el canal de los selectores interactivos de configuración cuando se establece en false
• exposure.docs: marca el canal como interno/privado para superficies de navegación de documentación
• showConfigured / showInSetup: alias heredados aún aceptados por compatibilidad; prefiere exposure
• quickstartAllowFrom: hace que el canal participe en el flujo estándar de quickstart allowFrom
• forceAccountBinding: requiere asociación explícita de cuenta incluso cuando solo existe una cuenta
• preferSessionLookupForAnnounceTarget: prefiere la búsqueda de sesión al resolver objetivos de anuncio

• ~/.openclaw/mpm/plugins.json
• ~/.openclaw/mpm/catalog.json
• ~/.openclaw/plugins/catalog.json

​

Plugins del motor de contexto

import { buildMemorySystemPromptAddition } from "openclaw/plugin-sdk/core";

export default function (api) {
  api.registerContextEngine("lossless-claw", () => ({
    info: { id: "lossless-claw", name: "Lossless Claw", ownsCompaction: true },
    async ingest() {
      return { ingested: true };
    },
    async assemble({ messages, availableTools, citationsMode }) {
      return {
        messages,
        estimatedTokens: 0,
        systemPromptAddition: buildMemorySystemPromptAddition({
          availableTools: availableTools ?? new Set(),
          citationsMode,
        }),
      };
    },
    async compact() {
      return { ok: true, compacted: false };
    },
  }));
}

import {
  buildMemorySystemPromptAddition,
  delegateCompactionToRuntime,
} from "openclaw/plugin-sdk/core";

export default function (api) {
  api.registerContextEngine("my-memory-engine", () => ({
    info: {
      id: "my-memory-engine",
      name: "My Memory Engine",
      ownsCompaction: false,
    },
    async ingest() {
      return { ingested: true };
    },
    async assemble({ messages, availableTools, citationsMode }) {
      return {
        messages,
        estimatedTokens: 0,
        systemPromptAddition: buildMemorySystemPromptAddition({
          availableTools: availableTools ?? new Set(),
          citationsMode,
        }),
      };
    },
    async compact(params) {
      return await delegateCompactionToRuntime(params);
    },
  }));
}

​

Agregar una nueva capacidad

1. definir el contrato del core Decide qué comportamiento compartido debe ser propiedad del core: política, fallback, combinación de configuración, ciclo de vida, semántica orientada al canal y forma del asistente de tiempo de ejecución.
2. agregar superficies tipadas de registro/tiempo de ejecución para plugins Extiende OpenClawPluginApi y/o api.runtime con la superficie tipada de capacidad más pequeña que sea útil.
3. conectar consumidores del core y de canal/función Los canales y plugins de función deben consumir la nueva capacidad a través del core, no importando directamente una implementación del proveedor.
4. registrar implementaciones del proveedor Los plugins de proveedor registran entonces sus backends en la capacidad.
5. agregar cobertura de contrato Agrega pruebas para que la propiedad y la forma del registro sigan siendo explícitas con el tiempo.

​

Lista de verificación de capacidades

• tipos de contrato del core en src/<capability>/types.ts
• runner/asistente de tiempo de ejecución del core en src/<capability>/runtime.ts
• superficie de registro de la API de plugins en src/plugins/types.ts
• conexión del registro de plugins en src/plugins/registry.ts
• exposición del tiempo de ejecución del plugin en src/plugins/runtime/* cuando los plugins de función/canal necesiten consumirlo
• asistentes de captura/prueba en src/test-utils/plugin-registration.ts
• aserciones de propiedad/contrato en src/plugins/contracts/registry.ts
• documentación para operadores/plugins en docs/

​

Plantilla de capacidad

// core contract
export type VideoGenerationProviderPlugin = {
  id: string;
  label: string;
  generateVideo: (req: VideoGenerationRequest) => Promise<VideoGenerationResult>;
};

// plugin API
api.registerVideoGenerationProvider({
  id: "openai",
  label: "OpenAI",
  async generateVideo(req) {
    return await generateOpenAiVideo(req);
  },
});

// shared runtime helper for feature/channel plugins
const clip = await api.runtime.videoGeneration.generate({
  prompt: "Show the robot walking through the lab.",
  cfg,
});

expect(findVideoGenerationProviderIdsForPlugin("openai")).toEqual(["openai"]);

• el core es propietario del contrato de capacidad y de la orquestación
• los plugins de proveedor son propietarios de las implementaciones del proveedor
• los plugins de función/canal consumen asistentes de tiempo de ejecución
• las pruebas de contrato mantienen explícita la propiedad