Codex/enterprise application query

.gitignore

@@ -33,6 +33,7 @@ build/
 /external/
 external/
 scratchpad/
+.omx/
 check_parser*.py
 debug_*.py
 *.log

README.md

@@ -97,6 +97,15 @@ Ant Colony 不是一个单纯的聊天机器人，也不是一个单独的工作
 - `drive.search`
 - `mail.summary`
 
+### 企业微信机器人 MCP
+
+管理员可以通过控制台为企业微信机器人启用两类新增能力：
+
+- 文档：创建企业微信在线文档、写入 Markdown 正文、创建智能文档、向表格追加数据
+- 待办：创建待办、查询本人待办、更新或删除机器人创建的待办、搜索待办参与人
+
+对应入口已经集成到管理员控制台的“企微 MCP”页签中，服务器只保存配置地址，不把真实密钥写入 GitHub、公开说明书或前端源码。
+
 对应入口代码：
 
 - `src/platform/capability_backend.py`

data/business_systems/sample_enterprise_apps.json

@@ -0,0 +1,44 @@
+{
+  "meeting_rooms": [
+    {
+      "room_name": "三号会议室",
+      "date": "今天",
+      "start": "09:30",
+      "end": "10:30",
+      "title": "生产例会",
+      "applicant": "生产部"
+    },
+    {
+      "room_name": "一号会议室",
+      "date": "今天",
+      "start": "14:00",
+      "end": "15:00",
+      "title": "质量复盘",
+      "applicant": "质量部"
+    }
+  ],
+  "approvals": [
+    {
+      "title": "付款审批",
+      "status": "审批中",
+      "applicant": "财务部",
+      "current_node": "部门负责人"
+    },
+    {
+      "title": "会议室申请",
+      "status": "已通过",
+      "applicant": "生产部",
+      "current_node": "完成"
+    }
+  ],
+  "third_party_apps": [
+    {
+      "name": "工单系统",
+      "summary": "支持按工单号查询进度、异常、负责人和待审批节点"
+    },
+    {
+      "name": "设备点检",
+      "summary": "支持查询设备点检异常和维修跟进状态"
+    }
+  ]
+}

docs/releases/v1.0.1.md

@@ -0,0 +1,36 @@
+# Ant Colony v1.0.1
+
+本次发布把企业微信机器人能力从“能回答”推进到“能办事”：
+
+## 新增能力
+
+1. 企业微信文档 MCP
+   - 机器人可以创建企业微信在线文档。
+   - 机器人可以写入正文内容，支持 Markdown。
+   - 机器人可以创建企业微信智能文档。
+   - 机器人可以向企业微信表格追加数据。
+
+2. 企业微信待办 MCP
+   - 机器人可以创建待办。
+   - 机器人可以查询当前授权用户的待办列表。
+   - 机器人可以更新机器人创建的待办。
+   - 机器人可以删除机器人创建的待办。
+   - 机器人可以搜索待办参与人 userid。
+
+## 管理员体验
+
+1. 管理员控制台新增“企微 MCP”页签。
+2. 页面可查看文档/待办 MCP 是否已配置。
+3. 页面提供 URL 导入引导，指导管理员从企业微信机器人权限页复制 StreamableHttp URL。
+4. 页面只保存服务器配置，不在代码仓库中保存 apikey。
+
+## 验证结果
+
+1. 本地测试通过。
+2. 测试服务器已完成三端一致。
+3. 文档 MCP 和待办 MCP 在服务器侧均已做真实调用验证。
+
+## 备注
+
+1. 本版本继续保持 Bot First, Capability Backend 架构。
+2. 真实 MCP URL 仅保存在测试服务器配置中，不写入 GitHub。

docs/superpowers/plans/2026-07-09-enterprise-application-query.md

