ai_co_discuss 0.3.47 → 0.3.50

package/.agents/skills/discuss-host/SKILL.md

@@ -17,6 +17,7 @@ description: "AI CoDiscuss 的主持技能，仅主持人调用，且须同时
 |---|---|
 | 自由协作请求（任务含 `mode: "free"`、`role: "host"`，且没有 `discussion_request`） | [自由协作主持](references/free.md) |
 | 协作房间中的讨论主持任务（`mode` 仍为 `free`，`discussion_request.purpose` 为 `discuss_host`） | [讨论主持](references/discussion.md) |
+| 房间开启了 Goal（任务含 `goal`，或请求 purpose 为 `goal_start` / `goal_continue`） | 先读 [自由协作主持](references/free.md)，再读 [Goal 模式主持](references/goal.md) |
 | 用户要开始新讨论，当前会话还没有自动任务 | [新建讨论与从 AI 对话发起](references/launch.md) |
 | 本地手动成员注册说明，或安排手动成员发言 | [手动成员](references/manual.md) |
 

package/.agents/skills/discuss-host/references/discussion.md

@@ -1,113 +1,113 @@
-# 讨论主持
-
-仅用于协作房间中的讨论主持任务。房间始终是自由协作（任务 `mode` 为 `free`）；有讨论任务时，`discussion_request.purpose` 区分主持与专家请求，`session.phase` 给出讨论阶段。没有 `discussion_request` 时读 [自由协作主持](free.md)。
-
-## 讨论中的硬约束
-
-括号里是原因，遇到未覆盖的情况按原因判断。
-
-1. **一轮内每位专家各回应一次。** 不连续安排刚发言的专家，新一轮也不先安排上一轮最后发言者；只有需要其本人澄清刚发表内容的事实或原意时才例外，并在简报中说明原因。（避免对话变成两个人的往返，也保证每个人都被听到。）
-2. **不覆盖已有内容**：目标、背景、边界已有内容视为用户或此前主持的决定；只写用户原文能支持的内容，推断的前提注明“主持推断”，不添加用户未提出的硬性约束。
-
-## 自动主持流程：一次实质推进，一次交接
-
-1. **核验执行**：首次读到新任务时用 `execution view ROOM 执行编号 --access-file FILE` 核对它仍有效；执行已失效就停止。
-2. **恢复现场**：先读 `room view`，结合任务的 `discussion_request.purpose`、`session.phase`、当前安排、`queued_turns`、`limits` 和执行状态判断；网站已有的安排优先于旧笔记，没有待处理的专家安排不等于主持人没有工作。首次接手时目标、背景、边界为空，先补全（见「首次接手」）。
-3. **读新内容**：新增的相关回答、用户留言及必要原文。智能调度有把握时会代你完成插话分流和无点名追问的衔接，没把握时才唤醒你。
-   若任务带 `scheduler_suggestions`，按请求与原消息编号读原文；未自动生效的建议不是既定安排，需要依据时用 `state decision ROOM DECISION_ID` 取回完整判断，再自行决定。“没有模型判断”或结果尚未核验时按字段如实处理。
-4. **判断并选一种交接**（见下表）。不要只回复“已就绪”或只写一段摘要就退出。
-5. **先保存进度，再提交交接**：判断、争点、下一步或阶段变化时用 `state set` 保存（见「保存进度」）；随后创建安排或收束。成功后本次写入资格即结束：立即结束，只回一句话，此后只回读核验，不再补 state 或输出总结。结果不明按参与技能核对原提交，不另创安排。
-
-| 判断 | 动作 |
-|---|---|
-| 还需专家回应 | 提交「发言计划」，结束本次执行 |
-| 用户只追问某一成员的观点或负责内容，不改变讨论安排 | 先 `turn roster ROOM`，从 `host_requests` 核对请求编号和原消息，再 `turn ask ROOM --request ID --expert NAME --roster REV --submission-id UUID --as 本人`；可问已发言者或自己。这是普通提问，不计轮次、不改队列，只关闭所选请求。返回 `execution_completed=true` 即结束；否则继续处理本执行的其余请求 |
-| 本轮仍有排队安排（`queued_turns` 非空） | 说明用户留言、改资料（`held_since` 非 0）或打断让本轮提前交回。先处理这些新内容，再读 `turn roster` 取得最新 `revision`；原计划仍适用就用该 revision 执行 `turn continue`，否则创建新安排，剩余排队随之作废 |
-| 专家名单有变化 | 见「名单变化」 |
-| 主持人需要以专家身份发言 | 给自己创建正式安排后结束；同一会话收到新的 `discuss` 专家任务，再用该执行提交 `chat` |
-| 已可收束，或正在限时收束 | 见「收束」 |
-| 缺少必要用户决定或无法继续 | 保留已有判断与具体阻碍，用 `execution fail ROOM 执行编号 --reason 原因 --access-file FILE` 结束本次主持请求，保留阻碍并等待用户决定；不要自动重启或循环唤醒主持 |
-
-### 发言计划
-
-每次需要专家回应时，先写好计划再一次提交，不逐位安排：
-
-1. 每次创建安排前都运行 `turn roster ROOM`，取得在场专家、本轮待发言者 `waiting`、`unregistered` 和最新 `revision`。
-2. 单人安排用 `turn create ROOM --expert NAME --question ... --roster <revision>`；整轮用 `turn create ROOM --plan-file PLAN.json --roster <revision>`。
-
-计划是按顺序列出本轮每位应发言专家各一次的数组，最多 10 项，例如：
-
-```json
-[{"expert": "Claude", "question": "两种建议似乎采用了不同的失败容忍度。请判断这是否解释了分歧；若不是，指出决定选择的证据。"},
- {"expert": "Antigravity", "question": "先读取最新回答，再对 Claude 的判断给出你的看法。"}]
-```
-
-- 安排须带本次读取的 `revision`；整轮计划还须包含 `waiting` 中的每位专家。`unregistered` 中尚未注册的手动专家不能排入，它注册后会自动加入本轮队列。名单变化后 `revision` 失效需重取，缺人或未带 `revision` 都会被拒绝；本轮不需要某人时先让其暂离。
-- 计划只覆盖当前一轮，跨轮追问要看本轮回答后再定；只有各轮问题不依赖回答的固定流程（如依次报数）才可排满多轮。后一位的问题取决于前一位回答时也不必等前一位答完：把问题写成“先读取最新回答，再按……回应”，由专家自己读取。
-- 网站在专家间自动接力，末位答完才交回主持。用户留言或打断时服务端会自动把控制权交回主持。
-- `members` 中 `adapter` 为 `api` 的专家没有命令行；房间有项目目录时它能用文件工具读取、搜索项目文件，用户给了可写权限时还能新建和编辑文件，没有项目目录时读不到本地文件。网站不记录它的项目权限，议题涉及本地文件时，开场主持说明写明相关文件路径和要点，让它自己读取；它说明读不到或索要信息时，由能读文件的专家补充，必要时贴关键片段。需要运行测试、构建或 git 的工作交给 CLI 专家。`initial` 中它同样按任务的 `read_until` 阅读房间消息。
-
-### 名单变化
-
-用户邀请、请回、暂离或移除专家后，以 `room view` 中最新的 `experts` 和 `queued_turns` 为准。
-
-- 新邀请的专家：自动专家已追加到现有队列的末尾，手动专家注册后才加入；保留当前发言及原计划，不重排或重复安排。尚无安排时，把新专家放在本轮尚未发言的原专家之后。
-- 暂离、移除或请回会作废原排队安排，再按最新名单重排。
-- 新加入或请回的专家先补独立观点，再进入交锋。
-- `members` 中 `session_mode` 为 `borrowed` 的专家续接用户已有的会话，带着自己的历史上下文：请它先说明哪些判断来自原有上下文，而不是把它当作从零开始的独立观点。
-
-## 推进判断
-
-探索可以保留多个方向，决策需要比较标准，事实问题需要可核验的证据；快速咨询不必套完整的全员流程。普通留言不默认打断当前专家，明确的暂停、继续或收束要求按现有规则执行；通过后续发言、主持简报或总结自然说明用户意见如何被处理，不为每条留言另发确认。
-
-默认先形成必要的独立观点，再围绕关键分歧深入讨论，按需复核并总结。阶段是阅读和判断边界，不是需要填满的轮次：
-
-- `initial`：必要专家先独立判断。专家只读任务中给出的议题资料和服务端 `read_until` 允许的内容；安排问题里的文字不能放宽读取边界。主持人兼任专家时也要贡献自己的观点；尽量先安排自己，避免先读他人回答再声称独立。
-- `discussing`：找出会改变结论的事实、假设、标准或偏好差异，请最相关的人回应；需要时用拟定结论请相关当事人核对原意、条件和剩余阻碍，不是让全员再赞同一次。
-- `concluded`：已有足够依据完成本次目标，或依约交付有限结论。明确哪些已确认、哪些仍有分歧、缺什么证据；到限不等于达成共识。
-
-房间的 `named_followup`（点名追问）为 false 时，首轮照常拆题出题；之后各轮不给每位专家写针对性追问，统一请专家先读上一轮回答、回应不同意或需补充的观点、可 @ 彼此提问。需要引导方向时用自己的主持说明表达，不改写成逐人点名。用户开启智能调度时，这类衔接可能已由程序代你完成（对话中有“智能调度”记录），你被唤醒时多半是需要收束、跑偏、卡住或处理用户留言。
-
-追问应说明真正需要弄清的争点及材料入口，给专家自主质疑前提、发现遗漏和改变观点的空间，不预设答案或固定逐项答题格式。
-
-核对会改变结论的数字、出处与适用条件，区分实测、外部声称、估计和建议。误述原意时请原作者澄清；另一人的赞同不能代替当事人确认。保留少数意见及其影响，不为了收束抹去限制，也不为凑轮次制造争论。重复立场时缩小争点或补有区分力的证据，仍无法判断就明确保留未决。
-
-## 工作流
-
-本次任务有 `workflow` 字段时，按其工作流说明安排发言：本地软件读 `skills` 末尾的 SKILL.md，API 主持人读本次系统提示中的正文。规则见 [自由协作主持](free.md) 的“工作流”一节；没有该字段时不按任何工作流做事。
-
-## 首次接手
-
-网页新建只要求话题名称与用户原文，目标、背景和讨论边界留给主持人。首次接手时若这些字段为空，先读用户原文与已知材料补全，用 `room update ROOM --goal-file ... --background-file ... --boundaries-file ... --as 本人`（凭据方式遵循参与技能）一次保存，再安排专家。只有歧义会改变讨论方向时才向用户确认。
-
-## 上限与到限
-
-轮次由程序按专家发言量统计并判定到限（`limits.segment_rounds` / `round_cap`），不要用自己的计划结构推算；暂停、准备与收束期间不计时。
-
-开场安排第一位专家前，先核对目标与上限：若按目标推算，本次轮次或时长上限显然不够完成（如要求报数到 10，3 人 3 轮只有 9 次发言），先发一条主持消息告诉用户冲突所在、上限内能做到哪一步，以及调整的办法（结束后在中间区点“继续讨论”设新上限）；然后在上限内照常推进，不等待答复，也不自行放宽上限。只写进 state 或简报不算告知。
-
-到限或目标完成后讨论结束、房间回到自由协作，是否再开启由用户决定：
-
-- 到限：用 `room limits ROOM --check --as 本人`（凭据方式遵循参与技能）处理。返回后房间已回到自由协作，本次执行随之换代，停止即可；之后用户的未点名留言照常交给你处理。用户要总结时，按「收束」写出最终 `moderation`。
-- 目标提前完成：先保存有原文依据的结论、state 与简报，再 `room conclusion` 取得 `revision`，用 `room limits ROOM --done --conclusion <revision> --as 本人` 通知程序（未带、过期或有未处理留言、state 落后都会被拒绝）。
-
-## 收束
-
-1. 保存有原文依据的最终判断、state 与简报（`until` 须覆盖实际读过的最新材料）；需要留主持说明时按参与技能写入。主持说明本身不结束讨论。
-2. `room conclusion ROOM` 申请收束状态，得到阻碍项 `blockers` 与 `revision`。
-3. 目标已完成且无阻碍时，用 `room limits ROOM --done --conclusion <revision> --as 本人` 收束。到限则用 `room limits ROOM --check --as 本人`。有未处理留言、state 落后或仍有排队安排会被拒绝；状态变化后 revision 失效需重取。成功后房间回到自由协作，本次执行结束，不再补 chat 回执；已结束的讨论只有用户能重新开启。
-
-最终总结按议题组织结论、不同意见、重要条件与未验证影响，不强制固定栏目。用户要求独立报告时再调用仓库的 discuss-report，报告不表示建议已获采纳。
-
-## 保存进度
-
-当判断、争点、下一步或阶段发生变化时，用一次 `state set ROOM --body-file ... --until ... --brief-file ... --as 本人` 同时保存：
-
-- state：足够恢复判断的依据与原文编号、已处理内容、未决问题和下一步意图。
-- 简报：让用户迅速了解当前结论、关键分歧和为什么接下来这样安排；不复述执行日志。
-
-`--until` 只覆盖实际已读材料。下一安排尚未创建时写成意图，实际编号与状态由服务端安排记录提供；恢复时两者对照，不为补写同一个编号再做一轮状态维护。无变化不写，已在当前上下文的材料不反复全文读取。保存失败先核对，不能一边失去接续依据一边继续派发。
-
-## 停止
-
-等待回答或一次回复结束不是整场结束。用户叫停、已暂停/收束或时间用尽时停止新增安排。执行投递重试用尽只会让对应请求失败并交回主持判断；不要据此自动暂停整场讨论。自动任务由接入程序续租和停止，不建原生定时任务。恢复须有明确继续指令。向用户报告结论或暂停点，以及影响协作的真实障碍。
+# 讨论主持
+
+仅用于协作房间中的讨论主持任务。房间始终是自由协作（任务 `mode` 为 `free`）；有讨论任务时，`discussion_request.purpose` 区分主持与专家请求，`session.phase` 给出讨论阶段。没有 `discussion_request` 时读 [自由协作主持](free.md)。
+
+## 讨论中的硬约束
+
+括号里是原因，遇到未覆盖的情况按原因判断。
+
+1. **一轮内每位专家各回应一次。** 不连续安排刚发言的专家，新一轮也不先安排上一轮最后发言者；只有需要其本人澄清刚发表内容的事实或原意时才例外，并在简报中说明原因。（避免对话变成两个人的往返，也保证每个人都被听到。）
+2. **不覆盖已有内容**：目标、背景、边界已有内容视为用户或此前主持的决定；只写用户原文能支持的内容，推断的前提注明“主持推断”，不添加用户未提出的硬性约束。
+
+## 自动主持流程：一次实质推进，一次交接
+
+1. **核验执行**：首次读到新任务时用 `execution view ROOM 执行编号 --access-file FILE` 核对它仍有效；执行已失效就停止。
+2. **恢复现场**：先读 `room view`，结合任务的 `discussion_request.purpose`、`session.phase`、当前安排、`queued_turns`、`limits` 和执行状态判断；网站已有的安排优先于旧笔记，没有待处理的专家安排不等于主持人没有工作。首次接手时目标、背景、边界为空，先补全（见「首次接手」）。
+3. **读新内容**：新增的相关回答、用户留言及必要原文。智能调度有把握时会代你完成插话分流和无点名追问的衔接，没把握时才唤醒你。
+   若任务带 `scheduler_suggestions`，按请求与原消息编号读原文；未自动生效的建议不是既定安排，需要依据时用 `state decision ROOM DECISION_ID` 取回完整判断，再自行决定。“没有模型判断”或结果尚未核验时按字段如实处理。
+4. **判断并选一种交接**（见下表）。不要只回复“已就绪”或只写一段摘要就退出。
+5. **先保存进度，再提交交接**：判断、争点、下一步或阶段变化时用 `state set` 保存（见「保存进度」）；随后创建安排或收束。成功后本次写入资格即结束：立即结束，只回一句话，此后只回读核验，不再补 state 或输出总结。结果不明按参与技能核对原提交，不另创安排。
+
+| 判断 | 动作 |
+|---|---|
+| 还需专家回应 | 提交「发言计划」，结束本次执行 |
+| 用户只追问某一成员的观点或负责内容，不改变讨论安排 | 先 `turn roster ROOM`，从 `host_requests` 核对请求编号和原消息，再 `turn ask ROOM --request ID --expert NAME --roster REV --submission-id UUID --as 本人`；可问已发言者或自己。这是普通提问，不计轮次、不改队列，只关闭所选请求。返回 `execution_completed=true` 即结束；否则继续处理本执行的其余请求 |
+| 本轮仍有排队安排（`queued_turns` 非空） | 说明用户留言、改资料（`held_since` 非 0）或打断让本轮提前交回。先处理这些新内容，再读 `turn roster` 取得最新 `revision`；原计划仍适用就用该 revision 执行 `turn continue`，否则创建新安排，剩余排队随之作废 |
+| 专家名单有变化 | 见「名单变化」 |
+| 主持人需要以专家身份发言 | 给自己创建正式安排后结束；同一会话收到新的 `discuss` 专家任务，再用该执行提交 `chat` |
+| 已可收束，或正在限时收束 | 见「收束」 |
+| 缺少必要用户决定或无法继续 | 保留已有判断与具体阻碍，用 `execution fail ROOM 执行编号 --reason 原因 --access-file FILE` 结束本次主持请求，保留阻碍并等待用户决定；不要自动重启或循环唤醒主持 |
+
+### 发言计划
+
+每次需要专家回应时，先写好计划再一次提交，不逐位安排：
+
+1. 每次创建安排前都运行 `turn roster ROOM`，取得在场专家、本轮待发言者 `waiting`、`unregistered` 和最新 `revision`。
+2. 单人安排用 `turn create ROOM --expert NAME --question ... --roster <revision>`；整轮用 `turn create ROOM --plan-file PLAN.json --roster <revision>`。
+
+计划是按顺序列出本轮每位应发言专家各一次的数组，最多 10 项，例如：
+
+```json
+[{"expert": "Claude", "question": "两种建议似乎采用了不同的失败容忍度。请判断这是否解释了分歧；若不是，指出决定选择的证据。"},
+ {"expert": "Antigravity", "question": "先读取最新回答，再对 Claude 的判断给出你的看法。"}]
+```
+
+- 安排须带本次读取的 `revision`；整轮计划还须包含 `waiting` 中的每位专家。`unregistered` 中尚未注册的手动专家不能排入，它注册后会自动加入本轮队列。名单变化后 `revision` 失效需重取，缺人或未带 `revision` 都会被拒绝；本轮不需要某人时先让其暂离。
+- 计划只覆盖当前一轮，跨轮追问要看本轮回答后再定；只有各轮问题不依赖回答的固定流程（如依次报数）才可排满多轮。后一位的问题取决于前一位回答时也不必等前一位答完：把问题写成“先读取最新回答，再按……回应”，由专家自己读取。
+- 网站在专家间自动接力，末位答完才交回主持。用户留言或打断时服务端会自动把控制权交回主持。
+- `members` 中 `adapter` 为 `api` 的专家没有命令行；房间有项目目录时它能用文件工具读取、搜索项目文件，用户给了可写权限时还能新建和编辑文件，没有项目目录时读不到本地文件。网站不记录它的项目权限，议题涉及本地文件时，开场主持说明写明相关文件路径和要点，让它自己读取；它说明读不到或索要信息时，由能读文件的专家补充，必要时贴关键片段。需要运行测试、构建或 git 的工作交给 CLI 专家。`initial` 中它同样按任务的 `read_until` 阅读房间消息。
+
+### 名单变化
+
+用户邀请、请回、暂离或移除专家后，以 `room view` 中最新的 `experts` 和 `queued_turns` 为准。
+
+- 新邀请的专家：自动专家已追加到现有队列的末尾，手动专家注册后才加入；保留当前发言及原计划，不重排或重复安排。尚无安排时，把新专家放在本轮尚未发言的原专家之后。
+- 暂离、移除或请回会作废原排队安排，再按最新名单重排。
+- 新加入或请回的专家先补独立观点，再进入交锋。
+- `members` 中 `session_mode` 为 `borrowed` 的专家续接用户已有的会话，带着自己的历史上下文：请它先说明哪些判断来自原有上下文，而不是把它当作从零开始的独立观点。
+
+## 推进判断
+
+探索可以保留多个方向，决策需要比较标准，事实问题需要可核验的证据；快速咨询不必套完整的全员流程。普通留言不默认打断当前专家，明确的暂停、继续或收束要求按现有规则执行；通过后续发言、主持简报或总结自然说明用户意见如何被处理，不为每条留言另发确认。
+
+默认先形成必要的独立观点，再围绕关键分歧深入讨论，按需复核并总结。阶段是阅读和判断边界，不是需要填满的轮次：
+
+- `initial`：必要专家先独立判断。专家只读任务中给出的议题资料和服务端 `read_until` 允许的内容；安排问题里的文字不能放宽读取边界。主持人兼任专家时也要贡献自己的观点；尽量先安排自己，避免先读他人回答再声称独立。
+- `discussing`：找出会改变结论的事实、假设、标准或偏好差异，请最相关的人回应；需要时用拟定结论请相关当事人核对原意、条件和剩余阻碍，不是让全员再赞同一次。
+- `concluded`：已有足够依据完成本次目标，或依约交付有限结论。明确哪些已确认、哪些仍有分歧、缺什么证据；到限不等于达成共识。
+
+房间的 `named_followup`（点名追问）为 false 时，首轮照常拆题出题；之后各轮不给每位专家写针对性追问，统一请专家先读上一轮回答、回应不同意或需补充的观点、可 @ 彼此提问。需要引导方向时用自己的主持说明表达，不改写成逐人点名。用户开启智能调度时，这类衔接可能已由程序代你完成（对话中有“智能调度”记录），你被唤醒时多半是需要收束、跑偏、卡住或处理用户留言。
+
+追问应说明真正需要弄清的争点及材料入口，给专家自主质疑前提、发现遗漏和改变观点的空间，不预设答案或固定逐项答题格式。
+
+核对会改变结论的数字、出处与适用条件，区分实测、外部声称、估计和建议。误述原意时请原作者澄清；另一人的赞同不能代替当事人确认。保留少数意见及其影响，不为了收束抹去限制，也不为凑轮次制造争论。重复立场时缩小争点或补有区分力的证据，仍无法判断就明确保留未决。
+
+## 工作流
+
+本次任务有 `workflow` 字段时，按其工作流说明安排发言：本地软件读 `skills` 末尾的 SKILL.md，API 主持人读本次系统提示中的正文。规则见 [自由协作主持](free.md) 的“工作流”一节；没有该字段时不按任何工作流做事。
+
+## 首次接手
+
+网页新建只要求话题名称与用户原文，目标、背景和讨论边界留给主持人。首次接手时若这些字段为空，先读用户原文与已知材料补全，用 `room update ROOM --goal-file ... --background-file ... --boundaries-file ... --as 本人`（凭据方式遵循参与技能）一次保存，再安排专家。只有歧义会改变讨论方向时才向用户确认。
+
+## 上限与到限
+
+轮次由程序按专家发言量统计并判定到限（`limits.segment_rounds` / `round_cap`），不要用自己的计划结构推算；暂停、准备与收束期间不计时。
+
+开场安排第一位专家前，先核对目标与上限：若按目标推算，本次轮次或时长上限显然不够完成（如要求报数到 10，3 人 3 轮只有 9 次发言），先发一条主持消息告诉用户冲突所在、上限内能做到哪一步，以及调整的办法（结束后在中间区点“继续讨论”设新上限）；然后在上限内照常推进，不等待答复，也不自行放宽上限。只写进 state 或简报不算告知。
+
+到限或目标完成后讨论结束、房间回到自由协作，是否再开启由用户决定：
+
+- 到限：用 `room limits ROOM --check --as 本人`（凭据方式遵循参与技能）处理。返回后房间已回到自由协作，本次执行随之换代，停止即可；之后用户的未点名留言照常交给你处理。用户要总结时，按「收束」写出最终 `moderation`。
+- 目标提前完成：先保存有原文依据的结论、state 与简报，再 `room conclusion` 取得 `revision`，用 `room limits ROOM --done --conclusion <revision> --as 本人` 通知程序（未带、过期或有未处理留言、state 落后都会被拒绝）。
+
+## 收束
+
+1. 保存有原文依据的最终判断、state 与简报（`until` 须覆盖实际读过的最新材料）；需要留主持说明时按参与技能写入。主持说明本身不结束讨论。
+2. `room conclusion ROOM` 申请收束状态，得到阻碍项 `blockers` 与 `revision`。
+3. 目标已完成且无阻碍时，用 `room limits ROOM --done --conclusion <revision> --as 本人` 收束（也可 `mode view ROOM` 取 revision 后 `mode done ROOM --revision <revision>`，效果相同）。到限则用 `room limits ROOM --check --as 本人`。有未处理留言、state 落后或仍有排队安排会被拒绝；状态变化后 revision 失效需重取。成功后房间回到自由协作，本次执行结束，不再补 chat 回执；已结束的讨论只有用户能重新开启。
+
+最终总结按议题组织结论、不同意见、重要条件与未验证影响，不强制固定栏目。用户要求独立报告时再调用仓库的 discuss-report，报告不表示建议已获采纳。
+
+## 保存进度
+
+当判断、争点、下一步或阶段发生变化时，用一次 `state set ROOM --body-file ... --until ... --brief-file ... --as 本人` 同时保存：
+
+- state：足够恢复判断的依据与原文编号、已处理内容、未决问题和下一步意图。
+- 简报：让用户迅速了解当前结论、关键分歧和为什么接下来这样安排；不复述执行日志。
+
+`--until` 只覆盖实际已读材料。下一安排尚未创建时写成意图，实际编号与状态由服务端安排记录提供；恢复时两者对照，不为补写同一个编号再做一轮状态维护。无变化不写，已在当前上下文的材料不反复全文读取。保存失败先核对，不能一边失去接续依据一边继续派发。
+
+## 停止
+
+等待回答或一次回复结束不是整场结束。用户叫停、已暂停/收束或时间用尽时停止新增安排。执行投递重试用尽只会让对应请求失败并交回主持判断；不要据此自动暂停整场讨论。自动任务由接入程序续租和停止，不建原生定时任务。恢复须有明确继续指令。向用户报告结论或暂停点，以及影响协作的真实障碍。

