4.9 KiB
4.9 KiB
SM Flow Execution Hardening Decisions
User-interview
| 问题 | 用户回答 | 决策 | OpenSpec 回写 |
|---|---|---|---|
| 这次是否将复盘问题提炼为正式需求？ | “[$sm-flow] 提炼成需求” | 创建 sm-flow-execution-hardening 需求档案，先收敛需求，再决定是否进入 OpenSpec。 |
不影响 |
| 是否必须产出固定 checkpoint / alignment 模板？ | “确认 1” | 不强制固定模板；协议只要求必填字段和检查动作。 | 已回写 |
| 验收是否要求统一阶段汇报格式？ | “确认1” | 验收停在协议明确 gate、问题池和对齐规则，不要求统一阶段汇报格式。 | 已回写 |
Phase 2 Tracking
| 问题池项 | 模式 | 状态 | 备注 |
|---|---|---|---|
| Q1：是否必须产出固定 checkpoint / alignment 模板 | user-interview | 待确认 | 会影响 templates.md 与 tasks 范围 |
| Q2：协议主术语采用 checkpoint 还是 checklist | evidence-driven | 待整理 | 优先由现有文档术语一致性决定 |
| Q3：验收是否要求统一阶段汇报格式 | user-interview | 已确认 | 验收停在规则层，不扩到统一输出格式 |
| Q4：workflow 是否需要保留复盘案例示例 | evidence-driven | 待整理 | 主要影响 workflow 文档粒度 |
Phase 2.5 审计结论
-
决策：主术语采用
checkpoint，checklist作为内部核对动作描述。- 原因：仓库现有
phase-contracts.md已使用Human checkpoint，继续沿用能减少术语漂移。 - 影响：后续协议修改应优先写“phase checkpoint”，避免在规则层混用主术语。
- 风险接受：当前接受
- 原因：仓库现有
-
决策：
workflow.md不扩成案例手册，继续保留规则抽象和演进说明；具体复盘案例留在retrospective.md。- 原因：如果把案例并入 workflow，规则与示例会双份维护，后续更容易漂移。
- 影响：执行真理源继续留在
SKILL.md/phase-contracts.md/ OpenSpec，而不是 workflow 长文。 - 风险接受：当前接受
Phase 2.9 Commit Result
- 决策：
sm-flow-execution-hardening当前 Draft OpenSpec 通过 commit gate，视为 Committed OpenSpec。- 原因：proposal、design、specs、tasks 已完整；user-interview 已确认；evidence-driven 结论已汇报；未发现 devflow/OpenSpec 冲突。
- 影响：可以进入 Phase 3 修改协议文件，但仍需单独的 apply 授权。
- 风险接受：当前接受
关键取舍
-
决策：将本轮定位为
complex分档。- 原因：虽然不涉及业务代码，但它影响
sm-flow的多个核心文件、阶段协议和验收方式，且包含多处跨文档一致性约束。 - 影响：使用
brief.md、prd.md、evidence.md、decisions.md四类产物，而不是只写简短 brief。 - 风险接受：当前接受
- 原因：虽然不涉及业务代码，但它影响
-
决策：不复用
sm-flow-v3-1-upgrade项目，而是新开需求档案。- 原因：
v3.1已归档且目标不同；本轮关注的是执行稳定性，不宜混入已完成升级项目。 - 影响：后续若进入 OpenSpec，可独立创建新 change。
- 风险接受：当前接受
- 原因：
-
决策：将“规则存在但执行不稳”定义为首要问题。
- 原因：复盘中的多个现象都能收敛到这一点，能避免后续需求继续发散。
- 影响：后续需求改造应优先考虑 checklist、阶段 gate、显式声明和一致性检查。
- 风险接受：当前接受
Phase 3 Implementation Record
-
决策：Phase 3 以本地
openspec-apply-changeSKILL.md作为 capability 来源继续执行。- 原因：当前环境可读取对应 skill 协议，且用户已通过“apply”明确授权进入 Phase 3。
- 影响：本轮实现按 committed OpenSpec 的 task 切片直接修改协议与工作流文档。
- 风险接受：当前接受
-
决策：本轮不修改
templates.md。- 原因：用户已确认不要求固定 checkpoint / alignment 模板，也不要求统一阶段汇报格式；OpenSpec task 2.4 的目标是保持模板可选。
- 影响：实现集中在
SKILL.md、phase-contracts.md、fallbacks.md、workflow.md，避免把协议硬化扩大成模板标准化。 - 风险接受：当前接受
-
决策：把“checkpoint 缺失则阶段不算完成”写入顶层协议和阶段契约，而不是只放在说明文档。
- 原因：这是决定阶段能否前进的硬 gate，必须落在执行真理源。
- 影响：Phase 0、0.5、1、2、2.5、2.9 现在都需要显式 checkpoint 和 capability 声明。
- 风险接受：当前接受
-
决策：将 Phase 2 question pool、Phase 1.5/2.9 cross-artifact 对齐、
microgate 保留和 fallback 记录要求同步落在协议正文与 workflow 说明。- 原因：这些规则既要可执行，又要便于人类理解；单独放在一处容易再次漂移。
- 影响：OpenSpec、协议正文和 workflow 解释层的关键术语已收敛到同一套执行规则。
- 风险接受：当前接受