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

docs(plugins): clarify runtime config access

Browse Source
This commit is contained in:
Peter Steinberger
2026-04-27 12:52:05 +01:00
parent 9d5a211019
commit a041ea7ca7
4 changed files with 14 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -119,8 +119,9 @@ releases.
Mutation results include a typed `followUp` summary for tests and logging;
the gateway remains responsible for applying or scheduling the restart.
`loadConfig` and `writeConfigFile` remain as deprecated compatibility
helpers for external plugins during the migration window. Bundled plugins
and repo runtime code are protected by scanner guardrails: new production
helpers for external plugins during the migration window and warn once when
called. Bundled plugins and repo runtime code are protected by scanner
guardrails in `pnpm check:deprecated-internal-config-api`: new production
plugin usage fails outright, direct config writes fail, gateway server
methods must use the request runtime snapshot, and long-lived runtime
modules have zero allowed ambient `loadConfig()` calls.

4
docs/plugins/sdk-runtime.md
View File

@@ -41,9 +41,9 @@ Persist changes with `api.runtime.config.mutateConfigFile(...)` or `api.runtime.
The mutation helpers return `afterWrite` plus a typed `followUp` summary so callers can log or test whether they requested a restart. The gateway still owns when that restart actually happens.
`api.runtime.config.loadConfig()` and `api.runtime.config.writeConfigFile(...)` are deprecated compatibility helpers. Bundled plugins must not use them; the architecture guard fails if production plugin code calls them or imports those helpers from plugin SDK subpaths.
`api.runtime.config.loadConfig()` and `api.runtime.config.writeConfigFile(...)` are deprecated compatibility helpers. They warn once at runtime, and bundled plugins must not use them; the architecture guard fails if production plugin code calls them or imports those helpers from plugin SDK subpaths.
Internal OpenClaw runtime code has the same direction: load config once at the CLI, gateway, or process boundary, then pass that value through. Long-lived runtime modules have a zero-tolerance scanner for ambient `loadConfig()` calls; use a passed `cfg`, a request `context.getRuntimeConfig()`, or `getRuntimeConfig()` at an explicit process boundary.
Internal OpenClaw runtime code has the same direction: load config once at the CLI, gateway, or process boundary, then pass that value through. Successful mutation writes refresh the process runtime snapshot and advance its internal revision; long-lived caches should key off the runtime-owned cache key instead of serializing config locally. Long-lived runtime modules have a zero-tolerance scanner for ambient `loadConfig()` calls; use a passed `cfg`, a request `context.getRuntimeConfig()`, or `getRuntimeConfig()` at an explicit process boundary.
## Runtime namespaces

8
docs/plugins/sdk-testing.md
View File

@@ -94,6 +94,14 @@ plugin calls a capability API it does not own. For example,
`api.registerMemoryCapability(...)` requires the plugin manifest or exported
entry to declare `kind: "memory"`.
### Testing runtime config access
Prefer the shared plugin runtime mock from the repo test helpers when testing
bundled plugins. Its deprecated `runtime.config.loadConfig()` and
`runtime.config.writeConfigFile(...)` mocks throw by default so tests catch new
usage of compatibility APIs. Override those mocks only when the test is
explicitly covering legacy compatibility behavior.
### Unit testing a channel plugin
```typescript