/audit-requirements

name: audit-requirements
description: 需求文档审查维度 RQ-1~RQ-8 — 需求定义/功能描述/产品事实源与可派生验证边界专属审查层

Audit Requirements Skill

适用范围

审查目标为**需求文档**（需求方输入、产品完整需求、需求变更、产品确认、功能需求、技术验收文档）时，叠加本 Skill（在 G1~G5 之后）。若目标是需求方输入型文档，只要求原始诉求清楚、来源可追溯和不确定点可识别；若目标是产品输入型需求，产品不需要填写验收标准；审查重点是双方确认后的产品事实源是否足以让研发 / AI 在技术方案、实施计划和测试方案中派生实现验收与验证清单。入口类型不得混写：纯新需求输入落 `00-需求概况.md`；有产品角色直接提供完整需求落 `01-产品需求.md`，产品模板正文只给产品填写完整 PRD，AI / 研发缺口 / 冲突检查记录在 CP1 摘要、`02-技术方案.md` 或报告中，不生成或重写产品需求；需求变更输入落 `00-需求变更概况.md` 并锚定原需求基线；AI 生成的产品确认落 `01-需求确认.md` / `01-需求变更确认.md`（历史 `01-需求概述.md` 仅作兼容）；Bug 问题应转 fix 的 `bugs/<问题>/00-问题概况.md` / `01-问题确认.md`，不按产品需求审查。

维度总览（RQ-1~RQ-8）

| 分组 | 维度 | 优先级 | |------|------|:------:| | A — 需求质量 | RQ-1 需求完整性 · RQ-2 需求明确性 · RQ-3 需求可验证性 | 🔴 | | B — 一致性与追溯 | RQ-4 需求一致性 · RQ-7 版本与变更追溯 | 🔴/💡 | | C — 影响与约束 | RQ-5 影响分析完整性 · RQ-6 约束条件明确性 | 🟡 | | D — 项目上下文 | RQ-8 项目上下文一致性 | 🟡 |

核心检查维度

**RQ-1 需求完整性 🔴**

• 必含章节：背景/问题描述、目标、功能需求或业务规则、非功能业务约束、范围/排除范围、示例/反例/异常或待确认问题
• 需求链路应先区分入口类型：无产品角色的纯新需求 `00-需求概况.md`（需求方轻量原始诉求）→ `01-需求确认.md`（AI 生成产品需求草稿，产品补充归一化）→ 需求方 + 产品双方确认 → 技术方案；有产品角色的产品完整需求 `01-产品需求.md`（产品直接提供完整 PRD，包含流程、交互、字段描述和规则）→ AI / 研发缺口 / 冲突检查（记录在 CP1 摘要、`02-技术方案.md` 或报告中，不写入产品模板正文）→ 技术方案；需求变更 `00-需求变更概况.md` → `01-需求变更确认.md` → 回写目标需求真相源 → 技术方案；Bug 问题转 fix，不进入产品需求模板
• 需求方输入型文档不要求 Mermaid、完整交互、字段全量规则或验收标准；但必须保留背景、痛点、期望结果、场景、样例、附件和不确定点
• `RequesterTemplatePlainLanguageGate`：面向用户、运营、老板、客户、内部使用方等非产品 / 非研发填写者的输入模板，字段必须用口语化问题表达，并解释“这项填什么、可以怎么写、可以不填的情况、不要写什么”；抽象术语如期望结果、当前处理方式、已知规则与限制、示例 / 反例必须转成“你希望系统帮你做到什么、现在你们怎么凑合处理、有哪些必须遵守的业务口径、给一个希望出现的例子、给一个不能接受的例子、有哪些截图表格链接或聊天记录”
• 产品输入型需求不要求产品填写验收标准；实现验收应由技术方案 / 实施计划 / 测试方案从双方确认后的产品事实源或产品直接提供的完整需求派生
• 条件必含：**业务流程**（除纯静态文案、纯说明补充一类无需行为流转的改动外，建议使用 Mermaid 主流程图 + 文字步骤图 + 节点解释；确无流程时标 N/A 并说明原因）
• 功能需求有唯一编号（如 F-01、A-01）
• 每个需求有优先级标注
• 有排除范围（明确不做什么）
• 页面 / 组件 / 可视化 / 用户可见交互类需求必须描述前端交互流程、状态覆盖、反馈方式、输入方式和设计来源
• 涉及字段时只要求字段描述、业务含义、来源、展示、编辑规则和备注，不要求数据库字段、接口 Schema 或内部 ID

