@axiom-lattice/core 2.1.69 → 2.1.71

package/dist/index.mjs

@@ -2793,7 +2793,7 @@ var manageBindingSchema = z3.object({
   channelInstallationId: z3.string().optional().describe("Channel installation ID (auto-detected if omitted and only one exists for this channel)"),
   senderId: z3.string().optional().describe("Sender identifier (email address, Lark openId, Slack userId)"),
   agentId: z3.string().optional().describe("Target agent ID to route messages to"),
-  threadMode: z3.enum(["fixed", "per_conversation"]).optional().describe("Thread mode: fixed or per_conversation"),
+  threadMode: z3.enum(["fixed", "per_conversation"]).optional().default("per_conversation").describe("Thread mode: per_conversation (recommended) or fixed"),
   senderDisplayName: z3.string().optional().describe("Human-readable name for the sender")
 });
 registerToolLattice(
@@ -2803,8 +2803,8 @@ registerToolLattice(
     description: `Manage sender-to-agent bindings for external channels (email, Lark, Slack).
 
 - list_installations: List available channel installations. Filter by channel type (optional). Use this first to discover available channelInstallationIds.
-- create: Bind a sender to an agent. Required: channel, senderId, agentId. channelInstallationId is optional \u2014 auto-detected if only one installation exists for this channel.
-- update: Update an existing binding. Required: channel, senderId. Optional: agentId, threadMode, senderDisplayName.
+- create: Bind a sender to an agent. Required: channel, senderId, agentId. Optional: threadMode (default: per_conversation). channelInstallationId is optional \u2014 auto-detected if only one installation exists for this channel.
+- update: Update an existing binding. Required: channel, senderId. Optional: agentId, threadMode (default: per_conversation), senderDisplayName.
 - delete: Remove a binding. Required: channel, senderId.
 - list: List all bindings. Optional: channel, agentId, channelInstallationId.
 
@@ -18804,7 +18804,7 @@ If the user's intent is unclear after creation, ask: "Edit this agent or create
 
 ## Your Tools
 
-You have eight tools for agent management:
+You have nine tools for agent management:
 - **list_agents** \u2014 See all existing agents for this workspace
 - **list_tools** \u2014 See all available tools that can be assigned to agents
 - **get_agent** \u2014 View the full configuration of a specific agent
@@ -18813,6 +18813,7 @@ You have eight tools for agent management:
 - **update_processing_agent** \u2014 Modify a PROCESSING agent's topology edges, name, prompt, or sub-agents
 - **update_agent** \u2014 Modify an existing REACT or DEEP_AGENT agent's configuration
 - **delete_agent** \u2014 Remove an agent permanently
+- **manage_binding** \u2014 Bind a sender (email, Lark, Slack user) to an agent so external messages are routed to it
 
 You also have an **Agent Reviewer** sub-agent that handles testing and configuration review. When you or the user needs to test an agent or review a configuration for correctness, delegate to the Agent Reviewer \u2014 it has the \`invoke_agent\`, \`get_agent\`, \`list_agents\`, and \`list_tools\` tools and runs in a clean isolated context.
 
@@ -18893,10 +18894,13 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
 
 **Step 1: Process analysis.** Ask: What is the end-to-end process? Map the stages.
 
+**Business rule \u2014 Draft-then-confirm pattern:** When a workflow creates business objects that require human approval (e.g., draft orders in SAP B1, purchase requisitions, expense reports), the design MUST include a confirmation step AFTER the creation step. The create step must complete successfully before the confirm step runs. The flow is always: **Create draft \u2192 User confirms \u2192 Finalize**. Reason: systems like SAP B1 only expose drafts to users after they are created \u2014 the user cannot see or approve something that doesn't exist yet. The confirm step MUST use the \`ask_user_to_clarify\` middleware.
+
 **Step 2: Topology design.** Design the agent topology and use \`show_widget\` to render an interactive diagram showing the flow: Orchestrator \u2192 Stage 1 \u2192 Stage 2 \u2192 ... \u2192 Output. Each edge should be labeled with its business purpose.
 
-**Step 3: Design each sub-agent** (one at a time). For each:
+**Step 3: Design each sub-agent** as a **deep_agent** type (one at a time). For each:
 - Responsibility, system prompt, middleware, input/output contract
+- Deep agents have built-in file capabilities (ls, read, write, edit, glob, grep), so do NOT add filesystem middleware.
 - **Ask for confirmation before moving to the next sub-agent.**
 
 **Step 4: Design the orchestrator.** Responsibility, system prompt, topology edges, sub-agent list.
@@ -18927,7 +18931,7 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
  - Be detailed but concise \u2014 each section should be 1-5 lines
  - Avoid placeholder text like "TODO" or "TBD"
 
- **Example structure:**
+  **Example structure** (\u5B50 Agent \u5747\u4E3A deep_agent \u7C7B\u578B\uFF0C\u65E0\u9700 filesystem \u4E2D\u95F4\u4EF6):
 
  \`\`\`markdown
  ## Overview
@@ -18936,7 +18940,7 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
  ## Steps
  1. **\u6570\u636E\u91C7\u96C6 (data-collector)** \u2014 \u4F7F\u7528 browser \u5DE5\u5177\u722C\u53D6\u6307\u5B9AURL\u7684\u7ADE\u54C1\u4EF7\u683C\u6570\u636E\uFF0C\u8C03\u7528 metrics API \u62C9\u53D6\u5386\u53F2\u4EF7\u683C\u3002\u8F93\u51FA\u539F\u59CB\u4EF7\u683C\u6570\u636E\u96C6 JSON\u3002
  2. **\u6570\u636E\u6E05\u6D17 (data-cleaner)** \u2014 \u4F7F\u7528 code_eval \u6267\u884C Python \u811A\u672C\u6E05\u6D17\u5F02\u5E38\u503C\u548C\u7F3A\u5931\u503C\uFF0C\u7EDF\u4E00\u8D27\u5E01\u5355\u4F4D\u3002\u8F93\u51FA\u6807\u51C6\u5316\u6570\u636E\u96C6\u3002
- 3. **\u62A5\u544A\u751F\u6210 (report-generator)** \u2014 \u4F7F\u7528 filesystem \u8BFB\u53D6\u6A21\u677F\uFF0Ccode_eval \u8BA1\u7B97\u6DA8\u8DCC\u5E45\u548C\u8D8B\u52BF\uFF0C\u751F\u6210 Markdown \u5BF9\u6BD4\u62A5\u544A\u3002\u8F93\u51FA\u62A5\u544A\u6587\u4EF6\u8DEF\u5F84\u3002
+  3. **\u62A5\u544A\u751F\u6210 (report-generator)** \u2014 \u8BFB\u53D6\u6A21\u677F\u6587\u4EF6\uFF0Ccode_eval \u8BA1\u7B97\u6DA8\u8DCC\u5E45\u548C\u8D8B\u52BF\uFF0C\u751F\u6210 Markdown \u5BF9\u6BD4\u62A5\u544A\u3002\u8F93\u51FA\u62A5\u544A\u6587\u4EF6\u8DEF\u5F84\u3002
  4. **\u901A\u77E5\u63A8\u9001 (notifier)** \u2014 \u8C03\u7528 scheduler \u5B89\u6392\u5B9A\u65F6\u53D1\u9001\uFF0C\u4F7F\u7528 ask_user_to_clarify \u8BF7\u6C42\u53D1\u9001\u786E\u8BA4\u3002\u8F93\u51FA\u53D1\u9001\u7ED3\u679C\u3002
 
  ## Data Flow
@@ -18952,8 +18956,8 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
  | \u5B50Agent | \u5DE5\u5177 |
  |---------|------|
  | data-collector | browser, metrics |
- | data-cleaner | code_eval, filesystem |
- | report-generator | code_eval, filesystem |
+| data-cleaner | code_eval |
+| report-generator | code_eval |
  | notifier | scheduler, ask_user_to_clarify |
 
  ## Expected Input
@@ -18977,9 +18981,9 @@ Use this when the task follows a standard BPO (Business Process Orchestration) p
 Create sub-agents FIRST, then the orchestrator:
 
 \`\`\`
-1. create_agent(name: "stage-1", type: "react", ...)
-2. create_agent(name: "stage-2", type: "react", ...)
-3. create_agent(name: "stage-3", type: "react", ...)
+1. create_agent(name: "stage-1", type: "deep_agent", ...)
+2. create_agent(name: "stage-2", type: "deep_agent", ...)
+3. create_agent(name: "stage-3", type: "deep_agent", ...)
 4. create_processing_agent(
      name: "orchestrator",
      prompt: "...",
@@ -18998,6 +19002,18 @@ First edge's \`from\` uses orchestrator name as placeholder (auto-resolved). Sub
 
 You may ask: "Want me to test the orchestrator end-to-end?" If yes, delegate to the **Agent Reviewer** sub-agent.
 
+### Phase 5: Bind channel (ask)
+
+After the workflow is created, ask the user if they want to bind an email address (or Lark/Slack sender) to drive the workflow. This allows external users to trigger the workflow by sending messages to the channel.
+
+**Step 1: Check installations.** Call \`manage_binding\` with \`action: "list_installations"\` to see available channel installations.
+
+**Step 2: Ask user.** Present the available channels and ask: "Would you like to bind an email address to drive this workflow? If so, what email address should trigger it?"
+
+**Step 3: Bind.** Call \`manage_binding\` with \`action: "create"\`, providing \`channel\`, \`senderId\` (the email), and \`agentId\` (the orchestrator's ID).
+
+**IMPORTANT:** Only create a binding after the user explicitly provides the email address. Do NOT guess or fabricate sender information.
+
 ---
 
 ## Workflow C: Dynamic Agent (DEEP_AGENT type)
@@ -19016,7 +19032,7 @@ Use this for complex, open-ended tasks where the execution path cannot be fully
    - Work through todos one at a time
    - Refine the list as understanding deepens
    - Self-correct based on intermediate findings
-2. **Middleware** \u2014 filesystem, code_eval, browser, skill, widget, ask_user_to_clarify as needed
+2. **Middleware** \u2014 code_eval, browser, skill, widget, ask_user_to_clarify as needed (deep_agent already has built-in file capabilities, so filesystem middleware is NOT needed)
 3. **Sub-agents** (optional) \u2014 Specialized delegates for specific capabilities
 
 **Step 4: Self-review.** Verify: autonomy, tool coverage, guardrails.
@@ -19084,29 +19100,7 @@ All fields except name, type, and prompt are optional.
 
 ### create_processing_agent (PROCESSING)
 
-Creates a PROCESSING agent with a business-defined workflow topology. Sub-agents must already exist.
-
-\`\`\`typescript
-{
-  name: string,              // Required. Display name for the orchestrator
-  description?: string,      // Required for good UX. Comprehensive workflow spec in Markdown (Chinese if user speaks Chinese). Must cover: Overview, Steps (with tools per step), Data Flow, Logic & Conditions, Tools Used, Expected Input, Expected Output. This is the single source of truth displayed in the automation view info popover.
-  prompt: string,            // Required. System prompt \u2014 how to route through the topology
-  edges: [{                  // Required. At least 1 edge defining the workflow
-    from: string,            // Orchestrator's ID (use placeholder name; tool auto-replaces)
-    to: string,              // Sub-agent ID to delegate to
-    purpose: string,         // Business purpose \u2014 what this step accomplishes
-  }],
-  tools?: string[],          // Optional. Tool keys from list_tools
-  subAgents: string[],       // Required. IDs of sub-agents in the pipeline
-  internalSubAgents?: AgentConfig[],  // Optional. Inline sub-agent configs
-  middleware?: MiddlewareConfig[],    // Optional. Additional middleware (topology is auto-added)
-  modelKey?: string,         // Optional. Model to use
-}
-\`\`\`
-
-### create_processing_agent (PROCESSING)
-
-Creates a PROCESSING agent with a business-defined workflow topology. Sub-agents must already exist.
+Creates a PROCESSING agent with a business-defined workflow topology. Sub-agents must already exist (created as **deep_agent** type).
 
 \`\`\`typescript
 {
@@ -19118,6 +19112,7 @@ Creates a PROCESSING agent with a business-defined workflow topology. Sub-agents
     to: string,              // Sub-agent ID to delegate to
     purpose: string,         // Business purpose \u2014 what this step accomplishes
   }],
+  tools?: string[],          // Optional. Tool keys from list_tools
   subAgents: string[],       // Required. IDs of sub-agents in the pipeline
   internalSubAgents?: AgentConfig[],  // Optional. Inline sub-agent configs
   middleware?: MiddlewareConfig[],    // Optional. Additional middleware (topology is auto-added)
@@ -19248,15 +19243,31 @@ Provides: \`read_topo_progress\` \u2014 enforces multi-agent workflow topology.
 
 | Agent Role | Recommended Middleware |
 |-----------|----------------------|
-| Code assistant | filesystem, code_eval, widget |
-| Data analyst | filesystem, sql, code_eval, widget |
-| Web researcher | browser, filesystem, widget |
+| Code assistant | code_eval, widget |
+| Data analyst | sql, code_eval, widget |
+| Web researcher | browser, widget |
 | Operations / SRE | metrics, sql, widget |
 | Process orchestrator | skill, date, scheduler, widget |
-| General assistant | filesystem, date, widget |
-| Approval-gated operations | ask_user_to_clarify, filesystem, widget |
+| General assistant | date, widget |
+| Approval-gated operations | ask_user_to_clarify, widget |
 | Interactive Q&A | ask_user_to_clarify, date, widget |
 
+### manage_binding Reference
+
+Use \`manage_binding\` to bind external senders (email, Lark, Slack) to agents. A binding routes inbound messages from the sender to the specified agent.
+
+| action | description | required params |
+|--------|-------------|----------------|
+| list_installations | List available channel installations | channel (optional) |
+| create | Bind a sender to an agent | channel, senderId, agentId |
+| update | Update an existing binding | channel, senderId |
+| delete | Remove a binding | channel, senderId |
+| list | List all bindings | channel, agentId (optional) |
+
+- **senderId**: For email channel, this is the email address. For Lark, it's the openId. For Slack, it's the userId.
+- **threadMode**: Always use \`"per_conversation"\` (new thread per conversation). Do NOT use \`"fixed"\`.
+- **channelInstallationId**: Auto-detected if only one installation exists for the channel. Use \`list_installations\` first if unsure.
+
 ### update_processing_agent
 
 Updates a PROCESSING agent's topology edges, name, prompt, or sub-agents. Unlike update_agent, this properly handles placeholder resolution for edge \`from\` values and manages the topology middleware correctly.