Update sm-flow workflow docs
This commit is contained in:
@@ -0,0 +1,42 @@
|
||||
# 分档规则
|
||||
|
||||
本文件是 `micro / standard / complex` 的唯一规则源。其它文件只引用本文件,不重复定义分档细节。
|
||||
|
||||
## standard 基准
|
||||
|
||||
standard 是默认分档,适用于普通功能、明确但有一定实现范围的变更。
|
||||
|
||||
- 用户可见 checkpoint:Discover → Commit → Apply → Archive。
|
||||
- OpenSpec 产物:`proposal.md`、独立 `design.md`、`specs/`、`tasks.md`。
|
||||
- grill:解决术语、边界、验收三个维度的高价值问题。
|
||||
- commit gate:检查 proposal、design、specs、tasks 的完整性和一致性。
|
||||
- devflow 档案:`brief.md`、`evidence.md`、`decisions.md`、`acceptance.md`。
|
||||
|
||||
## micro 覆盖
|
||||
|
||||
micro 适用于小改动、低风险、需求明确的变更。micro 是 standard 的减法,不是跳过流程。
|
||||
|
||||
- checkpoint 可合并:Discover + Commit 可在无阻塞时合并汇报。
|
||||
- micro 内部流程压缩为:clarify+context 合并 checkpoint → 轻量 propose → grill → specify+commit 合并 checkpoint。
|
||||
- context 保留最小收集:至少检查 glossary 和相关 ADR。
|
||||
- grill 保留最小澄清:至少解决一个高价值问题,并记录术语、边界、验收三类是否明确;不明确项必须补问或标记风险。
|
||||
- OpenSpec 仍需要 `proposal.md`、`specs/`、`tasks.md`。
|
||||
- `design.md` 可不独立创建;允许在 `proposal.md` 或 `tasks.md` 中写等价设计小节。
|
||||
- `specs/` 和 `tasks.md` 可轻量,但必须表达可观察行为和可执行任务。
|
||||
- commit gate 仍必须通过,并创建 `.committed`。
|
||||
- devflow 档案至少包含 `brief.md`、`decisions.md`、`acceptance.md`;证据少时可并入 `brief.md` 或 `decisions.md`。
|
||||
- apply 仍只能依据 Committed OpenSpec。
|
||||
- archive 仍要轻量回填 devflow,并询问是否归档 OpenSpec。
|
||||
|
||||
micro 不适用于接口影响不清、跨团队消费者、迁移/回滚、复杂状态机、长期架构决策或需求边界不清的变更;遇到这些情况应升级为 standard 或 complex。
|
||||
|
||||
## complex 增量
|
||||
|
||||
complex 适用于高风险、跨模块、需求不清、多人协作或长期架构影响明显的变更。complex 是 standard 的加法。
|
||||
|
||||
- 需要更完整的 Discover:增加需求澄清、证据查证、范围确认和风险接受。
|
||||
- checkpoint 内可补充关键内部阶段结果,但不要把内部阶段名当作用户操作入口。
|
||||
- 按需创建 `prd.md`、`research.md`、`alignment.md`、接口文档、ADR 或 compound knowledge。
|
||||
- 接口影响、迁移、灰度、回滚、兼容性和消费者边界必须显式记录。
|
||||
- audit 需要覆盖模块链路、数据所有权、生命周期、耦合风险和 ADR 冲突。
|
||||
- archive 在 standard 档案基础上按需提炼长期 design、research、tasks、ADR 和 compound knowledge。
|
||||
Reference in New Issue
Block a user