Status: Draft, not yet implementing. Surfacing the design space and a positioning tension before any code is written.

Motivation

Two recurring asks from CN users:

1. Run Reasonix from a chat client — paste a task into Feishu / WeWork / WeChat, get the agent's reply back in the same thread, including tool calls and approvals.
2. Pull team knowledge into context — read a Feishu Wiki page, a WeWork message thread, or a WeChat group discussion as @-mentioned context for a turn.

Both are cousins of "connect Reasonix to where the team already works." Different surfaces, different integration shapes, very different security models — they should not be conflated.

Positioning check

Reasonix is a terminal-first DeepSeek-native coding agent. Adding chat bridges nudges the project toward general-purpose chatbot territory, which is not what the cache-first loop, cell-diff renderer, or filesystem sandbox are designed for.

Two sane stances, both consistent with the project's positioning:

• A. Bridges live outside core. Reasonix does not ship Feishu/WeChat code. We document the MCP server pattern so users can wire it themselves; the core stays a coding-agent CLI.
• B. Bridges are first-class for one surface (probably Feishu Wiki / WeWork docs). The use case is read-only context ingest, not bidirectional bot. Slash commands (/wiki <url>) and @feishu:doc-id mentions, no message-sending, no bot identity.

Stance C — full bidirectional bot — almost certainly belongs in a separate project. It's a different product.

Design space

Personal-WeChat support is a non-starter regardless of stance — anyone shipping that would be one Tencent ban-wave from a dead user base.

Three integration shapes (orthogonal, not exclusive)

1. Read-only context ingest. @feishu:wiki/<id>, @wework:doc/<id> mentions resolve to inlined markdown, same shape as @http(s):// today. No outbound writes. Auth via personal access token in ~/.reasonix/config.json.

2. Notification sink. Reasonix posts progress / approval prompts to a configured chat channel via webhook. One-way, no inbound. Useful for long-running plan mode where the user steps away from the terminal.

3. Bot identity. Full bidirectional — task in chat, agent runs, reply back. Pulls Reasonix into bot territory; needs session routing, multi-tenant auth, abuse controls. Probably belongs in a separate project that uses Reasonix as a library.

Open questions

1. Is shape (1) — read-only ingest — enough to satisfy the actual user need, or does "connect Feishu/WeChat" inevitably mean shape (3)?
2. If (1) and (2) are the goal, can both be MCP servers (already supported, no core change), and does this issue collapse to "docs + a curated MCP entry in mcp browse"?
3. For shape (1), do we want a thin native adapter for Feishu Wiki specifically (because it's the most-asked) so it works without the user setting up an MCP server?
4. Token-cost story: Wiki ingests can be huge. Reuse the @-mention truncation budget, or treat wiki/doc bodies as MCP tool results (already capped)?

Non-goals (call them out now)

• Personal WeChat bot support. ToS violation, not happening.
• Two-way slash commands inside chat ("/reasonix code in main.py" from a Feishu thread). That's shape (3).
• Replacing the terminal as the primary UI. Chat surfaces are companions, not the canonical entry point.

What I'd commit to today

• Stance A as the default — punt to MCP, add mcp browse entries for community Feishu / WeWork servers when they exist.
• Possibly stance B for Feishu Wiki only if the MCP path is too clunky. Decide after a survey of existing Feishu MCP servers.
• No bot identity — that's a separate project.

Decision points needed before any code lands

• Pick A or B (or A-then-B-later).
• If B: scope to Feishu Wiki read-only, or include WeWork docs.
• If A: produce a one-page "connect Reasonix to your team chat" doc covering the existing MCP path.
• Confirm WeChat personal is permanently out of scope and write that into ## Not doing in the README.

Out of scope for this RFC

• The other thread the same comment touches ("if search worked, ...") — search is already a Pillar-1 surface and is tracked separately.