# PROGRESS · 校正提议在开案成功后才标已开始（BUG-1306 F3，2026-10-12）

分支 `codex/rectification-offer-opened-state-20261012`，基线 `b8bdc003`（`origin/staging`）。未 push，未部署。状态保持 fixed-pending-verify，不是 resolved。

## 结论

明确要求做校正时，结算记下的提议仍是普通提议：状态 `offered`，并带 `autoOpen: true`。卡片写价格和题数，按钮是「开始核对出生时间」，不说「已经开始」。浏览器仍按 `rectificationDirectOpen` 自动开案。只有开案成功、`bindOfferToCase` 绑定来源之后，状态才变成 `opened`，卡片才说「已经开始」。打开失败时记录保持 `offered`，卡片可以再点。没有第四种状态。已存的 `offered` / `opened` / `returned` 照常解析。`complete_consultation_free` 和五句用户文案没改。

## 实现

`finishExplicitRectificationRequest` 不再把结算记录写成 `opened`。`autoOpen` 是可选字段，只在为真时写入；旧记录省略它也能解析。刷新走 `parseRectificationOfferRecord`，不会丢掉这个字段。`persistOpenedDirectOffer` 仍把这条还没打开的记录挂到免费回复上。客户端新开仍调用 `openRectificationFromChat`，接着做仍调用 `openRectificationSession`。开案函数失败时返回空，调用处不把本地记录改成 `opened`。成功仍由原来的绑定路径改状态。

## 既有断言

| 原值 | 新值 | 原因 |
| --- | --- | --- |
| `rectification-explicit-entry-20261012.test.ts`「explicit pass…」两处 `deepEqual` 期望 `offer("opened")` | `offer("offered", { autoOpen: true })` | F3：结算保持 offered，用 autoOpen 表示这一轮要自动开案；开案绑定后才是 opened |
| 同文件「explicitRequest bypasses…」`rectificationOffer.status` 期望 `"opened"` | `"offered"`，且 `autoOpen === true` | 同上。直达入口 `kind: "new"` 不变 |
| 同文件直达流「run.completed」`rectificationOffer.status` 期望 `"opened"` | `"offered"`，且 `autoOpen === true`；`rectificationDirectOpen.mode` 仍是 `"new"` | 完成事件转发的是结算记录，不能再预写 opened |
| 同文件两处流式夹具把 `state.rectificationOffer` 设成 `offer("opened")` | `offer("offered", { autoOpen: true })` | 夹具要模拟现在的结算记录，否则事件仍像开案前就已经 opened |

`rectification-in-chat-20261007.test.ts` 里原来的期望值没有改。普通提议仍是没有 `autoOpen` 的 `offered`。无 caseId 的旧 `opened` 记录仍能绑定。

## 验证

| 命令 | 结果 |
| --- | --- |
| `npx tsx --test tests/rectification-explicit-entry-20261012.test.ts` | 16 通过，0 失败，cancelled 0 |
| `npx tsx --test tests/rectification-in-chat-20261007.test.ts` | 15 通过，0 失败，cancelled 0 |
| `npx tsc --noEmit`（frontend） | 0 错 |

没有跑 `next build`（Turbopack 拒绝 `node_modules` junction）。没有跑全量 `npm test`。没有 `npm install`，没有删 junction。`Home()` 没有改，`page.tsx` 没有改。