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
2.4 KiB
2.4 KiB
name, description
| name | description |
|---|---|
| huanxi-issue | 寰汐议题：提出议题、记录进展与决策链、调整分级、关闭。当用户说「提个议题」「这事记一下」「议题进展」「关掉这个议题」时使用。 |
寰汐议题
前置：先读 huanxi-shared。
议题是「需要被讨论和跟进的事」，与任务的区别：任务有明确执行人和完成标准， 议题是待决策或待澄清的问题。议题不需要审批，任何非观察期用户直接建。
决策链是核心
议题的价值不在「现在什么状态」，而在 progress_logs 记录的怎么走到这一步的。
issue_get 会带出完整决策链——起草结论、回顾判断时都应基于它，而不是只看当前状态。
常用流程
提出 issue_create(issues=[{title, description?, level?, is_management_only?,
participant_ids?, module_ids?, tag_ids?}])
查 issue_query(scope="library"|"created"|"participating", level?, q?, ...)
issue_get(issue_ids=[...]) ← 含决策链
记进展 issue_record_progress(issue_id, content, meeting_id?)
↓ meeting_id 填了 = 这条结论是某次会上定的，会议与议题因此建立关联
↓ 不填 = 独立记录的一条进展
调分级 issue_update(updates=[{id, level}]) ← 变更会记入决策链
关闭 ⏸ 先与用户确认结论文字
issue_close(issue_id, conclusion) ← 结论必填
分级
critical（必须讨论）/ watch（需关注）/ info（信息同步）。这是议题的分级，
与任务的 priority 是两套取值，别混。
几条容易踩的
- 关闭必须带结论，且要走
issue_close。用issue_update改状态到「已完成」是另一条 路径，服务端会拒——「关了但没说为什么」不允许存在。 is_management_only的议题只对管理层/创建人/参与人可见，其余人在列表和详情里 都看不到（不是置灰，是不存在）。你查不到某条议题时，可能就是这个原因，不要断言它不存在。- 编辑/关闭/重开/删除需要是创建人或后台管理员；记进展的范围更宽（创建人、参与人、 或该条挂在某会议下时该会议的主持人）。
- 默认隐藏已完成/已取消，要看全部传
include_closed=true。