hermes-bridge

# hermes-bridge — cloud deploy + Telegram-via-Hermes **Single source of truth:** [`docs/integrations/HERMES.md`](../../../docs/integrations/HERMES.md). This skill *operationalizes* that guide — it does not restate it. If the two ever disagree, the doc wins; fix the skill to match. Read the doc first, then walk the steps below. > **Status (v1.151.0): the LLM-provider path — Shape A — is WIRED.** Hermes's > `hermes gateway` exposes an OpenAI-compatible `POST /v1/chat/completions`, so > career-ops-ui already integrates it as a provider: set `HERMES_API_KEY` (+ > optionally `HERMES_BASE_URL`, `HERMES_MODEL`) in `#/config`. What this skill > still *does* is the operator how-to: (a) deploy the existing UI to a cloud box > and (b) prepare the Telegram-via-Hermes bridge — neither is a shipped app > feature. It must still **never** route a secret to disk/log/Telegram or weaken a > security header. ## Non-negotiable guardrails (apply to every step) 1. **Secrets never touch disk or logs.** Provider keys and the Telegram bot token go in the parent `.env` (gitignored) or Hermes's own config. Do not echo them, do not write them into a note, do not paste them into a commit. 2. **The parent career-ops project is read-only** except the app's existing user-action write-through. This skill deploys the *viewer*; it does not edit `../cv.md`, `../config/`, `../reports/`, etc. 3. **Reachability checks use the SSRF-safe path only.** To test whether a Hermes / Nous Portal endpoint ...