# Quickstart: REV-005 发票业务流计划评审与最小校验

## 1. 评审入口

本轮目标是：
- 明确 REV-005 一期发票业务流范围与老系统对齐口径
- 形成 backend 可实施的接口、数据模型与查询兜底方案
- 为后续 `/speckit.tasks` 与 `/speckit.implement` 提供直接输入

本轮验收重点检查：
- 范围与老系统操作手册是否一致
- 发票申请 / 查询兜底 / 结果回写 / 客户侧消费口径是否闭环
- planning 产物是否可直接拆解为 backend 开发任务

## 2. 评审步骤

### 步骤一：范围校验
确认一期只覆盖以下核心能力：
- 后台发票申请
- 后台单笔 / 批量开票
- `SYS-008` 异步协同与查询兜底
- 发票结果回写与账单关联
- 客户侧查看 / 下载 / 推送已开票电子发票

同时确认以下内容未被带入：
- 客户侧直接申请开票
- 原始单账单任意部分金额开票
- 复杂拆分合并开票策略一次性做深
- 与税务局直接对接的细节实现

### 步骤二：老系统对齐校验
对照以下来源：
- `营收系统_用户操作手册.md`
- `福建水投微网厅操作手册.md`
- `营收数据字典.md`

确认 planning 已吸收以下能力语义：
- 发票查询
- 发票开具
- 批量开票
- 电子发票查看/下载/推送
- 拆账/分账后分别开票

### 步骤三：单一真源校验
对照以下正式口径：
- `spec.md`
- `12_REV_Detailed.md`
- `03_Interface_Design.md`
- `01_Database_Design.md`
- `.specify/memory/constitution.md`

确认 planning 没有让 Archive 直接替代正式设计结论。

### 步骤四：查询兜底校验
确认以下口径已统一：
- 提交申请后先生成申请单号 / 外部受理号
- 通过查询接口轮询获取开票结果
- 幂等回写以申请单号和状态为主键
- 已成功状态不得被后续失败结果覆盖

### 步骤五：backend 现状核对
确认当前 backend 发票模块仍主要是配置 CRUD：
- `InvoiceController.java`
- `InvoiceServiceImpl.java`

并确认后续 implement 需要新增：
- 申请接口
- 查询接口
- 结果回写/补偿查询逻辑
- 账单/客户开票信息/税率校验联动

### 步骤六：正式文档修订闭环校验
后续进入正式主文档修订时，统一按以下顺序执行：
1. 先更新 `12_REV_Detailed.md` 的业务规则与状态机。
2. 再更新 `03_Interface_Design.md` 的接口合同与时序。
3. 再更新 `01_Database_Design.md` 的承接口径与关系快照说明。
4. 每修改 1 份目标文档，执行对应 `make validate-file FILE=<目标文件>`。
5. 涉及跨文档引用变更时执行 `make check-links`。
6. 涉及图表或时序图时执行 `make validate-mermaid`。

## 3. 最小校验命令

```bash
make validate-file FILE=docs/design/02_Detailed_Design/12_REV_Detailed.md
make validate-file FILE=docs/design/03_Technical_Design/03_Interface_Design.md
make validate-file FILE=docs/design/03_Technical_Design/01_Database_Design.md
make check-links
make validate-mermaid
```

说明：
- 当前 plan 阶段以正式文档门禁为主，不强制执行 backend 构建或测试。
- backend 相关验证将在 `/speckit.implement` 阶段展开。

## 4. backend 实施前建议核对点

在进入 implement 之前，至少补充核对以下对象：
- 账单对象：`biz_charge*`
- 发票主对象：`biz_invoice`
- 客户开票信息：`biz_cust_invoice`
- 税率配置：`biz_invoice_taxrate`
- 操作留痕：`biz_operat_log*`
- 现有发票 Controller / Service / Mapper / DO / ReqVO / RespVO

## 5. 通过标准

满足以下条件即可进入下一批 tasks 拆解：
- 一期范围、老系统对齐边界、查询兜底策略已明确
- 接口合同和数据模型能直接支撑 backend 任务拆解
- 最小校验动作已明确并可执行
- 后续正式文档修订与 backend 实施边界已分清