Finding
Docker-based Hermes operations become fragile when container creation, restart, and test commands assume names are free instead of checking existing containers first.
Current
A real Hermes installation may use containers for gateways, local services, testing, dashboards, or supporting infrastructure. The weak point appears when an agent or operator reruns a Docker command after a failed attempt and hits a name collision, then wastes time guessing whether the old container should be reused, stopped, removed, renamed, or inspected. This turns a simple deployment or debugging step into avoidable friction and can hide the real issue behind container lifecycle noise.
Suggested
- Add a preflight check before any Docker create or run step. Exact change: add a “Docker name preflight” item to
docs/runbooks/hermes-debugging.mdor the deployment runbook: before creating a named container, list existing containers by name, confirm whether the target name is already in use, and decide whether to reuse, stop, remove, or choose a new scoped name. - Use predictable, scoped container names for Hermes-related services. Exact change: patch the relevant Docker runbook or dashboard copy to require names in the pattern
hermes-<component>-<environment>for long-lived services andhermes-test-<purpose>-<timestamp>for temporary tests, so collisions are diagnosable instead of surprising. - Add collision handling to the debugging skill. Exact change: update the Hermes debugging skill or container operations checklist with: “If Docker reports that the container name already exists, inspect the existing container first; do not remove it until its purpose, status, image, mounts, and ownership are understood.”
Impact
This reduces Docker friction by turning name collisions into a known lifecycle checkpoint instead of a debugging detour. It also prevents accidental deletion of a useful running service when an agent is only trying to rerun a setup command. For Hermes operations, the main maturity gain is safer iteration: container state becomes visible before changes are made.
Effort
Small — the improvement is mostly a runbook and habit change, plus one naming convention. No new infrastructure is required unless the installation later chooses to automate the preflight.
Public page note
Safe public content includes the operational rule, generic Docker naming patterns, preflight checklist, and the recommendation to inspect before removing containers. Internal-only content includes real container names if sensitive, raw Docker output, image tags tied to private systems, volume paths, network names, credentials, environment values, production topology, and incident-specific chat or log excerpts.