vultr/openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/openclaw.git synced 2026-05-06 09:20:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(plugins): narrow explicit provider loads from manifests (#65259)

Browse Source 
* feat(plugins): narrow explicit provider loads from manifests

* fix(plugins): preserve setup trust filtering for explicit owners

* fix(plugins): respect runtime owner trust and disablement

* fix(plugins): preserve provider owner policy bounds
This commit is contained in:
Vincent Koc
2026-04-12 10:52:03 +01:00
committed by GitHub
parent 3686255a55
commit 12db6dfc8d
6 changed files with 674 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/plugins/architecture.md
View File

@@ -527,9 +527,12 @@ actual behavior such as hooks, tools, commands, or provider flows.
Optional manifest `activation` and `setup` blocks stay on the control plane.
They are metadata-only descriptors for activation planning and setup discovery;
they do not replace runtime registration, `register(...)`, or `setupEntry`.
The first activation consumer now uses manifest command hints to narrow CLI
plugin loading when a primary command is known, instead of always loading every
CLI-capable plugin up front.
The first live activation consumers now use manifest command and provider hints
to narrow plugin loading before broader registry materialization:
- CLI loading narrows to plugins that own the requested primary command
- explicit provider setup/runtime resolution narrows to plugins that own the
requested provider id
Setup discovery now prefers descriptor-owned ids such as `setup.providers` and
`setup.cliBackends` to narrow candidate plugins before it falls back to

14
docs/plugins/manifest.md
View File

@@ -222,8 +222,8 @@ should activate it later.
This block is metadata only. It does not register runtime behavior, and it does
not replace `register(...)`, `setupEntry`, or other runtime/plugin entrypoints.
Current consumers use it as a narrowing hint before broader plugin loading, so
missing activation metadata only costs performance; it should not change
correctness.
missing activation metadata usually only costs performance; it should not
change correctness while legacy manifest ownership fallbacks still exist.
```json
{
@@ -245,9 +245,13 @@ correctness.
| `onRoutes` | No | `string[]` | Route kinds that should activate this plugin. |
| `onCapabilities` | No | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Broad capability hints used by control-plane activation planning. |
For command-triggered planning specifically, OpenClaw still falls back to
legacy `commandAliases[].cliCommand` or `commandAliases[].name` when a plugin
has not added explicit `activation.onCommands` metadata yet.
Current live consumers:
- command-triggered CLI planning falls back to legacy
`commandAliases[].cliCommand` or `commandAliases[].name`
- provider-triggered setup/runtime planning falls back to legacy
`providers[]` and top-level `cliBackends[]` ownership when explicit provider
activation metadata is missing
## setup reference