workflow-rules.md

协作规则

阻塞分级

级别	判断依据	是否创建工作对话	模式
启动阻塞	范围、依赖、授权或修改归属不明，无法定义安全边界	否	无
开发阻塞	可分析，但缺失信息会决定接口、数据、核心流程或验收	是	分析
联调阻塞	业务边界已确认，仅缺真实环境值或外部服务	是	开发
非阻塞待确认	不影响当前范围和验收，可后续确认	是	开发

依次判断待确认内容是否改变对外 API、持久化结构、任务状态、公共调用流程或验收结果；是否能通过配置、依赖注入或适配器隔离；缺少真实值时能否显式失败；是否可用明确标识的 Mock 完成纯逻辑验证。

不能可靠分类时采用更严格级别并等待用户确认。禁止把猜测值写入生产代码或配置。

工作模式

• 分析模式：只读检查、复用分析、方案、测试设计和阻塞清单；默认不编辑或 Commit。
• 开发模式：在确认边界内编码和本地测试；未确认的环境值只能保留受控配置，缺失时显式失败。
• 联调模式：仅在获得真实参数和外部操作授权后验证环境，并记录实际结果。

模式转换使用原工作对话：分析获得确认后转开发；本地完成但缺环境时转待联调；环境具备后转联调。只有验收全部满足才能标记完成。

严格串行

同一工作目录同时只能有一个功能点工作对话。未知修改、未结束的工作对话或未归属差异会阻止创建下一个工作对话。测试失败、补充要求和联调恢复均继续使用原工作对话。

权威记录

项目应明确以下职责对应的权威文档：

• 功能点范围、状态、实现、测试、提交与遗留问题；
• 决策、待确认项、责任方、影响阶段和解除条件；
• 稳定项目上下文与技术边界；
• 接口或算法契约及样例；
• 部署和联调步骤；
• 指挥台与工作对话协作规则。

短时讨论、未经确认的猜测和可从 Git 读取的瞬时状态不写入长期文档。同一事实只在一个权威位置完整记录。

异常处理

场景	处理
工作区不干净	停止调度，确认修改归属
契约或输入缺失	先分级，在安全模式内推进
测试失败	原工作对话继续修复
新发现重要阻塞	用户确认后由工作对话更新权威记录
已知阻塞已记录	不重复修改或创建空提交
部分实现需要保留	用户明确授权后才能中间提交
工作对话中断	指挥台只读检查状态和差异，再恢复原对话
用户改变范围	停止实施，确认新范围后决定继续或重建任务