feat: native Discord embeds via [EMBED] marker

[Jonesyj83]

Summary

Agents can now emit native Discord embeds by including an [EMBED]{json}[/EMBED] block in a message. The gateway parses the JSON and sends it as a real discord.Embed — title, description, colour, inline fields (columns/rows), footer — while keeping any surrounding text as the plain message content.

This follows the established MEDIA: text-marker convention already in the adapter (agent → marker → platform feature).

Example

[EMBED]
{"title": "⚡ POWER WATCH", "color": "#3fb950", "fields": [{"name": "Import", "value": "12.8 kWh", "inline": true}, ...]}
[/EMBED]

Implementation

• _extract_embed(): parses the JSON block into a discord.Embed
  • json.loads(strict=False) — literal newlines inside strings work, so the model can write readable multi-line JSON
  • colour accepts int or #hex; footer accepts str or {"text": ...}
  • fields capped at Discord's 25
• send(): attaches the embed to the first chunk; marker stripped from content
• edit_message(): on streaming finalize, swaps the marker for the embed; mid-stream edits show a ⏳ rendering embed… placeholder so the raw JSON never flashes on screen
• Zero impact on normal messages — extraction is marker-gated

Tests

11 new unit tests in tests/gateway/test_discord_adapter_embed.py (parse, preamble/tail preservation, invalid-JSON fallback, newline handling, colour/footer forms, 25-field cap, send-path wiring, marker-gated no-op). Existing Discord adapter tests still pass.

[teknium1]

Thanks for adding a small, platform-scoped native Discord capability. Static review found two delivery gaps.

Problems

• Forum sends return through _send_to_forum(channel, content) before the new normal-send extraction path (plugins/platforms/discord/adapter.py:2938-2948). _send_to_forum() creates its starter with raw content (plugins/platforms/discord/adapter.py:3050-3061), so forum posts will show [EMBED] JSON rather than receive an embed.
• Finalized streaming content over 2,000 characters returns to _edit_overflow_split() before the new extraction code (plugins/platforms/discord/adapter.py:3218-3222). That helper chunks the raw content (plugins/platforms/discord/adapter.py:3317-3347), so a large marker is exposed instead of rendered.

Suggested changes

• Parse before forum routing and pass the embed through the forum-thread creation path, with a forum regression test.
• Parse finalized complete markers before overflow handling, then size-check only the remaining text; add a >2,000-character finalized-stream test.

Automated hermes-sweeper review.

[teknium1]

Forum parents return at the earlier _send_to_forum(channel, content) branch, before this normal-send extraction runs. Parse before that branch and carry the embed into _send_to_forum()/create_thread(); otherwise forum posts expose the marker as text.

[teknium1]

This runs after the finalized >2,000-character branch has already returned to _edit_overflow_split(), which chunks the raw marker content. Extract a complete finalized marker before overflow handling, then apply the text limit to the remaining content.

[Jonesyj83]

Thanks for the review @teknium1 — both gaps are fixed.

1. Forum routing: embed extraction now runs before the forum branch in send(), and _send_to_forum() accepts an embed param that rides on the create_thread() starter, so forum posts render the embed instead of raw JSON. Added test_forum_send_gets_embed.

2. Overflow splitting: edit_message() now parses the marker before the overflow pre-flight — the remaining text is what gets size-checked, and _edit_overflow_split() carries the embed on the first chunk. Added test_finalize_oversized_embed_parses_before_split (>2,000-char finalized stream).

Also added tests for the normal finalize edit path and the mid-stream placeholder. 15 tests in the file, 45 Discord tests total — all green.

[Jonesyj83]

Verified working end-to-end in production: the [EMBED] marker now renders as a native embed through ALL delivery paths — interactive streaming (edit_message finalize), normal send(), and the standalone REST path used by cron jobs and the send_message tool. Also tolerates LLM artifacts in the JSON block ((1/2) segment markers, trailing commas). 20 unit tests green.