openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(sync): mirror docs from openclaw/openclaw@6f6e2765e2

Browse Source
This commit is contained in:
openclaw-docs-sync[bot] 2026-04-27 11:22:10 +00:00
parent e0b15727ea
commit 64b007e9b3
2 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.openclaw-sync/source.json
View File

@ -1,5 +1,5 @@
{
"repository": "openclaw/openclaw",
"sha": "da822a56d8a9de1993111a768685b623dbae47eb",
"syncedAt": "2026-04-27T11:17:35.757Z"
"sha": "6f6e2765e270a86533c057b908c105f967c20450",
"syncedAt": "2026-04-27T11:20:53.692Z"
}

2
docs/plugins/architecture.md
View File

@ -159,6 +159,8 @@ The lookup table keeps repeated startup decisions on the fast path:
The safety boundary is snapshot replacement, not mutation. Rebuild the table when config, plugin inventory, install records, or persisted index policy changes. Do not treat it as a broad mutable global registry, and do not keep unbounded historical tables. Runtime plugin loading remains separate from lookup-table metadata so stale runtime state cannot be hidden behind a metadata cache.
Some cold-path callers still reconstruct manifest registries directly from the persisted installed plugin index instead of receiving a Gateway `PluginLookUpTable`. That fallback path keeps a small bounded in-memory cache keyed by the installed index, request shape, config policy, runtime roots, and manifest/package file signatures. It is a fallback safety net for repeated index reconstruction, not the preferred Gateway hot path. Prefer passing the current lookup table or an explicit manifest registry through runtime flows when a caller already has one.
### Activation planning
Activation planning is part of the control plane. Callers can ask which plugins are relevant to a concrete command, provider, channel, route, agent harness, or capability before loading broader runtime registries.