Jyotisha/docs/tasks/TASK-rectification-declared-uncertainty-20260907.md

TASK · 出生时间"有多确定"只问一次：intake 三档、校正读档案里的偏移、吻合率低时一键放宽并写回（2026-09-07）

• 基线：origin/staging @ 5c644f92（代码头 517df002，含 BUG-565～570）
• 分支：codex/rectification-declared-uncertainty-20260907
• 执行方：coding agent；验收：Claude
• 涉及文件：frontend/src/lib/birth-time-intake-model.ts、frontend/src/components/birth-time-intake.tsx、frontend/src/lib/account-profile-patch.ts、frontend/src/lib/rectification-agentic/v9/case-service.ts、decision-from-dossier.ts、core/rectification-decision.ts、method-followup.ts、answer-choice.ts、block-scan-answer.ts（重算函数泛化）、tool-service.ts、frontend/supabase/migrations/（新 RPC）、frontend/src/lib/rectification-agentic/user-copy.ts
• 涉及引擎：scripts/rectification/api_service.py::block_scan（泛化为任意子段）、scripts/rectification/contracts.py（可选 blocks 字段）
• 不改：探针契约 contracts/probe-question-v1.json、采用/确认门、page.tsx、jyotish_api_server.py
• BUG 编号：BUG-571（声明不确定度被忽略）、BUG-572（吻合率低不提议放宽）、BUG-573（选段后直接进 4～6 小时分钟网格）（开工时 grep -o "^## BUG-5[0-9][0-9]" docs/BUG_HISTORY.md | tail -1 复核）
• 串行：在 TASK-rectification-capability-fix-20260907.md（已合入）之后；与其他校正单无并行

0. 为什么做这件事

产品负责人 2026-09-07 拍板：出生时间"有多确定"在初始化出生资料时问一次、存进档案，校正每次直接读，不再问；校正过程中只在证据说窗口选错时，由系统出一键卡提议放宽，并把新偏移写回档案。对照上游 yinduzhanxing：它保留用户给的区间，且方法 1 规定吻合率 <60% 要调 ±1～2 小时重验；我们现在两件都没做。

1. 现状实证

#	事实	位置
1	intake 只露出两个来源："我知道准确出生时间"（family_exact，±0）和"我不确定准确时间"（period_only 自选起止 / unknown）。模型与校验里早有 approximate（±15/30/60）和 hospital_record（固定 ±2），但单选框 birthTimeSourceOptions 只有两项，用户选不到	birth-time-intake-model.ts L91–94、L96–140；account-profile-patch.ts L126–145
2	校正开 Case：只要档案有钟点，一律 reportedTime ± 15（FRESH_CASE_SEARCH_RADIUS_MINUTES），注释写明"引擎执行边界，不是用户声明的不确定度"；档案里的 uncertainty_before/after 被读进 baseline 但不参与窗口	case-service.ts L131–146
3	引擎每次重算都产出 event_fit_rate（matched / total / percent / band：≥80 high、60–80 medium、<60 low），TS 已解析，但只用在采用后的八法报告里；没有"吻合低 → 窗口可能错 → 放宽"的动作	refinement_packet.py::event_fit_rate；refinement-packet.ts L761；skill-verification-report.ts
4	设置弹窗的星盘资料复用 BirthTimeIntakeFields，所以 intake 改了设置页自动同步	profile-fields.tsx L3
5	改窗口的 RPC 只有 advance_agentic_rectification_case_from_block_scan，要求 stage=block_scan；分钟阶段没有放宽窗口的入口。candidateRangeFingerprint 含起止，窗口一变快照自动失配触发重算	20260906030000_rectification_block_scan_stage.sql L132–182；tool-service.ts L619
6	既有测试把填报 05:00 → 04:45–05:15 写死了三处	rectification-v9-case-service.test.ts L83、L136、L428

2. 决策记录（产品负责人 2026-09-07 拍板）

