feat(api-server): add read-only sessions, memory, skills, config endpoints

[outsourc-e]

Summary

Adds read-only and metadata endpoints to gateway/platforms/api_server.py that enable web UIs to inspect gateway state without bypassing the existing message handling pipeline.

All chat continues to flow through /v1/chat/completions exclusively — no parallel agent lifecycle, no direct AIAgent calls, no gateway runner bypass.

This follows up on #4639 feedback from @teknium1:

The read-only endpoints (listing sessions, reading memory/skills/config) are a reasonable idea, but the chat and write endpoints need to flow through the gateway's existing message handling pipeline.

What changed (1 file, purely additive)

Sessions (delegates to existing SessionDB)

• GET /api/sessions — list sessions (paginated via list_sessions_rich)
• POST /api/sessions — create session (metadata only, via create_session)
• GET /api/sessions/{id} — session details (via get_session)
• PATCH /api/sessions/{id} — update title (via set_session_title)
• DELETE /api/sessions/{id} — delete session (via delete_session)
• GET /api/sessions/{id}/messages — message history (via get_messages)

Memory, Skills, Config (read-only)

• GET /api/memory — reads ~/.hermes/memories/ files (MEMORY.md, USER.md)
• GET /api/skills — scans installed skill directories, parses YAML frontmatter
• GET /api/config — returns safe config subset (API keys stripped)

Architecture

• All handlers use the existing _check_auth() gate
• Follow established aiohttp patterns from the existing job endpoints
• Session endpoints delegate to SessionDB — the same database that /v1/chat/completions already writes to
• No new dependencies, no changes to existing endpoints or behavior
• Zero changes to the chat pipeline — web UIs connect chat through /v1/chat/completions with X-Hermes-Session-Id for session continuity

Why

The existing /v1/chat/completions endpoint handles agent creation, session persistence, and streaming. These additions fill the gap for stateful web UIs that need to read sessions, memory, and skills — following the same aiohttp patterns already established.

Testing

• All endpoints verified via curl against hermes --gateway
• Hermes Workspace connects with full capability detection
• Session CRUD, message history, skills listing, config reading all verified
• Chat flows through /v1/chat/completions + X-Hermes-Session-Id with session continuity confirmed

[Codename-11]

Superseded by #8556 which adds the same read-only endpoints plus session chat (sync + SSE streaming), memory CRUD, config write, capability probes, and 91 tests.

[Codename-11]

Closing in favor of #8556 which supersedes this with a complete session management API (20 endpoints including streaming chat, memory CRUD, config write, capability probes, and 91 tests).

[alt-glitch]

Superseded by #8556 which adds a more complete session management API. Consider closing in favor of that PR.

[alt-glitch]

Superseded by #8556.

[teknium1]

Thanks for opening this @outsourc-e — closing in favor of the focused split that's actually shipping:

• feat: add API server session controls #29302 (Codename-11) is the active session-control API on the OpenAI-compatible server. It explicitly scopes itself to sessions + capabilities and defers skills/config/memory.
• We're following up with a separate PR that adds read-only GET /v1/skills + GET /v1/toolsets to the API server — the specific gap a community user just hit asking how to list skills over REST without standing up the dashboard server.

Your PR is the original instance of this idea (April 8) and predates both #8556 and #29302. Credit retained in the lineage. The follow-up PR will link back here.

Closing as superseded — not as rejected. Thanks for the contribution.