ns-sdd-analyze-consistency

一致性分析

执行前验证：编码前检查计划是否一致。

查找 Harness

参见 ../ns-harness/references/harness-discovery.md。从 {harness_root}/rules/*.md 加载规则。先阅读 architecture-rules.md。旧版：仅当 {harness_root} 不存在时，才读取 .cursor/rules/*.mdc。

适用时机

• Gate 2（scope_confirmed）之后
• 用户要求“分析需求”或“检查一致性”
• 手动编辑 requirements.md 之后

前置条件

• {product_root}/docs/versions/{version_san}/requirements.md 存在

工作流

步骤 1 — 为需求编制索引

阅读 requirements.md 并编制索引：

• 主要目标
• 功能（标题、优先级、验收标准）
• NFR
• 声明的技术栈

步骤 2 — 执行检查

将每项检查归类为 ✅ OK | ⚠️ Warning | ❌ Blocker：

功能完整性

检查	失败级别
每项功能都有标题、描述和验收标准	❌ Blocker
每项功能至少有 2 条验收标准	⚠️ Warning
不存在循环优先级	❌ Blocker
至少有一项根功能（无优先级依赖）	❌ Blocker
预期进行 E2E 测试的前端功能提及测试 ID	⚠️ Warning

测试覆盖

检查	失败级别
后端功能包含单元测试标准	⚠️ Warning
UI 功能包含 E2E 标准	⚠️ Warning
全新项目中基础设施优先于领域功能	⚠️ Warning

数据模型

检查	失败级别
有清晰的“数据模型和 API”章节	❌ Blocker
功能中提及的所有实体都列在数据模型中	❌ Blocker
遵循外键创建顺序	❌ Blocker
声明供前端使用的 API 端点	❌ Blocker

对齐情况

检查	失败级别
功能支持既定目标	⚠️ Warning
存在超出范围的功能	⚠️ Warning

如 Harness 规则中存在针对特定技术栈的检查，则应用这些检查（Laravel/React 检查为可选项）。

步骤 3 — 将状态写入 requirements.md

不要创建 consistency-report.md。

在 requirements.md 末尾追加（或替换已有的末尾 ## Consistency 区块）：

## Consistency

**Status:** Approved | Reproved
**Date:** {date}

## Warnings

{Omit this heading when there are no warnings.}
- {warning}

## Recommendations

{Omit this heading when there are no recommendations.}
- {recommendation}

规则：

• 存在任何 ❌ Blocker → Status: Reproved
• 没有 Blocker → Status: Approved（仍可包含警告/建议）
• 仅当至少存在一项 ⚠️ 时，才包含 Warnings
• 仅当至少存在一项可选改进时，才包含 Recommendations
• 重新运行时，替换之前的 ## Consistency 区块，不要重复添加

步骤 4 — 决定是否继续

• Reproved： 在聊天中告知用户（简要列出阻塞项），停止——不要继续生成任务。请用户修复需求后重新运行。
• Approved with warnings： 告知用户；询问现在修复还是继续，由用户决定。
• Approved with no warnings： 告知用户将自动继续生成任务；隐式设定 execution_confirmed（跳过 Gate 3）。

关键规则

• 仅编辑 requirements.md，以更新末尾的 Consistency 区块
• 有阻塞项时，必须先修复或明确豁免，才能生成任务
• 如果缺少需求 → 转到 Gate 1 / ns-sdd-requirements-generator
• 绝不编写 consistency-report.md

集成

Gate 2 → ns-sdd-analyze-consistency → [Approved] → ns-sdd-task-generator
                            → [Reproved] → stop; fix requirements

实施后：ns-code-reviewer 会验证需求与代码——这是互补流程，不能替代本步骤。