v0.8.17 research: Feishu-first mobile companion; defer Replit-in-WeChat

[Hmbown]

Decision update (2026-05-06)

This issue is no longer a v1 build plan for "Replit inside WeChat." Treat that as a later Tencent/WeChat research path. The first mobile habit wedge should be Feishu/Lark companion over the existing local runtime.

Position:

• Feishu first. It has the cleaner primitive for this product: a workplace bot that can be messaged from a phone, reply with cards, and map directly onto durable deepseek-tui runtime threads.
• Whalescale/deepseek-tui remain local-first. The phone is a remote control. The code workspace, shell, git, tools, and task execution stay on the user's machine through deepseek serve --http.
• WeChat/Tencent is deferred. WeChat Mini Program / CloudBase / WeCom are still important for Chinese-market distribution, but they are not the v1 control plane for a coding agent.
• Do not build a hosted Replit clone first. Per-user sandboxes, Mini Program review, real-name/entity requirements, data residency, AIGC compliance, and template publishing are too much surface area for the first sticky habit test.

Related architecture note: docs/FEISHU_BOT.md (#757) already sketches the correct adapter pattern.

Target behavior: OpenClaw-style, deepseek-tui-specific

The intended loop:

Feishu mobile DM / mention
  -> Feishu Open Platform event (`im.message.receive_v1`)
  -> Feishu adapter on the user's Mac / Whalescale sidecar context
  -> local `deepseek serve --http --host 127.0.0.1 --port 7878`
  -> local workspace tools: files, shell, grep, git, tasks
  -> Feishu reply/card update

This is similar to the OpenClaw-style channel gateway, but deliberately narrower:

• not a universal personal assistant;
• not a cloud relay with token/workspace custody;
• not arbitrary skill marketplace distribution;
• not a public multi-tenant bot in v1.

The promise should be: message your local coding agent from your phone; your code stays on your machine. Be precise that Feishu still carries message transport and DeepSeek API calls still leave the device unless configured otherwise.

Sticky habit hypothesis for Chinese users

The habit is not "Chinese visual style." The habit is re-entry without opening the IDE.

Design around mobile rituals:

1. Morning status card

   • Mac/daemon online state
   • current repo / branch / dirty status
   • running or blocked task
   • last useful summary
   • buttons: continue, summarize, open task, pause

2. Approval cards

   • show command/tool, risk level, files touched, short diff/plan preview
   • buttons: approve once, deny, edit instruction, stop
   • approvals must be explicit for shell/file/git operations

3. Commute capture

   • text first; voice later if the platform supplies transcript or a configured STT path exists
   • example: "continue yesterday's PR and add the missing tests"
   • if the Mac is offline/asleep, queue or reply with a clear offline state

4. Return-to-desktop continuity

   • every Feishu turn appears in the same runtime thread
   • Whalescale/TUI can resume the thread with the mobile instructions visible
   • no separate bot-only history silo

5. Later group workflow

   • group mentions can route to shared runtime threads, but this is v2 because multi-user steering/interrupt/approval ownership is messy

Feishu-first MVP scope

Ship only the smallest proof that validates the habit:

• single tenant / self-managed Feishu app;
• direct messages only for the first pass;
• pairing or allowlist gate before any user can drive the runtime;
• durable mapping: feishu:dm:{sender_open_id} -> thread_id;
• text input and card/text output;
• immediate placeholder reply, then SSE-to-card/message edits with throttling;
• commands: /status, /continue, /stop, /compact, /task, /summary;
• interactive cards for approval / deny / stop / steer;
• no arbitrary file upload from chat without confirmation;
• no group chat, no voice generation, no WeChat Mini Program, no template Mini Program publishing.

Runtime/API implications

Use the existing runtime shape rather than inventing a new agent backend:

• GET /health before accepting work;
• POST /v1/threads for mapped conversations;
• POST /v1/threads/{id}/turns for Feishu prompts;
• GET /v1/threads/{id}/events?since_seq=<last_seq> for replayable streaming;
• POST /v1/threads/{id}/turns/{turn_id}/interrupt for /stop;
• POST /v1/threads/{id}/turns/{turn_id}/steer for mid-run guidance;
• POST /v1/tasks / GET /v1/tasks/{id} for longer work;
• GET /v1/workspace/status and GET /v1/usage for status cards.

Known dependency: approval decision plumbing must exist in the runtime before approval cards are more than mock UI.

Why not WeChat-first?

A WeChat-first path is possible, but it is a different product shape:

WeChat / WeCom / Mini Program
  -> Tencent CloudBase
  -> Cloud Function / Cloud Run / Agent UI
  -> local runtime bridge or hosted sandbox

Tencent CloudBase is worth researching because it explicitly supports Mini Programs, Web, Official Accounts, Mini Program Customer Service, Enterprise WeChat Customer Service, DeepSeek/Hunyuan model access, agent development, and Agent UI components:

• https://docs.cloudbase.net/en/ai/introduce

But consumer WeChat surfaces are more service-account / Mini Program / customer-service shaped than "personal bot controls my local coding agent." That makes them better as later companion/distribution surfaces:

• Mini Program dashboard for task status and approvals;
• CloudBase-backed onboarding/share surface;
• WeCom bot if the target user lives in Tencent enterprise tooling;
• WeChat share cards for demos and lightweight status.

Do not assume Chinese users use one company's ecosystem exclusively. The practical behavior is multi-ecosystem: WeChat for identity/social/payments, Feishu/DingTalk/WeCom depending on employer, Bilibili/Xiaohongshu/Douyin for discovery, and desktop IDEs for real coding. For this product, choose the best control-plane primitive first, then bridge into Tencent surfaces after the mobile habit is proven.

Research / implementation tasks

1. Validate Feishu event transport choice:

   • HTTP callback vs SDK long connection;
   • local development without a public inbound URL;
   • reconnection and duplicate event handling.

2. Define the adapter store:

   • mapping key -> runtime thread/task;
   • last Feishu message/card id;
   • last runtime event seq;
   • pairing/allowlist state.

3. Design card templates:

   • status card;
   • turn progress card;
   • approval card;
   • final summary card;
   • offline/asleep card.

4. Threat model the channel:

   • Feishu messages are untrusted input;
   • group chat content can contain prompt injection;
   • never upload workspace files because a chat message asked for it;
   • require explicit confirmation for sensitive file/shell/git operations;
   • keep runtime bound to 127.0.0.1 unless a separate authenticated remote-access design is approved.

5. Keep Tencent path as research-only:

   • CloudBase + WeChat/WeCom companion feasibility;
   • Mini Program status/approval dashboard;
   • no per-user hosted coding sandbox in v1.

Acceptance criteria for closing this research issue

• Feishu-first recommendation is captured in docs/FEISHU_BOT.md or successor architecture doc.
• WeChat Mini Program full IDE path is explicitly deferred with reasons.
• MVP scope is limited to single-tenant Feishu DM companion and local runtime control.
• Runtime dependency list is filed or linked, especially approval decisions and any missing status/task endpoints.
• Security constraints are documented: pairing/allowlist, local runtime binding, untrusted chat input, explicit file/tool approvals.
• A follow-up implementation issue exists for the narrow Feishu proof of concept.