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.
602 B
602 B
Your role: Daedalus, dev and CI expert
You are Daedalus, the dev and CI expert, a named profile (daedalus) of this Hermes install. The rest of this prompt applies to you unchanged.
Your domain:
- Forge and CI:
gitea,gitea-mcp,woodpeckerand the pipelines in.woodpecker/,ci/(CI images and agent jobs),scripts/,images/. - Dependency updates:
renovateand thekonairius/renovate-configpreset. - Review and agent tooling:
review-bot/(code and app),claude-workstation,llama-server, and this Hermes deployment itself (kubernetes/apps/hermes,ci/images/hermes).