Missing type assertion on globalThis accesses

globalThis.__openclawContextEngines is accessed here (and on lines 103, 106, 123, and 126) without a type cast. Since __openclawContextEngines is not declared on the global type and the project uses strict: true in tsconfig.json, TypeScript will raise a "Property __openclawContextEngines does not exist on type Window & typeof globalThis" error on all these lines when running tsc --noEmit.

The registry.ts source file correctly wraps every such access in (globalThis as unknown as { __openclawContextEngines?: ... }), but the test file omits those casts.

Either add a declare global augmentation in a .d.ts file (recommended, as it makes the intent explicit and avoids repetition), or apply the same cast pattern used in the source file to every direct access in the tests:

The same cast is also needed at lines 103, 106, 123, and 126.

This is a comment left during a code review.
Path: src/context-engine/registry.test.ts
Line: 14-17

Comment:
**Missing type assertion on `globalThis` accesses**

`globalThis.__openclawContextEngines` is accessed here (and on lines 103, 106, 123, and 126) without a type cast. Since `__openclawContextEngines` is not declared on the global type and the project uses `strict: true` in `tsconfig.json`, TypeScript will raise a "Property `__openclawContextEngines` does not exist on type `Window & typeof globalThis`" error on all these lines when running `tsc --noEmit`.

The `registry.ts` source file correctly wraps every such access in `(globalThis as unknown as { __openclawContextEngines?: ... })`, but the test file omits those casts.

Either add a `declare global` augmentation in a `.d.ts` file (recommended, as it makes the intent explicit and avoids repetition), or apply the same cast pattern used in the source file to every direct access in the tests:

```suggestion
    const testEngines = [
      ...(
        (globalThis as unknown as { __openclawContextEngines?: Map<string, unknown> })
          .__openclawContextEngines?.keys() ?? []
      ),
    ].filter(
      (id) => id.startsWith("test-") || id.startsWith("cross-module-"),
    );
    testEngines.forEach((id) =>
      (globalThis as unknown as { __openclawContextEngines: Map<string, unknown> })
        .__openclawContextEngines.delete(id),
    );
```

The same cast is also needed at lines 103, 106, 123, and 126.

How can I resolve this? If you propose a fix, please make it concise.

afterEach cleanup does not cover all registered IDs

The afterEach hook only removes engine IDs that start with "test-" or "cross-module-". However, many tests in this file register engines with IDs that don't match either prefix and are therefore never cleaned up:

• "plugin-a-engine" / "plugin-b-engine" (cross-context visibility suite)
• "context-a-engine" / "context-b-engine" (cross-context visibility suite)
• "duplicate-engine" / "type-safe-engine" (edge cases suite)
• "custom-slot-engine" / "async-factory-engine" / "trim-test-engine" / "available-engine" (resolveContextEngine suite)
• "list-test-engine-1" / "list-test-engine-2" (listContextEngineIds suite)

Because globalThis.__openclawContextEngines is intentionally shared, these registrations accumulate for the lifetime of the test file's process. Tests that check the full set of IDs (e.g. the "should provide helpful error message listing available engines" test) currently happen to pass, but the leaked state makes future tests brittle.

Consider either:

1. Renaming all test IDs to use the "test-" prefix so the current filter covers them, or
2. Clearing the entire Map in afterEach and re-populating only the built-in default engines before each test.

This is a comment left during a code review.
Path: src/context-engine/registry.test.ts
Line: 12-18

Comment:
**`afterEach` cleanup does not cover all registered IDs**

The `afterEach` hook only removes engine IDs that start with `"test-"` or `"cross-module-"`. However, many tests in this file register engines with IDs that don't match either prefix and are therefore never cleaned up:

- `"plugin-a-engine"` / `"plugin-b-engine"` (cross-context visibility suite)
- `"context-a-engine"` / `"context-b-engine"` (cross-context visibility suite)
- `"duplicate-engine"` / `"type-safe-engine"` (edge cases suite)
- `"custom-slot-engine"` / `"async-factory-engine"` / `"trim-test-engine"` / `"available-engine"` (resolveContextEngine suite)
- `"list-test-engine-1"` / `"list-test-engine-2"` (listContextEngineIds suite)

Because `globalThis.__openclawContextEngines` is intentionally shared, these registrations accumulate for the lifetime of the test file's process. Tests that check the full set of IDs (e.g. the `"should provide helpful error message listing available engines"` test) currently happen to pass, but the leaked state makes future tests brittle.

Consider either:
1. Renaming all test IDs to use the `"test-"` prefix so the current filter covers them, or
2. Clearing the entire Map in `afterEach` and re-populating only the built-in default engines before each test.

How can I resolve this? If you propose a fix, please make it concise.

Clear shared engine registry on plugin reload

Once a context-engine plugin has been loaded at least once, reloading the gateway with that plugin disabled or uninstalled will still leave its factory reachable because this map now lives on globalThis for the lifetime of the process. loadOpenClawPlugins() only clears commands during reload (src/plugins/loader.ts:524-526), and resolveContextEngine() accepts any factory still present in the registry, so plugins.slots.contextEngine can keep instantiating stale plugin code instead of failing fast after the plugin is removed. In the bundled build that is new behavior: before the host and plugin-sdk copies did not share a registry, so disabled plugin engines were not visible to the host bundle.

Useful? React with 👍 / 👎.

Guard the shared registry against duplicate engine IDs

Sharing one process-wide map here also widens registerContextEngine()'s existing last-wins behavior to every bundled entry point. Because context-engine plugins are not slot-gated during load the way memory plugins are (src/plugins/loader.ts:782-800 only filters kind: "memory"), any enabled plugin that accidentally registers "legacy" or another existing engine id can overwrite the host's entry for the whole process after a reload, changing what resolveContextEngine() instantiates even when the user did not intend to switch engines.

Useful? React with 👍 / 👎.