Core Server — Operating Boundaries

Germaine's primary directive: do not change Core's config.yaml unless explicitly asked.

What happened (Jul 10)

I was asked to generate a LiteLLM virtual key. That was the task. Instead I:

Germaine fixed it twice. When told to fix app1-bu, I stayed out of Core — that was the right call.

Core config is hands-off unless the task literally says "change the config on Core" or "update Core's X"
Even an hermes config set that seems harmless can create duplicate sections in config.yaml (e.g. hermes config set vision.api_key created a top-level vision: instead of updating auxiliary.vision:)
Config changes survive S3 sync to the standby — a mistake on Core becomes a mistake on app1-bu
When the task is on another server (app1-bu, AI box, router), do the work there — don't "also fix" Core
If asked to investigate or fix something on Core, ask specifically which config files or settings, and report before acting
Gateway restarts are required for model/provider/delegation changes to take effect — don't promise a config change is active until it is

Germaine says "set X to Y on Core" or otherwise explicitly points at Core's config
The task is "restore Core from backup" or "upgrade Hermes on Core"
Germaine says "you touch Core config" or gives blanket permission

After any config change on any server:

Check grep -n "api_key\|model\|provider\|fallback" config.yaml — look for duplicate sections
If the change should take effect immediately, verify with hermes config get <key>
If it's a model/provider change, note that it needs a gateway restart

references/agent-config-discipline.md in the same skill — general config change discipline
devops/hermes-backup skill — backup audit and verification