analyze-consistency

分析一致性

执行前验证：计划与计划之间的验证，先于编码。

发现 Harness

参阅 ../nextstage-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 — 运行检查

将每项分类为 ✅ 正常 | ⚠️ 警告 | ❌ 阻断项：

功能完整性

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

测试覆盖

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

数据模型

检查	失败级别
有明确的“数据模型和 API”部分	❌ 阻断项
功能中涉及的所有实体都列在数据模型中	❌ 阻断项
遵守外键创建顺序	❌ 阻断项
声明供前端使用的 API 端点	❌ 阻断项

一致性

检查	失败级别
功能支持既定目标	⚠️ 警告
存在范围外功能	⚠️ 警告

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

步骤 3 — 报告

保存到 {product_root}/docs/versions/{version_san}/consistency-report.md：

# Consistency Report — {version_san}

**Date:** {date}
**Analyzed:** `{path}`

## Overall result

✅ 100% approved | ⚠️ Approved with reservations | ❌ Requires correction

## Blockers (❌)

...

## Warnings (⚠️)

...

## Passed (✅)

Count and summary

## Recommendations

Optional improvements

步骤 4 — 决策是否继续

• ❌ 存在阻断项： 停止 — 要求用户修复需求，然后重新运行
• ⚠️ 仅有警告： 询问是现在修复还是继续；由用户决定
• 100% ✅： 告知将自动继续生成任务；execution_confirmed 默认为已确认（跳过 Gate 3）

关键规则

• 不要编辑 requirements.md — 仅报告问题
• 未修复或未获得明确豁免的阻断项会阻止生成任务
• 如果缺少需求 → 转回 Gate 1 / requirements-generator

集成

Gate 2 → analyze-consistency → [100%] → task-generator
                            → [blockers] → fix requirements

实现后：code-reviewer 会验证需求与代码的一致性 — 与此流程互补，而非替代。