feat(GOV-002): 增加 PRD 与开发审查门禁

docs/governance/code-development-standards.md

@@ -113,3 +113,16 @@ count += 1;
 - AI 密钥、数据源凭证和支付凭证仅存在服务端密钥管理中。
 - SQL必须参数化；外部输入必须在边界处校验。
 - 日志和异常报告必须脱敏。
+
+## 12. 代码 Review 要求
+
+开发者完成自测不等于 Review 完成。审查者必须从功能 PRD、设计和 Git diff 出发，检查：
+
+- 业务行为是否真正满足验收标准，是否存在遗漏分支。
+- 类型、数据口径、缓存、消息、事务和异常恢复是否正确。
+- 是否引入安全、性能、并发、幂等或数据一致性风险。
+- 测试是否能捕获真实回归，而非只验证 Mock 或实现细节。
+- 中文注释是否解释关键原因、口径和限制，是否存在失真注释。
+- 文件拆分是否便于常规阅读，是否出现过度抽象或巨型多职责文件。
+
+Critical 和 Important 问题必须修复并复审。Minor 问题可以延期，但必须写明理由和后续功能编号。

docs/governance/development-workflow.md

@@ -7,7 +7,7 @@
 ## 2. 功能状态
 
 ```text
-proposed → designing → approved → developing → verifying → released
+proposed → prd_review → designing → approved → developing → verifying → reviewing → released
                                       ↘ blocked
 released → superseded
 ```
@@ -18,18 +18,19 @@ released → superseded
 
 1. 分配功能编号和英文短名称。
 2. 建立 `docs/features/<编号>-<短名称>/`。
-3. 填写需求、范围、非目标和验收标准。
-4. 比较可选方案，记录设计与关键决策。
-5. 更新 API、事件和数据结构契约。
-6. 编写测试计划和实施计划。
-7. 确保 Git 工作区基线可识别，执行：
+3. 编写 `prd.md`，明确用户问题、目标、范围、非目标、用户流程、指标、风险和验收标准。
+4. PRD 审核通过后，将产品需求转换为可测试的工程需求。
+5. 比较可选方案，记录设计与关键决策。
+6. 更新 API、事件和数据结构契约。
+7. 编写测试计划和实施计划。
+8. 确保 Git 工作区基线可识别，执行：
 
 ```bash
 npm run governance:start -- FEAT-MO-001 market-overview
 ```
 
-8. 运行 GitNexus 查询、上下文和影响分析，将结果写入 `gitnexus/impact-plan.md`。
-9. 高风险或关键路径变化必须先向用户说明影响，再进入开发。
+9. 运行 GitNexus 查询、上下文和影响分析，将结果写入 `gitnexus/impact-plan.md`。
+10. 高风险或关键路径变化必须先向用户说明影响，再进入开发。
 
 开发前必须至少回答：修改什么、为什么修改、影响谁、如何验证、失败后如何回退。
 
@@ -54,9 +55,12 @@ npm run governance:finish -- FEAT-MO-001 market-overview
 ```
 
 6. 填写 `gitnexus/after.md`、`detected-changes.md` 和 `comparison.md`。
-7. 更新发布说明、回退说明、变更记录和版本号。
-8. 使用中文 Conventional Commit提交。
-9. 提交后执行 `npx gitnexus status`；若状态过期，再运行 `npx gitnexus analyze`。
+7. 执行代码 Review，将问题、严重程度、修复提交和复审结论写入 `review/code-review.md`。
+8. 逐条执行开发规范符合性 Review，将结果写入 `review/standards-review.md`。
+9. 任一 Review 为 `changes_required` 时，返回开发阶段；修复后重跑相关测试、GitNexus开发后分析和 Review。
+10. 两项 Review 均为 `passed` 后，更新发布说明、回退说明、变更记录和版本号。
+11. 使用中文 Conventional Commit提交。
+12. 提交后执行 `npx gitnexus status`；若状态过期，再运行 `npx gitnexus analyze`。
 
 ## 6. 完成定义
 
@@ -68,6 +72,8 @@ npm run governance:finish -- FEAT-MO-001 market-overview
 - 测试和构建有最新成功证据。
 - 视觉变化有同视口对比证据。
 - GitNexus 开发前后报告和差异说明齐全。
+- 代码 Review 结论为 `passed`，Critical 和 Important 问题已关闭。
+- 开发规范符合性 Review 结论为 `passed`。
 - 发布说明和回退方法可执行。
 - 中文提交已关联功能编号。
 

docs/governance/documentation-traceability.md

@@ -9,6 +9,7 @@
 ```text
 docs/features/<编号>-<短名称>/
 ├── manifest.yaml
+├── prd.md
 ├── requirements.md
 ├── design.md
 ├── implementation-plan.md
