LLM/moltbot
1
0
Fork 0
mirror of https://github.com/moltbot/moltbot.git synced 2026-04-25 23:47:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: clarify bundled helper sdk seams

Browse Source
This commit is contained in:
Peter Steinberger
2026-04-04 12:59:26 +01:00
parent 8059942216
commit cec15e08d1
4 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/plugins/architecture.md
View File

@@ -473,6 +473,13 @@ Keep capability registration public. Trim non-contract helper exports:
- vendor-specific convenience helpers
- setup/onboarding helpers that are implementation details
Some bundled-plugin helper subpaths still remain in the generated SDK export
map for compatibility and bundled-plugin maintenance. Current examples include
`plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`,
`plugin-sdk/zalo-setup`, and several `plugin-sdk/matrix*` seams. Treat those as
reserved implementation-detail exports, not as the recommended SDK pattern for
new third-party plugins.
## Load pipeline
At startup, OpenClaw does roughly this:

5
docs/plugins/building-plugins.md
View File

@@ -248,6 +248,11 @@ barrels unless the seam is truly generic. Current bundled examples:
If a helper is only useful inside one bundled provider package, keep it on that
package-root seam instead of promoting it into `openclaw/plugin-sdk/*`.
Some generated `openclaw/plugin-sdk/<bundled-id>` helper seams still exist for
bundled-plugin maintenance and compatibility, for example
`plugin-sdk/feishu-setup` or `plugin-sdk/zalo-setup`. Treat those as reserved
surfaces, not as the default pattern for new third-party plugins.
## Pre-submission checklist
<Check>**package.json** has correct `openclaw` metadata</Check>

7
docs/plugins/sdk-migration.md
View File

@@ -195,6 +195,13 @@ This table is intentionally the common migration subset, not the full SDK
surface. The generated full list of 200+ entrypoints lives in
`scripts/lib/plugin-sdk-entrypoints.json`.
That generated list still includes some bundled-plugin helper seams such as
`plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`,
`plugin-sdk/zalo-setup`, and `plugin-sdk/matrix*`. Those remain exported for
bundled-plugin maintenance and compatibility, but they are intentionally
omitted from the common migration table and are not the recommended target for
new plugin code.
Use the narrowest import that matches the job. If you cannot find an export,
check the source at `src/plugin-sdk/` or ask in Discord.

11
docs/plugins/sdk-overview.md
View File

@@ -42,11 +42,22 @@ 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.
The generated export map still contains a small set of bundled-plugin helper
seams such as `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`,
`plugin-sdk/zalo`, `plugin-sdk/zalo-setup`, and `plugin-sdk/matrix*`. Those
subpaths exist for bundled-plugin maintenance and compatibility only; they are
intentionally omitted from the common table below and are not the recommended
import path for new third-party plugins.
## Subpath reference
The most commonly used subpaths, grouped by purpose. The generated full list of
200+ subpaths lives in `scripts/lib/plugin-sdk-entrypoints.json`.
Reserved bundled-plugin helper subpaths still appear in that generated list.
Treat those as implementation detail/compatibility surfaces unless a doc page
explicitly promotes one as public.
### Plugin entry
| Subpath | Key exports |