diff --git a/.openclaw-sync/source.json b/.openclaw-sync/source.json
index b8d054fd2..dc957407f 100644
--- a/.openclaw-sync/source.json
+++ b/.openclaw-sync/source.json
@@ -1,5 +1,5 @@
 {
   "repository": "openclaw/openclaw",
-  "sha": "66f4b52db31ba2b0d61c74b184a23f26d31edce3",
-  "syncedAt": "2026-04-27T07:47:39.663Z"
+  "sha": "45b0d5ccc20399b8a9566cab08eb87d4dd3d47b5",
+  "syncedAt": "2026-04-27T07:49:32.931Z"
 }
diff --git a/docs/cli/gateway.md b/docs/cli/gateway.md
index 6a10c0466..7c43a0837 100644
--- a/docs/cli/gateway.md
+++ b/docs/cli/gateway.md
@@ -110,8 +110,8 @@ Inline `--password` can be exposed in local process listings. Prefer `--password
 
 ### Startup profiling
 
-- Set `OPENCLAW_GATEWAY_STARTUP_TRACE=1` to log phase timings during Gateway startup.
-- Run `pnpm test:startup:gateway -- --runs 5 --warmup 1` to benchmark Gateway startup. The benchmark records first process output, `/healthz`, `/readyz`, and startup trace timings.
+- Set `OPENCLAW_GATEWAY_STARTUP_TRACE=1` to log phase timings during Gateway startup, including per-phase `eventLoopMax` delay and plugin lookup-table timings for installed-index, manifest registry, startup planning, and owner-map work.
+- Run `pnpm test:startup:gateway -- --runs 5 --warmup 1` to benchmark Gateway startup. The benchmark records first process output, `/healthz`, `/readyz`, startup trace timings, event-loop delay, and plugin lookup-table timing details.
 
 ## Query a running Gateway
 
diff --git a/docs/plugins/architecture.md b/docs/plugins/architecture.md
index 367afa158..81bb056de 100644
--- a/docs/plugins/architecture.md
+++ b/docs/plugins/architecture.md
@@ -145,6 +145,20 @@ The important design boundary:
 
 That split lets OpenClaw validate config, explain missing/disabled plugins, and build UI/schema hints before the full runtime is active.
 
+### Plugin lookup table
+
+Gateway startup builds a `PluginLookUpTable` from the installed plugin index and manifest registry for the current config snapshot. The table is metadata-only: it stores plugin ids, manifest records, diagnostics, owner maps, a plugin id normalizer, and the startup plugin plan. It does not hold loaded plugin modules, provider SDKs, package contents, or runtime exports.
+
+The lookup table keeps repeated startup decisions on the fast path:
+
+- channel ownership
+- deferred channel startup
+- startup plugin ids
+- provider and CLI backend ownership
+- setup provider, command alias, model catalog provider, and manifest contract ownership
+
+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.
+
 ### 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.