77 lines
4.9 KiB
Markdown
77 lines
4.9 KiB
Markdown
# 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-change` `SKILL.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 对齐、`micro` gate 保留和 fallback 记录要求同步落在协议正文与 workflow 说明。
|
||
- 原因：这些规则既要可执行，又要便于人类理解；单独放在一处容易再次漂移。
|
||
- 影响：OpenSpec、协议正文和 workflow 解释层的关键术语已收敛到同一套执行规则。
|
||
- 风险接受：当前接受
|