spec.md
需求说明，由 /req（spec-writing skill）按模板 skills/spec-writing/spec-template.md 写成，需求方确认后交给流水线。
头部
markdown
# <需求名称>
- 状态：已确认（2026-10-12）
- 档位：标准
- 执行方式：连续
- 类型：新需求
- 版本：1
- 格式：req-kit/spec@1| 行 | 谁读 | 规则 |
|---|---|---|
- 状态： | 引擎 | 以"已确认"开头才能启动流水线。正则：^\s*-\s*状态\s*[:：]\s*已确认 |
- 档位： | 引擎 | "快速"或"标准"（也接受 quick / standard）。没有时用配置中的 defaultProfile |
- 执行方式： | 引擎 | "连续"、"分阶段"或"只做研发"（也接受 continuous / gated / develop-only）。可以没有；没有时用配置中的 phases.mode，启动参数 --phases 优先（1.7 起） |
- 类型： | 引擎（1.8 起）、/req | 新需求 / 小改动 / 缺陷 / 重构 / 评估（也接受 defect、bug、refactor、assessment；"技术改进"同重构，"调研"同评估）。缺陷、重构、评估按各自的做法运行（engine/prompts/types/），配置 requirementTypes 可以关掉某个类型；其他写法按新需求处理 |
- 联合开发： | 引擎（1.8 起） | 这个需求还要改的其他仓库，写项目配置 relatedRepos 中的名称，最多两个，用顿号分开。可以没有。见 ADR 0025 |
- 引入问题的需求： | req stats、req outcome（1.14 起） | 缺陷需求才写：引入这个问题的需求的目录名（或功能目录、标题）。记为那个需求"合并后发现的问题"。可以没有 |
- 版本： | /req | 从 1 开始，每次修改需求加 1 |
- 格式： | /req、引擎（将来） | req-kit/spec@<n>。没有这一行的旧 spec 按 req-kit/spec@1 处理 |
正文中被引用的编号
- 功能需求
FR-<n>，验收标准AC-<n>.<m>，规则BR-<n>，假设A-<n>。 - 每条验收标准至少带一组具体的输入和期望输出（1.8 起由
acceptance-criteria、需求说明审阅检查）；方案的测试直接用这些例子作为期望值。 - 流水线各步骤和最终报告按这些编号引用，编号一旦确认就不要重排；删除的需求保留编号并注明"已取消"。
变更
- spec 的内容哈希记录在状态文件中。spec 在流水线中断后被修改，续跑时从方案设计重新开始。
本页由仓库中的 contracts/spec.md 生成。在 GitHub 上编辑