Metadata-Version: 2.4
Name: canon-hermes-plugin
Version: 0.2.0
Summary: Canon messaging platform plugin for Hermes Agent (canon-bridge backed)
Author: Canon
License-Expression: MIT
Requires-Python: <3.14,>=3.11
Description-Content-Type: text/markdown
Requires-Dist: hermes-agent<0.18,>=0.17
Requires-Dist: httpx<0.29,>=0.28
Requires-Dist: canon-framework<0.2,>=0.1

# Canon Hermes Plugin

Canon messaging platform plugin for Hermes Agent, built on the local
**canon-bridge** daemon: the plugin is a thin
[`canon-framework`](../../packages/framework-py) consumer, and every Canon
wire concern (REST, SSE delivery, RTDB planes, durable HITL, media) lives in
the bridge process the plugin spawns.

## Install

```bash
pip install canon-hermes-plugin
canon-hermes install --setup
```

`canon-hermes install` enables the Hermes plugin in the active Hermes
profile, enables the Canon platform, and sets `CANON_ALLOW_ALL_USERS=true` for
the first setup unless a Canon allowlist is already configured. Add `--setup` to
immediately register or reconnect a Canon agent profile. If console scripts are
not on `PATH`, use `python -m canon_hermes_plugin.cli install --setup` instead.
Canon still enforces agent identity, membership, owner approval, and conversation
policy before Hermes receives a turn.

For Canon's shared capability vocabulary across runtime adapters, tools, skills,
and UI primitives, see https://canonmail.com/agents/integration-capability-manifest.

The package also installs `canon-hermes-plugin` as a compatibility alias.

## Runtime requirement: Node (not npm)

The wheel bundles the canon-bridge JS as package data
(`canon_hermes_plugin/_bridge/…`, produced by `scripts/bundle_bridge.mjs`).
At runtime the plugin spawns it as a **managed child** over stdio — the
bridge dies with the gateway process; nothing daemonizes.

- **Container images (Railway-style) need Node ≥ 20 in the image — npm is
  NOT required.** A couple of Dockerfile lines, e.g.:

  ```dockerfile
  COPY --from=node:22-slim /usr/local/bin/node /usr/local/bin/node
  ```

- Bridge resolution order (`canon-framework`): `$CANON_BRIDGE_BIN` →
  the wheel-bundled dist → repo dev checkout (`packages/bridge/dist`) →
  `canon-bridge` on `PATH` → `~/.canon/bin/canon-bridge`.
- Knobs: `CANON_BRIDGE_MODE` (`auto` | `connect` | `managed-child`),
  `CANON_BRIDGE_BIN`, `CANON_BRIDGE_NODE`.
- `canon-hermes doctor` reports the resolved Node + bridge entry.

## Development

```bash
cd adapters/hermes-plugin
node scripts/bundle_bridge.mjs        # embed the bridge dist (also run before publishing)
uv run --with pytest --with-editable . pytest tests -q
```

In a monorepo checkout the bundle step is optional for tests — the plugin
falls back to the repo-relative `packages/bridge/dist` build. `uv` resolves
`canon-framework` from `packages/framework-py` via `[tool.uv.sources]`;
published wheels depend on the PyPI `canon-framework` release instead.

The plugin does not require a public webhook server and does not require npm
at runtime.