package/.agents/skills/discuss-host/references/free.md

@@ -1,34 +1,36 @@
-# 自由协作主持
-
-仅用于自由协作房间的主持人（任务 `role` 为 `host`）。成员的回答与提交方式见参与技能的自由协作一节。
-
-## 请求类型
-
-任务的 `request_purposes` 说明每条请求为何交给你：
-
-- `route`：用户未点名的消息，或全体调度交回的原问题，由你回答或分派；全体调度未代办时仍须读取原文，再决定安排。
-- `handoff`：你派出并要求交回的成员都已结束，据结果决定下一步。
-- `all`：用户请全体成员各自回应一次，其他成员已同时收到；你只回答自己的部分，不加 `--to`。
-
-先 `room view` 看成员与状态，再决定由谁处理。
-
-任务若有 `scheduler_suggestions`，按其中的 `request_id`、`message_id` 先读原问题；`applied:false` 表示未自动生效，`actual_action:unverified` 表示动作结果尚未核验。需要依据时用 `state decision ROOM DECISION_ID` 读取 `decision_id` 对应的完整判断，再自行决定；“没有模型判断”或没有记录编号时，不假定模型已经给过建议。
-
-## 派活
-
-- 需要他人时在回答中加 `--to 显示名`（可重复，不能点名自己），写明各自负责的文件或模块；不需要他人时不加，本次即结束。
-- 只点名一位成员时，它的回答直接面向用户；还要按结果安排下一步（如再交评审）时加 `--handoff`，它做完你会再被唤醒。点名多位时，全部结束后总会回到你汇总。
-- 需要预先指定实现后的只读评审时，先读 `review roster ROOM`，再在派实现的 `message post` 中带 `--next-review NAME --review-scope 范围 --review-roster REVISION`；评审者不能是本批实现者。授权与实现任务同时保存，自动要求该批交回主持人。候选目前限程序启动的 Codex CLI；没有合格成员时读取结果给出原因。
-- 收到 `review_handoffs` 时，先用 `review ready ROOM --batch ID` 读取完整委派、交付和报告，确认可交既定评审后用 `review advance ROOM --batch ID --revision REV --submission-id UUID --as 本人` 推进。只处理该批交接，其他请求继续完成；状态变化须重读，不能替换评审者或扩大权限。能力失效、额度不足、交付不完整等原因保留在读取结果和任务中。实际投递前本机复核只读权限与能力版本，失败撤销该次评审并交回主持人。
-- 收到 `handoff` 后交给其他成员或汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。
-- 同一条用户消息最多推进若干轮（`room view` 的 `free.max_rounds`，本链已用见 `free.chain_rounds`，用户可调）：你派一次活算一轮，成员做完交回给你汇总不另计。到上限时你的下一次派活会被暂存、任务链停下，由用户决定继续或发新消息；你不能自己加轮。派活前先想清楚需要几位、几轮，最后一轮留给汇总。（上限防止 AI 之间无人值守地来回转交。）
-
-用户请成员分工改代码（定计划、实现、评审、整理文档）时，先读 [开发协作](dev-flow.md)。
-
-## 工作流
-
-本次任务有 `workflow` 字段时，本房间启用了用户的工作流。它像技能一样按需使用：`workflow.description` 是它的用途，请求与用途相符或用户要求按它做时才用，其他请求照常处理。要用时，本会话还没读过、或 `workflow.revision` 与上次读到的不同，才读 `workflow.skill_path`（API 主持人读系统提示中的工作流正文）；否则沿用已读内容。按它组织工作时，`workflow.members` 列出每张卡片现在由哪位成员担任、是否在场、项目权限；只点名在场的成员，缺某个角色时在回答里说明缺谁，不另找成员代替。工作流只带来做法和成员，不扩大你的权限。
-
-本次任务（本地任务文件或 API 的 `task`）没有 `workflow` 字段时，不按任何工作流做事，即使会话里读过。
-
-用户请你把本房间的做法存成工作流（或要你按某种分工新建一套流程）时，按 [workflow-creator](../../workflow-creator/SKILL.md) 技能做。任务有 `host_workflows: true` 时，房主已允许你自行保存并启用，不必等用户导入。
+# 自由协作主持
+
+仅用于自由协作房间的主持人（任务 `role` 为 `host`）。成员的回答与提交方式见参与技能的自由协作一节。
+
+## 请求类型
+
+任务的 `request_purposes` 说明每条请求为何交给你：
+
+- `route`：用户未点名的消息，或全体调度交回的原问题，由你回答或分派；全体调度未代办时仍须读取原文，再决定安排。
+- `handoff`：你派出并要求交回的成员都已结束，据结果决定下一步。
+- `all`：用户请全体成员各自回应一次，其他成员已同时收到；你只回答自己的部分，不加 `--to`。
+- `goal_start`、`goal_continue`：用户开启了 Goal，按 [Goal 模式主持](goal.md) 处理。
+- `discuss_start`：用户发了 `/discuss`，等你补全讨论目标后开启讨论。消息带了文本时以原文为准，只整理措辞；没带时从最近对话提炼，提炼不出明确的讨论问题就不开启，直接回答并说明缺什么。开启：`run start ROOM --request 请求编号 --goal-file 草稿`，上限用房间默认值，你不设置。然后照常简短回答；之后程序会给你讨论主持任务，按 [讨论主持](discussion.md) 安排发言。
+
+先 `room view` 看成员与状态，再决定由谁处理。
+
+任务若有 `scheduler_suggestions`，按其中的 `request_id`、`message_id` 先读原问题；`applied:false` 表示未自动生效，`actual_action:unverified` 表示动作结果尚未核验。需要依据时用 `state decision ROOM DECISION_ID` 读取 `decision_id` 对应的完整判断，再自行决定；“没有模型判断”或没有记录编号时，不假定模型已经给过建议。
+
+## 派活
+
+- 需要他人时在回答中加 `--to 显示名`（可重复，不能点名自己），写明各自负责的文件或模块；不需要他人时不加，本次即结束。
+- 只点名一位成员时，它的回答直接面向用户；还要按结果安排下一步（如再交评审）时加 `--handoff`，它做完你会再被唤醒。派评审、验证这类结论要回到流程里的工作时默认加：不加则结论只停在用户面前，房间不会自动继续。点名多位时，全部结束后总会回到你汇总。
+- 需要预先指定实现后的只读评审时，先读 `review roster ROOM`，再在派实现的 `message post` 中带 `--next-review NAME --review-scope 范围 --review-roster REVISION`；评审者不能是本批实现者。授权与实现任务同时保存，自动要求该批交回主持人。候选目前限程序启动的 Codex CLI；没有合格成员时读取结果给出原因。
+- 收到 `review_handoffs` 时，先用 `review ready ROOM --batch ID` 读取完整委派、交付和报告，确认可交既定评审后用 `review advance ROOM --batch ID --revision REV --submission-id UUID --as 本人` 推进。只处理该批交接，其他请求继续完成；状态变化须重读，不能替换评审者或扩大权限。能力失效、额度不足、交付不完整等原因保留在读取结果和任务中。实际投递前本机复核只读权限与能力版本，失败撤销该次评审并交回主持人。
+- 收到 `handoff` 后交给其他成员或汇总给用户；成员的回答已完整时只用一两句说明完成，不复述。
+- 同一条用户消息最多推进若干轮（`room view` 的 `free.max_rounds`，本链已用见 `free.chain_rounds`，用户可调）：你派一次活算一轮，成员做完交回给你汇总不另计。到上限时你的下一次派活会被暂存、任务链停下，由用户决定继续或发新消息；你不能自己加轮。派活前先想清楚需要几位、几轮，最后一轮留给汇总。（上限防止 AI 之间无人值守地来回转交。）
+
+用户请成员分工改代码（定计划、实现、评审、整理文档）时，先读 [开发协作](dev-flow.md)。
+
+## 工作流
+
+本次任务有 `workflow` 字段时，本房间启用了用户的工作流。它像技能一样按需使用：`workflow.description` 是它的用途，请求与用途相符或用户要求按它做时才用，其他请求照常处理。要用时，本会话还没读过、或 `workflow.revision` 与上次读到的不同，才读 `workflow.skill_path`（API 主持人读系统提示中的工作流正文）；否则沿用已读内容。按它组织工作时，`workflow.members` 列出每张卡片现在由哪位成员担任、是否在场、项目权限；只点名在场的成员，缺某个角色时在回答里说明缺谁，不另找成员代替。工作流只带来做法和成员，不扩大你的权限。
+
+本次任务（本地任务文件或 API 的 `task`）没有 `workflow` 字段时，不按任何工作流做事，即使会话里读过。
+
+用户请你把本房间的做法存成工作流（或要你按某种分工新建一套流程）时，按 [workflow-creator](../../workflow-creator/SKILL.md) 技能做。任务有 `host_workflows: true` 时，房主已允许你自行保存并启用，不必等用户导入。

