hermes-agent

mirror of https://github.com/NousResearch/hermes-agent.git synced 2026-07-29 18:46:59 +00:00

History

vaibhavjnf fe95194c59 feat(photon): render multiple-choice clarify as a native iMessage poll The `clarify` tool's multiple-choice prompts flattened to a numbered text list on Photon/iMessage, even though iMessage has a native poll bubble and spectrum-ts already exposes it via the `poll()` content builder. Two gaps caused the flattening: * Outbound: the sidecar only had `/send` (text); there was no way to send a poll, so the base adapter's numbered-text fallback was used. * Inbound: `normalizeContent()` handled only text/attachment/voice, so a poll vote (`poll_option`) was dropped on the floor ("[Photon content type not handled: poll_option]") and never resolved the clarify. Fix, end to end: * Sidecar: import `poll` from spectrum-ts; add a `/send-poll` route (`space.send(poll(title, ...options))`); serialize inbound `poll_option` (the vote: chosen title + selected bool) and `poll` content in `normalizeContent()`. * Adapter: override `send_clarify` — for choices, send a native poll via `_sidecar_send_poll` and call `mark_awaiting_text` so the gateway's existing pending-clarify text-intercept resolves the answer; open-ended clarifies keep the plain-text path. Inbound `poll_option` selections are dispatched as a plain-text MessageEvent carrying the chosen option (deselections / empty votes are dropped). If the poll send fails (an older sidecar without `/send-poll`, or a send error) it falls back to the numbered-text clarify, so nothing regresses on a half-upgraded restart. No new model tool, no new env var, no core change — the capability lives at the platform edge. The poll vote reuses the existing clarify text-intercept resolution path, so no new gateway resolution mechanism is introduced. Tests: tests/plugins/platforms/photon/test_poll_clarify.py — inbound vote -> choice text, deselection/empty-vote dropped, send_clarify sends a poll + enables text-capture, open-ended stays text, and poll-failure falls back to the text list. Full photon suite green. Contributed by Vaibhav Sharma (X: @vabbyshabby).	2026-07-28 22:10:57 -07:00
..
emails	feat(photon): render multiple-choice clarify as a native iMessage poll	2026-07-28 22:10:57 -07:00
README.md	fix(ci): make tests, workflows, and attribution reliable under load (#66373 )	2026-07-17 20:55:24 +00:00

vaibhavjnf fe95194c59 feat(photon): render multiple-choice clarify as a native iMessage poll

The `clarify` tool's multiple-choice prompts flattened to a numbered text
list on Photon/iMessage, even though iMessage has a native poll bubble and
spectrum-ts already exposes it via the `poll()` content builder. Two gaps
caused the flattening:

  * Outbound: the sidecar only had `/send` (text); there was no way to send
    a poll, so the base adapter's numbered-text fallback was used.
  * Inbound: `normalizeContent()` handled only text/attachment/voice, so a
    poll vote (`poll_option`) was dropped on the floor ("[Photon content
    type not handled: poll_option]") and never resolved the clarify.

Fix, end to end:

  * Sidecar: import `poll` from spectrum-ts; add a `/send-poll` route
    (`space.send(poll(title, ...options))`); serialize inbound `poll_option`
    (the vote: chosen title + selected bool) and `poll` content in
    `normalizeContent()`.
  * Adapter: override `send_clarify` — for choices, send a native poll via
    `_sidecar_send_poll` and call `mark_awaiting_text` so the gateway's
    existing pending-clarify text-intercept resolves the answer; open-ended
    clarifies keep the plain-text path. Inbound `poll_option` selections are
    dispatched as a plain-text MessageEvent carrying the chosen option
    (deselections / empty votes are dropped). If the poll send fails (an
    older sidecar without `/send-poll`, or a send error) it falls back to the
    numbered-text clarify, so nothing regresses on a half-upgraded restart.

No new model tool, no new env var, no core change — the capability lives at
the platform edge. The poll vote reuses the existing clarify text-intercept
resolution path, so no new gateway resolution mechanism is introduced.

Tests: tests/plugins/platforms/photon/test_poll_clarify.py — inbound vote ->
choice text, deselection/empty-vote dropped, send_clarify sends a poll +
enables text-capture, open-ended stays text, and poll-failure falls back to
the text list. Full photon suite green.

Contributed by Vaibhav Sharma (X: @vabbyshabby).

2026-07-28 22:10:57 -07:00

emails

feat(photon): render multiple-choice clarify as a native iMessage poll

2026-07-28 22:10:57 -07:00

README.md

fix(ci): make tests, workflows, and attribution reliable under load (#66373 )

2026-07-17 20:55:24 +00:00

README.md

This directory replaces appending entries to AUTHOR_MAP in scripts/release.py. The old dict caused constant merge conflicts when several salvage PRs landed at once — every PR edited the same lines of the same file. Here, each mapping is its own file, and file additions never conflict.

Adding a mapping

One file per commit-author email, under emails/:

python3 scripts/add_contributor.py <email> <github-login>
# or by hand:
echo "<github-login>" > contributors/emails/<email>

File name = the exact commit-author email (as shown by git log --format='%ae').
File content = the GitHub login on the first non-comment line. Lines starting with # are comments (use them for the PR reference).

Example — contributors/emails/jane.doe@example.com:

janedoe
# PR #12345 salvage (gateway: fix session key routing)

Rules

Do NOT add new entries to AUTHOR_MAP in scripts/release.py. That dict is frozen legacy data; the release tooling merges it with this directory (directory entries win on duplicates).
GitHub noreply emails (<id>+<login>@users.noreply.github.com and <login>@users.noreply.github.com) auto-resolve — no file needed.
The Contributor Attribution Check CI job fails a PR whose commits carry an unmapped email; the failure message prints the exact command to run.

README.md

Contributor email → GitHub login mappings

Adding a mapping

Rules