fix: enable OpenClaw plugin during AgentGuard install

[Mr-Lucky]

Summary

• Enable the AgentGuard OpenClaw plugin when installing via setup.sh
• Enable the plugin when running agentguard init --agent openclaw
• Add a dedicated OpenClaw package entrypoint so OpenClaw loads the runtime plugin
• Add @goplus/agentguard/openclaw root shim files for documented imports
• Document the OpenClaw install behavior and update the changelog
• Keep /agentguard skill CLI passthrough docs aligned with actual CLI commands and flags

Verification

• npm run build
• node --test dist/tests/installer.test.js
• bash -n setup.sh
• git diff --check
• Verified node dist/cli.js init --agent openclaw writes plugins.entries.agentguard.enabled = true

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (32 tests)
• Manually tested the change

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

This patch introduces a few concrete regressions in OpenClaw installation and config handling.

1. severity: high — src/installers.ts / setup.sh OpenClaw config write can destroy existing config when plugins is not an object

   • Reference: src/installers.ts: enableOpenClawPlugin() and setup.sh inline Node script
   • What can go wrong: ensureRecord() blindly replaces any non-object plugins, load, or entries value with {}. If an existing OpenClaw config uses a different schema shape or stores these keys as arrays/strings, running install will silently wipe those settings and rewrite the config with only AgentGuard-related fields.
   • Fix: Validate the config shape first and fail with a clear error if plugins, load, or entries are not plain objects, rather than overwriting them.

2. severity: medium — OpenClaw install path differs between installAgentTemplates() and setup.sh, causing template/config drift

   • Reference: src/installers.ts: installOpenClaw() writes to cwd/.openclaw/..., while setup.sh writes to ~/.openclaw/...
   • What can go wrong: agentguard init --agent openclaw and setup.sh now install to different locations depending on entrypoint. Users can end up with the plugin enabled in one location and the skill/template in another, making the install appear successful while OpenClaw does not load AgentGuard.
   • Fix: Centralize the OpenClaw root resolution and use the same base path in both installer paths, or explicitly document/handle the distinction with validation.

3. severity: medium — setup.sh writes a plugin entry file that requires the wrong runtime entrypoint

   • Reference: setup.sh Node script writes require(${JSON.stringify(distIndex)}) where distIndex = "$SCRIPT_DIR/dist/index.js"
   • What can go wrong: The new package entry point is dist/openclaw.js, but the generated OpenClaw plugin module requires dist/index.js. If index.js does not export the OpenClaw runtime adapter expected by registerOpenClawPlugin, the plugin will fail at load time or register the wrong behavior.
   • Fix: Require the dedicated OpenClaw build entry (dist/openclaw.js) in the generated plugin module.

4. severity: low — existing plugins.allow entries are only updated if the field already exists, so plugin may remain disabled

   • Reference: src/installers.ts: enableOpenClawPlugin() / setup.sh config updater
   • What can go wrong: The code sets plugins.entries.agentguard.enabled = true, but if OpenClaw also requires plugins.allow to contain agentguard and that array is absent, the installer does nothing. On installs where the allowlist is omitted by default, AgentGuard will still not load.
   • Fix: Ensure the installer creates and updates the allowlist unconditionally when OpenClaw requires it, or validate against the actual OpenClaw schema and set all required fields.