1. 只在 intake 问一次，用"你对这个时间有多确定"来问，不用"偏移 / 误差"字眼。三档：
   • 「有出生证或医院记录，精确到分钟」→ hospital_record（校验仍固定 ±2 作无感检查）
   • 「家人记得大概时间」→ approximate + 一排按钮「差不多准 / 前后半小时 / 前后一小时 / 前后两小时」= ±15 / 30 / 60 / 120（校验从 {15,30,60} 扩到 {15,30,60,120}）
   • 「只知道大概时段，或完全不知道」→ 现有 period_only / unknown 分支不动 family_exact 不再出现在新用户选项里，存量档案仍合法，语义等同"差不多准"（±15）。
2. 校正窗口读档案。 有钟点时：hospital_record / family_exact → ±15（引擎边界，记录常按 5 或 15 分钟取整）；approximate → ±max(15, 声明值)，最大 ±120。窗口宽度 > 120 分钟一律先进子段扫描（决策 7），≤ 120 分钟才进分钟网格。 period_only 四～六小时的时段窗口同样先切子段；unknown 仍先走五时段全日扫描，赢的时段再按决策 7 继续切。
3. 校正中唯一碰这个值的时机是证据说窗口错了：训练门已开、event_fit_rate.band = low 且 total ≥ 3、代表分钟落在窗口边缘 3 分钟内、stage=minute、未采用、有钟点、本证据指纹下没拒过。满足即出服务端一键卡（不是模型问句）："按你说的经历，出生时间可能比家人记的偏得更多。放宽后再比一次？" A「放宽到前后 {下一档}」 B「放宽到前后 {再下一档}」 C「不放宽，按现在的范围继续」 D「说不好」。A/B 改窗口、重算、并把新偏移写回档案（来源改为 approximate）；C/D 记 declined_at_fingerprint，同一批证据不再问。已是 ±120 的不出卡。
4. 放宽卡优先级高于区分卡：窗口都可能错的时候，先别在错窗口里出题。
5. 放宽不写证据账本、不进推断层；已答探针按 semantic_key 在新候选集上重放（buildInferenceState 现有行为），测试锁定。
6. 不动采用门、确认门、MIN_SEPARATION_LEAD、_relative_support；不动 adopted_credible_range（那是采用后的产物）。
7. 窗口 > 120 分钟先切三段，迭代到 ≤ 120 分钟再进分钟。 把 block_scan 泛化：请求可带 blocks: [{label,start_time,end_time}]，不带则用五个声明时段；子段 = 当前窗口等分三段（宽度不足 3 的取整到分钟），步长按窗口宽自适应（>360 分钟 10、>180 分钟 5、其余 2），支持度仍是"段内均值减窗口最低分"归一。选 A/B/C 把窗口改成该子段并再评估：仍 > 120 → 再出一张子段卡；≤ 120 → stage=minute 重算。D「说不好」= 再收一件经历后重比。每个 Case 最多连问 3 张子段卡，超过即按当前窗口进分钟阶段并在旁白写明"时段分不开，直接按分钟比"。
8. 事件可靠度只问一次、只问日级事件。 用户说到精确到日的经历时，随后的采集确认里多一句服务端口述："这个日子是查过记录，还是凭记忆？"——答"查过"写 date_reliability=high，"凭记忆"写 medium，不答留空；月级、年级不问。这只影响 date_quality 门与精度权重，不改任何其他门。
9. 脚本化手测场景进 docs/testing/：范围（家人说两点到四点）、时段（只知道傍晚）、完全未知、以及"必须停下"的反例（日期地点经历都不确定）四个脚本，每个写期望观察点，供产品负责人在 staging 照着走。

3. 硬红线