**RQ-2 需求明确性 🔴**

• 需求描述无歧义，可直接转化为实现
• 非功能业务约束写清用户感知、业务边界或运营约束；技术量化指标可由技术方案补充

**RQ-3 需求可验证性 🔴**

• 每个需求有清楚的入口类型、需求方原始输入锚点（`00-需求概况.md` / `00-需求变更概况.md` / `01-产品需求.md` 或等价附件）、AI 提炼口径或产品原文锚点、产品事实源（`01-需求确认.md` / `01-产品需求.md` / `01-需求变更确认.md` 或兼容真相源）、期望业务结果或可观察用户反馈，可被技术方案派生为验证项
• 需求应包含足够的正例、反例、边界例、异常与回退口径；缺失项应进入待确认问题
• 技术验收 / 测试方案类文档才要求可执行验证用例、正向/负向场景和通过标准

**RQ-4 需求一致性 🔴**

• 同一需求包内编号、术语、范围、优先级与阶段声明不得互相矛盾；同名功能不得给出相反行为
• 变更需求必须锚定原需求基线（路径/版本/章节），并显式列出 retained / changed / removed / deferred
• 正例：变更确认稿可追溯到原 F-01，且“不做什么”与正文功能列表无冲突
• 反例：同一 F-id 在概况写“必须登录”、在确认写“匿名可用”且无裁决记录 → 阻断
• 必要证据：冲突对（摘录 A/B）、裁决位置（确认稿/报告）、未决冲突清单（可为空）
• 验证路线：交叉阅读 `00/01` + 功能清单 + 排除范围；无冲突则写 `RQ-4=PASS`，有未决冲突则 `FAIL` 并禁止进入 CP2 编码

**RQ-5 影响分析完整性 🟡**

• 当需求触及外部系统、共享契约、多模块、数据迁移、权限边界或发布面时，必须说明影响面与回滚/降级口径；纯文案/单页说明可标 `N/A + skipReason`
• 影响面至少覆盖：直接消费者、间接调用链/数据依赖、破坏性兼容风险、需同步的 Profile/文档/配置（若适用）
• 正例：新增公开 API 列出 SDK/网站/旧客户端三类消费者与兼容策略
• 反例：引入跨服务写路径却只写“影响后端”且无消费者与回滚 → `FAIL`
• 必要证据：ImpactSurface 列表（或 N/A 理由）、兼容/回滚一句、关联模块路径
• 验证路线：对照变更类型检查是否触发外部依赖/共享契约；无外部依赖时 `RQ-5=N/A`

**RQ-6 约束条件明确性 🟡**

• 业务、合规、性能、安全、环境与时间窗口等约束须可观察、可判定，禁止仅写“尽量快/安全/兼容”
• 约束写清：主体（谁遵守）、条件（何时生效）、边界（上限/下限/禁止项）、例外（若有）
• 正例：“管理端导出单次 ≤ 1 万行；超限返回 400 与可操作提示”
• 反例：“系统应高性能”且无指标/场景/失败表现 → `FAIL` 或降为待确认
• 必要证据：约束条目表（主体/条件/边界/例外）或明确“无额外约束”
• 验证路线：扫描非功能/约束章节；技术量化指标可下沉 CP2，但业务边界须在需求层可判定

**RQ-7 版本与变更追溯 💡/🔴**

• 有版本号、修订日期或变更记录时，当前有效需求必须可指向唯一 current 真相源；历史版本须标记 historical/superseded
• 需求变更路径：概况 → 确认 → 回写目标需求真相源；缺失回写锚点时不得宣称“已同步主需求”
• 正例：`01-需求确认.md` 文首 `version/status/supersedes`，旧稿 status=superseded
• 反例：多份 active 确认稿并行、无 supersedes → 阻断（🔴）；仅缺 changelog 小节但 current 唯一 → 💡 改进
• 必要证据：current 路径、version/status、supersedes 链（可空）、变更回写位置
• 验证路线：列任务目录全部需求稿 status；current 计数必须 = 1

**RQ-8 项目上下文一致性 🟡**

