SDD 能力底座
怎么给你的 change 选档
xs / s / tech / m / l 五档 —— 选错了流程要么过重要么过轻
每次起新 change，Workbench 会让你选一个档位。选档决定你要写哪些文档、走哪些门禁。
选错了会很难受：选低了 Validator 报错让你补；选高了写一堆没用的文档浪费时间。
一棵决策树，按顺序自检
1. 我这次改外部行为吗?
├─ 否 (纯重构 / 升级) ──► tech
└─ 是 ↓
2. 跨多业务线 / 战略级吗?
├─ 是 (公司级新业务 / 大改造) ──► l
└─ 否 ↓
3. 跨子模块 / 调 NFR / 引新能力吗?
├─ 是 (动了架构 / 性能目标变了) ──► m
└─ 否 ↓
4. 1 天内能干完且不改 spec 吗?
├─ 是 (改文案 / 小调整) ──► xs
└─ 否 ──► s (默认)铁律：拿不准的时候选高一档，不要为了图快降档。
五档对照速查
| 档位 | 适用 | 时长 | 你需要写 | 谁参与 |
|---|---|---|---|---|
| xs | 改文案 / UI 微调 / 配置项 | < 1 天 | 简单 dev 包 + evidence | 1 人 |
| s | 加 / 改单个功能 | 1-5 天 | PD（简版） + Dev + Test | PD + 开发 |
| tech | 重构 / 升级 / 不改外部行为 | 1-10 天 | 架构 + Dev | 架构 + 开发 |
| m | 跨模块 / 调 NFR / 引新能力 | 2-6 周 | 全套 | 全员 |
| l | 跨多业务线 / 战略 | 6 周+ | 全套 + 全员评审 | 全员 + 领导层 |
不同档位你具体要写什么
打 ✅ 是必填、⚪ 是可选、⛔ 是不该写：
| 文档 | xs | s | tech | m | l |
|---|---|---|---|---|---|
| PD 包 | |||||
业务愿景 (vision.md) | ⚪ | ✅ | ⛔ | ✅ | ✅ |
用户故事 (stories.md) | ⚪ | ✅ | ⛔ | ✅ | ✅ |
功能需求 (requirements.md) | ✅ | ✅ | ⛔ | ✅ | ✅ |
非功能需求 (nfr.md) | ⚪ | ⚪ | ⛔ | ✅ | ✅ |
验收标准 (acceptance.md) | ✅ | ✅ | ⛔ | ✅ | ✅ |
产品设计 (product-design.md) | ⚪ | ⚪ | ⛔ | ✅ | ✅ |
风险 (risks.md) | ⚪ | ⚪ | ⛔ | ✅ | ✅ |
发布 (rollout.md) | ⚪ | ✅ | ⛔ | ✅ | ✅ |
术语 (glossary.md) | ⚪ | ✅ | ⛔ | ✅ | ✅ |
AI 规约 (ai-spec.md) | ⚪ | ⚪ | ⛔ | ⚪* | ⚪* |
| 架构包 | |||||
架构 (architecture.md) | ⛔ | ⛔ | ✅ | ✅ | ✅ |
关键决策 (adr.md) | ⛔ | ⛔ | ✅ | ✅ | ✅ |
质量属性 (quality-attributes.md) | ⛔ | ⛔ | ⚪ | ✅ | ✅ |
| 开发包 | |||||
工程提案 (proposal.md) | ✅ | ✅ | ✅ | ✅ | ✅ |
能力契约 (specs/) | ⚪ | ✅ | ✅ | ✅ | ✅ |
内部设计 (design.md) | ⚪ | ⚪ | ✅ | ✅ | ✅ |
任务清单 (tasks.md) | ✅ | ✅ | ✅ | ✅ | ✅ |
| 测试包 | |||||
测试用例 (test-cases.md) | ⚪ | ✅ | ⚪ | ✅ | ✅ |
测试证据 (test-evidence.md) | ✅ | ✅ | ✅ | ✅ | ✅ |
* 仅本次 change 含 AI 能力时需要
如果你勾错了，matrix Validator 会直接拒提交（看 校验报错了怎么办）。
怎么操作
在 Aiko Chat 里：
> /aiko-new-change add-coupon-discount
[选档向导]
Q1: 改外部行为吗? y
Q2: 跨多业务线? n
Q3: 跨子模块 / 动 NFR? n
Q4: 1 天能完成不改 spec? n
→ 推荐档位: s
确认? [Y/n]确认后会自动生成 .openspec.yaml 和对应档位的文档骨架。
或者你也可以直接手动写：
# .openspec.yaml
schema: pd-driven
change-type: s
group: coupon-discount
status: draft我半路发现选错档了，怎么办？
| 情况 | 怎么办 |
|---|---|
| s 写一半发现跨模块了 | 升 m：补架构包，PD 加 nfr 段 |
| m 评审觉得没那么大 | 不允许降：要么完整跑 m，要么作废重起一个 s |
| tech 发现要改外部行为 | 升 m：PD 包补上 |
| xs 写着写着超出 1 天 | 升 s：补 vision / stories |
升档的决策一定要写到 review-log.md 留痕。
进阶：让 profile 替你管编排
如果同类需求经常出现，可以在 openspec/config.yaml 里定义 workflowProfile：
aiko:
workflowProfiles:
new-feature-s:
tier: s
packages: [pd, test, dev]
gates: [validate, l2-e2e, ci]
defect-xs:
tier: xs
packages: [dev, test]
gates: [validate, l1-only]
compliance-m:
tier: m
packages: [pd, arch, test, dev]
gates: [validate, security-scan, l2-e2e, l3-regression]起新 change 时挂 workflowProfile: new-feature-s，所有默认就帮你选好了。
进阶：选 git 路径
gitPath 是另一个正交维度（决定分支怎么流转）：
| profile | 路径 | 适用 |
|---|---|---|
git-enterprise（默认） | feature → develop → release → main | 企业内部 |
git-saas-trunk | feature → main | SaaS 快速 trunk |
git-simple | feature → develop → main | 无 release 分支 |
git-hotfix | hotfix → release → main | 紧急修复 |
工作流 profile 决定"要写啥跑啥"，git path 决定"分支怎么走"，两个独立挂载。