交互演示 — Phase 0 需求导入
🎮 Interactive · v0.3.0
10 步模拟跑完需求导入全流程：从需求收集到 Handoff 交接。
流程亮点（v0.3.0 新增）
Section titled “流程亮点（v0.3.0 新增）”| 亮点 | 说明 |
|---|---|
| 🔢 产物编号对齐 | 01→02→03→04→05 全链路编号对齐 skill v0.3.0，RR单号从 01 继承到 IR/SR/handoff 全追溯 |
| 🚦 12 项结构化 Gate | Review Ready Gate 从 8 项升级为 12 项（+3 结构一致性 +1 遗留闭环），独立 subagent 判定 |
| 📝 决策纪要回流 | 新增 ohos-req-value-decision，评审会议后决策纪要结构化回流（Accepted/Rejected/PendingRe-review） |
| 📑 GA 审批门禁 | 每个 Proposal 必须通过 GA 审批才能生成对应 SR，维度确认从 IR 继承不重复交互 |
| 🤝 Handoff 交接 | 新增 Step 0.9 Handoff 交接契约，全套产物 + RR单号移交 Phase 1-9 交付流程 |
| 🛡️ 禁止占位符 | 硬规则升级：禁止“待确认”“TBD”“待分析”，不确定项留到澄清环节逐条关闭 |
10 步演示脚本
Section titled “10 步演示脚本”Step 1 — Phase 0.1：需求收集
Section titled “Step 1 — Phase 0.1：需求收集”AI (ohos-req-requirement-intake):
请提供需求描述，我将填写结构化需求模板。
📝 01-requirement.md 字段：
- 需求标题 / 诉求方
- 背景 / 目标 / 约束
- FR（功能需求）/ NFR（非功能需求）
- RR单号（电子流追溯键）
⚠️ 硬规则：禁止占位符
- 禁止“待确认”“TBD”“待分析”
- 所有字段必须写入已确认事实
- 不确定项 → 澄清环节提问
用户输入： 需求：支持 AI Agent 通过自然语言操控 ArkWeb Input 元素，实现表单自动填充和标准化校验
Step 2 — Phase 0.2：需求澄清
Section titled “Step 2 — Phase 0.2：需求澄清”AI (Clarification Gate):
以下 3 项需确认：
- Q1: 是否需支持 Shadow DOM 内的表单？
- Q2: 目标 OHOS 版本范围？
- Q3: 是否需要 Agent 沙箱权限隔离？
⚠️ 禁止跳过不确定项
- 禁止占位符传播到下游
- 确认后 01-requirement.md status → Clarified
用户回答：
A1: 是，需支持 Shadow DOM A2: OHOS 6.0+ A3: 是，需要 Agent 沙箱隔离
Step 3 — Phase 0.3：可行性分析
Section titled “Step 3 — Phase 0.3：可行性分析”AI (ohos-req-feasibility-analysis):
正在基于代码证据分析（kb_precheck_path）…
- ✅ AIPageCommandDispatcher — 17 命令分发框架
- ✅ kCommandEntries — 扩展路径确认
- ⚠️ NWebImpl 闭源层需确认扩展机制
📊 候选方案工作量估算（500行≈1人月）：
- 方案A（双通道统一分发）: ~4.8 人月
- 方案B（全 CDP 协议）: ~8.0 人月
- 方案C（纯 A11y）: ~12.0 人月
⚠️ 不做选型推荐
- 选型决策属于 03-arch-decision-record.md
Step 4 — Phase 0.4：方案选型决策
Section titled “Step 4 — Phase 0.4：方案选型决策”AI (ohos-req-arch-decision — 两阶段):
维度 方案A 方案B 方案C 架构一致 ✅ ⚠️ ❌ 性能 ✅ ⚠️ ❌ 覆盖率 ✅ ✅ ⚠️ 工作量 4.8人月 8.0人月 12.0人月 💡 AI 推荐倾向：方案A（仅供参考） 🛑 阶段A暂停 → 等待 SIG 评审会议决策
用户决策：
选定方案A：双通道统一分发 决策者：SIG 评审会议 遗留问题：NWebImpl 扩展机制需 Phase 2 验证
Step 5 — Phase 0.5：Feature 基线 + Gate
Section titled “Step 5 — Phase 0.5：Feature 基线 + Gate”AI (ohos-req-feature-baseline → ohos-req-review-gate):
📋 04-feature.md 生成：
- ✅ 价值 / 目标 / 非目标
- ✅ 验收标准（24 条 AC，可观察指标）
- ✅ 影响性分析（北向/南向/分布式/系统/用户 5 方）
- ✅ Proposal 拆分（端到端总工作量 11.8 人月 → 标准）
- ✅ 模块覆盖校验：pass
- ✅ 术语一致性：pass
🚦 Review Ready Gate（独立 subagent 判定）
- 固定检查 8 项 ✅
- 结构一致性 3 项 ✅
- 遗留问题闭环 1 项 ✅
- 结论：Ready ✅
Step 6 — Phase 0.6：评审 PPT + 决策回流
Section titled “Step 6 — Phase 0.6：评审 PPT + 决策回流”AI:
📋 ohos-req-review-ppt-gen 生成评审 PPT（8 页固定结构） 封面 · 价值描述 · 设计方案 · 变更背景 · 影响分析 · 交付计划 · 兼容性 · 风险评估
🎬 ── 评审会议 ──
📝 ohos-req-value-decision 评审结论：Accepted ✅ 决策纪要已生成并回流 RR单号：RR-2026-0724-001
→ 进入 IR 生成
用户输入：
评审结论：接纳 备注：NWebImpl 扩展机制在 Phase 2 验证
Step 7 — Phase 0.7：IR 生成
Section titled “Step 7 — Phase 0.7：IR 生成”AI (ohos-req-feature-to-ir):
IR.md 生成完成：
- ✅ 平台级 8 项评估（性能/功耗/内存/安全/…）
- ✅ 扩展维度确认
- ✅ AC 编号继承 04-feature.md（全链路追溯）
- ✅ RR单号继承到 frontmatter
→ 通过 RR_MCP 推送电子流系统
Step 8 — Phase 0.8：Proposal 拆分 + SR 生成
Section titled “Step 8 — Phase 0.8：Proposal 拆分 + SR 生成”AI (ohos-req-proposal-to-sr):
Proposal 拆分（按 IR 拆解矩阵）：
- PROP-01: P0 核心命令分发（≈4.8 人月）→ GA ✅
- PROP-02: P1 表单标准化增强（≈4.0 人月）→ GA ✅
- PROP-03: P2 手势交互扩展（≈3.0 人月）→ GA ✅
SR 生成（维度继承自 IR，不重复交互）：
- SR-01.md ✅ | SR-02.md ✅ | SR-03.md ✅
- 责任人已指定（分析/SE/TSE/测试）
Step 9 — Phase 0.9：Handoff 交接
Section titled “Step 9 — Phase 0.9：Handoff 交接”AI:
🤝 Intake 完成！
全套产物已生成：
- 01-requirement.md ✅
- 02-feasibility.md ✅
- 03-arch-decision-record.md ✅
- 04-feature.md ✅
- IR.md ✅
- 05-proposal-01/02/03.md ✅
- SR-01/02/03.md ✅
- handoff.md ✅
RR单号 RR-2026-0724-001 全链路追溯 → 进入 Phase 1-9 SDD 交付流程