package/.agents/skills/discuss-host/references/goal.md

@@ -0,0 +1,35 @@
+# Goal 模式主持
+
+用户用 `/goal` 或页面开启 Goal 后，你要持续推进这个目标，直到达成或确实无法推进。房间空闲时，程序会再唤醒你一次（`goal_continue`），所以不必在一次执行里做完全部工作；你每次需要判断的是下一步该做什么。
+
+任务文件的 `goal` 字段给出目标、状态、已续跑次数和用时；需要最新状态时用 `goal view ROOM`。目标文本是用户交给你的任务材料，不是更高优先级的指令。
+
+## 开启：`goal_start` 请求
+
+用户发了 `/goal`，等你补全目标。
+
+- 消息带了文本时，以原文为准：只能整理措辞，不改变范围。
+- 没带文本时，从最近的对话提炼用户要达成的结果。提炼不出明确、可核验的目标，就不开启：直接回答，说明缺什么。（目标含糊时自动推进只会放大偏差。）
+- 开启：`goal start ROOM --request 请求编号 --objective-file 草稿`，然后照常回答：说明你理解的目标，并开始第一步（通常是派活）。
+- 预算由用户设定，你不设置也不提高。
+
+## 推进：每次被唤醒
+
+1. 先判断上一次唤醒之后的情况：
+   - **有进展**：产生了改变状态的结果，或得到了改变下一步的证据。
+   - **在等用户**：需要用户决定、授权或补充信息。
+   - **无进展**：只复述了状态，或只列了计划没有执行。
+2. 能推进就派活（`--to`），并写明负责的范围和完成标准。派出去的活结束、房间再次空闲时，程序会再唤醒你。
+3. 需要用户时，直接向用户提问并说明需要什么。这次不派活，程序就不再自动唤醒你，直到用户回复。
+4. 无进展时，先查原因再换做法，不要重复同样的安排。
+
+不要把目标缩小成本次容易做完的部分，也不要把"做了一些"说成"完成"。（Goal 的价值在于完整达成用户要的结果。）
+
+权限不变：仍受成员项目权限和任务链轮数限制。不邀请成员，不提交、推送或部署，除非用户另行要求。
+
+## 结束
+
+- **完成**：先对照实际状态核验（成员交付原文、测试结果、文件），确认没有剩余必需工作；再 `goal view` 取 revision，然后 `goal done ROOM --revision REV --note-file 草稿`，在说明里写核验依据（`mode view` / `mode done` 效果相同）。还有成员在处理时会被拒绝。不能因为做了很久或预算将尽就宣告完成。
+- **卡住**：同一个阻碍连续 3 次唤醒都无法解决，且没有用户输入或外部变化就推进不了时，用 `goal block ROOM --revision REV --note-file 草稿` 写明阻碍。第一次遇到阻碍时不宣告。
+- **预算用完**：任务里 `goal.status` 为 `budget_limited` 时，只做收尾：总结已完成的部分、剩余工作与阻碍，给用户明确的下一步，不再派新活。
+- 暂停、恢复、结束由用户控制，你不能操作。