• approximate 校验扩到 120 只在 account-profile-patch.ts 与 isBirthTimeDraftReady 两处同改；hospital_record 固定 ±2 不改。
• 放宽只能扩大且必须包含旧窗口；新窗口 ≤ 241 分钟；只在 stage=minute 允许；RPC 内校验，不信客户端。
• 放宽后 candidate_range 改写是合法的（这是搜索窗口，不是采用产物）；但 adopted_credible_range 不得被动。
• 既有 04:45–05:15 断言只对 family_exact / hospital_record 保留；approximate 用例另写，三栏说明。
• 文案对照 frontend/docs/VOICE.md；不得出现"偏移 / 误差 / 置信度 / 概率"；一键卡四选项契约与其他卡一致（TS 内部 choice_kind: "widen_window"，不进 Python 契约，比照 block_choice）。
• 迁移需 Docker test:db；无 Docker 写 BLOCKED.md。
• 测试总数 ≥ 1521（口径同 BUG-569 验收）；tsc 0 错；lint 0 error。

4. 任务分解

D1 intake 三档

• birthTimeSourceOptions 改三项（决策 1），approximate 分支渲染四个按钮写 uncertaintyBefore/After；hospital_record 保留"无感检查前后 2 分钟"说明；family_exact 从选项移除、读档时映射为"差不多准"显示。
• 校验：isBirthTimeDraftReady 与 account-profile-patch.ts 的 approximate 集合 → {15,30,60,120}；错误文案同步。
• 验收：birth-time-intake.test.ts 新增三档渲染与 120 校验；account-profile-patch 测试 120 合法、90 非法；设置页（profile-fields）源扫描仍复用 BirthTimeIntakeFields。

D2 校正窗口读档案（BUG-571：声明的不确定度被忽略）

• case-service.ts::deriveRectificationOpenPlan 增加 uncertaintyBefore/After 入参：approximate → reportedTime − max(15,before) ～ reportedTime + max(15,after)（各自独立，允许不对称），上限 120；其他钟点来源 ±15。
• 验收：rectification-v9-case-service.test.ts 新增 approximate ±60 → 04:00–06:00、±120 → 03:00–07:00；既有三处 04:45–05:15 保留并注明来源为 family_exact（三栏）。

D3 放宽窗口一键卡（BUG-572：吻合率低不提议放宽）

• 迁移：widen_agentic_rectification_case_window(p_user_id, p_case_id, p_start_time, p_end_time)：校验 stage='minute'、新窗口包含旧窗口、宽度 ≤ 241、status ∉ terminal、未采用；写 candidate_range，返回新范围；同一迁移给 agentic_rectification_cases 加 widen_declined_at_fingerprint text null。
• 决策层：decideRectification 新入参 windowWidenSuggested（由 decision-from-dossier 按决策 3 条件计算，边缘判定用 separation.representativeTime 与 case.candidateRange），为真时返回 nextAction="ask_window_widen"，排在 ask_candidate_discriminator 之前；sessionOutcome="widen_window"；can_adopt=false。
• 计划层：method-followup.ts 比照 blockChoiceFollowup 生成 widen_window 卡，选项文案服务端生成，档位从当前半径推：15 → A ±30 / B ±60；30 → A ±60 / B ±120；60 → A ±120 / B「先补一件带月份的经历再说」（answer_class no，四选项契约要求四项且不重复）。
• 应用：answer-choice.ts 比照 mutateCaseForBlockChoice：A/B → RPC 改窗口 → 按 D5 的 stageForWindow(width) 决定去向（新窗口 ≤ 120 分钟：泛化 rescoreMinuteAfterBlockAdvance 为 rescoreMinuteAfterWindowChange 重算；> 120 分钟：切 block_scan 出三子段卡） → 调用现有账户资料 patch 路径把 uncertainty_before/after 写为新半径、birth_time_source 改 approximate（hospital_record 例外：档案不改，只改窗口，因为其校验固定 ±2）；C/D → 写 widen_declined_at_fingerprint。
• 验收：新文件 rectification-window-widen-20260907.test.ts——(1) fit low + 代表分钟在边缘 → nextAction=ask_window_widen，卡四项齐；(2) fit low 但代表分钟在中间 → 不出卡；(3) 答 A → RPC 收到包含旧窗口的新范围、重算被触发、profile patch 收到新半径、已答探针数不变；(4) 答 C → 记指纹，同指纹下再评估不出卡，新证据到来后可再出；(5) 已 ±120 不出卡；(6) hospital_record 答 A 不改档案来源。rectification-v9-database.test.ts 加 RPC 用例（Docker）。

