@ycodium-ai/plugin-im 0.2.3034 → 0.2.3056

package/README.md

@@ -158,7 +158,7 @@ The agent's questions and the messages queued behind a running turn use the
 optional `choiceCards` surface (`ImChoiceCard`, `src/adapter.ts`): Lark patches a
 card, Telegram edits a message and its inline keyboard. A request is posted on
 `thread.user-input-pending` (read with `listPendingUserInputs`), one card per
-question, and answered with one `thread.user-input.respond` once every question
+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
@@ -241,7 +241,7 @@ when its queue is paused (a `/stop` or a failure pauses it), which is how WeCom,
 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 team, a model) open
+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
@@ -250,6 +250,12 @@ answers that it has expired. A tap runs the same handler as the typed command an
 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,
+platform, chat, and inbound message ID. A successful goal binds the chat to the lead's
+conversation so the existing reply cards and turn notifications carry the lead's replies.
+See [Pointing a Chat at a Team](../../docs/user/im-bots.md#pointing-a-chat-at-a-team).
+
 The **Reply language** setting (Chinese by default, or English) picks the
 language of everything the bot says itself. The settings section follows the
 interface language instead. The copy lives in `locales/en.json` and
@@ -302,7 +308,7 @@ language, the saved-state mirror) plus an explicit `deps` object, never the whol
   persistence, delivery, bot and chat lookup), `connections` (one long connection per bot)
 - `inbound` (per-bot message handlers), `chatQueue` (per-chat serial queue), `commands`,
   `chatSetup` (picker, `/repo`, `/group`), `projectRows`/`projectList` (the project list),
-  `sessions`, `modelPlan`, `turns`, `inboundAttachments`, `teamRuns`
+  `sessions`, `modelPlan`, `turns`, `inboundAttachments`, `teamGoals`
 - `approvals`, `interactions` (question and queue cards, button routing), `replyCards`,
   `notifications`, `acknowledgements`, `panelWiring` (with `panelController`)
 - `lark/setup/` (the scan flow): `setupFlow` (the engine; running shows one progress line, the