SkyJourneyandClaude Opus 5
4ce9a92013
寰汐 v2 上线双 MCP（个人端 /mcp/ 与管理端 /admin-mcp/），两条端点是**两条独立的 信任边界**——Token 前缀不同、工具集不同、视角不同（管理端看全量、个人端只看我参与的）。 一个插件塞两套会让普通员工的客户端里出现他根本调不动的管理工具，因此拆成两个插件， 按角色各装各的。 ## huanxi（个人端，全体员工） 7 个技能：shared / report / leader / task / issue / meeting / org - 新增 `issue` `meeting`——v2 的议题域与会议域（M6v2 会议×议题解耦后的产物） - **删除 `weekly`**——v2 没有 weekly_report 表，周报已并入报告体系 - 各技能重写为**流水线定义**而非使用说明：写明工具调用顺序、ID 在步骤间怎么传、 人工确认节点落在哪。「禁止自动提交」这条 v1 已验证的硬约束保留 - 删掉 `references/` 拆分文件——v2 技能自包含 ## huanxi-admin（管理端，仅后台管理员） 4 个技能：admin-shared / admin-report / admin-module / admin-ops MCP server key 取 `huanxi-admin`（与个人端的 `huanxi` 不同名），否则两插件并存时 会键冲突。 ## 缓存目录按信任边界隔离 `~/.claude/huanxi-cache/` 下分 `personal/` `admin/` `dict/`：前两者视角不同， 混用会越权展示或数据错乱；`dict/` 与身份无关可共享。业务数据（任务/日报/会议/议题） **显式声明不缓存**——v1 没写这条，Agent 会自行决定缓存然后拿到陈旧数据。 ## 源码单一真相不在本仓库 技能源码在寰汐仓库 `skills/`，与 MCP docstring 同仓库同 commit——签名一改， 技能与工具在同一次改动里更新，从结构上消除跨仓库漂移（本仓库记忆 `feedback_plugin_dev.md` 记录的 4 类漂移覆盖全部 6 个 v1 技能，正是这个病）。 本仓库退化为**分发壳**，只接收 `python skills/sync_marketplace.py` 的产物，不手工编辑。 寰汐侧有 CI 守卫：技能里出现的每个工具名必须存在于实际注册表、个人端技能不得 指导调用管理端独有工具、不得硬编码状态字面量。 ## 本分支不合 main 插件配置的域名此刻跑的还是 v1，合进 main 会通过自动更新推给已安装用户， 他们的技能会去调 v1 上不存在的工具。合并前置条件写在 CLAUDE.md「已发布插件」节。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019Vyeia9k43dVaUFNLo8Lny
87 lines
2.6 KiB
Markdown
87 lines
2.6 KiB
Markdown
---
|
|
name: huanxi-admin-module
|
|
description: "寰汐管理端模块与任务：全量查模块任务、建模块、改模块状态、整组配置成员、跨模块任务管理。当用户说「建个模块」「把某人加进模块」「全公司任务情况」「关掉这个模块」时使用。"
|
|
---
|
|
|
|
# 寰汐管理端 · 模块与任务
|
|
|
|
**前置：先读 `huanxi-admin-shared`。**
|
|
|
|
全量视角，不受「我参不参与」过滤。
|
|
|
|
---
|
|
|
|
## 查
|
|
|
|
```
|
|
module_query(status_category?, q?) 全量模块，带负责人与成员数
|
|
module_get(module_ids=[...]) 详情含成员名单与各自角色
|
|
task_query(module_ids?, assignee_ids?, status_category?, priority?, q?)
|
|
task_get(task_ids=[...])
|
|
```
|
|
|
|
过滤维度都收列表，一次查多个比循环调用好。
|
|
|
|
---
|
|
|
|
## 建模块
|
|
|
|
```
|
|
module_create(name, type_id, leader_user_id, description?)
|
|
```
|
|
|
|
`type_id` 先 `dict_get(kinds=["module_types"])` 取，`leader_user_id` 用 `user_query` 取。
|
|
创建后会自动生成该模块的「杂记」任务，承载不值得单独建任务的零散工作。
|
|
|
|
---
|
|
|
|
## 改模块
|
|
|
|
```
|
|
module_update(module_id, name?, description?, status_option_id?)
|
|
```
|
|
|
|
⏸ **切到「已取消」有副作用**：级联取消该模块下全部未完成任务，并给成员发飞书通知。
|
|
这不是可撤销的操作，确认清楚再调。
|
|
|
|
模块**删除**不在本端点——那是纠错场景（建错了），需要在后台确认。
|
|
|
|
---
|
|
|
|
## 成员整组配置
|
|
|
|
```
|
|
module_set_members(module_id, members=[{user_id, role}, ...])
|
|
```
|
|
|
|
⏸ **替换语义**：不在名单里的现有成员**会被移除**。正确做法：
|
|
|
|
```
|
|
1. module_get 拿现有名单
|
|
2. 在现有名单基础上做改动（加人/改角色/去人）
|
|
3. 把完整的最终名单整组传回
|
|
4. 先把「改完会变成谁、谁会被移除」说给用户听，确认后再调
|
|
```
|
|
|
|
返回的 `added` / `role_changed` / `removed` 三组是本次实际发生的变更，
|
|
用它向用户复述结果。
|
|
|
|
一人一模块只能有一个角色（`leader` / `reviewer` / `member`）。新加入的成员会收到飞书通知。
|
|
|
|
---
|
|
|
|
## 任务
|
|
|
|
```
|
|
task_create(module_id, tasks=[{title, ...}])
|
|
task_update(updates=[{id, status_option_id?, progress?, priority?, ...}])
|
|
task_set_assignees(task_id, user_ids=[...])
|
|
```
|
|
|
|
- 改状态先 `dict_get` 取 task 类型的 `status_option_id`
|
|
- 状态与进度**有联动，只传一个就够**（进度 100 自动完成；已完成的调低进度自动回落）
|
|
- 非叶子任务（`progress_readonly` 为 true）不能直接设进度，要改它的子任务
|
|
- `task_set_assignees` 是**替换**不是追加，同 `module_set_members` 的注意事项
|
|
|
|
任务删除与跨模块转移不在本端点。
|