⌂ Home ☷ Board

HermesProfileRuntimeAdapter implementation brief

Reviewed: 2026-05-22 13:24 SAST Reviewer: Lucienne Scope: Mission Control on Luci (/home/lucienne/workspace/mission-control) + Luci control-room docs (/home/lucienne/workspace/agent-control-room) Tracking ticket: MC-3898 Status: implementation brief / ready for coder lane; no live runtime changes made by this brief

Plain-language goal

Mission Control already knows about Hermes runtime profiles. The next safe step is to make that integration more honest and robust before anyone relies on it for production work.

In user terms: when you pick “Hermes Codex”, “Hermes Kimi”, “Hermes GLM”, etc. inside Mission Control, MC should be able to show exactly what it is going to run, where it will run, how the output comes back, and what safety boundaries apply. Hermes remains a replaceable engine underneath MC; Mission Control remains the cockpit and source of truth.

Correction / boundary from Elmar on 2026-05-22: do not let this slice turn the wider Mission Control redesign into a Hermes-specific architecture. The adapter should improve one runtime family, but the control-plane contract must remain harness-independent. MC owns tickets, routing, evidence, history, status, and user intent; Hermes, Claude Code, Codex CLI, Gemini CLI, direct scripts, and future runtimes are replaceable harnesses beneath that contract.

Current observed state

Evidence inspected read-only:

Important gap found

The current Hermes command branch builds this kind of command:

hermes --yolo --accept-hooks chat --source mc-runtime --pass-session-id --provider ... --model ...

That is structurally close, but not yet strong enough as a governed adapter contract.

Key risks:

  1. The command uses bare hermes, not /home/lucienne/.local/bin/hermes.
  2. Preflight can find Hermes because it sources shell environment and .bashrc.
  3. The tmux launch path may not always inherit the same PATH, depending on the MC service environment and tmux server state.

  4. Safer contract: resolve the executable path once and record it in runtime metadata.

  5. Hermes profile isolation is not explicit yet.

  6. Current MC Hermes profiles use provider/model flags, not dedicated Hermes profiles.
  7. That is acceptable for experiments, but long-lived parallel runtimes should move toward dedicated Hermes profiles such as luci-codex, luci-kimi, luci-glm, etc.

  8. Until then, the UI/docs must label these as “Hermes default profile with provider/model override,” not fully isolated Hermes homes.

  9. No structured Hermes session reconciliation exists yet.

  10. Current durable path is tmux pane logs + MC harvest.
  11. That keeps MC alive as source of truth, but it misses Hermes-native session metadata unless later reconciled.

  12. Borrow from lotsoftick/hermes_client: read Hermes session files only as an import/reconciliation channel, never as the primary source of truth.

  13. No explicit adapter metadata is captured for Hermes-specific invocation details.

  14. MC should record: resolved executable, redacted argv, provider, model, MC runtime profile key, Hermes profile name if used, cwd, source tag, pane log path, Hermes session id if available, and whether session-file reconciliation is enabled.

Recommended implementation slice

Slice A — Adapter honesty and executable resolution

Files likely involved:

Acceptance:

Slice B — MC runtime profile vs Hermes profile clarity

Add optional catalog fields for Hermes profiles:

"hermes_profile": "default",
"profile_isolation": "default_profile_with_provider_model_override",

Later, when dedicated Hermes profiles are created, change those to:

"hermes_profile": "luci-codex",
"profile_isolation": "dedicated_hermes_home",

Acceptance:

Slice C — Invocation metadata contract

When MC starts a Hermes runtime session, record metadata like:

{
  "adapter": "HermesProfileRuntimeAdapter",
  "command_contract_version": 1,
  "executable": "/home/lucienne/.local/bin/hermes",
  "argv_redacted": ["hermes", "--yolo", "--accept-hooks", "chat", "--source", "mc-runtime", "--pass-session-id", "--provider", "openai-codex", "--model", "gpt-5.5"],
  "mc_runtime_profile": "hermes_codex",
  "hermes_profile": "default",
  "profile_isolation": "default_profile_with_provider_model_override",
  "source": "mc-runtime",
  "cwd": "/home/lucienne/workspace/PKA",
  "pane_log_path": "/home/lucienne/workspace/logs/...",
  "session_reconciliation": "not_enabled"
}

Acceptance:

Slice D — Session reconciliation placeholder, not full import yet

Add a documented placeholder for SessionFileReconciler but do not build full sync until the adapter launch contract is stable.

Acceptance:

Tests to request from coder lane

Minimum tests:

  1. Hermes profile preflight uses the same executable resolver as launch.
  2. _command_for_profile() for hermes_codex uses the resolved executable or a clearly wrapped login shell that guarantees PATH.
  3. Runtime metadata for a Hermes session includes adapter name, command contract version, MC runtime profile key, provider/model, source, cwd, and redacted argv.
  4. Existing Claude runtime command tests still pass unchanged.
  5. Missing Hermes binary produces a readable preflight error and does not start tmux.

Optional smoke test after code review, only if safe:

Non-goals for this slice

User-facing framing

This slice is not about “coding a new AI.” It is about making the cockpit honest:

Lucienne verdict

Proceed with this as the next coder-lane slice before adding deeper Hermes session sync or a PTY setup workbench. The adapter needs honesty and metadata first; then we can safely test Hermes as a first-class Mission Control runtime.