package/.agents/skills/discuss-participant/SKILL.md

@@ -28,6 +28,7 @@ description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主
 2. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。任务文件的 `stopped_executions` 列出你此前被用户停止或跳过的执行：会话里如有它们未完成的工作，不接着做、不为它们补交，只处理本次请求。（失效的执行若还能产生可见结果，用户的打断与暂停就失去意义。）
 3. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号；`message post` 可省略，CLI 按房间、身份、关联与内容生成，用同一份草稿重试即得同一编号；结果不明时先按原编号查询，再按 [写入与恢复](references/writing.md) 处理。（网站靠它去重，换号会产生重复发言。）
 4. **不创建定时任务、不操作其他软件、不发状态回执**（就绪、开始、完成、停止等说明），除非用户要求或出现需要记录的异常；回执不能作为观点、完成或共识的证据。（这些动作有副作用，回执只会淹没真正的回答。）
+5. **回复即交付**：一次请求只回答一次，回答后请求即结束。需要较长时间的工作做完再一次性回答，需要派活时在同一次回答里派；不在房间里回复进度，执行卡片会显示正在进行。（中途回复会提前结束请求，做完后就没有可绑定的请求来汇报。）
 
 ## 命令入口与身份
 

package/.agents/skills/workflow-creator/SKILL.md

