Finding
Hermes install and build failures become expensive when dependency fixes are discovered interactively but not pinned, verified, and captured as reusable installation knowledge.
Current
A real Hermes installation may rely on Python packages, browser automation dependencies, Node tooling, MCP servers, TTS components, gateway services, and profile-specific scripts. The weak point appears when a build or install fails, the operator finds a workaround, and the fix remains only in chat history or shell history. Without a dependency runbook, lockfile discipline, and a verification habit, the same failure can reappear during upgrades, fresh installs, container rebuilds, or profile migrations.
Suggested
- Add a dependency triage runbook for install and build failures. Exact change: create
docs/runbooks/dependency-triage.mdwith this sequence: capture the failing package or command at a high level, identify the dependency boundary, read the first meaningful error, check official install notes, apply the smallest pin or system prerequisite, rerun the install, and document the verified workaround without raw logs or secrets. - Pin known fragile dependencies where Hermes behavior depends on them. Exact change: update the relevant
requirements.txt,pyproject.toml,package.json, Docker build notes, or profile setup file with explicit version pins plus a short comment explaining the operational reason, such as browser automation compatibility, TTS runtime support, MCP SDK compatibility, or gateway stability. - Convert repeated dependency fixes into a skill or setup checklist. Exact change: add a “Dependency Hell Tourist” item to the Optimizer Agent review prompt: “When the same install, build, browser, TTS, MCP, or package-manager workaround appears twice, recommend a skill patch or setup checklist entry with exact prerequisites, commands, pins, and verification.”
Impact
This reduces repeated debugging during upgrades and rebuilds because the working dependency boundary is preserved instead of rediscovered. It also makes Hermes safer to operate across profiles and environments: fragile packages are pinned intentionally, and workarounds become documented procedures rather than tribal knowledge. Public documentation can describe the maturity pattern without exposing private logs, environment values, or exact production paths.
Effort
Medium — the runbook and review habit are small, but dependency pinning requires careful verification because an incorrect pin can freeze a bug or break another Hermes component.
Public page note
Safe public content includes the achievement meaning, the dependency-triage pattern, generic examples of pins and verification habits, and the operational benefit of reusable install knowledge. Internal-only content includes raw install logs, package mirrors, credentials, environment variables, private filesystem paths, production container details, exact failure traces, and customer- or business-specific workaround history.