@@ -26,6 +27,9 @@ docs/features/<编号>-<短名称>/
 ├── qa/
 │   ├── test-results.md
 │   └── visual-qa.md
+├── review/
+│   ├── code-review.md
+│   └── standards-review.md
 ├── release-notes.md
 └── rollback.md
 ```
@@ -33,6 +37,8 @@ docs/features/<编号>-<短名称>/
 ## 3. 历史保留
 
 - 已发布文档不删除、不覆盖历史结论；修订通过 Git 历史和文档版本说明保留。
+- PRD 是产品目标和验收口径的正式来源；`requirements.md` 是从 PRD 派生的工程约束，二者不能相互替代。
+- Review 文件必须记录审查范围、基线提交、审查提交、发现、处置和最终结论，禁止只写“看过了”。
 - 重大方案变化新增 ADR，旧 ADR 标记被替代。
 - 规则、提示词、API 和事件契约使用明确版本。
 - 截图文件名包含页面、状态、视口和版本，例如 `market-overview-trading-1440x1200-v0.1.0.png`。

docs/governance/prd-standard.md

@@ -0,0 +1,34 @@
+# PRD 编写规范
+
+## 1. 定位
+
+PRD 是每个业务功能的产品需求事实来源，回答“为谁解决什么问题、为什么做、做到什么程度算完成”。技术设计回答“如何实现”，不能替代 PRD。
+
+治理、重构和纯技术任务也需要简化 PRD，用于说明使用者、治理问题、目标和完成标准。
+
+## 2. 必备章节
+
+每份 `prd.md` 至少包含：
+
+1. 文档信息：功能编号、版本、状态、作者、日期。
+2. 背景与问题：当前状态、具体问题和证据。
+3. 目标用户与场景：谁在什么时点使用。
+4. 产品目标：用户能够完成什么，产品改善什么。
+5. 非目标：本期明确不解决什么。
+6. 用户流程：入口、关键步骤、结果和异常路径。
+7. 功能需求：编号、优先级、行为与可观察结果。
+8. 数据与口径：来源、时效、单位、缺失和过期处理。
+9. 状态与异常：加载、空、部分数据、错误和降级。
+10. 权限与合规：访问边界、隐私、声明和安全限制。
+11. 成功指标：可以观测和验证的产品指标。
+12. 验收标准：使用 Given/When/Then 或等价可测试描述。
+13. 风险与依赖：外部数据、技术、成本和上线依赖。
+14. 发布范围：本次、后续和回退触发条件。
+
+## 3. 编写规则
+
+- 需求使用 `FR-001` 等稳定编号，测试和 Review引用该编号。
+- 禁止用“体验更好”“速度较快”等不可验证表达。
+- UI 布局不是需求本身；应先写用户需要识别和完成的行为。
+- PRD 发生实质变化时更新版本和变更记录，并重新确认设计与测试影响。
+- 已发布 PRD 不删除旧结论，废弃需求标记 `superseded` 并说明替代项。

docs/governance/review-standard.md

@@ -0,0 +1,37 @@
+# Review 审查规范
+
+## 1. 两类 Review
+
+### 代码 Review
+
+以 PRD、设计、实施计划、Git diff和测试证据为输入，审查正确性、安全性、性能、数据一致性、契约兼容性和测试充分性。
+
+### 开发规范符合性 Review
+
+逐条检查代码开发规范和流程规范，包括中文注释、命名、文件拆分尺度、日志、错误处理、GitNexus前后门禁、中文提交、文档和回退材料。
+
+## 2. 审查角色
+
+- 优先由非实现者进行独立 Review。
+- 个人项目没有独立审查者时，可以执行结构化自审，但必须在报告中标明 `reviewer_type: self`，不得伪称独立审查。
+- 使用代理审查时，必须提供功能说明、PRD、设计、基线 SHA 和当前 SHA；只有用户明确授权多代理时才调用独立审查代理。
+
+## 3. 严重程度
+
+- Critical：可能导致数据错误、安全事故、核心功能不可用或不可恢复，必须修复。
+- Important：会造成明显错误、回归、规范失效或重要测试缺口，必须修复。
+- Minor：不阻塞当前功能，但应记录后续处理或接受理由。
+
+## 4. 结论
+
+Review 只能使用：
+
+- `passed`：没有未解决的 Critical 或 Important，证据齐全。
+- `changes_required`：存在必须修改的问题。
+- `blocked`：缺少 PRD、代码、测试、环境或其他必要证据。
+
+修复 Review 问题后必须记录修复提交和复审结论。代码变化会使旧的 GitNexus开发后报告失效时，必须重新更新图谱和影响报告。
+
+## 5. 发布门禁
+
+`review/code-review.md` 和 `review/standards-review.md` 均存在、非空且最终结论为 `passed` 后，功能才允许进入发布状态。