@@ -0,0 +1,83 @@
+# Enterprise Application Query Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Build permission-aware, domain-bounded and fuzzy enterprise application querying for WeCom, Feishu and DingTalk.
+
+**Architecture:** A query planner converts natural language into a typed plan. An application registry maps domains to capability IDs and permissions. The capability backend injects user context into providers, and providers return live data or explicit permission diagnostics without production sample fallback.
+
+**Tech Stack:** Python 3.12+, dataclasses, existing capability backend, platform API clients, pytest.
+
+---
+
+### Task 1: Typed query planner
+
+**Files:**
+- Create: `src/platform/enterprise_query.py`
+- Create: `tests/test_enterprise_query.py`
+
+- [ ] Write failing tests for meeting-room boundaries, approval self-scope, availability intent, fuzzy aliases and explicit cross-domain requests.
+- [ ] Run `python -m pytest -q tests/test_enterprise_query.py` and confirm missing-module failure.
+- [ ] Implement `EnterpriseQueryPlan`, domain aliases, normalized fuzzy matching and time-range extraction.
+- [ ] Run the query planner tests and confirm they pass.
+
+### Task 2: Application capability registry
+
+**Files:**
+- Create: `src/platform/application_registry.py`
+- Modify: `src/platform/capability_backend.py`
+- Test: `tests/test_application_registry.py`
+
+- [ ] Write failing tests proving each domain maps only to its own capability and required permissions.
+- [ ] Implement registry entries for meeting rooms, approvals, calendar, docs, drive, mail, contacts and third-party apps.
+- [ ] Add capability-context injection only for provider methods that declare `capability_context`.
+- [ ] Verify existing provider methods remain backward compatible.
+
+### Task 3: WeCom permission-aware providers
+
+**Files:**
+- Modify: `src/platform/api_wecom.py`
+- Test: `tests/test_wecom_enterprise_queries.py`
+
+- [ ] Write failing tests for room occupancy, room availability, approval self-filtering, fuzzy entity matching and independent domain failures.
+- [ ] Implement typed plan execution and provenance metadata.
+- [ ] Fetch approval numbers then details, filtering records by current user participation.
+- [ ] Keep permission failures separate from empty results.
+
+### Task 4: Agent and tool routing
+
+**Files:**
+- Modify: `src/workflows/office_workflow_service.py`
+- Modify: `src/agents/personal_agent.py`
+- Modify: `src/tools/platform_capability_tools.py`
+- Test: `tests/test_office_workflow_service.py`
+- Test: `tests/test_engine.py`
+
+- [ ] Write failing regressions for the four reported conversations.
+- [ ] Replace broad keyword branching with query-plan execution.
+- [ ] Render domain-separated results and omit unrelated sections.
+- [ ] Ensure missing tool arguments fall back to the original user query.
+
+### Task 5: Simulation and three-platform contract
+
+**Files:**
+- Modify: `src/platform/api_feishu.py`
+- Modify: `src/platform/api_dingtalk.py`
+- Modify: `src/platform/internal_capability_provider.py`
+- Test: `tests/test_platform_adapter_simulation.py`
+
+- [ ] Add typed-plan contract tests for Feishu and DingTalk.
+- [ ] Keep sample data available only behind `ANT_COLONY_ENABLE_SAMPLE_BUSINESS_DATA=true`.
+- [ ] Verify production mode never returns `[系统能力]` sample application data.
+
+### Task 6: Server rollout and validation
+
+**Files:**
+- Modify: `docs/handoff.md`
+
+- [ ] Run targeted tests, then `python -m pytest -q`.
+- [ ] Synchronize changed files to the test server.
+- [ ] Restart gateway, callback and root WeCom Bot processes so all channels load identical code.
+- [ ] Run the full server suite.
+- [ ] Probe the four acceptance queries through port 18090 and inspect the real Bot process logs.
+- [ ] Record exact permission limitations and results in `docs/handoff.md`.

docs/superpowers/specs/2026-07-09-enterprise-application-query-design.md

