Real agent turns invoke tools constantly; one 'Tool call X' message
per call flooded the chat with near-zero information. Tool frames now
only flush the pending interim explanation text; successful tool
results stay silent, and failures still push the tool name with the
error detail.
Resolve qq-bridge.mjs by keeping the inbound-file support (hasFiles,
files passthrough) and dropping the upstream stream session, which
this branch replaces with the discrete turn-feed notices.
Show what the agent is actually doing during a turn, the way Claude
Code does: interim explanation text, every Tool call, and the error
detail when a tool fails, each as its own pushed message before the
final markdown answer.
- HarnessReplyTracker.consume now returns every frame of a polling
batch in order (same-batch text frames collapse to the latest)
instead of dropping all but the last event, which silently ate
tool-call frames that shared a batch with their result
- tool frames carry callId; status frames carry the correlated
toolName and a flattened error text parsed from the tool/result
error payload (message, or name: code)
- the QQ bridge holds interim step text until the next tool call
(or the end of the turn) pushes it, emits 'Tool call <name>' per
call, emits 'Tool call <name>\nError: <reason>' for failures, and
skips re-sending interim text that already equals the final answer
Other channels keep their existing behaviour: the status frame still
reads '正在整理结果…' and they ignore the new optional fields.
Replace the in-place streaming reply (openStream replace-mode frames)
with discrete pushed messages, so the chat no longer flickers while
the turn is running:
- each tool call pushes one notice message (正在使用X…); status frames
such as '正在整理结果…' and per-token text frames are not pushed
- the final answer arrives as one new markdown message
- a stopped turn still announces '已停止。'; no stream session is
created, so there is nothing to cancel or finalize
The shared Harness client emits a '正在整理结果…' status update after
every tool/result. Pushing each one into the QQ stream message made
multi-tool turns repeatedly flash that notice instead of showing real
progress. Skip status frames in the QQ onUpdate handler so the stream
keeps the last meaningful frame (tool name or generated text), which
matches the official dsh-qqbot behaviour of not pushing tool-noise.
Deliver final Harness answers to QQ as msg_type=2 markdown so bold,
headings, code blocks, lists, and tables render natively in QQ.
- add markdown-reply.mjs: chunk long answers at code-fence/table
boundaries (4500-char limit) and send each chunk with a unique
msg_seq to avoid passive-reply dedup (40054005)
- fall back to plain text per chunk when the platform rejects
markdown, so bots without markdown capability keep working
- route the non-stream final answer path in qq-bridge through the
markdown sender; streaming replies already use markdown content
type, and command/notice texts stay plain
Add setMyCommands and setChatMenuButton to the Telegram Bot API client
and register a 12-command menu with a commands-type menu button when a
bot runtime connects. Menu setup failures are logged as warnings and do
not block startup.
Co-authored-by: xmanrui <841206367@qq.com>
Each session row is a column_set with a fixed 90px watch-toggle column
(⭐关注/⭐取关 for already-watched sessions) and a weighted session button
carrying the number label; number replies bind the session. Replaces the
stacked button pair; also honors the per-bot archived-session policy.
The session list (and the numeric /watch index) honors a per-bot persisted
policy: /archived off hides archived sessions from cards and index
resolution, /archived on restores them. Defaults to on.
- /watch resolves the target READ-ONLY: sessions are validated against
registered workspace listings (current or any other) without binding the
conversation or switching workspaces. /unwatch and /watchlist round out
the command set; the watchlist card supports button and number-reply
unwatching.
- Watches persist in the state store (sessionId + title + chatId + lastSeq)
and resume at runtime start: the bridge starts the global event-mux
watcher in its constructor when the harness supports it.
- Completion pushes fire on turn/end, deduped by sessionId + turn id, with
the seq watermark persisted per watch. After a mux reconnect the bridge
replays each watched session's recent history (session.history) through
the normal handler, so missed turn/end events are compensated without
duplicates.
- Bound-session push targets are persisted (chatTargets) instead of living
only in memory, and refresh on every accepted message.
- Watch failures map to safe user-facing messages.
- /m (or /menu) opens a card menu; /sessionlist and /workspacelist render
cards with bind/switch buttons; number replies stay usable as a fallback
when the app does not subscribe card.action.trigger.
- card.action.trigger callbacks validate the operator's open_id against the
allowed senders: group members outside the allowlist can never drive
binding, workspace switches or other card actions.
- Session-list pagination uses page numbers everywhere (buttons carry
sessions:<page>), fixing the previous double page-size scaling that
skipped pages past 20 sessions.
- Bind/workspace failures map to safe user-facing messages instead of raw
error details.
- Apps registered after this change subscribe card.action.trigger during
the scan flow.
