fix(discord): make clarify button labels always legible

[trevornk]

Summary

Discord clarify buttons previously embedded truncated choice text directly in button labels. Mobile clients cut or wrap those labels aggressively, so even valid 80-character labels remain difficult to read.

Changes

• Button labels are short numeric indexes.
• Full numbered choice text appears in the embed field.
• The same choices are mirrored in plain message content because some clients hide embeds.
• The plain fallback now budgets the question, numbered choices, and instruction suffix against Discord's 2,000-character message-content limit.
• Oversized choice text is truncated explicitly with [additional choice text truncated] while preserving the prompt and response instructions.
• Existing dict-choice normalization remains intact.

Tests

Coverage verifies short button labels, full choice visibility, dict unwrapping, embed limits, and the 2,000-character plain-content cap with oversized choices.

pytest -q tests/gateway/test_discord_clarify_buttons.py
22 passed

git diff --check is clean.

[teknium1]

Thanks for addressing a real Discord clarify UX issue. Current main still builds button labels from choice text in plugins/platforms/discord/adapter.py:7552-7584, while Telegram already uses body text plus numeric labels at plugins/platforms/telegram/adapter.py:4689-4724.

Problems

• plugins/platforms/discord/adapter.py:5806 in this diff truncates option_lines to 1024 characters, but the changed embed value appends a 65-character instruction suffix. A long option list can therefore create an 1089-character Choices field, above Discord's 1024-character cap, and send_clarify() will return a failed send after the caught API error.
• This Discord-focused PR also carries unrelated changes in agent/chat_completion_helpers.py, hermes_cli/doctor.py, hermes_cli/plugins_cmd.py, plugins/memory/hindsight/__init__.py, and tools/lazy_deps.py.

Suggested changes

• Cap the complete Choices-field value, reserving instruction text before truncating options, and add a boundary regression test asserting the field stays within 1024 characters.
• Split the unrelated carried commits so the Discord fix can be reviewed and salvaged independently.

Automated hermes-sweeper review.

[teknium1]

option_lines is capped at 1024 here, but the next field value appends the 65-character instruction suffix. Cap the complete rendered field (or reserve suffix space first), otherwise a long option list exceeds Discord's 1024-character embed-field limit and the prompt send fails.

[trevornk]

Thanks for the catch — both points were real, fixed in the updated commit:

1. Embed field cap bug: the truncation only bounded the option-list portion at 1024 chars, then appended the ~65-char instruction suffix afterward, so the combined value could hit ~1089 chars — over Discord's real 1024-char embed-field limit. Now reserves suffix length before truncating, so the combined field value never exceeds the cap. Added a boundary regression test (24 long choices) asserting the rendered field stays ≤1024 chars and the suffix is never dropped.

2. Unrelated files: confirmed — the branch had picked up 4 fork-local commits before I cut it (three explicitly tagged [carried], one untagged plugin symlink fix) that had no business in a Discord-only PR. Rebased cleanly onto current upstream main and dropped all four; this PR is now a single commit touching only plugins/platforms/discord/adapter.py and its test file.

Verified: pytest tests/gateway/test_discord_clarify_buttons.py → 21/21 pass (20 existing + 1 new boundary test), ruff check clean, git diff --check clean.

[trevornk]

The inline review comment on option_lines = "\n".join(...) (line 5806) reflects an earlier, since-amended revision of this diff — the review's own diff_hunk snapshot shows no suffix-budget reservation, but the commit it's anchored to (7275c6b6) already contains the fix:

option_lines_full = "\n".join(
    f"**{i + 1}.** {c}" for i, c in enumerate(clean_choices)
)
embed_suffix = (
    "\n\nPick a button below, or click ✏️ Other to type a "
    "custom answer."
)
max_field = 1024
option_lines = option_lines_full
if len(option_lines) + len(embed_suffix) > max_field:
    budget = max_field - len(embed_suffix) - 3
    option_lines = option_lines_full[:budget] + "..."

Verified the arithmetic directly: with the 65-char suffix reserved before truncation, len(option_lines) + len(embed_suffix) is exactly 1024 in the worst case (long option list), never over. This has also been running live in production (deployed to a real Hermes gateway) since 2026-07-11 with no field-overflow failures. No code change needed — this looks like a comment left against a stale cached diff view rather than the commit's actual current content. Happy to push a no-op commit to force a fresh render if that would help, just let me know.

[GottZ]

This was generated by AI during triage.

Summary

Four PRs address the Discord clarify-choice readability problem: #62291 replaces clipped choice-text buttons with numeric buttons and mirrors numbered choices, #72606 and #72608 retain shortened text labels while adding full-choice lists, and #73545 conditionally adds a full-options field for choices exceeding a mobile-oriented threshold. The diffs differ mainly in overflow handling and UI semantics, with none fully handling every Discord text-surface limit as currently written.

Related pull requests

• #62291 related — (+174/-133) — preferred, pending one boundary fix: replaces inherently clipped mobile labels with numeric buttons and mirrors normalized choices in the embed and plain content; the reviewed 1,024-character embed-field overflow and unrelated-file problems are resolved in the current diff, but the unbounded plain-text tail still needs a 2,000-character aggregate guard and regression test before merge.
• #72606 [closed] related — (+216/-7) — superseded closed prototype: demonstrates the full-choice-list approach, but its cached diff includes unrelated custom-provider and TLS/header changes, and its 4,088-character description slice can silently discard later choices; it remains relevant as prior implementation evidence for #72608.
• #72608 related — (+104/-10) — salvageable but not preferred: keeps truncated choice text on buttons and mirrors full choices into the embed and plain content, but the contributor review identifies two blocking diff-level defects—silent loss after the 4,088-character description slice and content potentially exceeding Discord's 2,000-character limit. Despite the keep_open review on #72608, consolidation onto #62291 is preferable because #62291 also fixes mobile button legibility rather than preserving clipped labels; the review's overflow concerns must still be carried into #62291 before merge.
• #73545 related — (+26/-1) — incomplete alternative: minimally and conditionally adds a “Full options” field while preserving existing button semantics, but joins all normalized choices into an unbounded embed-field value with no 1,024-character guard or aggregate-overflow test, so valid long inputs can fail Discord validation.

Duplicates

#72606 and #72608 are substantially the same implementation lineage; #62291, #72608, and #73545 overlap on exposing numbered full-choice text but use competing UI and overflow strategies rather than being exact duplicates.

Suggested consolidation

Merge #62291 after bounding the complete plain-content mirror to Discord's 2,000-character limit with explicit overflow behavior and a boundary regression test. Then close #72608 and #73545 as superseded alternatives, explicitly carrying forward the keep_open review on #72608 rather than treating it as resolved; #72606 is already closed and remains superseded by its cleaned successor and the more complete #62291 design.

Cross-PR triage: Reviewed 4 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 46 kB of PR diffs, 8 kB of issue/PR text, 5 kB of discussion (7 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.