Jyotisha/docs/tasks/TASK-rectification-birth-time-provenance-20260914.md

TASK · 报上来的出生时间是「记录」还是「推算」，必须一路带着标签 — 2026-09-14

• 基线：origin/staging @ 3314de2a（代码 963c147c，staging 已部署）。
• 分支：codex/rectification-birth-time-provenance-20260914，worktree .worktrees/rectification-birth-time-provenance-20260914。
• 关联：上游 docs/research/rectification_process_v2_guardrails_2026_09_04.md 的 R2 时间值 provenance 标签化（2026-09-14 与上游流程对照时发现本仓缺口）；BUG-689（补经历邀请）；references/candidate-comparison.md 的 candidate / accepted / confirmed 三层。
• 串行：改文案层与决策投影一处，不改打分与判据；与在途的两份研究单无文件重叠。

1. 问题

上游从一次真实闭环复盘里固化了一条硬规则（R2）：任何出生时间引用必须带来源标签，推算值不得当作已证实真值参与裁决。 他们分四类：recorded_time（出生记录原件）/ provisional_time（档案沿用推算值）/ rectified_window（校时收敛窗）/ representative_time（窗内代表值）。

本仓的现状是「收了但没用」：

• 录入时确实问过（frontend/src/lib/birth-time-intake-model.ts:100）：hospital_record（有出生证或医院记录，精确到分钟）/ approximate（家人记得大概时间）/ period_only（只知道大概时段或完全不知道），落库为 agentic_rectification_cases.birth_time_source，Dossier 里是 case.birthTimeSource（v9/tool-service.ts:480）。
• 但整条校正链里只用过一次：v9/block-scan-answer.ts:117，仅用来决定放宽窗口后要不要把 source 改写成 approximate。
• 决策、交付文案、采用流程、报告一律不看它。case.reportedBirthTime 被当锚点参与出题与比较（decision-from-dossier.ts:743 一带），不区分它是医院记录还是家人回忆。

后果：一个家里人事后推算的时间，和一个出生证上的分钟，在系统眼里一模一样；输出里也可能把前者直接称作「你的出生时间」。这既不诚实，也让用户无法判断该信谁。

2. 决策记录

决策	内容
D1	三类来源在表达上必须区分。 hospital_record → 可称「你的出生记录时间」；approximate → 只能称「你填的大概时间」/「家人记得的时间」；period_only → 只能称「你给的时间段」。任何输出（旁白、卡片、报告、采用确认）都不得把后两类称作「你的出生时间」。
D2	校正产物自己也要带标签。 交付区间是 rectified_window，代表分钟是 representative_time，采用之后是 accepted（本仓既有语义，不新造词）。不得把代表分钟说成「已确认的出生分钟」——这条是既有红线（BUG-587 一线），本单把它和来源标签统一成一套说法。
D3	推算值不得单独充当裁决锚点。 若 birth_time_source !== "hospital_record"，reportedBirthTime 只能作为搜索窗中心与展示参照，不得在任何文案里表述为「与你的出生时间一致 / 不一致」——应表述为「与你填的大概时间相差 N 分钟」。打分与出题逻辑本单不动（窗口中心本来就该用它）。
D4	hospital_record 与校正结果冲突时怎么说，本单不擅自定。 若用户有医院记录、而校正区间不含该分钟，属于产品判断（以记录为准？以证据为准？并列呈现？）。本单只做到「如实并列陈述两者与差值」，不给倾向性结论，并在进度记录里把这个问题挂给产品负责人。
D5	不改打分、不改判据、不改置信度与确认门控、不动数据库结构（birth_time_source 字段已存在）。

3. 硬红线

1. tsc --noEmit 0 错；npm run lint 0 error；npm test 失败数 = 基线 27 条；next build 通过且 / 仍 ○ Static。
2. 新文案对照 frontend/docs/VOICE.md；改 UI 的提交同时更新 frontend/DESIGN.md。
3. 不得因为要显示来源而在界面上暴露多余入口（产品偏好：多余入口宁可删除也不修）。
4. 不得把 period_only 的用户逼着补一个具体钟点。

4. 任务分解

任务 1 · 把来源标签接进投影（P0）

• case.birthTimeSource 进 decideFromDossier 的公开投影与 GET 快照（字段名沿用 birth_time_source），供文案层使用；缺失时按 approximate 处理（保守）。
• 验收标准：行为单测——三种 source 各自在快照里可见；缺失时落到 approximate。

任务 2 · 文案分档（P0）

• 交付卡、采用确认、旁白里所有指代"用户报的那个时间"的地方，按 D1 分档措辞；所有指代校正产物的地方按 D2 用既有三层词。
• 与填报时间比较时，按 D3 改成「与你填的大概时间相差 N 分钟」。
• 验收标准：
  • 行为单测：approximate / period_only 的案子，交付与采用路径产出的文本不含「你的出生时间」这类表述（用正则锁）。
  • 行为单测：hospital_record 的案子，文本可以出现「出生记录时间」，且同时给出与校正区间的差值。
  • 既有文案合同测试（agent-voice-copy-contract.test.ts 一线）同步补这三条。

任务 3 · Skill 侧口径（P1）

• skills/jyotish-birth-time-rectification/references/candidate-comparison.md 增补一节「出生时间来源标签」，把 D1/D2/D3 写成 Agent 必须遵守的表达规则；Skill 版本按是否改用户可见话术决定是否 bump，bump 了要在 CHANGELOG.md 写明。
• 验收标准：skill-registry 相关测试通过；若 bump，旧 Case 仍绑旧版本（BUG-621 的教训：bump 后必须验历史 Case 还能打开）。

任务 4 · 记录

• docs/BUG_HISTORY.md 新增 BUG-690（resolved）：现象写「家人推算的出生时间在系统里和医院记录等同对待，输出也直接称『你的出生时间』」；防复发条：birth_time_source 不是录入时的一次性字段，任何指代出生时间的输出都必须按它分档；推算值不得表述为已证实的出生时间。
• CHANGELOG.md 一行；PROGRESS-rectification-birth-time-provenance-20260914.md（把 D4 那个产品问题挂在这里）；docs/testing/ 清单：三种来源各走一遍，检查措辞。

5. 让步顺序

1. 任务 1、2 必做。
2. 任务 3 若 Skill bump 牵连面大，可只改 references 不 bump，在进度记录里说明。

6. 开工前置命令

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

开工前读：frontend/src/lib/birth-time-intake-model.ts:100（三类来源的原始定义）、frontend/docs/VOICE.md、docs/BUG_HISTORY.md 的 BUG-587、BUG-621。

7. BUG 编号起点

• 起点 BUG-690（当前最大号 688；689 已被 TASK-rectification-open-collect-invite-20260914.md 预留）。