Ohos Req Review Gate

OHOS Review Ready Gate (结构化判定)

Announce at start: "我正在使用 ohos-req-review-gate skill 对 04-feature.md 执行 Review Ready Gate。"

定位

OHOS Review Ready Gate 是 Phase 0 唯一的独立 subagent 结构化判定——主 session 已持有 01-04 全文上下文，自行推算 Gate 会产生确认偏差，必须由隔离上下文的 subagent 执行判定。Gate JSON 输出的 observations 字段（PIR #152 P1）将性能/功耗/内存等需 Phase 5-7 实测的指标归类为观测项，不阻塞 Ready 判定，在 Phase 1-9 跟踪闭环。

适用边界

• ✅ 适用：Phase 0 Step 0.5（Feature 评审就绪）
• ❌ 不适用：决策 0（立项评审）、决策 1（方案确认）、决策 1.5（SIG 评审）、决策 2（Phase 4 评审）、决策 3（代码审查）、Phase 5 Step 5.2（设计待解决问题门禁）——这些由主 session / 后续 phase 流程承载
• 后续如果其他决策点也需要物化，可参考本 skill 的 JSON 输出契约复制推广

输入

• {docs_dir}/01-requirement.md
• {docs_dir}/02-feasibility.md
• {docs_dir}/03-arch-decision-record.md
• {docs_dir}/04-feature.md
• reference/feature-checklist.md（检查项判定规则与边缘情况处理的详细定义，必须在流程第1步加载读取）

04-feature.md 不存在时直接判定为 Not Ready，并返回错误说明（不试图推断）。

Gate 检查项（8 项固定 + 3 项结构一致性 + 1 项遗留问题闭环 = 12 项；条件项为独立字段）

8 项固定检查对应 feature.md §1-§5（拆分决策与工作量约束同属 §5）+ 技术方向（引用 03-arch-decision-record.md）+ 影响性分析（模板外补充章节），避免规则两套。3 项结构一致性检查为本 skill 新增，确保跨文档数据传播完整。1 项遗留问题闭环检查确保 03-arch-decision-record.md §6 由用户评审会议输入且闭环可追溯。逐项读取 04-feature.md 对应章节，按以下规则判定：

固定检查项（8 项）：

结构一致性检查项（3 项新增，仅做 Ready/Conditional/Not Ready 决策判定，不重复校验内容）：

职责边界： ohos-req-feature-baseline skill 在生成期做模块覆盖完整性/术语一致性的逐项校验和修复；本 skill 只做最终的 Ready/Conditional/Not Ready 决策判定，引用 feature skill 的校验结果（不重复执行校验逻辑）。条件项传播完整性为本 skill 独有（feature skill 不涉及 02/03 的条件项跨文档追溯）。

遗留问题闭环检查项（1 项新增）：

条件项检查（独立字段）：

• 04-feature.md 中所有标记为"⚠️"或"未通过/未知"的项必须都有 Owner 和关闭时点，否则提升为失败项

Phase 0 观测项（不阻塞 Gate 判定）：

部分条件项的关闭依赖于 Phase 5-7（实现+测试阶段）才能获取的量化数据（如性能基准测试结果、功耗实测数据、内存占用基线等）。这类条件项在 Phase 0 阶段客观上无法关闭，若将其作为 Gate 阻塞项，会导致 Gate 永远停留在 Conditional Ready、IR 永远 Conditional、handoff 永远 ConditionalReady。

分类规则：

观测项识别规则：条件项描述中含"性能基准""功耗实测""内存占用基线""稳定性测试""压力测试"等需实际运行才能获取的量化指标时，自动归类为观测项。观测项仍需记录 Owner 和目标关闭时点（指向 Phase 5-7 对应阶段），但不影响 Gate 结论。

Gate 结论修订规则：

• Ready：无 fail，无可关闭 warn 项（观测项不计入 warn 统计）
• Conditional Ready：无 fail，有可关闭 warn 项且每条都有 Owner/动作/时点（观测项单独列出，不影响升级判定）
• Not Ready：有 fail，或有可关闭 warn 项但缺少 Owner/动作/时点

流程

1. 读取 reference/feature-checklist.md 获取各检查项的 Pass/Warn/Fail 判定规则与边缘情况处理规则；读取 04-feature.md（不存在 → 直接 Not Ready + 错误原因）。
2. 读取 §1-§5 及影响性分析补充章节的内容，只引用必要的摘要（不嵌入 01-04 全文）。
3. 对每项检查按上表规则判定 pass / warn / fail。
4. 收集所有 warn 项，按分类规则区分为「Phase 0 可关闭条件项」和「Phase 0 观测项」：
   • 可关闭条件项必须含 Owner、关闭动作、关闭时点，否则升级为 fail
   • 观测项记录 Owner 和目标关闭时点（指向 Phase 5-7），但不影响 Gate 判定