@@ -0,0 +1,58 @@
+# 企业应用权限化查询设计
+
+## 目标
+
+让企业 IM Bot 在用户权限范围内准确识别查询领域，调用对应应用、审批和流程数据，并支持模糊表达、复合查询、数据溯源与受控操作。
+
+## 查询模型
+
+每次用户请求先转换为 `EnterpriseQueryPlan`：
+
+- `domains`：会议室、审批、日程、文档、网盘、邮箱、通讯录、第三方应用
+- `operation`：查询、可用性、详情、列表、创建、催办等
+- `entities`：会议室名称、审批名称、流程编号等
+- `time_range`：今天、本周或明确时间
+- `user_scope`：本人、部门或授权范围
+- `cross_domain`：只有用户明确要求“全部、汇总、综合、跨应用”时开启
+
+领域判断采用领域关键词、别名和模糊匹配。通用词“申请”不能单独触发多个领域。
+
+## 权限模型
+
+统一能力后端把当前 IM 用户身份和组织上下文传给 provider。每个 provider 按以下顺序处理：
+
+1. 验证平台、用户和组织身份。
+2. 调用该应用对应的官方 API 或已登记连接器。
+3. 按申请人、审批人、部门、应用可见范围过滤。
+4. 返回来源、实时性、查询时间和权限诊断。
+
+平台应用凭据决定平台可调用的接口上限，用户身份决定结果可见范围。代码不绕过企微管理员未授予的接口权限。
+
+## 数据准确性
+
+- 生产环境禁止样例数据参与查询。
+- “哪个会议室可申请”必须用会议室清单减去时间段内的真实预订记录计算。
+- 查询失败、无权限和确实无数据必须是三个不同状态。
+- 多应用结果按领域隔离；单领域请求不得夹带其他领域数据。
+- 写操作进入现有风险确认和审计链路。
+
+## 扩展方式
+
+每个企微内置应用、审批模板或第三方应用通过能力注册表声明：
+
+- 领域和别名
+- 支持的查询及操作
+- 所需权限
+- provider 能力 ID
+- 是否支持用户级过滤
+
+飞书和钉钉复用同一查询计划与注册表，只替换 provider 实现。
+
+## 验收场景
+
+1. “三号会议室有人申请吗”只返回会议室数据。
+2. “哪个会议室今天可以申请”返回真实空闲会议室或明确权限不足。
+3. “查询我所有审批的状态”只返回当前用户有权查看的审批。
+4. “汇总我今天的会议、审批和日程”才允许跨域聚合。
+5. 模糊名称能够匹配应用、会议室和审批流程，但结果必须保留来源。
+6. 实际 WeCom Bot 进程重启后不再返回样例数据。

docs/user-manual.md

@@ -120,21 +120,21 @@
 管理员进入页面后按以下顺序操作：
 
 1. 先看“总览”，确认身份已验证
-2. 打开“平台 Bot 开通”
+2. 打开“平台通道接入”
 3. 逐字段填写对应平台的凭据
 4. 点击“保存并接管”
 5. 查看“是否需要重启”和“下一步”
-6. 打开“员工 AI 助手”
+6. 打开“员工助手开通”
 7. 输入同事的企业 IM 用户 ID
 8. 点击“开通并通知员工”
 9. 打开“运行验证”确认端口和环境变量状态
-10. 回到企业 IM 私聊和群聊中测试机器人是否正常回复
+10. 回到企业 IM 私聊和群聊中测试企业 AI 助手是否正常回复
 
-员工 AI 助手开通说明：
+员工助手开通说明：
 
 1. 这里不是给每个员工创建一个完全独立的企业微信机器人
-2. 正确模式是平台统一接管企业 AI 助手 Bot，再给员工分配使用权限和知识范围
-3. 企业微信场景下，系统会尝试向员工直接发送开通通知
+2. 正确模式是员工侧统一看到“企业 AI 助手”，后台自动使用应用通知、Bot 前台、群聊 @、文档/待办 MCP 等通道
+3. 企业微信场景下，系统会尝试向员工直接发送统一欢迎消息，员工可直接回复该消息开始使用
 4. 飞书和钉钉在没有真实账号时会保留为模拟/待联调状态
 
 知识库管理页面：
@@ -201,9 +201,9 @@
 
 ## 2026-06-24 后的当前规则：自动接管与自动权限
 
-### 平台 Bot 开通
+### 企业 AI 助手平台通道接入
 
-管理员不需要先理解或手动填写 `bot_id`、`bot_secret` 等技术字段。
+员工侧只看到一个“企业 AI 助手”。管理员不需要先理解或手动填写 `bot_id`、`bot_secret` 等技术字段；后台会根据能力自动使用应用通知、Bot 前台、群聊 @、文档/待办 MCP 等通道。
 
 当前管理台会按下面顺序自动采集已有配置：
 
@@ -312,3 +312,33 @@
    - `看一下这个工单为什么延迟`
 
 这些助手会自动组合审批、日历、会议、文档、知识库和样板业务系统能力，并把结果沉淀到记忆和知识库中，便于后续继续追问和复用。
