Jyotisha/docs/tasks/TASK-rectification-open-collect-invite-20260914.md

TASK · 并列时不说「问完了」，改成请用户补一件带年月的经历 — 2026-09-14

• 基线：origin/staging @ a643452b（代码最新 963c147c，staging 已部署该 SHA）。
• 分支：codex/rectification-open-collect-invite-20260914，worktree .worktrees/rectification-open-collect-invite-20260914。
• 关联：BUG-687（引入「能问的都问完了」这句收口文案）、BUG-646/651/653（门关不出结果是禁止的、必须有出口）、BUG-590、BUG-688。研究背景见 docs/research/rectification_minute_resolution_closure_2026_09_14.md。
• 串行：改 user-copy.ts、collection-question-pool.ts 文案层与 rectification-range-delivery.tsx 卡片一处；与在途分支无重叠。

1. 问题

两轮离线研究（定论页见上）证明：候选并列靠调打分尺度拉不开，目前唯一被证明有效的信息源是用户再给一件带年月的经历。

但产品现在的表现正好相反：

• 定向补事只覆盖固定七条线（结婚 / 收入 / 搬家 / 家人 / 学业 / 健康 / 职业）。用户答「没有发生过」就关闭该线，七条关完后，rangeNarrowHint（collection-question-pool.ts:845-849）输出 「能问的都问完了」（RECTIFICATION_USER_COPY.rangeDeliveryCollectClosed，user-copy.ts:152，BUG-687 引入）。
• 这句是终局口吻。用户读完就走了，而他其实完全可能有第八类经历——换专业、出国、打官司、创业、重病、亲人离世、搬迁工作城市……系统从来没请他说过。
• 真机实证：用户对结婚 / 收入 / 家人三条都答「没有 / 跳过」，只答了搬家，随即出卡 26% / 26% / 20%，然后被告知"问完了"。

能力其实已经在了：交付后 case 状态是 candidate_ready，属于 RESUMABLE_CASE_STATUSES（v9/case-status.ts:26），输入框不禁用；此时用户补一件带年月的经历会进账本、触发重算、候选重新打分、范围可以再收窄。缺的只是邀请与保证。

2. 决策记录

决策	内容
D1	产品拍板（2026-09-14）：并列且固定七条线问完时，交付卡照出，但卡上把「能问的都问完了」换成明确邀请。 文案要点：①说清这两分钟按现有信息分不开；②请用户再说一件记得年月的事，不限领域；③给几个七条线之外的例子（换专业、出国、打官司、创业、重病、亲人离世）；④说明补完会接着算。措辞对照 frontend/docs/VOICE.md。
D1b	优先要「记得确切哪一天」的事。 邀请语先请用户说能说出具体日期的事（登记结婚那天、入职第一天、手术那天、孩子出生那天、拿到录取通知那天），再退而求其次要年月。原因：出生时间每差 1 分钟，Vimshottari 大运边界只平移约 1.1 天，而出题闸门按 45 天卡（scripts/rectification/event_probes.py:543）——只有日精度的事件才有可能分开相隔几分钟的候选。机制与测量见 TASK-rectification-precision-adaptive-boundary-research-20260914.md。 但不得承诺「说了确切日期就能定到分钟」：闸门能不能按精度放宽、放宽后收益多大，要等那份研究单的结果。本单只改邀请的优先级与措辞，不动闸门。
D2	不采用"并列时先不出卡、再要一轮经历"（评估时的方案 B）。理由：接近 BUG-646 明令禁止的「门关不出结果」；用户真没有可说的时候会多一道无效问答，并可能退回开放式追问的死角。交付卡必须照出，用户随时可以停。
D3	邀请不得退回列举已拒答的线（BUG-687 的修复保持有效）。邀请语是"不限领域 + 举例"，不是把结婚 / 收入 / 家人再问一遍。
D4	补完必须可见地生效。 用户在交付卡之后说出的带年月经历，必须进账本、重算、并在界面上有可见变化（范围卡更新，或给出新一轮题）。补了没反应属于缺陷——本单要有行为测试守住。
D5	不改判据、不改打分、不放宽置信度或确认门控；不新增卡片组件；Skill 版本按是否改用户可见话术决定是否 bump（改了就 bump 并在 CHANGELOG.md 写明）。

3. 硬红线

