PR #63962: fix(gateway): include selected memory slot in startup plugin scope

• Repository: openclaw/openclaw
• Author: arifahmedjoy
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/63962

Description (problem / solution / changelog)

Summary

• Problem: gateway startup plugin selection did not explicitly include the selected memory-slot plugin when it was not also a configured channel plugin or startup sidecar.
• Why it matters: memory-slot startup surfaces can be skipped, which can prevent memory-driven startup reconciliation behaviors from running reliably.
• What changed: resolveGatewayStartupPluginIds now includes the selected memory-slot plugin when activation state permits it.
• What did NOT change: no cron execution internals, no plugin runtime API changes, no config schema changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #63936
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: startup plugin ID resolution only included configured channel plugins plus startup sidecars; the selected memory-slot plugin can fall outside both sets.
• Missing detection / guardrail: no startup invariant test that asserted selected memory slot plugin inclusion.
• Contributing context (if known): related reports (#62920, #63465) show the same symptom family; #63097 addresses overlapping startup reconciliation behavior.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/channel-plugin-ids.test.ts
• Scenario the test should lock in:
  • default startup includes memory-core when selected in memory slot
  • custom memory slot selection includes only the selected memory plugin in startup IDs
  • restrictive allowlist expectations still include the selected memory-slot plugin
• Why this is the smallest reliable guardrail: the bug is in startup plugin-ID classification, fully exercised by resolver unit tests.
• Existing test that already covers this (if any): existing startup resolver table tests now extended.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Gateway startup now consistently includes the selected memory-slot plugin in startup plugin scope.

Diagram (if applicable)

Before:
[gateway startup] -> [resolve startup plugin IDs]
                -> [memory-slot plugin may be excluded]
                -> [memory startup reconciliation may not run]

After:
[gateway startup] -> [resolve startup plugin IDs]
                -> [selected memory-slot plugin included]
                -> [memory startup reconciliation path available]

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows (dev), issue reports from macOS/Linux environments
• Runtime/container: Node + pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): default and custom plugins.slots.memory

Steps

1. Select memory slot plugin in config (memory-core default or custom memory plugin).
2. Resolve gateway startup plugin IDs.
3. Verify selected memory-slot plugin is present in startup scope.

Expected

• selected memory-slot plugin is included in startup plugin IDs.

Actual

• verified by focused tests in src/plugins/channel-plugin-ids.test.ts.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: ran pnpm test -- src/plugins/channel-plugin-ids.test.ts and confirmed all resolver scenarios pass with the new memory-slot startup invariant.
• Edge cases checked: restrictive allowlist startup case, custom memory slot selection, default startup path.
• What you did not verify: full end-to-end gateway restart reproduction on a live memory-core installation.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: could load one additional plugin at startup in setups where memory slot is selected but previously omitted.
  • Mitigation: startup inclusion is constrained to selected memory slot plugin and existing activation-state checks.
• Risk: overlap with #63097 implementation details.
  • Mitigation: this PR remains narrowly scoped to startup plugin ID classification and has focused regression tests.

Changed files

• src/commands/doctor-bootstrap-size.test.ts (modified, +1/-0)
• src/plugins/channel-plugin-ids.test.ts (modified, +68/-6)
• src/plugins/channel-plugin-ids.ts (modified, +18/-0)