Description

Published [email protected] appears to split context-engine registration across multiple bundled registry chunks.

This causes a failure mode where a plugin logs as loaded and calls api.registerContextEngine(...), but later context-engine resolution still reports only the built-in engine set.

Reproduction

Reproduced on March 8, 2026 against:

• [email protected]
• @martian-engineering/[email protected]

Using the published release bundle in a temp install:

1. Install [email protected]
2. Install [email protected] under ~/.openclaw/extensions/lossless-claw
3. Load plugins via the published host bundle entry that exports loadOpenClawPlugins from dist/reply-C5LKjXcC.js
4. Resolve the context engine via different published registry chunks

Observed:

• plugin load succeeds
• lossless-claw logs as loaded
• resolving via one registry chunk succeeds
• resolving via another registry chunk fails with:

Context engine "lossless-claw" is not registered. Available engines: (none)

Root Cause

The published bundle contains at least two distinct context-engine registry chunks:

• dist/registry-DGVIIthr.js
• dist/registry-DoLLbW4m.js

Each chunk has its own module-level context-engine map.

Direct repro in the same process:

• loadOpenClawPlugins(...) through dist/reply-C5LKjXcC.js registers lossless-claw
• registry-DGVIIthr.js can resolve it
• registry-DoLLbW4m.js cannot

That means plugin registration and later resolution can end up talking to different singleton instances.

Expected

All plugin registration and context-engine resolution paths in the published build should share a single registry/context-engine singleton.

Notes

This does not appear to be a lossless-claw registration bug.

Its register() path still calls:

api.registerContextEngine("lossless-claw", () => lcm)

before logging plugin load success.

Suggested Fix

• Deduplicate the registry/context-engine module in the published bundle
• Add a release-bundle regression test that loads a plugin context engine and then resolves it from the agent/gateway runtime path
• Verify gateway/plugin-loader and agent runner import the same registry module in dist