What Problem This Solves

/status plugins (detailed) distinguishes runtime-Loaded: plugins from a neutral Installed (not active): inventory line (added in #97479), but it never compares against the gateway's desired startup set. So a plugin the gateway's eager startup plan requires — yet that is absent from the live runtime-loaded set and did not surface an error — is silently bucketed into the neutral "Installed (not active)" line. A genuine startup drift (config changed since the gateway started, or a planned plugin that did not come up) is invisible today.

Why This Change Was Made

This builds on #97479's runtimeLoadedPluginIds provenance. With the observed set already available, the missing half is the desired set: the gateway's eager should-run plugin plan. Comparing the two turns an invisible partial-startup failure into a visible, observer-only diagnostic.

Computing that plan correctly requires the same config assembly the gateway performs at boot (auto-enable the operator activation source, then merge it into the runtime config). Rather than re-implement that inline in the status path — which is drift-prone — this extracts the existing boot assembly (server-startup-plugins.ts, non-minimal branch) into a small shared pure helper, resolveGatewayStartupPluginActivationConfig, so the status diagnostic and gateway boot use the same code and cannot diverge. The gateway change is a mechanical, behavior-preserving call-site swap; server-plugin-bootstrap.ts (the plugin-loading assembly) is intentionally left untouched.

User Impact

Detailed /status plugins gains one new line, and only when there is real drift:

Configured to run but not loaded: N (id, ...)

• Observer-only. No repair / retry / reload / config / doctor / channel / provider behavior changes; gateway startup behavior is unchanged (the helper extraction is mechanical and test-covered).
• Surfaces plugins expected by the gateway startup plan but missing from runtimeLoadedPluginIds.
• Installed-but-not-planned plugins stay neutral — the existing "Installed (not active)" inventory is unchanged; only genuine should-run drift is elevated, and a drift id never appears in both lines.
• Excludes deferred plugins (configuredDeferredChannelPluginIds): they finish loading only after the gateway starts listening, so they are never false-positive drift.
• Excludes plugins already explained by an error/disabled record.
• Compact /status plugin line is unchanged — no new error chip; drift appears only in the detailed view.
• Uses the shared startup activation config helper, so the should-run set matches the real gateway boot plan (auto-enable + operator activation source + runtime/defaulted merge).
• Plan resolution failure (or absent config) degrades to previous behavior — the should-run set is resolved lazily inside a try/catch; back-compat: snapshots without it render exactly as before.

Evidence

Reviewed at HEAD 74ad546d24b2c6354da818182874aef0fb2926d9.

Real behavior proof (production path, no mocks)

Ran the real /status plugins handler buildStatusPluginsReply against PR HEAD in an isolated OPENCLAW_STATE_DIR (timestamp 2026-06-29T17:10:13Z) — real collectInstalledPluginHealthSnapshot (real buildPluginSnapshotReport installed scan + real should-run plan via the shared resolveGatewayStartupPluginActivationConfig helper → real applyPluginAutoEnable + real loadGatewayStartupPluginPlan) → real formatDetailedPluginHealth. The live active registry was set empty via the real setActivePluginRegistry API (the planned-but-not-loaded condition); no records are fabricated and nothing is mocked.

Config {commands:{plugins:true}, plugins:{entries:{diffs:{enabled:true}}}}; real should-run plan = [acpx, browser, canvas, device-pair, diffs, file-transfer, memory-core, phone-control, talk-voice]; runtimeLoadedPluginIds = []. Observed /status plugins (detailed) output:

🔌 Plugins: OK
Loaded: 0
Disabled: 59
Installed (not active): 67 (alibaba, amazon-bedrock, amazon-bedrock-mantle, anthropic, +63 more)
Configured to run but not loaded: 9 (acpx, browser, canvas, device-pair, diffs, file-transfer, memory-core, phone-control, +1 more)
Full inventory: /plugins list

This shows, from the real handler: (1) the 9 planned-but-not-loaded plugins surfaced as Configured to run but not loaded; (2) the 67 installed-but-not-planned plugins staying neutral under Installed (not active) (not drift); (3) the drift ids absent from the neutral line (no double-listing); (4) the compact line unchanged (🔌 Plugins: OK).

Targeted tests / checks

• Status plugin health tests (src/status/status-plugin-health{,.runtime,.installed}.test.ts) — 32/32.
• Gateway startup tests (src/gateway/server-startup-plugins.test.ts) — 50/50 (boot behavior preserved after the helper extraction).
• New helper tests (src/gateway/plugin-activation-runtime-config.test.ts) — passed.
• tsgo -p tsconfig.core.json + test/tsconfig/tsconfig.core.test.json — clean.
• pnpm build — passed, no [INEFFECTIVE_DYNAMIC_IMPORT]. pnpm check:import-cycles — 0 cycles. oxfmt --check — clean.
• Independent codex / GPT-5.5 review — clean ("patch is correct"; confirms behavior-preserving gateway refactor + shared assembly reuse).

Known limitations

• A full live gateway (real plugin-module loading + chat transport + authorized sender over a running gateway) was not used; the proof drives the real handler/plan/formatter directly with an empty live registry as the closest deterministic production-path proof.
• The drift comparison is recomputed from current config vs the live runtime-loaded set, so it reflects "current config's plan vs what is loaded now" (the intended semantics).

Non-Scope

• No repair / retry / reload / auto-enable of plugins.
• No gateway startup behavior change (the helper extraction is a behavior-preserving call-site swap; server-plugin-bootstrap.ts plugin-loading assembly untouched).
• No config / doctor / channel / provider behavior change; no compact-line change; no new config or env surface.
• No CHANGELOG.md edit (per contributor guidance — maintainers add changelog entries on landing).

Risk checklist

• Observer-only; no repair/auto-mutation. Plan resolution failure (or absent config) degrades to prior behavior (try/catch, no drift line).
• Back-compat: snapshots without shouldRunPluginIds/runtimeLoadedPluginIds render exactly as before.
• Compact /status plugin line unchanged (no new error chip).
• Gateway behavior preserved — proven by server-startup-plugins.test.ts 50/50 + the helper extraction being a byte-equivalent call-site swap.
• No secret/PII surfaced — renders plugin ids only (same class fix(status): distinguish runtime-loaded plugins from installed inventory #97479 already renders).
• Lazy imports verified effective (pnpm build shows no [INEFFECTIVE_DYNAMIC_IMPORT]); no new import cycles.
• No CHANGELOG; no #97320.

Builds on #97479. Touches src/status/status-plugin-health{,.runtime}.ts and src/gateway/plugin-activation-runtime-config.ts + server-startup-plugins.ts (plus colocated tests).