hermes - 💡(How to fix) Fix Slack: use Block Kit for structured notifications, not normal conversation

Context

We should distinguish between two Slack rendering modes instead of treating all outbound messages the same:

1. Normal conversational replies should stay as plain text / Slack mrkdwn-style messages. They are free-form, often include code, can be long, and Block Kit adds awkward limits.
2. Structured system / agent notifications can benefit from Block Kit layouts because they are predictable, scannable, and action-oriented.

This came up while discussing Slack Block Kit vs plain mrkdwn for Hermes gateway messages. Related, but not identical, to #8552, which focuses on using Slack's markdown block type for better Markdown/table rendering.

Problem

Block Kit is useful for compact, high-signal notification payloads, but it is a bad default for all assistant replies:

• Block Kit has limits such as 50 blocks/message and ~3000 chars per section.
• It is worse for free-form code-heavy assistant responses.
• Conversational replies should optimize for flexible text streaming and low formatting friction.
• Notifications should optimize for quick scanning, status, metadata, and deep links.

Right now we need a clearer product/API distinction for when Slack output should be rendered as:

• plain conversational text / markdown, versus
• structured Block Kit notification blocks.

Candidate use cases for Block Kit

Good fits:

• GitHub PR / CI / agent-run result notifications
• Linear issue notifications
• setup checklists
• account connection notices
• "I found X things" summaries
• task status cards with stable metadata and a primary link/action

Bad fits:

• normal assistant conversation
• long generated prose
• code-heavy responses
• arbitrary Markdown where the shape is unknown ahead of time

Example

An agent-run / PR notification could render as:

Header: ✅ Agent run completed
Fields:
- Repo
- Branch
- PR
- Status
Context:
- timestamp
- run id
Optional action:
- Open PR

Proposed direction

Add a small abstraction for Slack message rendering, roughly:

• send_text_message(...) / existing conversational path: keep plain text / markdown rendering.
• send_structured_notification(...): accepts a typed notification payload and renders Block Kit.
• Keep fallback text populated for accessibility, notifications, search, and clients that do not render blocks.
• Avoid auto-converting arbitrary assistant messages into blocks.

Acceptance criteria

• Slack adapter has an explicit path for structured notification payloads.
• Existing normal conversational replies remain plain text / markdown-oriented and are not forced through Block Kit.
• At least one notification type is implemented as a proof of concept, e.g. GitHub PR / agent-run completion.
• Renderer handles Slack limits gracefully: section length, block count, fallback text.
• The design documents when to use Block Kit vs normal text.
• Include tests or fixtures covering both structured and conversational paths.

Open questions

• Should structured notifications be gateway-level primitives, tool-level payloads, or platform-specific helpers?
• Which notification schema should be first-class: GitHub PR result, Linear issue, cron/job run, or generic agent-run result?
• Should non-Slack platforms receive the same typed payload and render their own native equivalent where possible?