1. tsc --noEmit 0 错；npm run lint 0 error；npm test 失败数 = 基线 27 条；next build 通过且 / 仍 ○ Static；首屏 gzip ±2%。
2. 新增断言必须是行为断言。
3. 不得让邀请变成阻塞：交付卡、采用入口、"新建对话按此时间排盘"的出口都要照常可用。
4. 不得把邀请写成承诺（「再说一件就能定到分钟」这类）。实话是「能不能再收窄，取决于这件事落在哪段大运边界上」；日精度只是更有机会，不是保证。

4. 任务分解

任务 1 · 文案（P0）

• user-copy.ts:152 的 rangeDeliveryCollectClosed 改成邀请语（按 D1 四要点）；保留一个独立常量名以便测试与 VOICE 对照。
• collection-question-pool.ts:845-849 两处返回点同步；现在还剩 X–Y 里 N 个候选。 这半句保留。
• 验收标准：行为单测——七条线全部 declined 时，rangeNarrowHint 的输出不含「问完了」类终局措辞，包含"不限领域"的邀请与至少两个七条线之外的例子；且不含结婚 / 收入 / 添丁等已拒答线的字样（BUG-687 回归）。

任务 2 · 交付卡把邀请放在看得见的位置（P0）

• frontend/src/components/rectification-range-delivery.tsx：并列（前两名相对可能性差 ≤ 3 个百分点）且采集线已关闭时，邀请语要出现在卡片正文区，不能只躺在时间轴那行浅色小字里。
• 不新增组件、不新增第二套卡片路径（§6 红线）。
• 同一提交更新 frontend/DESIGN.md 的交付卡条目。
• 验收标准：行为单测/快照——该状态下卡片渲染包含邀请文本；非并列或采集线仍开放时不显示该邀请。

任务 3 · 补完必须生效（P0）

• 走查并用行为测试固定：交付卡之后用户输入一件带年月的经历 → 证据入账 → 重算 → 快照的 credible_range / 候选分数有变化，或给出新一轮题。
• 验收标准：行为单测（可用既有 fakeAccounting 套路）——交付态 + 新增一件 confirmed dated evidence → decideFromDossier 的结果不再是同一份快照（snapshotCurrent === false 或候选分数变化），且界面状态不停在 delivered。

任务 4 · 记录

• docs/BUG_HISTORY.md 新增 BUG-689（resolved）：现象写"七条线问完后只说『能问的都问完了』，用户不知道还能补经历，也不知道补了有用"；防复发条写明：采集线关闭不等于校正结束；交付卡必须给出不限领域的补充邀请，且补充必须可见地生效。
• CHANGELOG.md 一行；PROGRESS-rectification-open-collect-invite-20260914.md；docs/testing/ 清单：并列出卡后补一件带年月的经历 → 范围或排序应有可见变化。

4b. 后续联动（不在本单范围）

上游流程纪律 R3 要求「淘汰与定案只允许在合并 ≥3 个领域的账本上执行」，本仓现在是 MIN_ACCEPTANCE_EVENTS=3 / MIN_ACCEPTANCE_DOMAINS=2（scripts/rectification/decision_policy.py:34-35），比上游松一档。

产品负责人 2026-09-14 决定：先不动，等本单（BUG-689 补经历邀请）上线并有真机数据之后再评估。 理由：本单会让用户更容易补到第三个领域，届时把门槛从 2 收紧到 3 的代价会明显变小；现在就收紧会和「永远给结果」的既有口径冲突，把更多案子挡在"继续收集"。

执行方不得在本单里顺手改这两个常量。评估时机与结论另行记录。

5. 让步顺序

1. 任务 1、任务 3 必做（文案 + 补完真的有用）。
2. 任务 2 若卡片布局改动风险大，可先只改文案位置不改结构，写进进度记录。

6. 开工前置命令

git fetch origin --prune
git worktree add -b codex/rectification-open-collect-invite-20260914 \
  .worktrees/rectification-open-collect-invite-20260914 origin/staging
cd .worktrees/rectification-open-collect-invite-20260914
ln -s /workspace/Jyotisha/.venv .venv
cd frontend && npm ci

开工前读：docs/research/rectification_minute_resolution_closure_2026_09_14.md（为什么"补经历"是唯一有效手段）、docs/BUG_HISTORY.md 的 BUG-687、646、651、653、688，以及 frontend/docs/VOICE.md。

7. BUG 编号起点

• 起点 BUG-689（当前最大号 688）。