寰汐 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
2.8 KiB
2.8 KiB
name, description
| name | description |
|---|---|
| huanxi-report | 寰汐员工日报:查看今日状态、填写并提交日报、撤回修改。当用户说「帮我写日报」「填日报」「提交日报」「今天要报什么」时使用。 |
寰汐员工日报
前置:先读 huanxi-shared(缓存策略、状态模型、确认约定)。
标准流程
Step 1 report_get_context(date?)
↓ 一次拿全:是否工作日、是否免报、整体状态、按模块分组的待汇报条目
↓ 非工作日 → 告知并询问是否仍要填(不中断)
↓ 已全部提交 → 转「修改已提交内容」分支
↓ 免报日 → 告知无需提交,询问是否仍要记录
Step 2 展示待汇报任务,引导用户逐条说今天做了什么
↓ 每条记住 task_id(后续提交要用)
↓ 用户说不清的任务,可用 task_get 补上下文,不要替他编
Step 3 (可选)润色
↓ 你自己润色即可,**不要找工具**——你就是那个语言模型
↓ 展示润色前后,让用户选
Step 4 report_save_draft(items=[...])
↓ 存草稿,此时还没提交
↓ 今天不报某条 → 该项加 dismissed=true;恢复 → restore=true
Step 5 ⏸ 展示完整初稿,等待用户明确确认
Step 6 report_submit(task_ids=[...])
↓ 只提交确认过的那些;不传 task_ids 则提交全部草稿
Step 5 不可省略。 写日报和交日报是两个决定,用户可能只想先存着。
修改已提交内容
report_withdraw(task_ids=[...]) → 变回草稿
↓ 修改
report_save_draft(...)
↓ ⏸ 确认
report_submit(task_ids=[...])
仅当天可撤回。 隔天的日报已进入统计口径,撤回会被拒绝——这时应告诉用户去找管理员, 而不是反复重试。
查历史
report_history(scope="module", module_id=...) 某模块某天全体成员报了什么
report_history(scope="task", task_id=..., date_from=..., date_to=...)
某个任务被谁在哪天报过什么
几条容易踩的
- 条目用
task_id定位,不是条目自身的 id。report_get_context返回里的task_id就是后续 save/submit/withdraw 都要传的那个。 - 空内容不能提交:服务端会拒。要么写点内容,要么标
dismissed。 - 模块杂记(
is_module_misc)承载零散工作,可以报也可以不报,但它不计入 「未提交」统计——用户只写了杂记不算完成当天汇报,提醒他还有别的任务没写。 progress_update是任务进度(0-100),不是完成度描述。填了它会真的改任务进度。- 免报日(
is_exempt)不产生未提交统计,也不必催。