# 撤回后重新投递：后端与前端联调约定

范围：仅后端重投规则、兼容字段和关联权限；不调整已拒绝后的重投政策，不修改前端，不删除历史数据。测试结果以本批最终验收记录为准；本说明不代表已经上线。

## 1. 重投规则

| 当前情况 | POST /applications |
| --- | --- |
| 没有投递历史 | 创建首轮，SUBMITTED |
| 同岗位所有历史申请均为 WITHDRAWN | 创建新 id、新轮次，SUBMITTED |
| 存在 SUBMITTED/VIEWED/INTERVIEW | 拒绝重复投递 |
| 存在 REJECTED/HIRED | 仍拒绝，本批不放开 |
| 岗位不是 PUBLISHED | 不允许投递，包括撤回后重投 |

撤回仍只允许 SUBMITTED/VIEWED，不放开面试中撤回。旧记录不恢复为 SUBMITTED；每轮有独立时间线，旧匹配、面试、Offer 及简历卡片继续关联旧 id。

V58 新增 attempt_number、previous_application_id 和按状态生成的 active_application_key。旧记录轮次为 1；仅 WITHDRAWN 的占位键为 NULL。数据库同时限制“同岗位同求职者同轮次唯一”和“同岗位同求职者非撤回申请唯一”。投递事务锁定岗位，检查其发布状态、占位及上一轮，防止并发重投。岗位级锁会串行处理同岗位投递，是本批明确的正确性取舍。

## 2. 接口字段与错误码

继续调用 `POST /api/v1/applications`，请求不变：

```json
{"jobId":123}
```

重投成功仍返回 HTTP 200，新响应 `data` 示例（其他既有字段保留）：

```json
{"id":456,"jobId":123,"status":"SUBMITTED","attemptNumber":2,"previousApplicationId":321}
```

- `id`：本轮投递 ID。后续评分、企业处理、面试、Offer、会话解锁及简历卡片操作必须使用对应轮次的 ID。
- `attemptNumber`：从 1 开始；用于区分同岗位不同轮次，不代表新的投递状态。
- `previousApplicationId`：直接上一轮 id；首轮为 null，受全局非空序列化影响也可能省略。
- 上述字段下发于本人投递列表/详情、企业投递列表、企业候选人列表/详情。候选人 DTO 不新增手机号、用户 ID、简历存储引用等敏感字段。
- 重复投递沿用 HTTP 409 / `code=8001`，岗位不可投递沿用 HTTP 404 / `code=7001`。不要把所有非 200 都显示为“网络错误”。
- `code=8003`：撤回/状态流转不允许；`8304`：指定轮次未匹配；`8303`：企业与求职者当前没有有效匹配，不能建立/恢复发送。

前端撤回后将该轮显示为“已撤回”，在岗位仍可投递时展示“重新投递”。成功后使用服务端返回的新 id 刷新列表，不覆盖旧记录。防连点只用于体验，后端仍负责并发约束；请求超时后先刷新投递记录，不能擅自推断成功。

同岗位多轮全部保留在列表；判断最新轮次用该岗位的最大 attemptNumber，不依赖秒级 createdAt 相同情况下的数组顺序。

## 3. 旧会话与简历权限

- 新一轮不复制旧匹配分、阈值快照或匹配结果。旧 id 即使保留 MATCHED 历史记录，只要投递已撤回，不能通过该 id 解锁会话。
- 历史 DIRECT 会话可阅读。对有撤回历史的企业/求职者组合，发送消息和通过通用接口获取旧会话，必须存在双方当前有效 MATCHED 申请。重新匹配后可以复用原会话，不复制历史消息。
- 沟通解锁仍采用既有“企业—求职者关系”口径：若双方另一个岗位存在有效匹配，可以继续沟通；不能把它描述为每个岗位拥有完全独立的聊天权限。
- 聊天简历快照继续绑定原 applicationId，撤回后不能因新一轮匹配而恢复旧卡片授权；已显式撤销的卡片不复活。
- 本批不引入“投递时固化简历”新机制。企业当前简历下载仍读取求职者当前资料，并依据指定 applicationId、企业归属与隐私策略授权；主动发送卡片时才保存不可变快照。
- PRIVATE 为动态限制；VERIFIED_COMPANIES 等既有显式隐私授权语义不在本批调整。不可将用户面向认证企业的全局授权误称为旧轮次权限恢复。
- 面试和 Offer 不迁移到新 id，不恢复旧流程。

## 4. 前端联调验收步骤

1. 使用合成账号和已发布岗位首次投递，记录 id、轮次及列表状态。
2. 企业查看后，求职者撤回，确认旧时间线仍在。
3. 同一岗位重投，确认返回新 id、轮次加一、previousApplicationId 指向旧 id，企业收到新的待处理申请。
4. 连续点击/并发请求，确认最多一条有效申请，其余返回重复投递错误。
5. 对进行中、已拒绝、已录用和关闭岗位分别验证禁止重投。
6. 旧轮次匹配不能解锁新轮次；历史聊天可读，新轮次重新满足匹配后才按关系级规则发送。
7. 用真实结构的合成 PDF 验证旧卡片仍拒绝、新卡片绑定新轮次；更换源简历不能篡改旧快照。
8. 重启隔离 JAR 后核对两轮记录、时间线和授权行为。

发布前还需：真实 MySQL 5.7/8 迁移、专项回归、最新 JAR 黑盒与后续全量验证。前端接入与提交/推送/发布均另行安排。

本批本地验证记录（2026-10-20）：专项 Maven 测试合计 129 项，0 失败/错误/跳过；新 JAR 黑盒 61 项及重启复验 7 项通过；静态与运行时契约专项 12 项通过。已覆盖真实 MySQL 5.7/8 的 V57→V58 升级及 MySQL 并发。证据与制品在 `D:\Workspaces\qsp-reapply-20261020`。本批完整 `mvn verify` 尚未执行；上述结果不代表线上已经更新。