用途：在编码前做计划对计划的预执行校验，验证 requirements.md 的内部一致性及对项目规则的遵循，位于 Gate 2（scope_confirmed）之后、任务生成之前。适用时机：Gate 2 之后、用户要求“analyze requirements”或“check consistency”、手动编辑 requirements.md 之后。前置条件：{product_root}/docs/versions/{version_san}/requirements.md 存在；缺失则重定向到 Gate 1 / ns-sdd-requirements-generator。
主要能力：先索引需求（主目标、功能及其优先级与验收标准、NFR、声明的技术栈），再运行检查并分级为 ✅ OK、⚠️ Warning、❌ Blocker。功能完整性：每个功能需有标题、描述、验收标准（Blocker）；每功能至少 2 条验收标准（Warning）；无循环优先级（Blocker）；至少一个根功能（Blocker）；预期 E2E 时前端功能需提及 test id（Warning）。测试覆盖：后端功能含单元测试标准、UI 功能含 E2E 标准、greenfield 下基础设施先于领域（均为 Warning）。数据模型：清晰的“Data model and APIs”章节、功能中所有实体列入数据模型、遵守外键创建顺序、声明供前端消费的 API 端点（均为 Blocker）。对齐：功能支持既定目标、存在范围外功能（均为 Warning）。存在 harness 规则时应用栈特定检查（Laravel/React 检查为可选）。
使用方式：从 {harness_root}/rules/.md 加载规则，先读 architecture-rules.md；仅当 {harness_root} 缺失时回退到 .cursor/rules/.mdc。将状态写入 requirements.md 末尾的 ## Consistency 块（含 Status、Date，以及按需出现的 Warnings、Recommendations），不要创建 consistency-report.md；重跑时替换旧块而非重复。任何 Blocker 则 Status: Reproved；零 Blocker 则 Approved（仍可含警告与建议）。
后续决策：Reproved 时在对话中列出阻塞项并停止，不进入任务生成，请用户修复后重跑；Approved 但有警告时询问立即修复还是继续，由用户决定；Approved 且无警告时自动进入任务生成，execution_confirmed 隐式成立（跳过 Gate 3）。
限制：仅可编辑 requirements.md 的末尾 Consistency 块；阻塞项未修复或未明确豁免前不得生成任务；绝不写 consistency-report.md。与实现后的 ns-code-reviewer（校验需求×代码）互补，不可替代。