• 需求中的技术栈、目录边界、脚本、环境、发布面与 active Profile / 仓库现实一致；不一致须标注假设或待确认，不得静默当作事实
• 无项目 Profile 时 `RQ-8=N/A`；有 Profile 时至少核对 01 项目信息中的栈/阶段/关键路径是否与需求假设冲突
• 正例：需求声明 Node 20 + monorepo 包名与 Profile 01 一致
• 反例：需求写“必须改 Django 中间件”而 Profile/仓库为纯 Node CLI → `FAIL` 或待确认
• 必要证据：Profile 对照表（字段/需求声明/一致或差异）、差异处置（改需求/改 Profile/待确认）
• 验证路线：定向读取 active Profile 与需求假设句；差异进入待确认或阻断扩展范围

**RequirementDimensionCompletenessGate（声明完整性）**

• 凡 Skill/报告/清单声明覆盖 `RQ-1~RQ-8`，正文必须为每一维提供可执行通过条件、至少一类失败反例、必要证据字段与验证路线（或显式 `N/A + skipReason` 边界）
• 仅维度总览表/索引而无独立定义 → 本审查层与 validate 探针均视为不完整，不得标 RQ 全覆盖 PASS

**DistributionRequirementRealityGate / DomainRealityMatrix（CP1 候选）**

• CP1 候选文档在请求确认前必须形成 `CandidateReviewBundleV1`，并包含 `phaseKind=CP1`、`RQMatrix`、`DomainRealityMatrix`、`ClaimEvidenceMatrix`、`EscapeAbsorptionQueue`；缺任一项不得写“可确认 CP1”。
• `RQMatrix` 至少覆盖 RQ-1~RQ-8，每行包含 `dimension / status / evidence / gap / disposition / skipReason`；只写总评或“已覆盖”不算通过。
• `DomainRealityMatrix` 用来防止把分发、包、命令、运行态、授权和阶段状态想当然，至少包含：`domain`、`currentReality`、`repoEvidence`、`consumer`、`decision`、`negativeProbe`、`skipReason`。
• 推荐 domain：`sourceTruth`、`packageChannel`、`licensePolicy`、`commandSurface`、`runtimeCapability`、`phaseKind`。不触发的 domain 可 `N/A + skipReason`，但不能省略整张矩阵。
• `ClaimEvidenceMatrix` 将每个关键需求主张映射到原始输入、产品事实源、Profile/仓库证据或 `UNVERIFIED` 边界；不得把外部审查报告或 AI 推断当作已验证事实。
• `EscapeAbsorptionQueue` 记录外部审查/复审发现：`sourceClaimId / finding / localEvidence / disposition(adopt|partial|reject|defer) / targetArtifact / owner / status`；禁止把外部报告直接粘进需求正文后宣布已吸纳。
• 负向：缺 `DomainRealityMatrix` 却确认“包发布/命令/运行态可用”；缺 `ClaimEvidenceMatrix` 却把假设写成事实；发现外部问题但没有队列和 disposition → 阻断 CP1 确认。

**PhaseDeliverySemanticGate（条件）**

• 多阶段需求、路线图或“全部纳入某阶段”必须为每阶段标记 `phaseKind=planning-only / design-ready / implementation / release`，分别说明 planning coverage 与 source delivery。
• 建立 `PhaseDeliverySemanticMatrix`：originalIntent、phaseKind、inScope、sourceDelivery、entry、exit、carryOver、closeRule、confirmationText 必须一致。
• 执行 `OriginalIntentReverseTraceProbe`：从用户原始消息、已确认需求和当前阶段反向证明“纳入”指规划、设计、编码还是发布；事实不明时不得默认把全部源码债务锁入当前阶段。
• CP、技术方案、批次、验收、进度和最终结论出现不同 phaseKind 时为阻断性不一致。

**ValidationLifecycleTraceabilityGate（GR-044）**

• 分阶段 / 状态机型需求或明确「先验证再 accepted/final」的任务，验收矩阵**不能**替代独立验证阶段。
• 必须能反向追踪：`plan → execute → validate → accept/deliver → synthesize → global validate → complete`。
• 最小产物：`ValidationPlanV1`（进入执行前）、`BatchValidationResultV1`（批次 accepted 前）、`Gl