Summary

Today Feishu group chats can be isolated per group (chat_id / oc_...), which is enough for “one topic per group”. The ideal workflow is stronger: within a single Feishu group, different discussion threads/topics should be isolated into different OpenClaw sessions, so each session contains exactly one topic’s history. This would prevent cross-topic context contamination while keeping a single group as the container.

Proposed solution

Add native Feishu “thread/topic” routing support:

1. Inbound

• Detect a stable Feishu thread/topic identifier from message events (e.g., a thread id, root message id, reply parent id, or equivalent field exposed by Feishu events).
• When chat_type=group, derive sessionKey as:
  • Base: agent:<agentId>:feishu:group:<chat_id>
  • Thread/topic suffix: :topic:<threadId> (or :thread:<threadId>)
• Optionally, include topic title/subject in session metadata (for search/display), if Feishu exposes it; otherwise, derive a label from the root message snippet or a configured mapping.

2. Outbound

• When replying, ensure the response is posted into the same thread/topic context (reply to the correct root/parent message) so the conversation stays inside that Feishu topic/thread.

3. Configuration

• Provide a toggle like channels.feishu.threadSessions: true|false (default false until mature).
• If Feishu has multiple “threading modes” (reply chain vs. topic), allow selecting which identifier to use.

4. Diagnostics

• Add debug logs for inbound routing showing chat_id, threadId/rootId, computed sessionKey, and how the thread identifier was chosen.

Alternatives considered

• Separate group per topic (“one topic per group”): works but increases group management overhead and fragments the workspace.
• Tag-based manual routing inside one group (e.g., #topic prefixes): brittle and relies on user discipline; does not follow Feishu native thread UX.
• Use Telegram forum topics: OpenClaw already supports message_thread_id → :topic:<id> sessions, but organizations may require Feishu.

Additional context

• Desired behavior mirrors OpenClaw’s Telegram forum topic isolation (message_thread_id → sessionKey suffix), but for Feishu.
• Key requirement: “one session == one topic” even when all topics live in the same Feishu group.
• If Feishu does not expose a stable thread/topic identifier in im.message.receive_v1 events, a fallback could be “reply root message_id as thread key” (each root message becomes a topic), but only if outbound replies can reliably stay attached to that root.