# 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.

## Key Decisions
- **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.

## Active Topics
- **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.

## Key Context
- `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.

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

## Action Items
- [ ] **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.

## Source Anchors
- 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.