【PRD 合理性审核 — 本 PR 改动了 PRD，额外做这段审核】

本 PR 涉及以下 PRD 文档变更：
__PRD_FILES__

请在常规代码 review 之外，**额外评估这些 PRD 的"合理性"**（能否支撑后续实现），但严格遵守下面的噪音控制规则。

## 严重度阈值（最关键 — 不遵守等于这段审核失败）

只允许两档：

- **hard_block（P0）**：PRD 缺失契约面定义，直接阻断后续模块文档撰写或编码。判定锚点：
  - 业务边界（in/out scope）缺失或自相矛盾 → 实现者不知道做什么 / 不做什么
  - 关键状态机断裂、状态枚举与转换图不闭合
  - PRD 承诺的字段 / 角色 / 权限点与同模块已有 `06-data-model.md` / `07-api.md` / 全局角色定义冲突
  - 涉及长事务 / 外部依赖 / 异步流程时**完全没提**失败恢复

- **risk（P1）**：高风险维度空白，不阻断合并但作者必须显式响应：
  - 外部依赖未澄清返回格式 / 限流 / 脱敏 / 延迟
  - 测试覆盖章节只列 happy path，无 failure / 边界 / 并发
  - 数据迁移仅写"需迁移"未给迁移策略 / 回滚预案
  - 权限模型与现有角色（itadmin / dept-admin / region-admin 等）有潜在冲突但 PRD 未点明

## 绝对不要报告（直接 drop，静默处理）

下面这些即使发现也**不要**列为 finding：

- 文档卫生：链接 / frontmatter / 术语统一 / 措辞优化 / 章节顺序 / markdown 格式
- 可选维度且场景不敏感：性能未提（非热路径）、i18n 未提（仅内部工具）、监控未提（非长跑服务）
- "建议补充 X" 类锦上添花、风格偏好
- PRD 已显式 ack 的占位（如 "待 UI 阶段细化" / "Phase 2 再补"）
- doc-review / plan-review skill 覆盖的维度（实现就绪度细节 / 代码架构 / 回滚预案）— 那些阶段会单独审

## 审核优先级（按这个顺序找，找够就停）

1. 业务边界与 scope
2. 角色权限与现有角色冲突
3. 状态机闭合性
4. 数据模型与同模块文档一致性
5. API 契约（PRD 承诺字段 vs 07-api.md）
6. 失败恢复（仅涉及长事务 / 外部依赖时才查）
7. 外部依赖澄清度（仅涉及第三方时才查）
8. 测试覆盖维度齐不齐
9. 跨文档承诺一致性（PRD ↔ data-model / API / UI）

## 输出方式（强约束）

1. **额外增加一个 dimension**（追加在常规 7 个核心维度之后）：
   - `name`：`PRD 合理性`
   - `status`：有任何 hard_block → `block`；仅有 risk → `warn`；都没有 → `ok`
   - `note`：≤ 200 字，给作者一句最关键的话（哪个维度 / 哪条最该响应）

2. **PRD findings 上限**：findings 数组里 `category = "prd-rationale"` 的最多 **5 条**。
   - `severity` 只允许 `hard_block` 或 `risk`，**禁止 `suggestion`**
   - `message` 必须明确：①引用 PRD 哪一节/小节（例 "§3.2 状态机"）②为何是 P0/P1（一句话）③建议修复方向（一句话）
   - `file` 指向具体 PRD 路径（如 `docs/modules/xxx/01-prd.md`），尽量给 `line` 行号
   - `stable_id` 命名 `prd-<维度短词>-<问题短词>`，例：`prd-state-machine-missing-rollback`

3. **PRD 改动很小时不要硬挑**：若本 PR 中 PRD diff < 30 行且未触碰契约面段落（边界 / 角色 / 状态机 / 数据模型 / API） → `PRD 合理性` dimension 直接给 `ok`、note 写 "PRD 改动为非契约面微调"、不增加 prd-rationale finding。