hermes - 💡(How to fix) Fix Feishu gateway: Markdown tables render as broken plain text

Issue: Feishu (Lark) Gateway Renders Markdown Tables as Broken Plain Text

Problem

Feishu DM messages do not natively render Markdown tables. When the LLM produces a table (| col1 | col2 |), the gateway delivers it as raw pipe characters, resulting in unreadable output.

This creates a tension:

• Upstream (LLM / skill): Rules like "never use Markdown tables in Feishu" are soft constraints. The model occasionally violates them, especially in long summary responses where tables feel natural.
• Downstream (gateway): The Feishu platform adapter sends messages via the standard message API, which does not support Markdown tables. There is no automatic fallback or conversion.

Current Workarounds (Manual / Fragile)

1. Skill-level reminder: Encode "no tables" in the skill prompt. Works ~90% of the time, fails under load or complex summarization tasks.
2. User correction loop: User spots the violation, calls it out, model apologizes and reformats. Functional but annoying.
3. lark-cli --markdown --as bot: Supports full Markdown rendering, including tables. But requires explicit CLI invocation, changes message sender identity (bot vs personal), and may affect @mention behavior.
4. Interactive cards: Good for buttons/forms, not for arbitrary tabular data.

Proposed Solutions (Discuss)

Option A: Gateway-level auto-conversion (Soft)

In the Feishu platform adapter, detect Markdown tables in outgoing messages and convert them to a Feishu-friendly format (e.g., bulleted lists or card JSON) before sending.

• Pros: Transparent to the LLM; no skill changes needed.
• Cons: Lossy conversion; complex tables degrade poorly; adds regex/heuristic overhead per message.

Option B: Route table-containing messages to lark-cli --markdown

If a message contains a table, automatically send it via lark-cli message send --markdown --as bot instead of the standard API.

• Pros: Native table rendering; no content loss.
• Cons: Changes sender identity (bot card vs personal message); may break threading/mention semantics; requires lark-cli to be installed and authenticated.

Option C: Unified --markdown delivery mode

Add a config flag (e.g., feishu.markdown_mode: true) that routes ALL Feishu messages through lark-cli --markdown --as bot.

• Pros: Consistent rendering; unlocks full Markdown (tables, headings, code blocks).
• Cons: Global behavior change; bot identity for all messages; potential side effects on group chat interactions.

Option D: Keep soft constraint, improve skill enforcement

Enhance the skill system to support a "output format validator" hook that runs before delivery, flagging disallowed patterns (tables) and triggering a re-generation.

• Pros: No gateway changes; user-configurable per skill.
• Cons: Adds latency (re-generation); still not 100% reliable; punishes the model for a platform limitation.

Context

This issue was surfaced from real usage where the user explicitly prefers soft constraints + immediate correction over hard gateway hooks (previously rejected a transform_llm_output hook as "too rigid"). The user acknowledges that the root cause is a rendering-layer capability gap, not a model behavior issue.

Environment

• Hermes Agent version: v0.14.0+
• Platform: Feishu (Lark) DM and group chats
• Gateway: gateway/platforms/feishu.py
• lark-cli: installed and authenticated

Suggested Next Steps

1. Evaluate whether Option B or C can be implemented without breaking existing Feishu threading/mention behavior.
2. If not, document the limitation in gateway/platforms/feishu.py and recommend skill authors use list formats instead of tables.
3. Consider a hybrid: standard API for simple messages, lark-cli --markdown fallback for complex Markdown (tables, nested structures).