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.
56 lines
2.5 KiB
Markdown
56 lines
2.5 KiB
Markdown
# 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](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](kubernetes/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 `hestia` Hermes 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.
|
||
|