OHOS Proposal 转 SR

Announce at start: "我正在使用 ohos-req-proposal-to-sr skill 生成 SR.md。"

定位

SR.md 作为 OHOS 电子流 GA 后基线附件提交，SR 的 status=GA-Approved 是 ohos-delivery 启动 Phase 1-9 的前置条件。SR 的维度确认继承自 IR（PIR #152 P0），不重新逐条交互。SR §二责任人表的分析责任人/SE/TSE/测试责任人必须在 handoff 前指定（PIR #152 P2），缺失则阻断 Phase 1-9 启动。

适用边界

• ✅ 适用：Phase 0 GA 后每个 proposal 对应生成 SR 基线
• ❌ 不适用：IR 生成（ohos-req-feature-to-ir）、Feature 基线（ohos-req-feature-baseline）、可行性分析（ohos-req-feasibility-analysis）

输入与硬门禁

• IR.md
• 一个或多个 05-proposal*.md
• 每个 proposal 对应的 GA 记录

以下任一情况必须拒绝生成：

• proposal 状态不是 GA-Approved
• gate_a 或外部 GA 证据为空
• IR 拆解矩阵中的 proposal 未全部覆盖
• proposal 的 P0/P1 AC 无法回溯到 IR

模板说明

• 模板路径：reference/SR.md
• proposal 结构参考模板：reference/proposal.md（模板文件不带 05- 阶段编号前缀；05-proposal*.md 仅作为 {docs_dir} 下的产物文件名）
• 模板含 5 个章节：GA 通过证据 / 系统需求基线 / 接口责任与跨仓契约 / 验收与约束 / 来源追溯
• 一份 SR.md 只定义一个 SR；一个 proposal 对应一个 SR
• 多个 SR 时各自独立文件（SR-01.md、SR-02.md...），以模板内「关联 SR」表相互引用
• 流程规则（硬门禁、追溯矩阵、维度确认等）由本 skill 控制

流程

1. 读取 reference/SR.md、reference/proposal.md（了解 proposal 产物结构）、IR、proposal 和 GA 证据。
2. 从 IR.md frontmatter 继承 rr_id 到 SR.md frontmatter，并在 §二 需求概要表中填写 RR单号行。
3. 按 proposal 逐个生成 SR：每个 GA-Approved 的 proposal 对应一个独立的 SR 文件。
4. 记录该 proposal 的 GA 日期、结论、参与人和证据链接（§一）。
5. 从该 proposal 和 IR 的需求陈述中提取系统需求基线（§二），不添加 proposal 未批准的新范围。提取方法：
   • 按 FR/NFR 分类：从 proposal §3 需求基线逐条提取，分别归入功能需求和非功能需求
   • 合并重叠需求：同一能力在多个用户故事中出现时，合并为一条系统需求，保留各来源引用
   • 识别跨 proposal 依赖：仅记录依赖关系（如"SR-01 依赖 SR-02 的 XX 接口"），不合并多个 proposal 的需求
   • 标注来源：每条系统需求标注来源（proposal §X），确保可追溯
   • 填写「关联 SR」表引用其他 proposal 对应的 SR
   • §二「责任人」表的分析责任人/SE/TSE/测试责任人必须填写，不得留空或标"待确定"——如暂未确定，标注"⚠️ 待指定"并在 handoff 前置检查中阻断

Before writing an interface responsibility, ask yourself: am I adding implementation signatures (methods, classes) or just defining responsibility boundaries (direction, type)?

Before writing a traceability matrix row, ask yourself: does this AC trace back to a proposal requirement, or am I creating an untraceable link?

Before writing SR §二 需求基线, ask yourself: 每条系统需求是否可追溯到 proposal §X？是否新增了 proposal 未批准的范围？

Before 维度确认, ask yourself: IR 是否已确认此维度？是否只需继承结论而非重新逐条交互？

6. 定义接口责任、提供方、消费方和语义约束（§三），不写实现签名。定义方法：
   • 提取涉及接口：从 proposal 影响范围表提取涉及的接口清单
   • 标注方向：上游->下游 / 下游->上游 / 双向
   • 标注类型：Public（对外公开）/ System（系统级）/ Internal（仓内内部）
   • 定义责任与语义约束：明确每个接口的职责边界和语义约束，不写方法签名、类设计或时序设计
7. 填写验收标准、系统约束和维度涉及确认（§四）。维度确认继承自 IR.md——直接引用 IR 已确认的维度结论，不再向用户逐条重新确认。仅当 proposal 范围超出 IR 覆盖的新增维度时才补充确认。
8. 建立 IR -> Proposal -> SR -> AC 追溯矩阵（§五）。
9. 保存到 {docs_dir}/SR-{NN}.md（编号与 proposal 对应，如 SR-01.md 对应 05-proposal-01.md），状态设为 GA-Approved。

文件命名规则

proposal 文件	SR 文件
05-proposal.md（单一）	SR.md
05-proposal-01.md	SR-01.md
05-proposal-02.md	SR-02.md

自检

自检清单详见 reference/sr-checklist.md。核心：GA通过证据齐全、1:1 proposal→SR映射、维度继承自IR、责任人表无空值。

NEVER

• NEVER 在 SR 中新增 proposal 未批准的需求范围：SR 是 GA 后的基线，只能从已批准 proposal 提取，不可自行扩大范围（原因：SR 是 GA 后锁定的基线，新增范围绕过了 GA 审批，未批准的需求会进入 Phase 1-9 实现阶段导致返工）
• NEVER 在 SR 中写实现签名：SR 定义接口责任和语义约束，不包含方法签名、类设计、时序设计（这些属于 spec/design 阶段）（原因：SR 是系统需求基线附件，方法签名/类设计属于 spec/design 阶段产物，提前写入会与后续设计产生冲突）
• NEVER 合并多个 proposal 的 SR：一个 proposal 对应一个 SR（1:1 关系），跨 proposal 依赖仅记录依赖关系，不合并文件（原因：合并会模糊 GA 审批边界，导致部分 proposal 未批准的需求混入 SR 基线，电子流无法追溯单个 proposal 的验收状态）
• NEVER 忽略 P0/P1 AC 到 IR 的可追溯性：每条 P0/P1 AC 必须能在 IR 矩阵中找到对应行，缺失时拒绝生成 SR（原因：断链的 AC 在 Phase 5 测试阶段无法验证，导致 SR 验收无法闭环）

输出

• 路径：{docs_dir}/SR-{NN}.md（每个 proposal 一个）或 {docs_dir}/SR.md（单一 proposal 时）
• 回传：SR 文件列表、各 SR ID、RR单号、GA proposal 数量、系统需求数量和追溯覆盖率