+## 企业 AI 助手文档与待办能力
+
+管理员控制台提供“文档/待办能力”页签，用于配置企业 AI 助手背后的企业微信“文档”和“待办”MCP 能力。员工侧仍统一叫企业 AI 助手；该页面只保存 StreamableHttp URL 到服务器配置文件，不会把 apikey 写入 GitHub 代码、公开说明书或前端源码。
+
+配置步骤：
+
+1. 在企业微信机器人配置页打开“文档”可使用权限，复制 StreamableHttp URL。
+2. 在企业微信机器人配置页打开“待办”可使用权限，复制 StreamableHttp URL。
+3. 打开管理员控制台，进入“文档/待办能力”页签。
+4. 分别粘贴“企业 AI 助手文档能力”和“企业 AI 助手待办能力”的 StreamableHttp URL。
+5. 点击“保存 MCP URL”。
+6. 如果页面提示需要重启，重启 dashboard、gateway、wecom-bot 服务。
+7. 点击“发现 MCP 工具”，确认文档和待办均显示“已配置”且可发现工具。
+
+启用后企业 AI 助手可调用的典型能力：
+
+1. 文档：新建企微在线文档、写入 Markdown 内容、创建智能文档、追加表格数据。
+2. 待办：创建待办、查询本人待办、更新企业 AI 助手创建的待办、删除企业 AI 助手创建的待办、按姓名搜索待办参与人。
+3. 常见问法示例：
+   - `帮我新建一份项目周报文档`
+   - `把这几条内容整理成智能文档`
+   - `帮我创建一个明天下午 3 点前完成的待办`
+   - `查一下我本周有哪些待办`
+
+安全要求：
+
+1. StreamableHttp URL 中的 `apikey` 关联机器人和用户个人信息，只能保存在服务器环境变量或 `infra/.env.wecom`。
+2. 不要把 URL 复制到 GitHub、公开文档、截图、群公告或普通聊天记录中。
+3. 如果 URL 已泄露，应在企业微信机器人权限页面重置配置，并在管理员控制台重新导入。
+4. 管理员页面展示 URL 时只显示脱敏结果，用于确认已配置状态。

docs/wecom-ai-assistant-activation-guide.md

@@ -38,13 +38,13 @@
 
 #### 步骤 2：找到 AI 助手
 
-1. 在企业微信顶部搜索框输入公司发布的机器人名称
+1. 在企业微信顶部搜索框输入公司发布的企业 AI 助手名称
 2. 常见名称可能包括：
    `AI 助手`
    `企业 AI 助手`
    `马戈的机器人`
    `部门 AI 助手`
-3. 在搜索结果中点击对应机器人会话
+3. 在搜索结果中点击对应企业 AI 助手会话
 
 如果搜索不到：
 
@@ -222,7 +222,7 @@
 管理员完成统一开通后，员工只需要：
 
 1. 打开企业微信
-2. 搜索机器人名称
+2. 搜索企业 AI 助手名称，或直接回复管理员开通后推送的欢迎消息
 3. 发第一条消息开始使用
 
 员工无需再做任何回调配置。
@@ -276,7 +276,7 @@
 
 处理顺序：
 
-1. 确认机器人名称
+1. 确认企业 AI 助手名称
 2. 确认管理员是否已将机器人开放给你
 3. 确认你当前登录的是公司企业微信账号
 
@@ -347,11 +347,12 @@
 3. 历史平台配置
 4. 高级配置中管理员补录的一次性凭据
 
-正常开通企业微信 Bot 的操作是：
+正常开通企业 AI 助手的操作是：
 
 1. 打开管理员控制台
-2. 查看“平台 Bot 开通”里的企业微信状态
+2. 查看“平台通道接入”里的企业微信状态
 3. 点击“确认自动接管企业微信”
-4. 页面提示成功后，再到“员工 AI 助手”里填写同事的企业微信 user_id 并点击“开通并通知员工”
+4. 页面提示成功后，再到“员工助手开通”里填写同事的企业微信 user_id 并点击“开通并通知员工”
+5. 员工会收到统一欢迎消息，可直接回复该消息开始使用；也可搜索或在群里 @ 同名企业 AI 助手
 
 只有当系统明确提示“仍缺少必填凭据”时，管理员才需要展开高级配置补录一次。普通员工不需要创建机器人、不需要配置回调、不需要填写 Token 或 AESKey。