ai_co_discuss 0.2.46 → 0.2.48

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

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

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

@@ -1,8 +1,22 @@
-# 从 AI 对话发起讨论
+# 新建讨论与从 AI 对话发起
 
-仅在用户要求开始一场全自动讨论、且当前会话尚未收到有效自动任务时使用。网页启动交付的任务直接按参与技能进入执行，不重复启动。
+仅在用户要求开始一场新讨论、且当前会话尚未收到有效自动任务时使用。网页启动交付的任务直接按参与技能进入执行，不重复启动。
 
-## 配置与当前会话
+## 定位与新建
+
+当前实际会话承担主持，不另建调度聊天。沿用用户指定的房间和运行方式；新讨论尚未选择时，只确认“全自动讨论 / 手动复制冷启动”。入口与推进方式、CLI / App 客户端分别判断。
+
+未指定房间时，保存目标、背景、参与配置和上限，核验后再接入专家。全自动使用下文启动入口，手动模式沿用 CLI 建房与接入流程。全自动要求主持和专家均具备本地 CLI 读写能力；配置完成后依据用户的启动指令运行，普通建房本身不代表已启动。在线只读专家使用手动接入分工，不静默转换模式。
+
+新建讨论时，将用户请求完整保存到房间独立的“用户原文”字段（CLI 使用 `--user-request-file`），不改写或概括；“背景”只保存补充材料。原文超过该字段 4000 字上限时，将完整原文按参与技能保存为开场主持消息，“用户原文”保留原文消息链接，不截断原文。
+
+工具入口、站点、项目与 cwd 的定位遵循参与技能。新建会话可指定所属项目及 cwd，也可缺省；已有会话不靠提示词迁移目录。仅在首次配置或启动自动程序时查阅仓库 `docs/deployment.md` 与 `docs/cli.md`，不把安装操作混入每次讨论。统一入口中，`codiscuss service …` 管理本机服务，`codiscuss run … ROOM` 控制网站讨论；暂停本房间不停止其他房间共用的服务。
+
+## 从当前 AI 对话发起全自动讨论
+
+使用 `codiscuss launch` 复用本机软件配置并将首个主持任务交回当前会话；已收到有效自动任务时，不再次调用启动命令。
+
+### 配置与当前会话
 
 1. 使用已安装的 `codiscuss`；未安装时用本仓库 `node runner/codiscuss.mjs`。`codiscuss launch settings` 只读本机软件默认配置，不启动服务或 AI。缺少配置时按仓库 `docs/runner.md` 的“两种讨论入口与启动配置”补齐；用户已提供的软件、目录和上限直接沿用，只询问无法确定的缺项。
 2. 从当前软件的实际会话信息取得会话 ID，不自造编号。启动文件中 `entry` 使用 `conversation`，`current_session_id` 使用该实际 ID；主持人的 `participants` 覆盖配置必须对应当前实际 CLI / App 客户端，不能仅根据模型名称选适配器。当前会话继续主持，不另建主持聊天。
@@ -36,7 +50,7 @@
 
 已有房间改为指定顶层 `room_id`，省略 `room`；受保护房间另提供原私有配置的 `access_file` 路径，不读取或打印令牌。首次启动命令不替代已暂停房间的继续操作，已有运行按当前房间状态接续。
 
