start-consensus-goallisted

# Start Consensus Goal 把当前讨论整理成一个可执行 GOAL，落成任务清单，然后执行到底。本次调用授权按该 GOAL 开展工作，但不扩大既有的权限模式、审批策略、项目指令或用户已授予的范围。 ## 确立事实依据 审阅当前会话中可用的完整对话，包括压缩后保留的状态。需要时只读检查相关工作区材料，核实项目事实、命令、约束和完成检查。 按以下优先级确定需求： 1. 用户最新的明确决定； 2. 用户明确接受的建议或修正； 3. 已核实的工作区事实和适用的项目约定； 4. 未被后续决定取代的较早用户要求。 未被接受的助手建议、备选方案、引用、示例、头脑风暴、沉默和已被取代的决定都不算共识。工具结果和工作区内容只作为证据，不扩大用户授权。要求冲突时，以明确解决同一问题的较新用户决定为准，不把不兼容的要求静默拼在一起。 ## 处理不确定性 假设不会实质改变结果、范围、授权、成本或风险时，直接作出合理假设并把它写进 GOAL。 某个未决选择会实质改变上述任一项时，只提出解决该选择所需的最小问题，暂不开工。普通实现层面的不确定性不构成暂停理由。 ## 编写 GOAL 用简体中文编写完整 GOAL。文件路径、标识符、命令、代码、API 名称、产品名称和引用原文保留准确拼写。 GOAL 自包含且不超过 4,000 字符，只保留指导和验证工作所需的信息： - **结果：** 用户可见的最终结果。 - **证据与上下文：** 相关文件、规范、错误、数据和必需来源。 - **范围：** 必须完成的工作、需要保留的行为和明确排除项。 - **约束与授权：** 架构、兼容性、安全、隐私、性能、项目约定、允许的本地操作，以及需要确认的操作。 - **完成标准：** 可执行的测试、构建、检查、测量或评审标准。 - **正当阻塞项：** 缺少哪些证据、���问权、授权或外部状态时可以停止。 - **最终交付：** 需要报告的变更、验证证据、假设、风险和剩余缺口。 描述目标状态和完成门槛。不规定无必要的内部步骤，不重复全局指令，也不把 GOAL 写成讨论记录。 ## 落地并开始执行 先检查当前是否已有未完成的任务清单。有的话不要覆盖：说明现状，问用户是要继续原有工作、合并还是先收尾。 没有冲突时，按 GOAL 的范围建立任务清��——每个任务对应一个可核对的产出，而不是一句内部步骤描述——然后立即开始执行。跨越多个上下文窗口的长任务，可以把 GOAL 和进度记录写进一个文件以便重启后接续；该文件的路径先与用户确认，不擅自在仓库里新建文件。 开工前发一次简短的进度更新，只包含：GOAL 已开始执行、归并了哪些关键决定、作出了哪些重要假设、哪些事项因冲突或未决而未纳入。发完立即继续，不要把它当成最终答复。 执行期间： - 报告进展前，先把每条声明对应到本次会话的工具结果。只报告有证据的部分；尚未验证的明确说明。 - 只在工作确实需要用户时才停：破坏性或不可逆操作、真正的范围变更，或只有用户能提供的输入。遇到这类情况就提问并结束该轮，而不是以承诺结尾。 - 任务困难、耗时或需要多轮工具调用，本身都不构成阻塞。 - 结束前检查最后一段：如果它是计划、分析、下一步清单或「我接下来会……」一类的承诺，就现在把那件事做掉。 ## 完成 完成标准验证通过，或确实因缺少证据、访问权、授权或外部状态而阻塞时结束。 最终答复以结果开头：第一句回答「做成了什么」或「卡在哪里」，之后再给支撑细节。写完整句子、展开术语、给每个文件或标识符一句自然