Skip to content

Release Compatibility Gate

Use this checklist before publishing a Rampart release that advertises agent integration support. It keeps support claims tied to evidence from the exact candidate build, not a prior local install or stale plugin copy.

Support tiers

Rampart uses these tiers in the support matrix:

  • Recommended: actively tested against the current stable runtime, polished approval UX, and clear rampart doctor checks.
  • Supported: documented and regression-covered, with narrower UX or less frequent runtime smoke coverage.
  • Experimental: installable and useful, but with known limits that are still part of the public contract.
  • Legacy compatibility: maintained where practical for older clients, but not the preferred path.

Hermes Agent remains experimental until Hermes exposes a stable plugin approval/resume primitive and a full end-to-end test proves a single user-facing approval, exact tool-call resume, deny non-bypass, and audit/result correlation.

Required gate for release candidates

  1. Start from a clean candidate
  2. Fetch the target release branch and validate a clean worktree.
  3. Build the exact candidate commit.
  4. Reinstall bundled agent plugins from that exact build.

  5. Compare binary version, plugin manifest version, and runtime-reported plugin version.

  6. Check upstream version currency

  7. Record latest stable OpenClaw from npm.
  8. Record latest stable Hermes Agent from PyPI.

  9. Treat upstream release notes touching plugin discovery, hook dispatch, approval behavior, native tool relay, model/tool execution, or security boundaries as compatibility-relevant.

  10. Validate latest stable OpenClaw

  11. Use a controlled OpenClaw state, not a dirty local gateway config.
  12. Install the candidate Rampart OpenClaw plugin.
  13. Run openclaw config validate when available.
  14. Confirm plugin metadata reports the candidate version and startup activation.
  15. Exercise allow, ask, and deny with a unique marker.
  16. For command execution paths, require OpenClaw runtime evidence plus a correlated Rampart audit event for canonical exec.

  17. Check for stale shim, dist patch, or duplicate enforcement paths before calling the result clean.

  18. Validate latest stable Hermes Agent in isolation

  19. Use a temporary HERMES_HOME or temporary home directory.
  20. Install latest Hermes Agent in a temporary Python environment.
  21. Install the candidate Rampart plugin into only that temporary Hermes plugin directory.
  22. Enable only the temporary Hermes config.
  23. Exercise the real Hermes plugin dispatcher, including plugin discovery and pre_tool_call hook registration.
  24. Prove deny blocks before execution, allow continues, ask blocks with an approval-required/no-resume message, Rampart auth failures fail closed for mutating tools, and mutating tools fail closed when Rampart is unavailable.

  25. Do not restart or mutate a live Discord, Telegram, or other long-running Hermes gateway for this gate.

  26. Run rampart doctor as a support-contract check

  27. Group findings by integration surface.
  28. Classify each finding as blocker, expected optional local gap, or follow-up diagnostic improvement.

  29. Do not collapse OpenClaw, Hermes, Claude Code, Codex, and Cline findings into one global yes/no.

  30. Publish claims that match the evidence

  31. OpenClaw can be called recommended only when the latest stable path has fresh runtime/audit proof.
  32. Hermes can be called an experimental policy gate when isolated latest-Hermes plugin dispatch has deny, allow, ask-block, and fail-closed proof.
  33. Full Hermes support requires Hermes-owned approval/resume APIs plus live or staging end-to-end validation.

CI and local compatibility scripts

The repository includes compatibility harnesses for latest upstream agent checks:

python scripts/compat-hermes-latest.py
node scripts/compat-openclaw-latest.mjs --npm-latest

The Hermes harness installs or uses an isolated Hermes runtime and never touches the active gateway. The OpenClaw harness can run either the openclaw on PATH or --npm-latest for the latest npm package, uses a temporary home/state directory, and validates plugin installation plus the bundled plugin behavior checks.

For OpenClaw's recommended support tier, also run the opt-in runtime audit regression before a release promotion:

RAMPART_OPENCLAW_RUNTIME=1 node scripts/test-openclaw-codex-native-audit.mjs

That live regression is intentionally separate from scheduled CI because it temporarily enables the OpenClaw Rampart plugin, restarts local OpenClaw user services, runs one real OpenClaw Codex app-server turn, and requires correlated OpenClaw trajectory plus Rampart canonical exec audit proof.

A scheduled/manual GitHub Actions workflow runs these upstream checks outside the core unit-test matrix so external upstream breakage is visible without destabilizing ordinary pull-request CI.