D5 子段扫描（决策 7；BUG-573：选定时段后直接进 4～6 小时分钟网格）

• 引擎：contracts.py 接收可选 blocks（1～5 段，每段起止 HH:MM，必须落在请求窗口内且不重叠）；api_service.block_scan 在有 blocks 时按其聚合，否则沿用五时段；步长按窗口宽自适应（决策 7），minute_step 显式传入时以传入为准。jyotish_api_server.py 不改（同一端点）。
• TS：block-scan.ts 的 BlockScanBlock.period 放宽为 label（五时段标签或 sub_1/sub_2/sub_3），选项文案用起止时间（"04:00—05:59"）；deriveRectificationOpenPlan 与放宽卡（D3）落地新窗口后统一走 stageForWindow(width)：> 120 → block_scan + 三等分 blocks；≤ 120 → minute。advance_agentic_rectification_case_from_block_scan RPC 放开"必须是 00:00–23:59"的限制，改为"新窗口必须是当前窗口的子区间"；block_scan 列记 rounds 计数，≥ 3 直接切 minute。
• 验收：test_rectification_v5_services.py——三段 blocks 支持度和 100、等分网格三段各 33.3/33.3/33.4、越界或重叠段报错；TS rectification-block-scan-*.test.ts——±120 approximate 开 Case 为 block_scan 三子段；period_only 傍晚（18:00–22:59）先出三子段卡；选 A 后窗口 ≤ 120 切 minute；连问 3 张后强制 minute 并有旁白；unknown 五时段 → 赢段再切三段。

D6 事件可靠度一问 + 脚本化手测场景（决策 8、9）

• method-followup.ts / collect-prompt.ts：账本新增 datePrecision=day 且 date_reliability 为空的事件时，下一轮口述题固定为服务端句"刚才那个日子是查过记录，还是凭记忆？"，答案由意图分类映射 high / medium，写回该条证据（用现有证据修订链，不新造 RPC）；每条事件只问一次，用户不答则跳过。
• docs/testing/rectification-scenarios-20260907.md：四个脚本（范围 / 时段 / 完全未知 / 必须停下），每个含开场输入、3～5 条虚构经历、期望看到的卡与旁白、不得出现的内容（如全日窗口上出现分钟或采用卡）。
• 验收：rectification-collect-*.test.ts 新增日级事件后下一问是可靠度句、月级不问、答"凭记忆"写 medium；docs/testing 文件存在且四场景齐。

D4 记录

• docs/BUG_HISTORY.md BUG-571、BUG-572、BUG-573；CHANGELOG.md；PROGRESS-rectification-declared-uncertainty-20260907.md；docs/testing/rectification-declared-uncertainty-20260907.md（真实环境：intake 选"家人记得大概时间 · 前后一小时"→ 进校正后顶部范围是 2 小时；说 3 件与该窗口明显不合的经历 → 出放宽卡 → 点 A 后范围变宽且设置页里的选项跟着变）；frontend/DESIGN.md、frontend/docs/VOICE.md。

5. 让步顺序

D1 + D2 + D5 是一组（窗口读档案与 >120 分钟切子段互相依赖），不可拆，先做；D3 其次（若做不完，先落 RPC + 决策层 + 卡，写回档案可后置并写明）；D6 最后，可拆到同分支第三次提交；D4 不可省。

6. 开工前置命令