5. 汇总得到 Gate 结论（观测项不计入 warn 统计）：
   • Ready：无 fail，无可关闭 warn 项
   • Conditional Ready：无 fail，有可关闭 warn 项且每条都有 Owner/动作/时点
   • Not Ready：有 fail，或有可关闭 warn 项但缺少 Owner/动作/时点
6. 同时写两份产物：
   • tmp/decision_gate_{feature_id}_{timestamp}.json（机读）
   • tmp/decision_gate_{feature_id}_{timestamp}.md（人读摘要）
7. 回传主 session：路径 + 结论 + 失败/条件项计数。不复读 01-04 内容。

⭐ 思维准则

在执行 Gate 检查前，自问以下问题：

• Before evaluating each check item, ask yourself: am I reading the actual § content from 04-feature.md, or inferring from the section title?
• Before upgrading a warn to fail, ask yourself: does the warn item genuinely lack Owner/close_action/close_at, or did I fail to extract them?
• Before returning Not Ready, ask yourself: have I checked the degradation rules for missing 02/03, or am I blanket-failing all structural checks?

输出契约

JSON Schema（机读）

{
  "feature_id": "<FEAT-YYYYMMDD-NNN>",
  "checks": [ /* 12 项检查结果，含 8 固定 + 3 结构一致性 + 1 遗留问题闭环 */ ],
  "summary": {"pass": 11, "warn": 0, "fail": 0},
  "gate": "Conditional Ready",
  "block_reasons": []
}

（完整 JSON Schema 示例见 reference/gate-schema-example.json）

字段语义

• gate：仅取 "Ready" | "Conditional Ready" | "Not Ready"
• summary.pass / summary.warn / summary.fail：12 项检查的统计
• conditions：所有可关闭 warn 项 + 关闭信息（Owner/动作/时点），如 Owner/动作/时点缺失，由本 skill 自动从 warn 升级为 fail
• observations：Phase 0 观测项（性能/功耗/内存等需 Phase 5-7 实测的指标），记录 Owner 和目标关闭阶段，不阻塞 Gate 判定
• next_action：主 session 路由提示（如"生成 IR"、"阻塞回 Step 0.4 补全"、"阻塞：feature.md 不存在"）
• block_reasons：升级为 fail 的条件项描述（仅在 gate=Not Ready 时非空）

Markdown 摘要（人读）

（人读 Markdown 摘要模板见 reference/gate-summary-template.md）

与主 Session 的契约

主 session 在 Phase 0 Step 0.5 时：

1. spawn ohos-req-review-gate subagent，task 仅含 docs_dir 绝对路径（不嵌 01-04 全文）
2. 等待 subagent 回传路径
3. 读 tmp/decision_gate_*.json（≤100 行结构化数据，符合 Token 经济性规则）
4. 根据 gate 字段路由：
   - "Ready"           → spawn ohos-req-feature-to-ir
   - "Conditional Ready" → spawn ohos-req-feature-to-ir（task 中追加 conditions 摘要）
   - "Not Ready"       → 阻塞；如 block_reasons 非空，用其内容生成 AskUserQuestion

NEVER

• 禁止主 session 自行读 01-04 推算 Gate: 必须通过 spawn 独立 subagent 执行，本 skill 的 JSON 输出是唯一 Gate 结论（原因：主 session 已持有 01-04 全文上下文，自行推算会产生确认偏差，独立 subagent 判定是唯一可信结论）
• 禁止嵌入 01-04 全文到 task: task 仅含 docs_dir 绝对路径，不嵌入 01-04 全文（原因：嵌入全文会 fork 上下文，导致 subagent token 爆炸且无法隔离判断）
• 禁止复读产物全文到会话: 正式产物落盘+路径回传，不复读全文（原因：复读全文违背 Token 经济性规则，正式产物只需落盘+路径回传）
• 禁止在 Gate 输出 JSON 中添加 schema 外字段: schema_version 1.0 固定字段不可增删，主 session 仅消费 gate/conditions/block_reasons 字段
• 禁止在 04-feature.md 不存在时尝试从 01-03 推断 Gate 结论: 必须直接判定 Not Ready 并返回错误说明

错误处理

自检

• 8 项检查与 feature.md §1-§5 + 技术方向/影响性分析完全对齐，无新增无删减
• 3 项结构一致性检查已执行（模块覆盖/术语一致性/条件项传播）
• 1 项遗留问题闭环检查已执行（03 §6 用户输入+三字段齐全）
• 条件项 Owner/动作/时点缺失时自动升级为 fail
• 性能/功耗/内存等需 Phase 5-7 实测的条件项已归类为「观测项」，不阻塞 Gate 判定
• JSON 字段与 schema_version 一致
• Markdown 摘要表行数 = 12（8固定+3结构+1遗留）
• 不嵌入 01-04 全文到 task
• 回传 ≤ 15 行

输出

• 路径：
  • tmp/decision_gate_{feature_id}_{timestamp}.json
  • tmp/decision_gate_{feature_id}_{timestamp}.md
• 回传：JSON 路径、Gate 结论、pass/warn/fail 计数、block_reasons 数量