# svrnty-hermes-webui-plugin THE single repo holding every Svrnty modification to `nesquena/hermes-webui`. Loaded at runtime via the plugin loader hook patched into the fork. **Protocol contract:** [`hermes/docs/SVRNTY-PLUGIN-PROTOCOL.md`](../docs/SVRNTY-PLUGIN-PROTOCOL.md) — read this before contributing. **Adding features?** Read [`CONTRIBUTING.md`](CONTRIBUTING.md) for the 5 recipes + decision flowchart. ## Install ```bash # 1. Install the plugin in the same venv as hermes-webui pip install -e ~/workspaces/hermes/svrnty-hermes-webui-plugin # 2. Tell hermes-webui to load it export HERMES_WEBUI_PYTHON_PLUGIN=svrnty_hermes_webui_plugin # or set in docker-compose.override.yml under environment: # 3. Restart hermes-webui — endpoints under /api/* + assets under /plugins/svrnty/* land ``` Without `HERMES_WEBUI_PYTHON_PLUGIN`, hermes-webui runs vanilla (no Svrnty mods). ## What's in here | Dir | What | |---|---| | `plugin.py` | Entry point — `register(api)` wires routes + static | | `routes/` | One file per Svrnty `/api/*` endpoint (transcribe, vault_status, …) | | `static/` | Brand skin: `app.js`, `app.css`, Montserrat fonts | | `CONNECTION-MAP.md` | **AST-generated** map of every upstream symbol this plugin touches | | `scripts/` | Tooling — AST walker, upstream sync, boot smoke | | `tests/` | Unit · integration · evals (each upstream-sync runs evals) | | `.github/workflows/` | Plugin-tests · connection-map-check · upstream-drift CI | ## Public extension API The plugin loader (one fork commit in hermes-webui) exposes exactly 7 methods: ```python api.register_route(path, method, handler) # add /api/ api.register_static(prefix, directory) # serve files under /plugins//... api.inject_script(url) # add