git fetch origin --prune
git worktree add -b codex/rectification-declared-uncertainty-20260907 .worktrees/rectification-declared-uncertainty-20260907 origin/staging
cd .worktrees/rectification-declared-uncertainty-20260907
ln -s /workspace/Jyotisha/frontend/node_modules frontend/node_modules
cd frontend && ls tests/rectification-*.test.ts tests/consultation-*.test.ts tests/report-*.test.ts tests/personal-report-*.test.ts tests/birth-time-*.test.ts tests/account-profile*.test.ts tests/agent-voice-copy-contract.test.ts 2>/dev/null | grep -v database | xargs npx tsx --test 2>&1 | grep -E "^# (tests|pass|fail)"
grep -o "^## BUG-5[0-9][0-9]" ../docs/BUG_HISTORY.md | tail -1

验收（Claude，2026-09-07，origin/staging @ 7cf7705a，实现 8e31680b）

门	结果
tsc / lint	0 错 / 0 error（83 warning，既有类型）
前端 rectification + consultation + report + personal-report + birth-time + account-api + voice（非 DB）	1899 / 0
Python v5_services / event_probes / engine_convergence / growth contract / flexible engine / input_contract	全绿
minute_step=1 字节级不变（虚构 7 件事新旧引擎复跑）	candidate_scores / result_id / spec_hash 全等
子段扫描（18:00–22:59 三等分，3 件事）	0.8 s，步长 5，三段各 20 个候选，支持 48.7 / 41.4 / 9.9，和 100
Docker test:db	执行方 37/0（含 widen 扩大 / 缩小拒绝 / 权限；08:00–11:59 选定后仍 block_scan，08:00–09:00 进 minute）；本机无 Docker，取其数字

项	结论
D1 intake 三档	通过。三档文案"你对这个时间有多确定"，approximate 四个范围按钮，family_exact 读档映射"差不多准"，校验集合 {15,30,60,120} 两处同改
D2 窗口读档案（BUG-571）	通过。deriveDeclaredSearchWindow：医院/存量准确 → ±15；approximate → 前后各自 clamp(15..120)；既有 04:45–05:15 断言只保留给 family_exact，三栏齐
D5 子段扫描（BUG-573）	通过。blocks 进请求契约（1～5 段、须落窗内、除共享端点不重叠）；步长随窗宽 10/5/2；advance_* 改为"新窗须是当前窗子区间"，span>120 且 rounds<3 留 block_scan；最多 3 轮后强制 minute 并有旁白；全零均分改 100/n（执行方偏差合理：写死 20 在三段只到 60）
D3 放宽卡（BUG-572）	通过。触发条件六项齐；RPC 校验含旧窗、inclusive ≤241、stage=minute、未采用；放宽后按 stageForClockWindow 决定去向；档案写回 approximate + 新半径，hospital_record 只改窗口；C/D 记指纹
D6 可靠度一问 + 脚本	通过。只对本回合刚写入的日级事件问一次，答案正则映射 high/medium，薄 RPC 原地写（执行方偏差合理：修订链会改指纹误伤训练门）；docs/testing/rectification-scenarios-20260907.md 四场景齐
D4 记录	通过；四处书面偏差都在进度记录里写明
P3	classifyDateReliabilityUtterance 用「记得」判 medium，用户在该焦点下改说新经历（"我记得 2018 年入职"）会被顺带记成凭记忆；影响只到 date_quality 权重，可接受但建议把"记得"从正则里去掉，只留"凭记忆 / 印象 / 大概"
P3	patchV9BirthUncertainty 直接 from("profiles").update，绕开 account-profile-patch 的校验层，档案由此多了第二条写路径；值是常量所以当前无害，建议改走同一 patch 函数
P2（沿用）	test_block_scan_seven_events_finishes_within_fifteen_seconds 壁钟断言仍在，门禁可能间歇红

部署：staging 当前 72dd5e9d（迁移到 20260907010000），本轮迁移 20260907020000 未应用，部署前先 Migrate Staging Database。真实环境走查按 docs/testing/rectification-scenarios-20260907.md 四个脚本。