Repro (verified live)

While smoke-testing the just-merged devagentic-docs plugin (#19/#20), found that every GraphQL request silently 404s against the canonical devagentic deployment on devbox:

$ curl -X POST -H "Content-Type: application/json" -H "X-User-Id: hermes-maintainer" \
       -d '{"query":"{__typename}"}' \
       http://devbox:6070/graphql
404
$ curl -X POST -H "Content-Type: application/json" -H "X-User-Id: hermes-maintainer" \
       -d '{"query":"{__typename}"}' \
       http://devbox:6071/graphql
404

Probed 6070, 6071, 6072, 8000, 8080, 8888, 4000, 5000. None expose /graphql. The HTTP surface on devbox:6070 exposes:

• GET /canvas → 200 (HTML canvas index)
• GET /v1/canvases → 401 (REST canvas API — works with auth)
• POST /graphql → 404 (no GraphQL HTTP endpoint)

The schema exists — proven via in-process introspection over SSH:

$ ssh dev@devbox 'cd /home/dev/projects && DEVAGENTIC_USER_ID=hermes-maintainer \
                  .venv/bin/python -c "from api import schema; \
                  print(schema.execute_sync(chr(123)+\"__typename\"+chr(125)).data)"'
{'__typename': 'Query'}

…but only as a Python import, not over HTTP.

Impact

Three hermes adapters depend on <DEVAGENTIC_BASE_URL>/graphql:

• agent/devagentic_skills.py — DEVAGENTIC_SKILLS_GRAPH=1 opt-in path
• agent/devagentic_memory.py — DEVAGENTIC_MEMORY_GRAPH=1 opt-in path
• plugins/devagentic-docs/ — /doc + /fork slash commands (shipped in devagentic-docs: MVP plugin (/doc search | write | show) #19/devagentic-docs: fix searchDocs schema + add /fork + pre_llm_call hook #20)

All three silently return None on every call against the current canonical devagentic deployment. The skills + memory adapters then fall back to files (correct loss-tolerant behavior, but the operator gets zero signal); the docs slash commands surface a Reason: not found at <url>/graphql via #15's last_error_text() pattern (correct loud behavior, but misleading because /graphql is intentionally missing on this deployment).

The diagnostic added in #17/#18 already catches this — hermes doctor reports Devagentic GraphQL: not found at <url>/graphql. Just needs a sharper hint pointing operators here.

Two-pronged scope

Hermes-side (this issue)

Small DX changes only. The transport refactor is a devagentic decision, not ours.

1. Doctor's 404 message — point at this issue, suggest verifying /graphql is exposed before assuming the env vars are wrong. Currently says "verify DEVAGENTIC_BASE_URL points at a graph-enabled instance" which is correct but vague.
2. Adapter docstrings (skills + memory + docs README) — explicit "requires devagentic to expose /graphql over HTTP" line, with a pointer to this issue.
3. No code changes to transport. We don't try to invent an alternative path (SSH-tunneled, in-process bridge, etc.) — that's a much bigger design.

Devagentic-side (out of scope here)

The real fix is upstream: either expose /graphql over HTTP on the canonical deployment, or document an alternative HTTP transport for the schema. Filing this on devagentic as a companion issue.

Filed by hermes-maintainer (PowerCreek). PR for the hermes-side DX delta incoming.