OpenClaw host compatibility
Use this playbook with AGENTS.md whenever a change crosses the plugin/host
boundary. A mocked unit test or a build against the lockfile SDK alone is not
evidence for another host version.
Define the compatibility claim
List the exact versions the change claims to support:
- the lockfile development version;
- the declared minimum host version;
- any additional exact stable, beta, or prerelease version named by the task or
PR.
Do not silently broaden the claim to untested versions. Routine compatibility
fixes do not bump package, lockfile, or plugin versions or create a dated release
section.
Inspect the real SDK boundary
For every claimed version:
- Inspect
node_modules/openclaw/package.json exports and the installed .d.ts
declarations.
- Confirm the exact exported subpath, symbol name, signature, and return shape.
- Check all production imports and callers of the changed symbol.
- Keep NodeNext source imports on
.js specifiers where required by this
repository.
Do not infer compatibility from a similarly named subpath or an unchanged-looking
signature.
Keep mocks honest
- Search for every mock of the old and new module specifier.
- Mock the exact specifier imported by production code.
- Assert the relevant symbol is exercised when the mock represents a compatibility
seam.
- Keep a separate unmocked check; mocks prove local behavior, not package exports.
Validate every claimed version without mocks
Use an isolated or disposable dependency installation so manifests and the
lockfile remain unchanged. For each exact claimed host version:
- Install that exact OpenClaw version and assert the version actually present in
node_modules.
- Run type checking and build after installing the target version.
- Start a fresh Node process with no Vitest mocks and import the compiled plugin
entry point and any changed production module.
- Register the plugin and verify the
openclaw-weixin plugin/channel ID and
expected registration count.
- Exercise the smallest runtime boundary needed to prove the changed export can
be called, without contacting the live Weixin backend.
Restore the lockfile dependency installation before the normal full validation.
Packaging and documentation
- Run
npm run pack:check when entry points, build output, package metadata,
dependencies, or published files change.
- Keep the declared minimum host consistent across
SUPPORTED_HOST_MIN in
src/compat.ts, the package.json peerDependencies and
openclaw.install.minHostVersion fields, bilingual READMEs, CONTRIBUTING.md,
and CI.
- Update matching English and Chinese
Unreleased notes for user-visible
compatibility changes, but leave release versioning to the maintainer flow.
- State exact tested versions and commands in the PR; do not use total test count
as compatibility evidence.
Completion evidence
- Unit mocks match production import specifiers.
- Each claimed host version passes post-install type checking, build, fresh-process
import, and registration smoke.
- No compatibility claim depends only on the current SDK, a mock, or a green
unrelated CI job.
- The normal
npm run check and applicable npm run pack:check pass afterward.
1---2name: openclaw-host-compatibility3description: Review, implement, or test openclaw-weixin changes involving OpenClaw SDK imports or exported subpaths, host APIs, plugin registration, entry points, peer or minimum host versions, build output, packaging, or compatibility claims.4---56# OpenClaw host compatibility78Use this playbook with `AGENTS.md` whenever a change crosses the plugin/host9boundary. A mocked unit test or a build against the lockfile SDK alone is not10evidence for another host version.1112## Define the compatibility claim1314List the exact versions the change claims to support:1516- the lockfile development version;17- the declared minimum host version;18- any additional exact stable, beta, or prerelease version named by the task or19 PR.2021Do not silently broaden the claim to untested versions. Routine compatibility22fixes do not bump package, lockfile, or plugin versions or create a dated release23section.2425## Inspect the real SDK boundary2627For every claimed version:28291. Inspect `node_modules/openclaw/package.json` exports and the installed `.d.ts`30 declarations.312. Confirm the exact exported subpath, symbol name, signature, and return shape.323. Check all production imports and callers of the changed symbol.334. Keep NodeNext source imports on `.js` specifiers where required by this34 repository.3536Do not infer compatibility from a similarly named subpath or an unchanged-looking37signature.3839## Keep mocks honest4041- Search for every mock of the old and new module specifier.42- Mock the exact specifier imported by production code.43- Assert the relevant symbol is exercised when the mock represents a compatibility44 seam.45- Keep a separate unmocked check; mocks prove local behavior, not package exports.4647## Validate every claimed version without mocks4849Use an isolated or disposable dependency installation so manifests and the50lockfile remain unchanged. For each exact claimed host version:51521. Install that exact OpenClaw version and assert the version actually present in53 `node_modules`.542. Run type checking and build **after** installing the target version.553. Start a fresh Node process with no Vitest mocks and import the compiled plugin56 entry point and any changed production module.574. Register the plugin and verify the `openclaw-weixin` plugin/channel ID and58 expected registration count.595. Exercise the smallest runtime boundary needed to prove the changed export can60 be called, without contacting the live Weixin backend.6162Restore the lockfile dependency installation before the normal full validation.6364## Packaging and documentation6566- Run `npm run pack:check` when entry points, build output, package metadata,67 dependencies, or published files change.68- Keep the declared minimum host consistent across `SUPPORTED_HOST_MIN` in69 `src/compat.ts`, the `package.json` `peerDependencies` and70 `openclaw.install.minHostVersion` fields, bilingual READMEs, `CONTRIBUTING.md`,71 and CI.72- Update matching English and Chinese `Unreleased` notes for user-visible73 compatibility changes, but leave release versioning to the maintainer flow.74- State exact tested versions and commands in the PR; do not use total test count75 as compatibility evidence.7677## Completion evidence7879- Unit mocks match production import specifiers.80- Each claimed host version passes post-install type checking, build, fresh-process81 import, and registration smoke.82- No compatibility claim depends only on the current SDK, a mock, or a green83 unrelated CI job.84- The normal `npm run check` and applicable `npm run pack:check` pass afterward.