107 lines
8.4 KiB
Markdown
107 lines
8.4 KiB
Markdown
# SM Flow Execution Hardening Evidence
|
|
|
|
## 证据
|
|
|
|
| 来源 | 证据 | 结论 | 是否已汇报 |
|
|
| --- | --- | --- | --- |
|
|
| `skill-workbench/docs/sm-flow/retrospective.md` | 逐 Phase 复盘了一次真实执行，明确记录了 Phase 0、0.5、1.5、2、2.5、2.9、4 的实际偏差。 | 当前主要问题是执行偏差和自检不足，不是流程理念方向错误。 | 是 |
|
|
| `skill-workbench/docs/sm-flow/workflow.md` | v3.1 已经补入 Draft/Committed OpenSpec、接口影响分级、Phase 2.9、Phase 3 冲突分类等规则。 | 新一轮需求不应继续扩展原则，而应硬化执行协议。 | 是 |
|
|
| `.agents/skills/sm-flow/SKILL.md` | 已明确 Phase 0.5、2、2.9 不可跳过，且要求显式 skill/fallback 声明。 | 当前缺口在于代理执行时没有被强制逐项核对这些规则。 | 是 |
|
|
| `.agents/skills/sm-flow/references/phase-contracts.md` | 每个 Phase 已有进入条件、动作、退出条件和 checkpoint。 | 还缺一个更短、更高频的执行时 checklist 机制。 | 是 |
|
|
| `.agents/skills/grill-with-docs/SKILL.md` | 明确要求 one-at-a-time 提问，并在可探索时优先查代码。 | Phase 2 的问题不是缺规则，而是没有把“问题池 + 单题推进”落成稳定动作。 | 是 |
|
|
| `devflow/projects/2026-05-19-dev-flow-skill-evaluation/dev-flow-skill-evaluation.md` | 历史评估已指出 `SKILL.md` 更像设计说明书，缺少执行时检查点。 | 本轮需求与历史评估一致，属于同一产品化方向的继续深化。 | 是 |
|
|
| `openspec/changes/sm-flow-execution-hardening/proposal.md` | Draft proposal 已将变更范围收敛到 phase checkpoint、问题池、cross-artifact alignment、micro gate preservation。 | Phase 1.5 已完成大方向对齐，未决问题主要落在“是否要求固定记录格式”这一类实现边界。 | 是 |
|
|
| `openspec/changes/sm-flow-execution-hardening/design.md` | Draft design 已明确 checkpoint、问题池、cross-artifact 检查链路和 devflow 过程内同步更新。 | Phase 2 需要确认的重点不再是方向，而是边界和验收粒度。 | 是 |
|
|
|
|
## Evidence-driven 结论
|
|
|
|
- 结论：`sm-flow` 当前最需要的是“执行硬化”，不是“设计重构”。
|
|
- 证据：v3.1 已经把主从关系、gate 和冲突分类写清楚，但真实执行仍偏离。
|
|
- 风险：如果继续增加理念说明，可能让文档更长，但不提升执行稳定性。
|
|
- 用户确认：不需要
|
|
|
|
- 结论：Phase 1.5 和 2.9 的 cross-artifact 检查应成为优先增强点。
|
|
- 证据：复盘里 `proposal` 漏字段未被代理提前发现，直到用户 review 才暴露。
|
|
- 风险：如果这两层不稳，Phase 2 即使问得更全，问题仍会漏到 apply 前后。
|
|
- 用户确认：不需要
|
|
|
|
- 结论：`micro` 模式的误用是本次偏差的重要诱因。
|
|
- 证据：复盘根因明确指出“高估了小改动判断，误以为 micro 可以跳检查”。
|
|
- 风险：若不把这点写得更硬，后续类似问题会重复出现。
|
|
- 用户确认：不需要
|
|
|
|
## Phase 1.5 对齐检查
|
|
|
|
- `brief/prd` -> `proposal`：已对齐
|
|
- 覆盖了执行硬化而非主设计重构、影响文件范围、非目标边界。
|
|
- `proposal` -> `design`：已对齐
|
|
- 设计已展开 checkpoint、问题池、cross-artifact alignment、micro gate preservation 和 devflow 过程内更新。
|
|
- `design` -> `specs`：已对齐
|
|
- 已拆出 `sm-flow-phase-checkpoints`、`sm-flow-question-pool`、`sm-flow-cross-artifact-alignment`、`sm-flow-micro-gate-preservation` 四个 capability spec。
|
|
- `specs` -> `tasks`：部分对齐，仍有一个边界待确认
|
|
- 当前 tasks 写了“如有需要则更新模板”，但是否必须定义固定记录格式，尚未明确。
|
|
- `specs` -> `tasks`：现已对齐
|
|
- 用户已确认这轮不强制固定模板，也不把统一阶段汇报格式纳入验收，因此 tasks 保持“协议强化优先，模板仅按需微调”。
|
|
|
|
## Phase 2 Question Pool
|
|
|
|
- Q1 `user-interview` / 范围：
|
|
- 这次 change 是否必须产出固定的 checkpoint / alignment 记录模板，还是只要求协议定义必填字段即可。
|
|
- 状态：已确认为后者。
|
|
- Q2 `evidence-driven` / 术语：
|
|
- `phase checkpoint`、`phase checklist`、`stage-completion rule` 三个说法里，哪个作为协议中的主术语最稳。
|
|
- Q3 `user-interview` / 验收：
|
|
- 验收是以“文档明确要求这些门禁”为准，还是要进一步要求代理输出统一格式的阶段汇报。
|
|
- 状态：已确认采用前者。
|
|
- Q4 `evidence-driven` / 边界：
|
|
- 这次是否需要把 retrospective 中的具体案例映射到 workflow 文档中的示例，还是只保留规则层抽象。
|
|
|
|
## Phase 2.5 架构审计
|
|
|
|
- 输入 -> 处理 -> 输出链路
|
|
- `retrospective.md` / 现有 `sm-flow` 协议 / 已归档 OpenSpec change
|
|
- -> `SKILL.md` 核心规则、`phase-contracts.md` 阶段契约、`fallbacks.md` 降级协议、按需 `templates.md`
|
|
- -> `workflow.md` 设计说明、`devflow` 过程记录、最终可提交的 OpenSpec
|
|
|
|
- 模块职责
|
|
- `.agents/skills/sm-flow/SKILL.md`：放短而硬的总规则、gate 和主从关系。
|
|
- `.agents/skills/sm-flow/references/phase-contracts.md`：放逐阶段的进入/动作/退出条件与 checkpoint。
|
|
- `.agents/skills/sm-flow/references/fallbacks.md`：放 capability 不可用时的降级协议和记录要求。
|
|
- `.agents/skills/sm-flow/references/templates.md`：只放稳定模板，不承载这轮的主逻辑。
|
|
- `skill-workbench/docs/sm-flow/workflow.md`：保留设计说明和演进脉络，不承载执行真理源。
|
|
|
|
- 架构风险评估
|
|
- 当前最大风险不是规则缺失，而是把同一条规则分散到 `SKILL.md`、`phase-contracts.md`、`workflow.md` 后出现漂移。
|
|
- 这轮 change 如果把“checkpoint”同时做成规则、模板和示例，容易再次扩大维护面。
|
|
- 更稳的做法是让 `SKILL.md` 和 `phase-contracts.md` 成为主落点，`workflow.md` 只解释，不重复列执行细则。
|
|
- `templates.md` 应保持可选和轻量，否则会把“协议硬化”扩成“输出格式标准化”。
|
|
- 审计结论与当前 Draft OpenSpec 一致，不需要新增 capability，只需要在实现时严格控制规则落点。
|
|
|
|
## Phase 2.9 Commit Gate
|
|
|
|
- proposal：通过
|
|
- 已覆盖变更原因、范围、非目标、关键边界，以及“不强制固定模板 / 不要求统一阶段汇报格式”的范围约束。
|
|
- design：通过
|
|
- 已覆盖 checkpoint、问题池、cross-artifact alignment、micro gate preservation、devflow 过程内更新和规则落点分层。
|
|
- specs：通过
|
|
- 已覆盖四个新增 capability，且行为描述集中在可观察的协议要求。
|
|
- tasks：通过
|
|
- 已覆盖协议修改、workflow 更新、校验和验收边界验证。
|
|
- user-interview：通过
|
|
- 两个需要用户确认的问题均已确认并回写。
|
|
- evidence-driven：通过
|
|
- 术语与 workflow 粒度问题已通过现有文档证据收束。
|
|
- devflow / OpenSpec 冲突：未发现
|
|
|
|
结论：当前 Draft OpenSpec 已达到可执行状态，可视为 Committed OpenSpec，进入 Phase 3 前仅缺明确 apply 授权。
|
|
|
|
## Phase 3 Apply Evidence
|
|
|
|
| 来源 | 证据 | 结论 | 是否已汇报 |
|
|
| --- | --- | --- | --- |
|
|
| `.agents/skills/sm-flow/SKILL.md` | 已新增显式 checkpoint 完成规则、question pool 规则、cross-artifact 对齐规则、`micro` gate 保留规则和 devflow 分阶段更新规则。 | 顶层协议已把执行硬化从“建议”提升为阶段完成条件。 | 是 |
|
|
| `.agents/skills/sm-flow/references/phase-contracts.md` | 已新增 Phase 1.5 对齐链检查、Phase 2 问题池建立、Phase 2.9 闭环复核、Phase 3 capability 启动汇报和 Phase 4 consolidation 约束。 | 逐阶段执行契约已经覆盖 committed OpenSpec 的核心要求。 | 是 |
|
|
| `.agents/skills/sm-flow/references/fallbacks.md` | 已新增统一 fallback 记录要求，并在各 fallback 协议中补入记录动作。 | 降级执行现在是可见、可审计的协议事件。 | 是 |
|
|
| `skill-workbench/docs/sm-flow/workflow.md` | 已新增 question pool、Phase Checkpoint、Cross-Artifact Alignment、Micro 不是 Skip、fallback 记录要求等说明。 | retrospective 中的经验已被提升为稳定规则，而不是仅停留在叙述层。 | 是 |
|
|
| `openspec/changes/sm-flow-execution-hardening/tasks.md` | 已完成 1.1-3.2，文档实现范围已落地。 | Phase 3 的协议/文档实现部分已完成，剩余工作转入验证与验收。 | 是 |
|