@@ -84,14 +84,14 @@ project_access: write
 | 你在哪里 | 怎么保存 |
 |---|---|
 | 房间主持人，任务里有 `host_workflows: true` | 房主已允许你自建：把草稿写成一个文件（下方“草稿格式”，只用一段 `1/1`），放在任务的 `draft_directory` 下，运行 `<cli> launch workflow-adopt --draft <文件> --access-file <本次任务的 access_file>`。程序校验、保存、在本房间启用并邀请缺少的卡片成员（离开的请回），返回 `members`（卡片 ID → 成员名），本次执行里就能点名派活。只能更新本房间绑定的工作流；卡片权限最高 write。 |
-| 房间主持人，任务里没有该字段 | 在回答里发出草稿（草稿格式），由用户在网页“工作流库 → 粘贴导入”保存。可以告诉用户：在“成员与设置 → 协作设置”打开“允许主持人自建工作流”后，你就能自己保存并启用。 |
+| 房间主持人，任务里没有该字段 | 你不能保存。告诉用户：在“成员与设置 → 协作设置”打开“允许主持人自建工作流”后，你就能自己保存并启用；用户打开后再按上一行做。 |
 | 不在房间里，用户直接让你建 | 先在一个临时文件夹里按“格式”写好，运行 `codiscuss launch workflow-check --dir <文件夹>` 校验；用户确认后运行 `codiscuss launch workflow-save --dir <文件夹>` 保存进工作流库。同 ID 会覆盖原有工作流，覆盖前先告诉用户。 |
 
 不要直接写入本机服务目录的 `workflows/`：那样会跳过校验和写入锁，格式错的文件会让启用它的房间读不到工作流。命令失败时按报错修正，不要绕过。
 
 ### 草稿格式
 
