Channel Wiki: #jarvis-jr-v1-hermes-setup

Channel ID: 1526844602303123466 Created: 2026-07-23 18:22 UTC Last sync: 2026-08-02 18:06 UTC

Purpose

Hermes installation, persistent runtime configuration, secret management, and setup troubleshooting.

CONFIRMED — Gitea credential (2026-08-02): authenticated operations against gitea.lego-cloud.eu must use the Bitwarden Secrets Manager key/environment variable HL_V1_GITEA_ACCESS_TOKEN. Do not use GITHUB_TOKEN for this Gitea instance and do not copy the Gitea token into /opt/data/.env.
CONFIRMED — secret naming: Hermes exports Bitwarden secret keys exactly as named; it does not create aliases. The briefly reported HL_V1_GITEA_TOKEN alias was stale cache information and was explicitly corrected.
CONFIRMED — restart semantics: /reset only resets a conversation and does not reload process environment. A gateway restart is required after Bitwarden keys change so the gateway imports them.

Bitwarden setup: enabled and operational. Live verification at sync time showed project access, bws 2.0.0, and one applied key: HL_V1_GITEA_ACCESS_TOKEN (value never exposed).
PENDING: the gateway process observed during the 2026-08-02 conversation predated the corrected Bitwarden cache and had not imported HL_V1_GITEA_ACCESS_TOKEN; run /restart once, then verify the variable is present without printing its value.

HERMES_HOME=/opt/data; this is persistent storage, so Bitwarden configuration survives gateway/container restarts and container recreation as long as /opt/data remains mounted and HERMES_HOME is unchanged.
Persistent Bitwarden components: token bootstrap in /opt/data/.env, configuration in /opt/data/config.yaml, managed CLI at /opt/data/bin/bws, and cache at /opt/data/cache/bws_cache.json.
Bitwarden configuration uses access_token_env: BWS_ACCESS_TOKEN, a 300-second cache TTL, automatic bws installation, and exact-key export.
A permissions incident made /opt/data/.env unreadable and caused repeated gateway PermissionError responses. It was fixed; at 2026-08-02 18:06 UTC both /opt/data/.env and /opt/data/config.yaml were owned by hermes:hermes with mode 0600.
gitea-repository-operations, gitea-docusaurus-projects, and the Discord knowledge-wiki Gitea creation workflow were updated to require HL_V1_GITEA_ACCESS_TOKEN and reject GITHUB_TOKEN for gitea.lego-cloud.eu. GitHub-specific workflows may continue using GITHUB_TOKEN for github.com.
The blank human message 1533511724370624693 included message.txt; its CDN URL returned HTTP 403 when this sync attempted retrieval, so its contents remain UNKNOWN. Subsequent messages and live verification establish the setup outcome above.

RootAtSkic / Lego: configured Bitwarden and directed the Gitea credential migration.
Hermes: validates secret integration without revealing values and maintains Gitea-related skills.

Owner: infrastructure operator / Lego — due date UNKNOWN: restart the Hermes gateway once so HL_V1_GITEA_ACCESS_TOKEN is imported into the gateway environment.
Owner: Hermes — due date after restart: verify gateway access to HL_V1_GITEA_ACCESS_TOKEN without displaying the value, then use it for future authenticated Gitea API operations.

Latest processed human message: 1533516194106048725 (2026-08-02 16:45 UTC).
Decision thread: human messages 1533507837391798413 through 1533516194106048725 (2026-08-02 16:12–16:45 UTC), with bot responses used only to establish implementation and verification outcomes.