hermes - 💡(How to fix) Fix [Feature] Native Feishu CardKit Streaming: consolidate best-in-class implementations

Summary

There are two actively-maintained community implementations solving the Feishu CardKit streaming gap (Issue #16084). This issue proposes the Hermes team consider adopting the best features from both into core.

Background

• Issue #16084: im.v1.message.update falls back to "edited" badge, 50 QPM limit, full re-render — community consensus is CardKit streaming API is the right solution.
• Issue #17852: Two projects have shipped E2E-tested CardKit streaming in production.

Comparing the two active implementations

1. baileyh8/hermes-feishu-streaming-card (V3.4.2)

• Architecture: Sidecar-only (independent process, HTTP POST /events)
• Strengths:
  • Process isolation — sidecar crash does not affect Hermes
  • Multi-profile in-process support (V3.3.0+)
  • Multi-bot routing by chat_id with fallback/default bot (V3.2.0+)
  • Fixes #31: concurrent PATCH sequence race causing content rollback/missing chars
  • Table overflow protection (auto-truncates >5 tables to avoid Feishu 11310 error)
  • DeepSeek `` tag filtering
• Weaknesses:
  • No image resolution (markdown image → Feishu img_key)
  • No cron card delivery
  • No /stop interrupt handling
  • No multi-language (zh/en) support
  • Deployment complexity (clone + pip + config + sidecar start)

2. Aowen-Nower/hermes-lark-streaming (v0.9.0, fork of Cheerwhy/hermes-lark-streaming)

• Architecture: In-process monkey patching (no sidecar, hermes plugins install one-liner)
• Strengths:
  • Zero-deployment sidecar — pure plugin, survives Hermes restart
  • Markdown image → Feishu img_key automatic resolution & re-upload
  • Cron result card delivery (preserves Markdown rendering)
  • /stop interrupt: shows interrupted card, opens new session cleanly
  • Linear mode: auto-splits long cards at Feishu's 200-element limit
  • Multi-language (zh/en) auto-detection from Feishu client locale
  • threading.local() fallback for contextvars cross-thread propagation
• Weaknesses:
  • No multi-profile / multi-bot support
  • No process isolation (in-process)
  • No concurrent PATCH handling

Recommended consolidation

The ideal native implementation would combine:

References

• Current issue: #16084 (CardKit streaming vs im.v1.message.update)
• Community request: #17852 (streaming card project)
• Bailey repo: https://github.com/baileyh8/hermes-feishu-streaming-card
• Aowen/Gitee repo: https://gitee.com/Aowen-Nower/hermes-lark-streaming
• Original fork source: https://github.com/Cheerwhy/hermes-lark-streaming

Ask

Would the Hermes team consider either:

1. Adopting the consolidated approach into core (gateway/platforms/feishu.py), or
2. Officially endorsing one implementation as the recommended plugin for Feishu CardKit streaming?

Either would give the Feishu user base a first-class streaming card experience and close the long-standing gap described in #16084.