chore(sync): mirror docs from openclaw/openclaw@5dd1e264eb

.openclaw-sync/source.json

@@ -1,5 +1,5 @@
 {
   "repository": "openclaw/openclaw",
-  "sha": "67a447c1753058d1f66488955258650d92b6ffef",
-  "syncedAt": "2026-04-27T13:17:12.256Z"
+  "sha": "5dd1e264eb3ddefbffbe825788f7b8e87493e73d",
+  "syncedAt": "2026-04-27T13:21:47.023Z"
 }

docs/plugins/compatibility.md

@@ -105,7 +105,8 @@ Current compatibility records include:
 - legacy provider plugin hooks and type aliases while providers move to
   explicit catalog, auth, thinking, replay, and transport hooks
 - legacy runtime aliases such as `api.runtime.taskFlow`,
-  `api.runtime.subagent.getSession`, and `api.runtime.stt`
+  `api.runtime.subagent.getSession`, `api.runtime.stt`, and deprecated
+  `api.runtime.config.loadConfig()` / `api.runtime.config.writeConfigFile(...)`
 - legacy memory-plugin split registration while memory plugins move to
   `registerMemoryCapability`
 - legacy channel SDK helpers for native message schemas, mention gating,

docs/plugins/sdk-migration.md

@@ -119,12 +119,15 @@ 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 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.
+    helpers for external plugins during the migration window and warn once with
+    the `runtime-config-load-write` compatibility code. Bundled plugins and repo
+    runtime code are protected by scanner guardrails in
+    `pnpm check:deprecated-internal-config-api` and
+    `pnpm check:no-runtime-action-load-config`: new production plugin usage
+    fails outright, direct config writes fail, gateway server methods must use
+    the request runtime snapshot, runtime channel send/action/client helpers
+    must receive config from their boundary, and long-lived runtime modules have
+    zero allowed ambient `loadConfig()` calls.
 
   </Step>
 

docs/plugins/sdk-runtime.md

@@ -41,7 +41,7 @@ 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. 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.
+`api.runtime.config.loadConfig()` and `api.runtime.config.writeConfigFile(...)` are deprecated compatibility helpers under `runtime-config-load-write`. They warn once at runtime, and bundled plugins must not use them; the config boundary guards fail 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. 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.