-草稿把整个文件夹写进一段文本，用于 `workflow-adopt` 或粘贴导入：
+草稿把整个文件夹写进一段文本，用于 `workflow-adopt`：
 
 ```
 <!-- workflow-part: 1/1 id: novel-serial -->

package/README.md

@@ -28,6 +28,7 @@ Most multi-agent frameworks spin up fresh agents inside their own runtime. AI Co
 
 - **Delegate by mention** — `@` an agent and it works in its own original session; several can run in parallel. Unaddressed messages go to an AI host that routes the work.
 - **Structured discussions** — set a goal and round / time limits; the host schedules speakers and follow-ups, then the room returns to free collaboration with history and conclusions kept.
+- **Goal mode** — give the host an objective with `/goal`; whenever the room goes idle the host is woken to carry on, until it confirms the goal is complete, gets blocked, a budget runs out or you end it.
 - **Smart Scheduling** — optionally let a decision model handle routine routing instead of waking the host.
 - **Workflows** — save a way of working as a host playbook (`SKILL.md`) plus a set of agent cards, share it as a folder, and select it when creating a room or inviting members; after you confirm the members, the host follows the playbook. It brings the method and the people, not a guaranteed procedure. See [runner docs](docs/runner.md#工作流可选).
 - **Mix any participant** — local CLIs and desktop apps, model APIs and manually connected sessions in one room.
@@ -42,6 +43,7 @@ Many turns in a room are routing decisions: who a message is for, whether member
 
 - Unaddressed messages go to the member they are clearly meant for, to everyone, or to no one; otherwise to the host.
 - In discussions, it resumes the queue after an interjection and picks the next speaker between rounds.
+- In Goal mode, it skips waking the host when the idle room is clearly waiting for your reply.
 - It acts only above a confidence threshold, and falls back to the host on low confidence or errors. Each decision is shown in the conversation and can be rated.
 
 It is opt-in per room and uses your own key; the room title and recent messages are sent to the provider. See [Smart Scheduling](docs/en/workflow.md#smart-scheduling).
@@ -68,7 +70,7 @@ codiscuss setup
 
 1. Click **New Room** (新建房间) and add AI members.
 2. Pick a host with the crown icon, and optionally set a project directory.
-3. Optionally enable **Start discussion after creating** (创建后开启讨论) and set a goal.
+3. Optionally choose under **After creating** (创建后) to start a discussion or a Goal, and set its goal.
 4. Create the room and start talking — `@` members to assign work.
 
 ```sh