openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(sync): mirror docs from openclaw/openclaw@4a65b69073

Browse Source
This commit is contained in:
openclaw-docs-sync[bot] 2026-04-27 10:52:20 +00:00
parent 0f91e5b9b6
commit 3fc3ff813a
2 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.openclaw-sync/source.json
View File

@ -1,5 +1,5 @@
{
"repository": "openclaw/openclaw",
"sha": "f487ed160e5c27d9f1d0f1c2b6c4097fa7ae0caf",
"syncedAt": "2026-04-27T10:46:46.547Z"
"sha": "4a65b69073f9f177e27d37f9cdae65d773a549df",
"syncedAt": "2026-04-27T10:50:54.097Z"
}

2
docs/plugins/architecture.md
View File

@ -208,6 +208,8 @@ For channel-owned execution helpers, bundled plugins should keep the execution r
The same boundary applies to provider-named SDK seams in general: core should not import channel-specific convenience barrels for Slack, Discord, Signal, WhatsApp, or similar extensions. 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.
Bundled plugins follow the same rule. A bundled plugin's `runtime-api.ts` should not re-export its own branded `openclaw/plugin-sdk/<plugin-id>` facade. Those branded facades remain compatibility shims for external plugins and older consumers, but bundled plugins should use local exports plus narrow generic SDK subpaths such as `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store`, or `openclaw/plugin-sdk/webhook-ingress`. New code should not add plugin-id-specific SDK facades unless the compatibility boundary for an existing external ecosystem requires it.
For polls specifically, there are two execution paths:
- `outbound.sendPoll` is the shared baseline for channels that fit the common poll model