@ycodium-ai/plugin-im 0.2.3238 → 0.2.3244

package/README.md

@@ -46,11 +46,13 @@ they pick their own project:
   when the platform reports no sender id.
 - A chat with no project starts nothing. The first message from an allowed
   person gets a project picker (a card on Lark, an inline keyboard on Telegram,
-  a numbered text list on WeCom, which has no buttons: reply with the number or
+  a numbered text list on WeCom: reply with the number or
   `/repo <number>`). The pick is written as a plugin fact and survives restarts.
   `/repo` switches the project: the old thread is kept (still under that
   project's `/sessions`), the chat forgets it, and a running turn blocks the
-  switch. The panel has a Pick project button.
+  switch. The panel has a Pick project button. On the WeCom smart bot, `/repo`
+  and this prompt stay the numbered list (`projectPicker` is false on
+  `src/wecomPanel.ts`); the button on the command card is separate.
 - On Telegram a forum topic is a chat of its own: its chat id is `chat:topic`
   (`chatIdOf`, only when Telegram marks the message `is_topic_message`; a reply
   chain in an ordinary supergroup also carries `message_thread_id` and stays the
@@ -133,7 +135,15 @@ text and images (fetched through `media/get`), outbound text, images and files
 It listens on `127.0.0.1:30987` by default (path `/wecom-app-callback/<rowId>/<secret>`);
 put a reverse proxy or tunnel in front and paste the public URL into WeCom “Receive
 messages → API receive”. Each column is validated, and a row with problems does not
-connect. Streaming replies are not done yet — final replies go out actively.
+connect. Streaming replies are off by default (the app's passive stream reply has not
+been verified on a real WeCom client). With it on, WeCom refreshes the reply as the agent
+writes; if the client never refreshes the stream, the final reply is sent as text.
+
+Known limits with Streaming replies on: the "Got it, working on it" placeholder is
+not closed when a turn cannot start because the project has no default model, or
+when handling the message throws; and a message queued for a team goal has its
+placeholder closed right away, so it gets no 5-second fallback confirmation. The
+reply itself still arrives as text in all three cases.
 
 The default is one message per finished turn. A single turn can produce dozens
 of assistant messages, mostly commentary between tool calls.
@@ -177,15 +187,15 @@ card, Telegram edits a message and its inline keyboard. A request is posted on
 question, and answered through `ctx.threads.userInput.respond` once every question
 has an answer; a free-form answer is the next ordinary message in the chat, and
 `thread.request-resolved` freezes the cards of a question answered elsewhere or
-closed unanswered. WeCom has no buttons: it writes the options as numbers and the
+closed unanswered. WeCom writes the options as numbers and the
 reply is parsed in `src/questionCards.ts`. A message that lands behind a running
 turn gets a queued card (Steer, Withdraw, Resume sending) drawn from
 `getThreadExecution` and refreshed when the turn intents or the queue change
 (`src/queueCards.ts`, `src/queueFlow.ts`); the buttons call
 `threads.turnIntents.run` (steer, with the active turn id), `threads.turnIntents.cancel`
 and `threads.turnQueue.resume`, and the card is the user's own action, so no
-`intentAction` is sent. WeCom only gets a one-line notice, since steering
-and withdrawing need buttons (resuming is the `/continue` command). Editing a queued message is not offered:
+`intentAction` is sent. WeCom only gets a one-line notice: that notice has no
+steer or withdraw buttons (resuming is the `/continue` command). Editing a queued message is not offered:
 the host does not let a plugin dispatch `thread.turn-intent.edit`.
 
 A chat keeps its place across restarts. Which project a chat picked, which thread
@@ -255,18 +265,10 @@ Chat commands: `/stop`, `/continue`, `/status`, `/new`, `/sessions`, `/resume`,
 `/sessions`, `/resume` and the team commands answer with the project picker. `/sessions` and `/resume` only list and
 switch threads this plugin opened, since the host lets a plugin send only into
 its own threads. `/continue` calls `threads.turnQueue.resume` for the chat's thread
-when its queue is paused (a `/stop` or a failure pauses it), which is how WeCom, with
-no buttons, resumes; it is not `/resume`, which already switches threads.
-
-On Lark and Telegram, `/panel` sends a command panel (`/help` stays text and ends with a pointer to it; on WeCom, which has no panel, it does not): every command above
-is a button (a card on Lark, an inline keyboard on Telegram), and the ones that take an argument (a thread, a project, a model) open
-a second view on the same message with a Back button. Telegram buttons carry only
-a short `pn:<version>:<index>` token (`callback_data` is capped at 64 bytes);
-the action stays in memory and a tap on an older keyboard version counts as expired. Each card keeps its own view
-stack in memory (`src/panelController.ts`), so after a restart an old card only
-answers that it has expired. A tap runs the same handler as the typed command and
-waits in the same per-chat queue as typed messages. Another platform opts in by
-implementing the optional `panel` surface on its adapter (`src/adapter.ts`).
+when its queue is paused (a `/stop` or a failure pauses it), which is how WeCom
+resumes a paused queue from the chat; it is not `/resume`, which already switches threads.
+
+On Lark, Telegram, and the WeCom smart bot, `/panel` sends a command panel, and `/help` stays text and ends with a pointer to it. WeCom App does not implement the panel surface, so `/panel` answers with the text list and `/help` does not mention `/panel`. Lark cards and Telegram inline keyboards show all command buttons. The WeCom smart bot uses a template card from `src/wecomPanel.ts`; its main menu is limited to six buttons. Commands that do not fit are listed in `/help` and can be typed into the chat. Commands that take an argument (a thread, a project, a model) open a second view on the same message with a Back button. These lists let you reach every option by paging: Lark and Telegram show eight items per page, and WeCom shows three, leaving room for Back, Previous, and Next. A tap on the WeCom card updates that same card; when the update cannot be applied, `src/panelController.ts` posts a new card and the old one stops accepting taps. A busy placeholder is not drawn on that card: it stays as it is until the next interactive view. Telegram buttons carry only a short `pn:<version>:<index>` token (`callback_data` is capped at 64 bytes); the action stays in memory and a tap on an older keyboard version counts as expired. Each card keeps its own view stack in memory (`src/panelController.ts`), so after a restart an old card only answers that it has expired. A tap runs the same handler as the typed command and waits in the same per-chat queue as typed messages. Another platform opts in by implementing the optional `panel` surface on its adapter (`src/adapter.ts`).
 
 `/team` uses the chat's selected project. It reads the roster from the `team` plugin and
 each text message invokes `startGoal` with a stable request ID derived from the bot,