Jesse_ChenandClaude Fable 5
b56147e524
与上游流程对照补两处。①精度研究单加 M1b：上游有一张分盘分钟敏感度表 （D60=2 / D30=4 / D24=5 / D9=13.3 / D1=120 分钟换一次上升），而本仓 11 张分盘 等权再除以 22（且没有 D60）——20 分钟窗里 D30 和 D2 同分量，分辨率最高的盘被 稀释。测 V1 反比配权 / V2 按窗宽选盘 / V3 加 D60，并报过拟合风险。 ②新任务书 BUG-690：录入已收 birth_time_source 三类，但校正链只用过一次， 推算值与医院记录等同对待、输出直称「你的出生时间」。接进投影并按来源分档措辞； 医院记录与校正结果冲突时怎么说挂给产品。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0155nFCgCHtoA7jhSDGmZmMu
84 lines
7.1 KiB
Markdown
84 lines
7.1 KiB
Markdown
# 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. 开工前置命令
|
||
|
||
```bash
|
||
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` 预留）。
|