Wire real Hermes runtime execution (HermesBridge.runTask still validates-and-queues, does not run the external submodule)

[tradersurfer]

Context

Issue #27 (Hermes bridge does not execute) is being closed by a dedicated wiring pass that fixes its two concrete defects:

1. core/BridgeExecutors.js now registers Hermes as a WorkflowRuntime executor for all 14 of its allowed task types (previously it registered only Sales Intake, Onboarding Comms, and the optional Dispute Agent).
2. The dispatch handler now calls HermesBridge.runTask() for real (the hardcoded queued short-circuit is removed), matching how the dispute-agent bridge is dispatched through its real trigger().

Issue #27 also noted: "HermesBridge.runTask() currently only returns blocked or queued; that contract should also be reviewed once the wiring itself is fixed." This issue is that review's outcome.

The remaining gap (this issue)

HermesBridge.runTask() still validates and queues — it delegates to BaseBridge.execute(), which returns blocked (validation failed) or queued (validated), and never executes the external Hermes runtime. Concretely, with the wiring now correct:

• A dispatched Hermes task returns a real, honest queued/blocked result from runTask() (verified in tests/DispatchHermes.test.js).
• A Hermes workflow step resolves to failure (validated-but-not-executed), because queued is not triggered — honest bookkeeping, verified in tests/BridgeExecutors.test.js.

So Hermes is now correctly wired but still does not execute. Making it actually execute is a separate, larger, security-sensitive piece and is intentionally out of scope for the #27 wiring pass.

Scope for this issue

• Give HermesBridge a real execution path that invokes the external Hermes runtime (the hermes-agent submodule at departments/operations/hermes/hermes-agent/) via HERMES_RUNTIME_PATH / HERMES_APPLICATION_PATH, returning triggered on genuine submission and preserving blocked/failed/queued honestly.
• This requires process/runtime invocation of an external agent runtime. SECURITY.md explicitly states Hermes is not sandboxed by this scaffold — real execution must be designed with process isolation, not bolted on. Treat sandboxing as a prerequisite, not a follow-up.
• Keep the "unconfigured runtime → queued → workflow failure" behavior for installs that have not wired a runtime; only a configured, connected runtime should reach triggered.
• Update the Hermes doctrine (departments/operations/hermes/*.md) once real execution exists, and add tests covering the triggered path (mocked runtime), the timeout path, and the unconfigured-queued path.

Acceptance criteria

• A configured Hermes runtime produces a real triggered result through both the dispatch handler and a WorkflowRuntime step.
• Execution runs under explicit process isolation consistent with SECURITY.md.
• Unconfigured installs still return honest queued/blocked and never a false success.
• Doctrine and tests reflect the real, connected behavior.

Not this issue

The #27 wiring pass (executor registration + real dispatch call + honest queued/blocked/failure semantics + doctrine correction) is complete and does not depend on this. This issue is only the real-execution layer.

[tradersurfer]

Design accepted: ADR-001 (docs/adr/ADR-001-hermes-sandboxed-execution.md) was merged in #38 as the accepted design for this work. This issue stays open as the implementation tracker.

The upstream NousResearch/hermes-agent submodule audit — a prerequisite ADR-001 calls out — has been split into its own issue: #40. That audit must complete before the HermesRuntimeAdapter, container manifest, egress allowlist, and scoped-credential wiring tracked here can be finalized.

---

Generated by Claude Code

[tradersurfer]

Status update — this did not auto-close on merge (PR #94's description didn't use a closing keyword), so updating manually rather than leaving it stale.

Shipped in PR #94 (merged, d7d24b3): the synchronous submission path. HermesBridge.runTask() now validates → checks against Hermes's seven off_limits items (ADR-009 §4 stopgap) → submits to the real gateway's POST /v1/runs when configured. A real 202 maps to triggered with the run id; a real network/auth/429 failure maps to failed with the actual reason; an unconfigured install stays honestly queued. 421/421 tests pass, clean production build, and a real curl-verified round trip through a booted next dev server.

One correction to this issue's original scope, worth stating explicitly rather than silently reinterpreting: this issue was originally scoped around invoking the hermes-agent submodule directly via HERMES_RUNTIME_PATH/HERMES_APPLICATION_PATH as a subprocess, with "process isolation consistent with SECURITY.md" as an acceptance criterion. That model was superseded before implementation by ADR-001a/ADR-001b/ADR-009: Hermes execution is an HTTP client of the gateway's api_server adapter, not a subprocess supervisor — so there's no child-process sandboxing question for PR #94 to satisfy; the equivalent hardening PR #94 actually implements is credential scoping (ADR-009 §2, tested) and the off_limits stopgap (ADR-009 §4, tested). HERMES_RUNTIME_PATH/HERMES_APPLICATION_PATH remain unused metadata fields, unchanged.

Deferred, not dropped: ADR-009 §3's post-submission async lifecycle (polling GET /v1/runs/{run_id}, SSE, waiting_for_approval → workflow waiting, run-level and approval-wait timeouts, never-auto-approve) is now tracked separately as #95.

Still pending, blocking full closure: live-gateway verification. PR #94 was built and tested against the documented ADR-001b contract with a mocked fetch, but no live Hermes gateway was reachable from that environment (no api_server adapter running, no outbound network path to one). This issue stays open until someone with an actual operator-provisioned Hermes gateway (API_SERVER_ENABLED/API_SERVER_KEY set, hermes gateway start) confirms a real POST /v1/runs round trip — the exact checklist is in PR #94's description.

---

Generated by Claude Code