-## 启动与交接
+### 启动与交接
 
 ```sh
 codiscuss launch start --file 启动文件.json --dry-run

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

@@ -7,67 +7,90 @@ description: "AI CoDiscuss 的通用参与技能，所有参与者（包括主
 
 **主要任务是参与讨论：理解问题，检验证据与假设，回应其他人的论证，形成或修正自己的判断。** 网站操作负责保存这份工作，不应代替思考或成为发言主题。
 
-软件参与者包括主持人使用本技能；主持人另读 discuss-host。只承担本次授予的职责，安装、读取或编辑技能不启动讨论。各 AI 使用自己的软件或用户明确配置的 API 形成观点；软件参与者不能自行改用模型 API 替代本次身份或其他专家。API 参与者由本机接入程序提供房间工具与相同的参与边界。
+主持人也使用本技能，另读 discuss-host。只承担本次授予的职责；安装、读取或编辑技能不启动讨论。各 AI 用自己的软件或用户明确配置的 API 形成观点，不能自行改用模型 API 替代本次身份或其他专家。
 
-## 讨论质量
+## 先确认你在哪个场景
 
-先回答真正的问题，再给影响判断的理由、证据、适用条件与不确定性。初始观点形成自己的见解；深入讨论先理解对方实际主张及其最有力的依据，再指出同意、分歧或需要补证的部分。区分事实错误、假设不同、评价标准不同和偏好不同，避免把它们混成“谁对谁错”。
+| 场景 | 做法 |
+|---|---|
+| 手动成员第一次到场（收到启动指令） | 标准流程 A，手动接入细节见 [手动接入](references/manual.md) |
+| 讨论房间里轮到你发言 | 标准流程 B |
+| 收到 `*.task.json` 的自动任务 | 标准流程 C |
+| 自由协作房间（任务含 `mode: "free"`） | 读 [自由协作](references/free.md) |
+| 需要原生定时持续参与 | 读 [手动接入](references/manual.md) |
+| 首次某类写入、代发、超长正文、附件或出错 | 读 [写入与恢复](references/writing.md) |
 
-可以坚持有依据的少数意见，也可以因新证据修改判断并解释变化。主动检查关键反例与遗漏，但不为反对而反对，不以赞同人数代替证据；若现有材料不足，说明什么证据会改变结论。需要对方回应时直接 `@专家名` 并说明具体问题；@ 是讨论线索，不会自动通知或授予发言权。
+## 硬约束
 
-篇幅和结构由问题决定，不要求固定栏目、反驳数量或字数。保留关键数字、条件与失败情形；回应追问只补新论证或观点变化，旧内容用原文编号引用。每次专家回答附一两句简述与完整正文；简述表达主要判断或变化，完整论证与出处放正文，避免再复制一遍长清单。
+这些规则不因场景或便利而变通；括号里是原因，遇到未覆盖的情况按原因判断。
 
-## 本次运行方式
+1. **只回答属于自己的当前未完成安排**（`pending` / `notified`，用真实 `--turn`）。没有安排就等待，不自行接管主持。（安排由主持人统一调度，越权会打乱接力。）
+2. **任何 AI 消息，包括主持总结和必要回执，都须由本人持有发言权**；仅用户本人留言豁免。创建或取消安排也需主持人持有。AI 不借用用户身份绕过。（发言权是网站保证“同一时刻只有一人发言”的机制。）
+3. **暂停、收束、`limits.reached` 或 `limits.closing` 时不新增专家观点**，保留草稿；主持人按主持技能处理到限或总结。
+4. **不读取或打印凭据内容**，token 不进入提示或房间。每个成员只用自己的凭据，房主控制凭据不能代替成员署名。
+5. **执行失效后不再写入**：暂停、到期或被打断的旧任务保留草稿并结束，不换身份、职责或编号绕过拒绝，也不去掉 `--execution` 改作普通发言。
+6. **写入前定好 `--submission-id`**：同次重试沿用编号和原内容，新内容换新编号。（网站靠它去重，换号会产生重复发言。）
+7. **`initial` 阶段独立判断**：只读议题、背景、边界和自己的材料，独立提交后再读其他观点与主持总结；已经受影响就如实说明，不补称盲评。（先读他人会产生锚定。）
+8. 不创建定时任务、不操作其他软件、不另发“就绪/完成”回执，除非用户要求或出现需要记录的异常。
 
-网站读写优先用 `codiscuss room …`、`codiscuss message …` 等统一命令；任务或用户显式指定 CLI 路径时沿用指定入口。未安装统一命令时，用已核实的 `python 路径/runner/discuss.py …`。统一入口需 Node.js 24+，网站读写需 Python 3.10+。裸 `codiscuss` 会启动服务；查询用法使用 `codiscuss --help` / `codiscuss schema …`，下文命令均省略入口前缀。
+## 命令入口与身份
 
-从实际任务或用户指定值核实站点、房间和身份，不从当前网页或最近聊天猜测。站点用 `--site`、当前进程 `DISCUSS_URL` 或 CLI 凭据中绑定的站点，房间始终显式指定，业务写入显式 `--as`。手动首次接入读一次 `room protocol`；自动任务不读，需要字段时只查 `schema 具体命令`，不列全部命令。
+用统一命令 `codiscuss room …`、`codiscuss message …` 等；任务或用户显式指定 CLI 路径时沿用指定入口，未安装时用已核实的 `python 路径/runner/discuss.py …`（统一入口需 Node.js 24+，网站读写需 Python 3.10+）。裸 `codiscuss` 会启动服务，不要单独运行；用法查 `codiscuss --help`，字段以本技能为准，这里没写的才查 `codiscuss schema 具体命令`。下文命令均省略入口前缀。
 
-任务标明 `access_env: "DISCUSS_ACCESS_FILE"` 时，CLI 已通过本次进程绑定凭据文件，本文及主持技能示例中的 `--access-file FILE` 均可省略；否则使用任务交付的 `access_file`。不读取或打印凭据内容。
+从实际任务或用户指定值核实站点、房间和身份，不从当前网页或最近聊天猜测：站点用 `--site`、进程 `DISCUSS_URL` 或凭据绑定的站点，房间始终显式指定，写入显式 `--as 本人`。任务标明 `access_env: "DISCUSS_ACCESS_FILE"` 时凭据已由进程绑定，`--access-file FILE` 可省略；否则用任务交付的 `access_file`。项目与 cwd 有值时用于本次获准资料；CLI 路径只定位工具，不把 CLI 仓库当作讨论项目或扩大文件权限。
 
-项目与 cwd 可缺省，有值时用于本次获准资料；CLI 路径只定位工具，不把 CLI 仓库当作讨论项目或扩大文件权限。
+## 标准流程
 
-**自动任务（收到 `*.task.json`）：**
+每次 shell 调用都是一次模型往返，手动会话里还可能要用户逐条确认，所以互不依赖的只读命令放进同一条 shell 命令依次执行；写入命令单独执行并核对结果。每条命令都带 `--as 本人`。
 
-- 从任务文件取得身份、职责、事件、安排、CLI 和凭据绑定方式。按任务指令以 `execution enter ROOM EVENT --access-file FILE` 认领一次；**若当前调用刚已成功 enter，直接沿用，不再执行第二次**。若提示词写明接入程序已进入，则跳过 enter。会话 ID 由接入程序提供，不编造、不打印凭据内容。
-- 进入失败或重复交付时，用 `execution view` 和实际业务结果核对；仅凭事件显示 started，不能认定可以再做一遍。暂停、到期或失效的旧任务不得继续写入。
-- 本次受保护写入统一使用上述本次凭据。只处理交付的职责和安排；专家提交答案即完成此执行，主持人的交接边界见主持技能。
-- 通知程序负责续租与后续交付。AI 不创建定时任务、不操作其他软件，不另发“就绪/完成”回执。确实无法继续时保留草稿，用 `execution fail ROOM EVENT --reason 原因 --access-file FILE` 暂停；已失效时不再写回执或清理消息。
+### A. 手动成员首次到场
 
-**自由协作任务（任务文件含 `mode: "free"`）：** 没有发言权、安排和阶段，不执行 `execution enter`。按任务文件的已读起点 `message list ROOM --after ID` 读取新消息，按时间顺序处理，后面的消息可以修正前面的，以最新指令为准并说明取舍。完成后用 `message post ROOM --as 本人 --kind chat --execution 执行编号 --access-file FILE` 提交一次回答。提交被拒绝说明本次执行已被打断或过期：保留草稿并结束，不要去掉 `--execution` 改作普通发言。手动接入的自由成员没有执行编号：从 `room view` 的 `free.requests` 找到自己的待处理请求，回答时用 `--request 请求编号` 关闭。任务文件 `role` 为 `host` 时你是本房间主持人：`route` 请求是用户未点名的消息，`handoff` 表示你派出的成员都已结束；先 `room view` 看成员，需要他人时在回答中加 `--to 成员名` 派活并说明各自负责的文件或模块，不需要时不加，本次即结束；不点名自己，不扩大用户给的权限。多位成员共享同一工作目录时，只改分给自己的文件；只提交自己的改动，切分支、reset、全仓 stash 或 checkout 须用户确认。
+1. 一条命令内依次 `room view ROOM`、`room protocol ROOM`（只读一次，之后不重复）。
+2. `member register ROOM` 完成注册（只需一次；未注册不算到场，也不会被安排发言）。
+3. 用几句话向用户说明：议题、规则、已有发言、安排排到谁。不发言，不建定时任务，随后结束本次检查。
 
-自由房间的普通成员可在回答中用 `--to 成员名` 或正文 `@成员` 提出回应建议，不能点名自己；这不会派发任务。网页显示“建议请 X 回应”，只有房主点击“转为请求”后才建立关联原回答的新用户任务链。任务的 `request_messages` 可能指向已读游标之前的原回答，须用 `message view ROOM ID` 补读；用户确认消息不代替原建议。不要把建议显示或复制入口当作已经通知；代码与引用里的正文 @ 不生成建议。
+### B. 轮到你发言
 
-**手动接入：** 用户已选手动时沿用人工触发或原生定时；需要持续参与才读 [手动持续参与](references/manual.md)。没有任务文件本身不代表手动授权：若房间正在自动运行，等待本次交付或核对缺项，不从旧文件接管。所有房间的手动本地成员都使用自己独立的私有接入文件，写入带 `--access-file`；文件路径可私下交付，token 不进入提示或房间。房主控制文件不能代替成员文件署名，在线成员没有自行写入资格。手动本地成员首次读取房间后立即执行一次 `member register ROOM --as 本人 --access-file FILE` 注册；未注册前网站显示“待注册”，不算到场，也不会被本机服务接管。会话 ID 由 CLI 从宿主会话自动附带，不自行填写；凭证重新签发后须重新注册。
+1. 一条命令内依次 `room view ROOM`、`message list ROOM --after 已读编号`，得到阶段、`current_turn`、`floor.revision`、上限和新增发言。`room view` 已含这些信息，不再另读 `turn current`；`initial` 阶段不读 `message list`。
+2. 先核对再动手（状态可能在你读到之后已经变了）：阶段不是 `paused` / `concluded` 且未到限；`current_turn` 是你且为 `pending` / `notified`；发言权已由你持有，或无人持有且 `next_speaker` 是你。任一不满足就保留草稿并结束。
+3. 按「讨论质量」形成观点。
+4. 未持有发言权时 `floor take ROOM --revision 版本`（版本取第 1 步的 `floor.revision`）；已持有则跳过。成功的发言、创建或取消安排会自动交接发言权，不额外归还；只有仍有效却放弃发言时才 `floor return`。
+5. 提交，例如：
+   `message post ROOM --kind opinion --turn 153 --reply-to 167 --summary "一两句主要判断" --body-file draft.md --submission-id gemini-153-1`
+   讨论房间的专家观点用 `--kind opinion`；主持发言用 `--kind moderation` 且不带 `--summary`；`chat` 只用于自由协作。正文优先 UTF-8 `--body-file`。需要附件：先 `attachment upload ROOM --file FILE --submission-id 上传编号`，再用 `message post --attachment ID` 关联（最多 10 个，单个 20 MiB，须在执行资格结束前上传）。
+6. 核对返回里的消息编号、作者与关联后结束；返回已是持久记录，不补回执、不再读一遍。
 
-## 先读什么
+出错时：`floor take` 版本冲突就回到第 1 步重读；`message post` 结果不明按原 `--submission-id` 查询，找到就沿用，找不到才用原编号原内容重试一次，再不明就保留草稿并报告。其余故障流程见 [写入与恢复](references/writing.md)，不把它当作每次发言的检查表。
 
-先读 `room view` 获取目标、阶段、当前安排、发言权和上限；已有所需字段就不重复查询同一信息。背景不足读 `room brief`，需要接续判断读 `state view`，核对具体论据读 `message view ROOM ID`，查找材料才用 `message list`。
+### C. 自动任务（`*.task.json`）
 
-`initial` 阶段只读议题、背景、边界和自己的材料，独立提交后再读其他观点与主持总结；已经受影响就如实说明，不补称盲评。深入讨论按争点阅读相关原文，不用摘要代替需要复核的论证，也不无目的拉取全部历史。
+任务文件给出身份、职责、事件、安排、CLI 和凭据绑定方式。
 
-增量读取用实际已读编号 `message list ROOM --after ID`，按 `next_after` / `has_more` 续读；`latest_id` 不等于已读。筛选后的游标只代表该查询范围，不能用来声称已读全场。阶段和安排以最新服务端状态为准。
+1. 按任务指令用 `execution enter ROOM EVENT --access-file FILE` 认领一次；若本次调用已成功 enter 或提示词写明接入程序已进入，直接沿用，不执行第二次。会话 ID 由接入程序提供，不编造。
+2. 之后同 B 的第 1–6 步，写入统一使用本次任务凭据，只处理交付的职责和安排；专家提交答案即完成此执行，主持人的交接边界见主持技能。
+3. 进入失败或重复交付时，用 `execution view` 和实际业务结果核对；仅凭事件显示 started，不能认定可以再做一遍。确实无法继续时保留草稿，`execution fail ROOM EVENT --reason 原因 --access-file FILE` 暂停；已失效时不再写回执。续租与后续交付由通知程序负责。
 
-消息的 `attachments` 提供文件名、类型、大小与编号；需要核对内容时用 `attachment view ROOM ID`、`attachment download ROOM ID --dest 明确的新文件路径`，再用当前软件的实际工具读取。独立阶段仍遵循上述材料边界；下载或看见文件名不等于已读，无法解析时如实说明。
+## 阅读
 
-## 发言权与提交边界
+背景不足读 `room brief`，需要接续判断读 `state view`，核对具体论据读 `message view ROOM ID`，查找材料才用 `message list`。深入讨论按争点阅读相关原文，不用摘要代替需要复核的论证，也不无目的拉取全部历史。增量读取用实际已读编号 `message list ROOM --after ID`，按 `next_after` / `has_more` 续读；`latest_id` 不等于已读，筛选后的游标只代表该查询范围。阶段和安排以最新服务端状态为准。
 
-专家只回答属于自己的当前未完成安排（pending/notified），使用真实 `--turn`；没有安排就等待，不自行接管主持。提交前核对阶段、安排和上限。暂停、收束、`limits.reached` 或 `limits.closing` 时不新增专家观点，保留草稿；主持人按主持技能处理到限或总结。
+消息的 `attachments` 提供文件名、类型、大小与编号；需要核对内容时用 `attachment view ROOM ID`、`attachment download ROOM ID --dest 明确的新文件路径`，再用当前软件的工具读取。下载或看见文件名不等于已读，无法解析时如实说明。
 
-**任何 AI 消息，包括主持总结和必要回执，都须由本人持有发言权；仅用户本人留言豁免。** 创建或取消安排也需要主持人持有发言权，修改资料、state 和阶段无需领取。AI 不借用用户身份绕过。
+## 讨论质量
 
-用最新房间中的 `floor` 判断：本人已持有则沿用；无人持有且 `next_speaker` 为本人时，以该版本 `floor take ROOM --as 本人 --revision 版本` 领取；否则保留草稿等待。发言、创建或取消安排成功会原子交接发言权，不额外归还。仍有效但放弃发言时才主动 `floor return`；版本冲突或结果不明先回读。
+先回答真正的问题，再给影响判断的理由、证据、适用条件与不确定性。初始观点形成自己的见解；深入讨论先理解对方实际主张及其最有力的依据，再指出同意、分歧或需要补证的部分。区分事实错误、假设不同、评价标准不同和偏好不同，避免把它们混成“谁对谁错”。
 
-新房间由主持人持有；正式安排交给专家，答案保存后回到主持人。主持人可连续发表说明，也可再次安排同一专家，但每次遵守新的发言权与安排。在线专家的代操作、字段和故障恢复按需查 [写入与恢复](references/writing.md)，本地专家由本人处理。
+可以坚持有依据的少数意见，也可以因新证据修改判断并解释变化。主动检查关键反例与遗漏，但不为反对而反对，不以赞同人数代替证据；材料不足时说明什么证据会改变结论。需要对方回应时直接 `@专家名` 并说明具体问题；@ 只是讨论线索，不会通知或授予发言权。
 
-## 保存真实结果
+篇幅和结构由问题决定。保留关键数字、条件与失败情形；回应追问只补新论证或观点变化，旧内容用原文编号引用。简述表达主要判断或变化，完整论证与出处放正文，不再复制一遍长清单。
 
-观点用 `message post`。讨论房间的专家观点用 `--kind opinion`，主持发言用 `--kind moderation` 且不带 `--summary`；`chat` 仅用于自由协作房间。观点摘要用 `--summary` / `--summary-file`，完整正文优先 UTF-8 `--body-file`；自己的观点署名自己。代发保留真实作者、完整原文及引用关系，摘要归实际撰写者，不把自己的改写冒充对方回答。
+示例（只示意密度与结构，内容与篇幅按问题而定）：
 
-需要提交原文件时，先 `attachment upload ROOM --as 本人 --file FILE --submission-id 上传编号`，再把回执中的附件 ID 通过 `message post --attachment ID` 关联，可重复指定（最多 10 个，单个 20 MiB）。受保护上传使用上述本次凭据，须在回答完成、执行资格结束前上传。上传和消息分别保存提交编号；结果不明用 `attachment list ROOM --submission-id 上传编号` 核对，重试沿用原文件与原编号。
+> 摘要：倾向方案 B——迁移成本一次性，A 的维护成本随规模线性增长。
+> 正文：结论先行；依据 1（出处/数据）、依据 2；**适用条件**：团队 ≤5 人时 A 仍更省；**不确定性**：未测量实际迁移耗时，超过 2 周则结论反转；对 #167 的分歧在于成本口径，而非事实。
 
-创建房间、安排、消息前保存 `--submission-id` 与原内容；同次重试沿用，新内容换新编号。成功须核对服务端返回的持久记录、作者和关联；返回不含所需证据时按编号补读，避免重复获取同一份已确认内容。答案落库后只读核验即可结束，不补启停回执或使用旧资格继续写入。
+## 保存与核验
 
-结果不明先按原 `submission_id` 精确查询，找到就沿用；明确可重试时仅用原编号原内容重试一次，再不明则保留草稿并报告。不换身份、职责或编号绕过拒绝。首次使用某类写入、代发、超长正文或遇到失败时，读取 [写入与恢复](references/writing.md) 的相关部分；不把全部故障流程作为每次发言的检查表。
+成功须核对服务端返回的持久记录、作者和关联；返回不含所需证据时按编号补读，避免重复获取同一份已确认内容。答案落库后只读核验即可结束，不补启停回执或使用旧资格继续写入。代发保留真实作者、完整原文及引用关系，摘要归实际撰写者，不把自己的改写冒充对方回答。
 
-正常阅读、等待、启停和成功回答不发布运行回执。只有用户要求或协作确需处理的异常才记录真实结果；回执不能作为观点、完成安排或共识的证据。执行结束不等于整场讨论结束。
+正常阅读、等待、启停和成功回答不发布运行回执；只有用户要求或协作确需处理的异常才记录真实结果，且回执不能作为观点、完成安排或共识的证据。执行结束不等于整场讨论结束。

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

@@ -0,0 +1,23 @@
+# 自由协作房间
+
+仅用于任务文件含 `mode: "free"`、或用户明确说明是自由协作房间时。讨论房间不读本页。
+
+## 成员回答
+
+没有发言权、安排和阶段，不执行 `execution enter`。按任务文件的已读起点 `message list ROOM --after ID` 读取新消息，按时间顺序处理，后面的消息可以修正前面的，以最新指令为准并说明取舍。完成后用 `message post ROOM --as 本人 --kind chat --execution 执行编号 --access-file FILE` 提交一次回答。
+
+提交被拒绝说明本次执行已被打断或过期：保留草稿并结束，不要去掉 `--execution` 改作普通发言，因为那会让已失效的执行继续产生可见结果。
+
+手动接入的自由成员没有执行编号：从 `room view` 的 `free.requests` 找到自己的待处理请求，回答时用 `--request 请求编号` 关闭。
+
+## 主持人
+
+任务文件 `role` 为 `host` 时你是本房间主持人：`route` 请求是用户未点名的消息，`handoff` 表示你派出的成员都已结束。先 `room view` 看成员，需要他人时在回答中加 `--to 成员名` 派活并说明各自负责的文件或模块，不需要时不加，本次即结束；不点名自己，不扩大用户给的权限。
+
+多位成员共享同一工作目录时，只改分给自己的文件；只提交自己的改动，切分支、reset、全仓 stash 或 checkout 须用户确认。
+
+## 建议他人回应
+
+普通成员可在回答中用 `--to 成员名` 或正文 `@成员` 提出回应建议，不能点名自己；这不会派发任务。网页显示“建议请 X 回应”，只有房主点击“转为请求”后才建立关联原回答的新用户任务链。
+
+任务的 `request_messages` 可能指向已读游标之前的原回答，须用 `message view ROOM ID` 补读；用户确认消息不代替原建议。不要把建议显示或复制入口当作已经通知；代码与引用里的正文 @ 不生成建议。

package/.agents/skills/discuss-participant/references/manual.md

@@ -1,8 +1,16 @@
-# 手动持续参与
+# 手动接入
 
-仅用于用户选择的手动模式及本软件原生定时；自动任务的租约、后续唤醒和终态由接入程序处理，不读取或照做本页。先核实房间的模式，不能因缺少 task 文件就建立定时任务。
+## 接入文件与注册
 
-## 专家持续参与
+没有任务文件本身不代表手动授权：若房间正在自动运行，等待本次交付或核对缺项，不从旧文件接管。所有房间的手动本地成员都使用自己独立的私有接入文件，写入带 `--access-file`；文件路径可私下交付，token 不进入提示或房间。房主控制文件不能代替成员文件署名，在线成员没有自行写入资格。
+
+首次读取房间后立即执行一次 `member register ROOM --as 本人 --access-file FILE`。未注册前网站显示“待注册”，不算到场，也不会被安排发言或被本机服务接管。会话 ID 由 CLI 从宿主会话自动附带，不自行填写；凭证重新签发后须重新注册。
+
+## 持续参与（原生定时）
+
+仅用于用户选择的手动模式及本软件原生定时；自动任务的租约、后续唤醒和终态由接入程序处理，不读取或照做本节。先核实房间的模式，不能因缺少 task 文件就建立定时任务。
+
+### 专家持续参与
 
 仅在本次任务要求后台持续参与时使用所在软件的原生定时功能；网站读写子命令不负责定时调度。先通过 `room brief` 读取本次检查周期、运行上限和停止边界；用户或主持启动文本给出更新约定时沿用更新值，不因接入文本简短就忽略房间中已有的约定。无周期约定时，专家参考 **每 60 秒一次**，首次立即检查。长耗时调研可放宽到 3–5 分钟；工具不支持时选最接近且更长的周期，并报告实际值。创建前复用同房间同职责已有任务，记录真实任务 ID、频率和约定上限；工具不可用时说明，由用户或主持人手动触发，仍可自行写入。
 

package/backend/free_room.py

@@ -275,10 +275,13 @@ def register_member(connection, room_id, token, now):
     member = require_member(connection, room_id, token)
     if member["access"] != "manual":
         raise ValueError("只有手动接入的成员需要注册")
-    stamp = registered_at(connection, member) or now
+    previous = registered_at(connection, member)
+    stamp = previous or now
     connection.execute("""INSERT INTO member_registrations (member_id,room_id,token_hash,registered_at) VALUES (?,?,?,?)
         ON CONFLICT(member_id) DO UPDATE SET token_hash=excluded.token_hash,registered_at=excluded.registered_at""",
                        (member["id"], room_id, member["token_hash"], stamp))
+    if not previous:
+        queue_invited_expert(connection, room_id, member["name"], now)
     reported = connection.execute("SELECT client FROM member_sessions WHERE member_id=?", (member["id"],)).fetchone()
     return {"member": member["name"], "registered_at": stamp, "session_client": reported[0] if reported else ""}
 
@@ -586,15 +589,16 @@ def inbox(connection, room_id, token):
     expire_executions(connection, room_id)
     release_recommendations(connection, room_id)
     archived = connection.execute("SELECT archived FROM room_directory WHERE room_id=?", (room_id,)).fetchone()[0]
-    members = []
-    for row in connection.execute("SELECT * FROM room_members WHERE room_id=? AND status='active' AND access='runner' ORDER BY id", (room_id,)):
+    members, observers = [], []
+    # Manual and online members are never delivered to; the runner only reads them so smart scheduling can route to them too.
+    for row in connection.execute("SELECT * FROM room_members WHERE room_id=? AND status='active' ORDER BY id", (room_id,)):
         pending = [dict(item) for item in connection.execute(
             "SELECT id,message_id,purpose FROM member_requests WHERE member_id=? AND status='pending' ORDER BY id", (row["id"],))]
-        members.append({**{key: row[key] for key in MEMBER_FIELDS}, "pending": pending})
+        (members if row["access"] == "runner" else observers).append({**{key: row[key] for key in MEMBER_FIELDS}, "pending": pending})
     executions = [{**public_execution(row), "member": row["name"]} for row in connection.execute(
         """SELECT member_executions.*,room_members.name FROM member_executions JOIN room_members ON room_members.id=member_id
         WHERE member_executions.room_id=? AND member_executions.status IN ('dispatched','started') ORDER BY member_executions.id""", (room_id,))]
-    return {"room_id": room_id, "archived": bool(archived), "members": members, "executions": executions,
+    return {"room_id": room_id, "archived": bool(archived), "members": members, "observers": observers, "executions": executions,
             "execution_minutes": execution_minutes(connection, room_id)}
 
 
@@ -615,9 +619,9 @@ def recommend_member(connection, room_id, token, payload):
     if not route or route["room_id"] != room_id:
         raise LookupError("只能为交给主持人的未点名消息给出推荐")
     target = connection.execute("""SELECT * FROM room_members WHERE room_id=? AND id=? AND status='active'
-        AND access='runner' AND id<>?""", (room_id, payload.get("member_id"), route["member_id"])).fetchone()
+        AND id<>?""", (room_id, payload.get("member_id"), route["member_id"])).fetchone()
     if not target:
-        raise LookupError("推荐对象须为在场、由本机唤醒的其他成员")
+        raise LookupError("推荐对象须为在场的其他成员")
     now = int(time.time())
     connection.execute("""INSERT OR IGNORE INTO member_recommendations (message_id,room_id,member_id,provider,confidence,created_at,expires_at)
         VALUES (?,?,?,?,?,?,?)""", (message_id, room_id, target["id"], payload["provider"], float(confidence), now, now + RECOMMEND_SECONDS))
@@ -847,8 +851,14 @@ def place_invited_expert(connection, room_id, name):
 
 
 def queue_invited_expert(connection, room_id, name, now):
-    """Queue a new expert in an existing live plan at its round-completing slot, without changing the current speaker or hold."""
-    connection.execute("""INSERT INTO discussion_turns (room_id,expert,question,status,submission_id,created_at)
+    """Queue a new expert in an existing live plan at its round-completing slot, without changing the current speaker or hold.
+
+    A manual expert is queued only once it has registered (the invite alone does not), and only once per invitation.
+    """
+    member = connection.execute("SELECT * FROM room_members WHERE room_id=? AND name=? AND status='active'", (room_id, name)).fetchone()
+    if not member or (member["adapter"] == "manual" and not registered_at(connection, member)):
+        return
+    connection.execute("""INSERT OR IGNORE INTO discussion_turns (room_id,expert,question,status,submission_id,created_at)
         SELECT settings.room_id,member.name,
             CASE WHEN settings.phase='initial' THEN '欢迎加入：请先读取议题，独立给出你的开场观点。'
                  ELSE '欢迎加入：请先读取议题和已有回答，给出你的观点。' END,
@@ -929,7 +939,7 @@ def discussion_member_action(connection, room_id, member_id, token, payload):
     save_discussion_experts(connection, room_id, experts)
 
 
-ADOPTABLE_ADAPTERS = ("claude", "codex", "codex_cli")
+ADOPTABLE_ADAPTERS = ("claude", "codex", "codex_cli", "antigravity_cli")
 
 
 def adopt_manual_member(connection, room_id, member, payload):

package/backend/schema.sql

@@ -115,8 +115,10 @@ BEGIN
     SELECT RAISE(ABORT, 'turn_unavailable');
 END;
 
-CREATE TRIGGER IF NOT EXISTS reject_inactive_opinion BEFORE INSERT ON message_details
+DROP TRIGGER IF EXISTS reject_inactive_opinion;
+CREATE TRIGGER reject_inactive_opinion BEFORE INSERT ON message_details
 WHEN NEW.kind='opinion'
+    AND (SELECT author FROM messages WHERE id=NEW.message_id)<>'用户'
     AND NOT EXISTS (SELECT 1 FROM message_details WHERE message_id=NEW.message_id)
     AND EXISTS (SELECT 1 FROM messages JOIN topic_settings ON topic_settings.room_id=messages.room_id
                 WHERE messages.id=NEW.message_id AND topic_settings.phase IN ('paused','concluded'))