Summary

• Adds a single top-level "kind": "context-engine" field to openclaw.plugin.json so OpenClaw core's slot resolver binds the contextEngine slot to this plugin on install.
• Adds a matching manifest-shape test to test/config.test.ts so any future edit that drops or retypes the field fails fast.

Fixes #384.

Root cause (quoting the issue)

OpenClaw core's slot resolver lives in src/plugins/slots.ts (compiled to dist/slots-CFrDTeTR.js in the published build). Its pipeline:

const SLOT_BY_KIND = {
  memory: "memory",
  "context-engine": "contextEngine",
};

function slotKeysForPluginKind(kind) {
  return normalizeKinds(kind).map((k) => SLOT_BY_KIND[k]).filter((k) => k != null);
}

function applyExclusiveSlotSelection(params) {
  const slotKeys = slotKeysForPluginKind(params.selectedKind);
  if (slotKeys.length === 0) return { config: params.config, warnings: [], changed: false };
  // ...write plugins.slots[slotKey] = params.selectedId
}

Before this PR, openclaw.plugin.json has no top-level kind field, so slotKeysForPluginKind returns [] and applyExclusiveSlotSelection early-returns with changed: false. openclaw plugins install @martian-engineering/lossless-claw silently leaves plugins.slots.contextEngine unset, and OpenClaw falls back to the default legacy context engine at runtime.

The plugin still loads and still calls api.registerContextEngine("lossless-claw", () => lcm) — but the slot resolver never routes any traffic to that registration, so no conversation ever reaches lcm.handleContextPrepare / lcm.onTurnComplete.

User-visible symptom

lcm.db stays at the initial ~4 KB / 0 tables forever, even on an install that reports success and even with plugins.entries.lossless-claw.enabled: true. On one 4-week-old v0.3.0 install the DB was still empty until plugins.slots.contextEngine: "lossless-claw" was added manually, at which point all 21 LCM tables initialized on the next turn and LCM started writing normally. See #384 for the full trace.

Fix

One new top-level field in openclaw.plugin.json:

 {
   "id": "lossless-claw",
+  "kind": "context-engine",
   "skills": [

With kind present, slotKeysForPluginKind now returns ["contextEngine"] and applyExclusiveSlotSelection writes plugins.slots.contextEngine = "lossless-claw" — which is the exact config state users currently have to hand-edit to make LCM work.

Test

Adds one shape test next to the existing skill-path test:

it("declares context-engine kind so OpenClaw core binds the contextEngine slot on install", () => {
  expect(manifest.kind).toBe("context-engine");
});

Verification

• npm test — all 40 test files / 694 tests pass locally
• Traced against OpenClaw core dist/slots-CFrDTeTR.js (SLOT_BY_KIND, slotKeysForPluginKind, applyExclusiveSlotSelection) — the semantics match what is claimed above
• No other files in this repo reference a top-level manifest kind field, so this is a pure addition

What this does NOT change

• No runtime code changes
• No config schema changes
• No change to the api.registerContextEngine call or index.ts entrypoint
• No change for users who have already hand-added the slot config — the slot resolver is idempotent, so this just makes the first install do the right thing

🤖 Generated with Claude Code