The bridge only supported a single global model (DEEPSEEK_MODEL env /
default_text_model in config.toml). Users who wanted a different model
for a particular Feishu group had to restart the bridge with a different
env var — impractical and disruptive.
This commit adds per-chat model switching so users in a group chat can
run "/model <name>" to switch the model for all future threads and
turns in that chat, without affecting other chats.
Changes:
- **lib.mjs — commandAction()**: handle "model" command → { kind:
"set_model", modelName }.
- **index.mjs**:
- setChatModel(chatId, modelName): store/clear per-chat model in the
thread store. "/model default" resets to the bridge-level default.
- ensureThread(): read per-chat model from store when creating a
new runtime thread; fall back to config.model.
- runPrompt(): read per-chat model for each turn submission
(independent of the thread-creation model), so a /model change
takes effect on the very next message.
Usage:
/model deepseek-v4-flash — switch this chat to Flash
/model deepseek-v4-pro — switch this chat to Pro
/model default — reset to bridge default
Resolution priority (per-chat): global default < per-chat /model.
/ 新增 /model 命令，支持按飞书群设置独立模型。
/ 群内输入 /model <name> 切换，/model default 恢复全局默认。
When running in a Feishu thread-enabled group (话题群), every bot
response — status messages, approval prompts, streaming progress,
turn results — was sent via the Lark SDK's `create` API which spawns
a new standalone topic. The user sees a cluttered group with orphan
topics for each intermediate bot message.
Root cause: `sendText()` only called `client.im.message.create()`
with a bare `chat_id`, never passing any reply context. The Feishu
`reply` API was completely unused.
Fix (two changes, one site each):
1. **lib.mjs — incomingIdentity()**: expose `parentId`, `rootId`,
`threadId` from the raw Feishu message event so callers can
determine thread context. (Not consumed directly yet, but
available for future use.)
2. **index.mjs**:
- `handleIncomingMessage()`: store the latest incoming
`messageId` as `replyToMessageId` in the per-chat thread store.
- `sendText()`: look up `replyToMessageId` from the thread store;
when present, call `client.im.message.reply()` instead of
`create()`. This keeps ALL bot responses nested under the
original user message inside the same topic.
No config changes needed. New chats automatically start using the
reply path; existing chats without a `replyToMessageId` in the store
fall back to the old `create` behaviour.
/ 修复飞书话题群中 bot 消息新建独立话题的问题。所有回复改为使用 reply API
/ 在原话题内嵌套回复，而非通过 create API 创建新话题。
Add the Feishu/Lark long-connection bridge, Tencent Lighthouse runbooks, CNB mirror guidance, CNB tag release pipeline, and China-friendly update fallback documentation for the v0.8.37 line.
Hunter B