hermes - 💡(How to fix) Fix [Feature]: Render Slack progress drafts as plan cards [2 pull requests]

Problem or Use Case

Hermes Slack gateway progress updates are currently text/edit-based tool-progress messages. For tool-heavy runs, the visible progress draft can become repetitive and hard to scan: users see multiple plain status lines while the agent is working, then a separate final reply after completion.

Slack has native stream chunks for agent progress surfaces (chat.startStream, chat.appendStream, chat.stopStream) that can render plan_update and task_update chunks as a plan/task-card style UI. Hermes should be able to use that Slack-native presentation for progress while keeping the existing final-answer lifecycle unchanged.

I searched existing Hermes issues for related terms such as Slack progress, native task cards, chat.startStream, chat.appendStream, and task_display_mode, and did not find an existing matching issue.

Proposed Solution

Add an opt-in Slack-only mode that renders Hermes tool progress as native Slack plan/task cards.

Expected behavior:

• Preserve current/default Slack behavior unless the new Slack-specific flag is enabled.
• Keep final answer delivery separate from progress: the task card shows work state, and the final assistant reply still lands as normal text in the correct Slack thread.
• Show the first running tool while the run is still active, not only after finalization.
• Prefer Slack native stream chunks (plan_update, task_update) over replacing full Block Kit messages in a loop.
• Preserve current Slack thread/session/DM routing semantics and fallback behavior.
• Include fallback text for accessibility, logs, and clients that do not render the native card.

A possible config shape would be Slack-owned, for example:

gateway:
  platforms:
    slack:
      extra:
        streaming:
          progress:
            native_task_cards: true

Implementation notes to consider:

• Keep the setting Slack-specific rather than adding it to generic gateway streaming config.
• Map running tools to Slack task status in_progress, completed tools to complete, and failed tools to error only when Hermes has a real failure signal.
• Use stable tool invocation IDs if available; otherwise use a gateway-local sequence to avoid collapsing repeated same-name tool calls.
• If native stream startup fails, final reply should still use the original/planned Slack thread.
• Do not stream final answer text through the progress stream by accident.

Alternatives Considered

1. Keep plain text progress messages as-is.

This is lowest risk, but the current UI remains noisy for tool-heavy runs and does not use Slack's native agent progress surfaces.

1. Render task cards by repeatedly posting/updating Block Kit messages.

This is easier to implement but risks UI churn and rendering issues because the whole message is replaced repeatedly. Native Slack stream chunks are a better fit for incremental task-card updates.

1. Make this a generic gateway streaming feature.

The semantics are Slack-specific. Other messaging platforms do not expose the same plan_update / task_update stream contract, so a generic flag would leak Slack behavior into unrelated adapters.

Feature Type

Gateway / messaging improvement

Scope

Medium (few files, < 300 lines)

Additional Context

Proof and test expectations:

• Use Slack native stream chunks with task_display_mode: plan.
• Do not prove only the upstream tool callback; tests should prove the running tool event is converted into Slack-native chunks before final answer delivery.
• Final-thread readback alone is not sufficient proof for transient native progress; live proof should include redacted Slack stream-call evidence or UI capture showing the task card while work is running.