claude-bot
bb3cee8a3c
Adds five expert profiles to the existing hermes pod, managed from git: hestia (home automation), atlas (platform), apollo (media), clio (documents and web), daedalus (dev and CI). Their main purpose is to be used by the default profile, which acts as coordinator. - experts/<name>.md: each expert's role and domain (apps, repos, domain rules). ConfigMap hermes-experts. - New non-fatal init container `experts`: creates each profile once (`hermes profile create`), then on every start writes its SOUL.md (shared SOUL.md + role file), its description (the kanban routing hint), the Bot Mode title in profile.yaml (`ui_meta.hermes-bots`, which also enables message_agent in Bot Chats), skills.external_dirs, and links the hermes-bot tea login into the profile HOME (container profiles get HOME=<profile>/home), and copies default's Home Assistant MCP entry (#1404) into each expert, read from the root config.yaml so there is one source; ${HA_TOKEN} resolves from the pod env in expert workers, verified. It also enables the kanban toolset for default on matrix, cli and api_server. - SOUL.md: the HA MCP server added to "What you can touch" (#1404 left it out; every profile now has it). "The team" section, shared by all profiles: the roster; the coordinator hands in-domain work out as self-contained kanban cards and relays the outcome; experts stay in their domain and finish with kanban_complete / kanban_block. - README: the HA-impact reviewer stays the owner until the owner hands that review to the new `hestia` profile. How it runs: the kanban dispatcher already runs inside the default gateway and spawns `hermes -p <expert>` workers for cards. Experts have no messaging platforms of their own (secondary profiles read platform credentials only from their own .env), so nothing double-binds Matrix or the API server. They use the root Anthropic OAuth login; refreshes are written back to root. Same access as default, by owner decision: read-only kubectl/talosctl/ bao, PRs as hermes-bot, Home Assistant through ha-updates and the HA MCP server. HA MCP write tools stay behind trust: untrusted; kanban workers run as `hermes chat -q`, where the trust gate never auto-accepts (tools/approval_prompt.py request_elicitation_consent: single-query sessions decline, gateway prompts nobody answers end as cancel). All profiles share the pod and its mounted secrets, so this is not a credential boundary. Verified locally in the current image (build.1792397861) on a fresh volume: the init script runs clean twice (idempotent) and produces the profiles with the composed SOUL.md, title, description, external_dirs and tea link; the gateway boots with all six profiles; a kanban card assigned to hestia is claimed and spawned as a worker, and that worker connects to its MCP server with ${HA_TOKEN} resolved from the env. Trade-off: `hermes tools enable kanban --platform X` snapshots the current default toolset list for that platform into config.yaml, so toolsets Hermes adds by default later will not appear on matrix/cli/api_server without another enable. After merge: nothing manual. Check `hermes profile list` and the experts init log in the new pod, then give default one domain question on Matrix.
homelab
GitOps source for the Renner homelab cluster. Flux applies main to
production, so every merge is a production change. Changes go in by pull
request only; see CONTRIBUTING.md for YAML conventions.
Change rules that protect Home Assistant
Owner decision (REN-240, REN-243). Home Assistant runs the house, so it gets two rules on top of normal review.
1. Disruptive work runs only 02:00–05:00 Europe/Berlin
Planned work that can restart Home Assistant or disrupt the cluster is merged and applied only between 02:00 and 05:00 Europe/Berlin. That covers:
- node drain, node reboot, Talos upgrade
- CNI (Cilium, Multus) and cluster-wide network policy
- storage (Rook/Ceph, CSI, snapshot controller, CNPG operator)
- Flux core (
kubernetes/clusters/*/flux-system/, Flux controllers) - Authentik
- OpenBao, including secret rotation that restarts consumers
- anything in
kubernetes/apps/home-assistant/
A PR in this list states in its description that it waits for the window. Flux applies on merge, so "wait for the window" means merge in the window, not just apply. If unsure whether a change is disruptive, treat it as disruptive.
Not covered: Home Assistant image bumps by Flux image automation. They stay fully automatic by owner decision. If one breaks Home Assistant, roll it back with RUNBOOK-home-assistant-image-rollback.md. An incident rollback is not planned work; the owner decides its timing.
Also not covered, by owner decision: the Hermes ha-updates job
(kubernetes/apps/hermes/skills/ha-updates/) installs HACS and device-firmware
updates that Home Assistant offers, and restarts Home Assistant for them, on
its own inside the 02:00–05:00 window (UniFi and SMLIGHT firmware excluded;
reported only). The window is enforced by its ha.py, not only by the prompt.
2. HA-impact review before merge
Every PR that touches kubernetes/apps/home-assistant/, or makes a
cluster-wide disruptive change from the list above, needs an HA-impact
review before merge: a named reviewer states in the PR what Home
Assistant will notice (restart, lost integration, lost history, none) and
approves.
- Reviewer: Hestia, the Home Assistant maintainer.
- Until the owner hands this review to Hestia (the
hestiaHermes profile, which today only states the expected impact in its PRs): the owner does the HA-impact review.
This is in addition to the normal review and merge by Argus. Argus does not merge such a PR without the HA-impact approval.