Add chatId and threadId source fields across all nine IM channels, update UI/docs/tests, reconcile the latest main branch, and credit @Chan-0312 as a contributor.
Address review feedback on the interaction cards:
1. Bind card decisions to the initiating actor. The card-action operator
(operatorOpenId) is now passed into the approval and question handlers:
- submitByApprovalId receives { actor } so another allowed group member
cannot approve/reject someone else's approval;
- the answer branch requires pending.actor === operator.
2. Include the question index in the answer button action and validate it
against the current pending question, so a stale card from an earlier
question in a multi-question interaction cannot be applied to the next one.
3. When both the card send and the plain-text fallback fail, the error is no
longer swallowed: it propagates so the interaction is not marked as
presented and the existing retry/reconnect behaviour can run.
Adds regression tests for all three cases.
Render Harness approval and single-choice question interactions as
interactive Feishu cards with approve/reject and answer buttons,
matching the already-available interactionCards behaviour. Cards are now
the default; set DSH_IM_INTERACTION_CARDS=0 (or interactionCards=false)
to keep the plain-text reply flow.
- bridge.mjs: approve:/reject:/answer: card actions, interactionCards
option, gated approval render hook, interactive question presentation,
and operationArguments/printableText helpers; refactor the inline
question answer into #submitQuestionAnswer so both text replies and
card buttons share one path.
- feishu-cards.mjs: approvalCard (approve/reject) and questionCard
(option buttons) templates.
- feishu-runtime.mjs: default interactionCards from env (on).
- harness-approval.mjs: optional channel render hook + submitByApprovalId.
- i18n-en: add the new card t() keys.
- Tests: pin the plain-text reply flow in state-machine suites that
drive it, and add dedicated card tests for the default approve/reject,
answer buttons, and the text fallback. Full suite shows no new
failures versus upstream.
- CHANGELOG: keep the image-fallback entry under Unreleased alongside the new 4.5.0 section
- harness-client: upstream renameSession coexists with the image-rejection fallback retry path
- lib/index.js rebuilt from merged sources
Failure notices (turn failures, sub-flow errors from list/card/preset/
model/compact/stop/bind/switch paths, batch-input results, and the
card-queue rate-limit notice) were sent as fresh messages keyed only by
chat_id, so in topic groups they landed in the group's default area
instead of the topic the interaction belongs to.
- #sendFailure accepts options.replyTo; every call site forwards the
anchor available in its context (command message, card message, or
watch/list anchor)
- #handleMessageFailure and #finishBatchResult thread to the triggering
message
- /repair stays private-chat-only by design; proactive delivery keeps
its existing behavior (no thread context exists there)
- lib/index.js: regenerated host bundle
Watch-completion pushes rebuilt a fresh completion card keyed only by
chat_id, so in topic groups the "task finished" notice landed in the
group's default area instead of the topic where the watch was created.
- #runWatch persists the anchor message id (command message or card)
on the durable watch entry
- #deliverCompletion sends the completion card as a reply to that
anchor; entries without an anchor keep the previous behavior
- batch watch_add passes the card message as the anchor
- lib/index.js: regenerated host bundle
Card-button sub-flows (bind session, watch/unwatch, workspace switch,
compact, stop, steer, preset/model selection and their confirmations)
sent fresh messages keyed only by chat_id, so in topic groups the
confirmations landed in the group's default area instead of the topic
containing the card.
- #handleCardAction anchors every confirmation and sub-flow to the
card's message id; #handleMenuPick anchors to the replying message
- #bindSession / #switchWorkspace / #handleCompact / #handleStop /
#handlePreset* / #handleModelSelect / #sendSteer accept and forward
the anchor; the expired-menu and steer-form notices follow suit
- lib/index.js: regenerated host bundle
webSocketProxyUrl() picks up https_proxy/HTTPS_PROXY/http_proxy/
HTTP_PROXY and forces the Feishu WSS long connection through the proxy,
without consulting NO_PROXY/no_proxy. With a local proxy exported in
the shell (Clash/V2Ray setups), every long-connection attempt is
rejected by Feishu's server and the runtime force-closes and retries
in a loop, so the bot never reaches a stable connected state.
Resolve NO_PROXY/no_proxy for the long-connection endpoints
(open.feishu.cn / open.larksuite.com) before falling back to the proxy
env: exact host, parent-domain (.cn, feishu.cn) and * entries follow
the common NO_PROXY semantics.
- production.mjs: NO_PROXY gate in front of the proxy lookup
- feishu-proxy.test.mjs: NO_PROXY exclusion and fallthrough cases
- lib/index.js: regenerated host bundle
Plain command replies (menu cards, session/workspace/watch lists, /new,
/status, /compact, /archived, model and preset commands) and Harness
approval prompts were sent as fresh messages keyed only by chat_id, so
in topic groups they landed in the group's default area instead of the
topic the conversation belongs to.
Deliver them as replies to the triggering message, mirroring how stream
answers already thread:
- #sendCard accepts { replyTo } and replies interactively, falling back
to a plain card when the referenced message is gone
- command replies, status text, menu/session/workspace/watch cards,
approval prompts and resolved-question notices all carry the
triggering message id
- batch-input failure notices follow the same rule
- bridge.test.mjs: /new in a topic group must thread the confirmation
text and the menu card to the command message
- lib/index.js: regenerated host bundle
