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

* 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

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