osiman/git-learn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
63994b6440aa5b22ce6519fc07726aed1daa138b
git-learn/devflow/projects/2026-05-22-sm-flow-execution-hardening/evidence.md
T

8.4 KiB
Raw Blame History

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 的协议/文档实现部分已完成，剩余工作转入验证与验收。 是
Reference in New Issue View Git Blame Copy Permalink