# 项目管理列表重新分析后端验证记录

## 验证范围

- 手动重打标接口可直接复用于列表页
- 重打标开始后项目进入打标中
- 重打标成功后自动重算项目风险人数
- 运行中任务和归档项目保留既有后端保护

## 链路核验

- `POST /ccdi/project/tags/rebuild` 由 `CcdiBankTagController.rebuild(...)` 提供入口，并透传 `projectId`、`modelCode` 与操作人
- `CcdiBankTagServiceImpl.submitRebuild(...)` 继续复用 `ProjectBankTagRebuildCoordinator.submitManual(...)`
- `CcdiBankTagServiceImpl.rebuildProject(...)` 开始时调用 `projectService.updateProjectStatus(projectId, CcdiProjectStatusConstants.TAGGING, operator)`，满足“打标中”状态切换要求
- `CcdiBankTagServiceImpl.rebuildProject(...)` 成功路径会调用 `projectOverviewService.refreshOverviewEmployeeResults(projectId, operator)`
- `CcdiProjectOverviewServiceImpl.refreshOverviewEmployeeResults(...)` 会在重建员工结果后同步调用 `projectMapper.updateRiskCountsByProjectId(...)`，刷新高/中/低风险人数

## 验证命令

```bash
mvn -pl ccdi-project -Dtest=CcdiBankTagControllerTest,ProjectBankTagRebuildCoordinatorTest,CcdiBankTagServiceRiskCountRefreshTest test
```

## 验证结果

- 结果：通过
- `CcdiBankTagControllerTest` 通过 2 个用例，覆盖手动重打标控制器入口
- `ProjectBankTagRebuildCoordinatorTest` 通过 6 个用例，覆盖运行中防重提交流程、补跑标记与归档保护
- `CcdiBankTagServiceRiskCountRefreshTest` 通过 2 个用例，覆盖成功后刷新员工结果与刷新失败时任务转失败分支
- 总计 10 个用例全部通过，Surefire 结果为 `BUILD SUCCESS`
- 测试日志中的 `refresh failed` 为失败分支测试主动构造的预期异常，不影响最终通过结论

## 关键结论

- 项目列表“重新分析”后端无需新增接口，直接复用现有 `POST /ccdi/project/tags/rebuild`
- 现有链路已覆盖“重新打标并重新计算人数”的后端要求，不需要新增服务分支或补充额外人数重算调用
- 手动重打标开始后会先切换项目状态为 `TAGGING`
- 重打标成功后会同步刷新员工风险结果，并回写项目高/中/低风险人数
- 运行中任务重复提交与不可启动项目的保护逻辑已存在，可继续沿用