docs(plugin-sdk): refresh seam cleanup docs

docs/plugins/architecture.md

@@ -196,6 +196,12 @@ We do not publish separate `plugin-sdk/*-action-runtime` subpaths, and bundled
 plugins should import their own local runtime code directly from their
 extension-owned modules.
 
+The same boundary applies to provider-named SDK seams in general: core should
+not import `openclaw/plugin-sdk/slack`, `.../discord`, `.../signal`,
+`.../whatsapp`, or other channel-specific convenience barrels. If core needs a
+behavior, either consume the bundled plugin's own `api.ts` / `runtime-api.ts`
+barrel or promote the need into a narrow generic capability in the shared SDK.
+
 For polls specifically, there are two execution paths:
 
 - `outbound.sendPoll` is the shared baseline for channels that fit the common

docs/plugins/sdk-migration.md

@@ -46,6 +46,14 @@ The old approach caused problems:
 The modern plugin SDK fixes this: each import path (`openclaw/plugin-sdk/\<subpath\>`)
 is a small, self-contained module with a clear purpose and documented contract.
 
+Legacy provider convenience seams for bundled channels are also gone. Imports
+such as `openclaw/plugin-sdk/slack`, `openclaw/plugin-sdk/discord`,
+`openclaw/plugin-sdk/signal`, `openclaw/plugin-sdk/whatsapp`, and
+`openclaw/plugin-sdk/telegram-core` were private mono-repo shortcuts, not
+stable plugin contracts. Use narrow generic SDK subpaths instead. Inside the
+bundled plugin workspace, keep provider-owned helpers in that plugin's own
+`api.ts` or `runtime-api.ts`.
+
 ## How to migrate
 
 <Steps>

docs/plugins/sdk-overview.md

@@ -32,6 +32,13 @@ import { defineChannelPluginEntry } from "openclaw/plugin-sdk/core";
 Each subpath is a small, self-contained module. This keeps startup fast and
 prevents circular dependency issues.
 
+Do not add or depend on provider-named convenience seams such as
+`openclaw/plugin-sdk/slack`, `openclaw/plugin-sdk/discord`,
+`openclaw/plugin-sdk/signal`, or `openclaw/plugin-sdk/whatsapp`. Bundled plugins should compose generic SDK
+subpaths inside their own `api.ts` or `runtime-api.ts` barrels, and core should
+either use those plugin-local barrels or add a narrow generic SDK contract when
+the need is truly cross-channel.
+
 ## Subpath reference
 
 The most commonly used subpaths, grouped by purpose. The full list of 100+

src/plugin-sdk/AGENTS.md

@@ -28,10 +28,10 @@ can affect bundled plugins and third-party plugins.
   intentionally promoting a supported public contract.
 - Prefer `api.runtime` or a focused SDK facade over telling extensions to reach
   into host internals directly.
-- When core or tests need bundled plugin helpers, expose them through
-  the plugin package `api.ts` and a matching `src/plugin-sdk/<id>.ts` facade
-  instead of importing plugin-private `src/**` files or `onboard.js`
-  directly.
+- When core or tests need bundled plugin helpers, prefer the plugin package
+  `api.ts` or `runtime-api.ts` plus generic SDK capabilities. Do not add a
+  provider-named `src/plugin-sdk/<id>.ts` seam just to make core aware of a
+  bundled channel's private helpers.
 
 ## Expanding The Boundary
 
@@ -42,7 +42,7 @@ can affect bundled plugins and third-party plugins.
   - `src/plugin-sdk/entrypoints.ts`
   - `package.json` exports
   - API baseline and export checks
-- If the seam is for bundled-provider onboarding/config helpers, update the
-  generated plugin facades instead of teaching core tests or commands to reach
-  into private extension files.
+- If a bundled channel/helper need crosses package boundaries, first ask
+  whether the need is truly generic. If yes, add a narrow generic subpath. If
+  not, keep it plugin-local through `api.ts` / `runtime-api.ts`.
 - Breaking removals or renames are major-version work, not drive-by cleanup.