fix(consult): mark rectification opened only after the case opens (BUG-1306)
This commit is contained in:
jesse-ux
+4
-3
@@ -17538,7 +17538,7 @@
|
||||
|
||||
## BUG-1306 | 对话里明说「帮我做生时纠正」进不了校正：模型不出提议卡，反而在普通对话里自己「收窄出生时间」
|
||||
|
||||
- 状态：fixed-pending-verify（已部署 staging；T0 无主机日志、T5 无模型凭据，真机清单 `docs/testing/rectification-explicit-entry-20261012.md` 未走前不标 resolved）
|
||||
- 状态：fixed-pending-verify（直达已部署 staging；F3 跟进随 10-12 批次合入 staging；T0 无主机日志、T5 无模型凭据，真机清单 `docs/testing/rectification-explicit-entry-20261012.md` 未走前不标 resolved）
|
||||
- 首次发现 / 最近更新：2026-10-11 / 2026-10-12
|
||||
- 来源：产品在 staging（`de4cfeb8`）新对话第一句输入「请你帮我进行生时纠正」，回复截图转述。
|
||||
- 现象：回复显示「已完成 3 步」，正文说「收窄出生时间这件事能做」，要用户报有年月的经历，「对得上，区间就能往里收」；全文没有提到提议卡，界面上也没有卡片。正文还按「代表分钟」写出大运 / 子运起止年月。
|
||||
@@ -17551,11 +17551,12 @@
|
||||
- 推断（未证实）：正文主动承诺能收窄，不像收到「不要提校正」的拒绝，更像模型没有调用提议工具；无模型凭据、无 staging 运行日志，暂未取证。另：用户若照做在普通对话里报经历，这些经历不会进入校正引擎计分，正文「区间就能往里收」是做不到的承诺；按代表分钟写大运起止，与申报时段指令「精确应期一律不可用」不符。
|
||||
- 待做：取该轮观测记录确认是否调用了工具及服务端结果（任务书 T0；观测只打到 web 容器控制台，需 staging 主机日志）。本轮没有主机和数据库，查法见进度记录，不阻塞修复。
|
||||
- 修复：不新建工具。`offer-birth-time-rectification` 增加 `explicitRequest`。这一轮明确要校正由模型填写；`userAsked` 仍是「提议过之后用户自己再要求才出卡」。服务端判定仍是 `decideRectificationOffer`（本人、开关、无进行中 case、有价）。通过则记下与提议卡同结构、状态直接为 `opened`、尚无 caseId 的记录，`run.completed` 带 `rectificationDirectOpen`，浏览器调用已有的 `openRectificationFromChat`。同一轮已有直达或已有提议时不再开第二次。`bindOfferToCase` 也会绑定这种还没有 caseId 的 `opened` 记录，刷新后按 caseId 找回。进行中的 case 不新开：查到 `agentic_rectification_cases.session_id` 就打开那次，查不到就说可以在历史对话里接着做。`product_disabled` 与 `pricing_unavailable` 对用户是同一句「出生时间核对这会儿还做不了。」家人仍是「给家人校正暂时还不支持」。四种拒绝说明都不再写「不要提校正」。没有明确要求时的拒绝仍走原来的排盘回答。直达和明确拒绝把首轮合同视为就绪，不跑「运行合同不完整」重试、不跑空答重试、不跑 Pass4，已流出的正文换成那一句。这一轮结算走 `complete_consultation_free`，不走 `complete_consultation_response`；新开时再把提议补到会话消息上，不改请求行。规则仍只定义在 `RECTIFICATION_OFFER_RULE`：不承诺收窄出生时间，不在对话里收集经历做校正。申报时段指令补「大运、子运只说在哪一段附近，不写起止年月日」。不改校正引擎、打分、闸门和数据库。
|
||||
- 跟进（F3，2026-10-12）：结算不再把记录写成 `opened`。直达通过仍记同结构提议，状态保持 `offered`，只在要自动开案时带 `autoOpen: true`（省略该字段的旧记录照常解析）。卡片在开案并绑定来源之前是普通提议：价格句和「开始核对出生时间」，不说「已经开始」。浏览器仍按 `rectificationDirectOpen` 自动开案，成功路径不用点。只有 `bindOfferToCase` 在开案成功、来源绑定后把状态改成 `opened`。打开失败不把本地记录改成 `opened`，卡片可再点。不新增第四种状态。`complete_consultation_free` 与五句用户文案未改。
|
||||
- 验证：`npx tsc --noEmit` 0 错。`npm run lint` 0 error（125 条既有 warning）。定向 `rectification-explicit-entry-20261012` 与 `rectification-in-chat-20261007` 26 通过。合同套件 236 条里 235 通过；唯一失败是 Skill 符号链接 EPERM。`CI=1 npm test` 4922 条，通过 4780，失败 101，cancelled 0；失败在本轮没改的文件（无 Docker、符号链接、WSL、路径拼接、junction 下的依赖解析）。telemetry 合同按直达结算改了一条断言，改完 4 条通过。默认 `next build` 因 worktree `node_modules` junction 被 Turbopack 拒绝；`npm run build -- --webpack` 编译与 TypeScript 已过，收集 page data 时 Skill 符号链接 EPERM，没有路由表，`/` Static 与首屏 gzip 未测。T5 未跑模型。
|
||||
- 防复发：`frontend/tests/rectification-explicit-entry-20261012.test.ts` 锁住直达、同一轮不重复开案、无 caseId 的 opened 绑定与找回、四种拒绝说明、两条路径不重试、普通咨询仍重试一次、规则只定义一处、申报时段「在哪一段附近」、结算调用 `complete_consultation_free`。用户可见句长度 ≤20。真机清单 `docs/testing/rectification-explicit-entry-20261012.md`。
|
||||
- 防复发：`frontend/tests/rectification-explicit-entry-20261012.test.ts` 锁住直达、同一轮不重复开案、无 caseId 的 opened 绑定与找回、四种拒绝说明、两条路径不重试、普通咨询仍重试一次、规则只定义一处、申报时段「在哪一段附近」、结算调用 `complete_consultation_free`。F3 另锁：结算记录是 `offered` 且 `autoOpen: true`、卡片在绑定前不说「已经开始」、绑定后才说已经开始、打开失败仍是 `offered`、旧的 `offered` / `opened` / `returned` 照常解析且 `returned` 不出卡。用户可见句长度 ≤20。真机清单 `docs/testing/rectification-explicit-entry-20261012.md`。
|
||||
- 相关记录：BUG-1247、BUG-1248（入口改为提议卡）、BUG-976/977（禁正则判意图）。
|
||||
- 复发自：无。
|
||||
- 修复版本：staging `b8bdc003`（实现 `6a799582` 变基到 `9f1e8257`，代码逐字节相同；2026-10-12 Claude 验收通过、产品要求合入；部署核对：health gitCommit=b8bdc003、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401）。跟进项 F3（打开失败卡片仍说已开始）见 `TASK-rectification-1012-batch-fix-20261012`。
|
||||
- 修复版本：staging `b8bdc003`（实现 `6a799582` 变基到 `9f1e8257`，代码逐字节相同；2026-10-12 Claude 验收通过、产品要求合入；部署核对：health gitCommit=b8bdc003、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401）。跟进项 F3（打开失败卡片仍说已开始）见 `TASK-rectification-1012-batch-fix-20261012`。 F3 跟进（`51a77721`）随 10-12 批次合入 staging，部署核对见 BUG-1307。
|
||||
- 决策日志（2026-10-12，产品）：选 A——用户明确要求做生时校正时直接进入校正，不先写解读、不用点卡；意图由模型判断，禁正则 / 关键词。**推翻 BUG-1248 两处**：①明确要求的这一轮不再「只出卡、点卡才进」；②`product_disabled`、`pricing_unavailable`「正文不要提校正」改为必须一句话说明做不了，不得静默。普通对话模型不得承诺收窄出生时间、不得在对话里收集经历假装校正；申报时段下不得写大运 / 子运精确起止。服务端本人 / 开关 / 进行中 case / 价格判定不变。同日另立 BUG-1307（最近分界开场）、BUG-1308（父母静态题研究）。
|
||||
|
||||
## BUG-1307 | 生时校正开场不说记录时间离最近分界多近，首轮选题面向整个窗口，用户觉得步骤多、目的不明
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
# 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` 没有改。
|
||||
@@ -127,7 +127,7 @@
|
||||
| `TASK-rectification-explicit-entry-20261012.md` | `PROGRESS-rectification-explicit-entry-20261012.md` | **明说要校正就直接进入（BUG-1306）**：模型判断意图（禁正则），服务端判定后直接开案并绑定来源对话；首轮排盘合同对此轮豁免；拒绝必须一句话说明（推翻 BUG-1248 静默两条）；普通对话不得假装校正、申报时段不写子运起止。**先做** | 已部署 staging `b8bdc003`，真机欠 | — |
|
||||
| `TASK-rectification-nearest-boundary-opening-20261012.md` | — | **最近分界开场（BUG-1307）**：开场说记录时间离最近分盘换段点多近、两侧哪些层不同，近分界时首轮只问该分界；不改打分 / 闸门 / 4 件 3 域，77 例回放不降；改 page.tsx / 校正开场组件的部分须在 BUG-1306 合入后 | 待领取 | — |
|
||||
| `TASK-rectification-d12-parent-probes-research-20261012.md` | — | **父母静态是非题（D12）研究（BUG-1308）**：公开案例 ≥60、预登记、乱序与正对照，过门才立实现单；纯研究可并行 | 待领取 | — |
|
||||
| `TASK-rectification-1012-batch-fix-20261012.md` | — | **10-12 三单验收修复**：entry `6a799582` 通过（合入待产品）；boundary `b285011a` 未通过——F1 开场与段汇总岁差写死 Raman（BUG-1307 / 新 BUG-1309）、F2 本命上升换段不说；F3 打开失败卡片仍说已开始（BUG-1306 跟进）；F4 研究报告补编码问题与暂停结论（BUG-1308） | 待领取 | — |
|
||||
| `TASK-rectification-1012-batch-fix-20261012.md` | `PROGRESS-rectification-offer-opened-state-20261012.md` | **10-12 三单验收修复**：entry `6a799582` 通过（合入待产品）；boundary `b285011a` 未通过——F1 开场与段汇总岁差写死 Raman（BUG-1307 / 新 BUG-1309）、F2 本命上升换段不说；F3 提议在开案成功后才标 opened（BUG-1306 跟进，本分支待验收）；F4 研究报告补编码问题与暂停结论（BUG-1308） | F3 待验收（`codex/rectification-offer-opened-state-20261012`）；F1/F2/F4 仍待领取 | — |
|
||||
|
||||
### 聊天主链路与首页
|
||||
|
||||
|
||||
Reference in New Issue
Block a user