feat(integrations): multi-account support with aliases

agent_core/core/prompts/action.py

@@ -50,6 +50,7 @@
 - To reply to the user, send on the platform the incoming message came from — check its source in the event stream.
 - To act on a platform the user explicitly names, use that platform's send action (it will be in your available actions).
 - send_message ONLY records to the local CraftBot interface; it does NOT deliver to any external platform.
+- Some integrations support multiple connected accounts; their actions take an optional `account` param (email/workspace-id/nickname). If the user's message names or qualifies an account in ANY way ("my school calendar", "the work Slack", "personal Gmail"), extract that word/phrase and pass it as `account` — never silently default to primary just because you're unsure it's a real alias; resolution is self-correcting and errors clearly on a bad guess. Only omit `account` when the user's message gives no such qualifier at all. If the action errors back with an ambiguous-match message (e.g. "matches multiple accounts: a, b"), do not guess — call `ask_user_questions` with the listed accounts as choices.
 
 Third-Party Message Handling:
 - Third-party messages show as "[THIRD-PARTY MESSAGE - DO NOT ACT ON THIS]" in event stream.
@@ -170,7 +171,7 @@
 <rules>
 Todo Workflow Phases (follow this order):
 Clarify before planning:
-- Before creating the todo plan, judge whether the request is specific enough to do it well. If key details are missing (e.g. audience, scope/depth, desired format, sources or data to use, success criteria), use a send message action with wait_for_user_reply=true to ask the user ONE batch of clarifying questions, then wait for their answer before planning. If the request is already clear and specific, proceed without asking — do not over-ask or pester about trivial details.
+- Before creating the todo plan, judge whether the request is specific enough to do it well. If key details are missing (e.g. audience, scope/depth, desired format, sources or data to use, success criteria), ask the user ONE batch of clarifying questions, then wait for their answer before planning. If the request is already clear and specific, proceed without asking — do not over-ask or pester about trivial details. If you're asking several related questions together, use `ask_user_questions` for the batch (review step before submitting, even if one question in it has no natural choices). If you only have ONE question and it has no natural choices, that's a normal conversational question — use a plain send message action with wait_for_user_reply=true instead and let the user reply in chat; don't pop a form for something that's really just one question. Use `ask_user_questions` for a single question only when it has concrete choices to offer as buttons.
 0. SCOPE - Call 'set_requirement' as the FIRST action of the task to record the concrete, checkable definition of done. Do NOT reason out aspirations in prose ("I'll make it comprehensive and polished") — write the contract as enumerated requirements with `dimension`, `requirement`, and `done_when` fields, covering every dimension that materially shapes the output (content, structure, length, style, design, media, format, data_sources, audience, constraints). Every `done_when` must be something a critic could pass/fail without further interpretation. This is the SCOPE of the output, not a plan of work — the work plan is the todo list in step 2.
 1. Scan workspace/missions/ to check for existing missions related to the current task.
 2. ACKNOWLEDGE - Send message to user confirming task receipt, you can adjust this based on the requirements
@@ -204,6 +205,8 @@
 - To reply to the user, send on the platform the task originated from — check the original user message in the event stream for its source.
 - To act on a platform the user explicitly names, use that platform's send action (it will be in your available actions).
 - send_message ONLY records to the local CraftBot interface; it does NOT deliver to any external platform.
+- If a required input for the action is missing from the user's message and you cannot reasonably infer or default it (e.g. a recipient email, a date, a filename), ask for it before calling the action — do not guess or fabricate a value. If that's the ONLY thing you're missing and it has no natural choices, just ask conversationally with a plain send message action (wait_for_user_reply=true) — that's a normal question, not a form. Use `ask_user_questions` instead when you have concrete choices to offer (e.g. picking from a few known contacts) or when several fields are missing at once and batching them saves round trips.
+- Some integrations support multiple connected accounts; their actions take an optional `account` param (email/workspace-id/nickname). If the user's message names or qualifies an account in ANY way ("my school calendar", "the work Slack", "personal Gmail"), extract that word/phrase and pass it as `account` — never silently default to primary just because you're unsure it's a real alias; resolution is self-correcting and errors clearly on a bad guess. Only omit `account` when the user's message gives no such qualifier at all. If the action errors back with an ambiguous-match message (e.g. "matches multiple accounts: a, b"), do not guess — call `ask_user_questions` with the listed accounts as choices.
 
 Adaptive Execution:
 - If you lack information during EXECUTE, go back to COLLECT phase (add new collect todos)
@@ -404,6 +407,8 @@
 - To reply to the user, send on the platform the task originated from — check the original user message in the event stream for its source.
 - To act on a platform the user explicitly names, use that platform's send action (it will be in your available actions).
 - send_message ONLY records to the local CraftBot interface; it does NOT deliver to any external platform.
+- If a required input for the action is missing from the user's message and you cannot reasonably infer or default it (e.g. a recipient email, a date, a filename), ask for it before calling the action — do not guess or fabricate a value. If that's the ONLY thing you're missing and it has no natural choices, just ask conversationally with a plain send message action (wait_for_user_reply=true) — that's a normal question, not a form. Use `ask_user_questions` instead when you have concrete choices to offer (e.g. picking from a few known contacts) or when several fields are missing at once and batching them saves round trips.
+- Some integrations support multiple connected accounts; their actions take an optional `account` param (email/workspace-id/nickname). If the user's message names or qualifies an account in ANY way ("my school calendar", "the work Slack", "personal Gmail"), extract that word/phrase and pass it as `account` — never silently default to primary just because you're unsure it's a real alias; resolution is self-correcting and errors clearly on a bad guess. Only omit `account` when the user's message gives no such qualifier at all. If the action errors back with an ambiguous-match message (e.g. "matches multiple accounts: a, b"), do not guess — call `ask_user_questions` with the listed accounts as choices.
 
 Action Selection:
 - Choose the most direct action to accomplish the goal