feat(sink): add hermes sink for OpenAI-compatible /v1/runs delivery

[IYENTeam]

Summary

• Add a new HermesSink so clawhip can route GitHub events to Hermes Agent (https://github.com/nousresearch/hermes-agent) as a peer of OpenClaw — i.e. as a decision authority for IYEN label-driven workflows.
• Wire it through the existing sink/router/dispatch/daemon machinery using the same pattern OpenClawSink and IyenSystemSink follow.
• 312 LOC new + 80 LOC modifications. 5 new unit tests; full suite still green (314 passed, 0 failed).

Why

Hermes plays the same role OpenClawSink plays — receive a clawhip-routed event, decide the lane, apply the lane label using its own bot identity. The label that exits Hermes is the only signal IYENsystem reads, identical to the OpenClaw flow. clawhip stays in its lane (router only); Hermes does the deciding and the GitHub write.

This unblocks running an IYEN deployment with Hermes instead of OpenClaw as the decider. The companion skill (decision rubric + GitHub label call) lives in the IYENsystem repo (a parallel PR adds integrations/hermes-skill/iyen-triage/SKILL.md and docs/HERMES_ROLES.md).

What ships

Piece	Location
Sink implementation	src/sink/hermes.rs (new, 312 LOC)
Sink target variant	src/sink/mod.rs::SinkTarget::Hermes
Match-arm coverage	src/discord.rs, src/slack.rs (peer clients reject Hermes targets explicitly)
Dispatch routing key	src/dispatch.rs::sink_target_key
Config	src/config.rs::HermesConfig under [providers.hermes] (base_url, auth_token, optional instructions/model)
Validation	src/config.rs::validate rejects sink = "hermes" routes when provider not configured
Router label mapping	src/router.rs accepts "hermes" as a sink
Daemon wiring	src/daemon.rs registers sink when [providers.hermes].is_configured(), applying optional overrides

Why POST /v1/runs (not chat completions)

• Returns 202 + run_id immediately → matches the fire-and-forget contract clawhip sinks use today (compare: OpenClawSink::send drops the response body)
• Lets Hermes do tool calling (GitHub label apply) inside the same run rather than forcing clawhip to parse a streaming reply and apply the label itself — which would push clawhip out of its "router only" lane
• Doesn't tie the decision lifetime to the HTTP request — Hermes can take as long as it needs without clawhip holding a TCP slot

What this sink deliberately does NOT do

• Parse Hermes's reasoning / decision (we never see it; the label coming back through GitHub is the decision)
• Apply GitHub labels (Hermes does that with its own bot identity, same as OpenClaw)
• Retry on Hermes errors (best-effort delivery is the dispatch contract; if Hermes is down the route just drops, like OpenClaw)

These are stated as invariants in the module docstring so a future maintainer can't accidentally break the role separation.

Configuration example

[providers.hermes]
base_url = "http://127.0.0.1:8000"
auth_token = "<hermes gateway bearer>"
# Optional:
# instructions = "...custom IYEN prompt..."
# model = "openai/gpt-4o"

[[routes]]
event = "github.issue-opened"
sink = "hermes"

[[routes]]
event = "github.pull-request-opened"
sink = "hermes"

Test plan

cargo build           # clean
cargo test            # 314 passed, 0 failed (added 5 new hermes tests)

New tests cover:

1. is_configured boundary cases (None, empty, whitespace-only)
2. endpoint strips trailing slash and appends /v1/runs
3. body shape — instructions, input[].content[].text, metadata, stream: false
4. model pin-through
5. with_instructions override (default constant must NOT leak when overridden)
6. Contract test: default instructions must mention every iyen:* label IYEN's workflows trigger on. Adding a new lane label forces an update here.

Mutually exclusive with OpenClaw

A deployment runs one decision authority at a time. Per-repo split is fine (one route filters repo = A to Hermes, another routes repo = B to OpenClaw); two deciders on the same repo would race on the label.

Companion changes (separate PR in iyensystem repo)

• integrations/hermes-skill/iyen-triage/SKILL.md — Hermes-side decision rubric and GitHub label call
• docs/HERMES_ROLES.md — operator-facing role contract, parallel to docs/OPENCLAW_ROLES.md
• examples/config.toml — hermes-bot pre-registered in [safety].system_actors and allowed_label_actors so swapping deciders doesn't require a config edit there

[changeroa]

Summary: The PR head appears to introduce GitHub PR review polling and related events integration for clawhip, including new data models, fetchers, and tests. However, the PR title states: feat(sink): add hermes sink for OpenAI-compatible /v1/runs delivery, which does not map to the visible changes in this diff (the changes visible here align with PR reviews/CI polling rather than a Hermes/OpenAI sink integration).

Notes and suggestions:

• Scope alignment: If the Hermes sink for OpenAI is indeed the intended target, please point to the Hermes sink module and the delivery path in the codebase. If not, consider aligning the PR title and description with the code changes (e.g., something like “feat(github): add PR review polling and CI status events”).
• Error handling: The new logic fetches reviews, check-runs, and workflow runs. Ensure error paths gracefully degrade to the previous state instead of panicking or breaking the source loop.
• Data model stability: Ensure newly introduced types (e.g., ReviewSnapshot, GitHubCISnapshot) serialize/deserialize consistently with existing state and that any optional fields have sane defaults.
• Performance considerations: Multiple external API calls per PR can add latency and throttle. Consider caching, backoff strategies, or aggregating requests where feasible.
• Testing: Review tests added for normalization and PR reviews. Ensure tests cover failure modes (HTTP errors, rate limiting) and do not rely on real network calls in CI unless properly mocked.
• Logging: Current code emits a lot of eprintln logs for GitHub interactions. Gate verbose logging behind a debug/trace flag or redact sensitive details in production.
• Documentation: Update developer/docs to reflect the new PR-review polling flow and data structures, including any configuration knobs (e.g., enabling/disabling PR review emission).

If you want, I can add targeted inline feedback once you confirm the precise area to annotate (and provide a quick walkthrough of any intended Hermes/OpenAI sink integration).