Jyotisha/docs/tasks/PROGRESS-rectification-narrower-delivery-fix-20261017.md

进度：生时校正交付区间收窄 · 第 1 次打回修复（2026-10-17）

issue #77。分支 codex/rectification-narrower-delivery-20261016。修复单在 origin/staging 的 docs/tasks/TASK-rectification-narrower-delivery-fix-20261017.md。

结论

卡片和旁白上的「目前范围」改为读写盘时算好的分段。差 7.2 分、四舍五入后看起来像差 8 分的候选会留下。某个还活着的候选没有时间区间时，整张卡退回原来的首尾，不再把那一段藏起来。打分、采用、确认、分离门槛 8、出题闸 30/45 天都没有改。对半出题和把进区间门槛从 8 改成 6 这次仍然不做。

两份回放都已落地，各 924 条。每档都是 70 条能比、7 条被挡住。全对和翻 1/3/5 的包含率都是 70/70。分段显示没有比改前的整段包络更漏真值，12 格都过红线。退出码是 1，因为有被挡住的行，不是条数不够。

口径

位置	这一轮
交付卡、只读范围行、旁白、口头钟点、遥测宽度	读结果里已保存的 living_display_intervals。没有这份字段，或写盘时某个还活着的候选缺区间，就用原来的首尾
谁还活着	与 stillValidCandidates 相同，用原始 posterior_score，门槛仍是 8。不用取整后的相对支持
credible_range / credible_intervals	决策包络，门槛仍是 8
技能报告「不可分宽度」	仍由前端按决策包络填写（candidate-plateau.ts）。Python 里没有用户看得到的范围句
会话标题	仍是数据库函数里的单段。本轮不改表
对半出题、门槛 8 改 6	不做

F4 选 b：删掉没有调用方的 scripts/rectification/living_display_intervals.py 和 tests/test_rectification_living_display_intervals.py。

漏段

• 写盘（buildInferenceState）用 livingDisplayForInference 按原始分数算出分段，随推断状态保存。
• 读盘只展示保存下来的区间。旧结果没有这个字段时，标题仍是原来的首尾。
• 真实样本：开工 SHA 712a0fd2 上一条已经答过题的 ±60 回放，只留下分数和区间，日期改锚到 2000-01-01。样本有大于 4 分钟的空档。显示成员与 stillValidCandidates 相同，标题是 3 段、共 38 分钟。文件：frontend/tests/fixtures/rectification-living-display-radius60-20261017.json。手写的 7.2 分边界和缺区间用例仍在，没有放宽。

包含率

比较的是：改前包络是否包住真值，改后分段显示是否包住真值。能比的行都是 70。全对要求包含条数不少于基线减 1；翻题要求比例不少于基线减 5 个百分点。两边都是 70，全部通过。

窗口	答题	基线包络	改后分段	剩余分钟中位数（基线 / 改后）	显示宽度中位数（基线 / 改后）
±10	全对	70/70	70/70	10 / 10	10 / 10
±10	翻 1	70/70	70/70	11.5 / 11.5	12 / 12
±10	翻 3	70/70	70/70	10 / 10	11 / 11
±10	翻 5	70/70	70/70	10.5 / 10.5	10.5 / 10.5
±30	全对	70/70	70/70	11 / 11	15 / 12
±30	翻 1	70/70	70/70	17 / 17	29 / 17
±30	翻 3	70/70	70/70	19 / 19	27 / 20
±30	翻 5	70/70	70/70	17 / 17	28 / 18.5
±60	全对	70/70	70/70	21.5 / 21.5	32.5 / 21.5
±60	翻 1	70/70	70/70	34 / 34	65.5 / 34
±60	翻 3	70/70	70/70	31 / 31	59 / 31
±60	翻 5	70/70	70/70	28 / 28	53.5 / 28

基线文件 docs/research/rectification_narrower_delivery_baseline_2026_10_16.json，代码 712a0fd2a19947405a1dfb486bad96a7661d41c3，2026-10-18 18:55 写完。对照文件 docs/research/rectification_narrower_delivery_t1_2026_10_17.json，代码 1ba473970ff58eba4b2a21590feef67a7e2254e8，2026-10-19 07:54 写完。第一遍对照在启动后约 8 分钟因数据库断开而没有落盘，这一份是重跑的。

测试

检查	命令	结果
分段显示，含 7.2 分、缺区间、成员一致、真实 ±60 样本	node --import tsx --test tests/rectification-living-display-20261016.test.ts	13 pass，0 fail，0 cancelled
Python 显示单测	文件已按 F4-b 删除	未跑
Python 快速门	本轮不跑	未跑
tsc、lint、前端全量 npm test	修复单没有点名	未跑

红线

未改引擎打分、SCORE_DELTA、采用/确认门、MIN_SEPARATION_LEAD（仍是 8）、MIN_BOUNDARY_DAYS=45、REFRESH_MIN_BOUNDARY_DAYS=30。

其它

• 这条显示漏段原先写成 BUG-1370。婚恋合盘保留了 BUG-1370 到 BUG-1374，上游第八轮从 BUG-1380 起。历史文件里也还没有 1375。所以改记为 BUG-1375。婚恋合盘那几个号没有动。
• git fetch 后 origin/staging 为 edf25918b2f14a4339740be505916ba41e65acb7（修复单所在提交 f95eb670 之后还有 5 个文档提交）。本轮用 merge，不 rebase。
• 临时目录 G:\Ferti\tmp\replay-temp 和 G:\Ferti\tmp\baseline-712a0fd2 不进仓库。
• 2026-10-19 Claude 验收合并时：staging 上 BUG-1375、BUG-1376 已归 #81（full-reading 补模块），本条显示漏段顺延为 BUG-1392（1380～1391 已归上游第八轮）。上文保留当时的编号叙述。

Claude 验收与转换（2026-10-19，产品选 B）

• 第三次验收（f67d2661）：回放数字通过。Claude 从两份 JSON 的 924 条记录独立重算，12 格（3 窗口 × 全对 / 翻 1/3/5）改前整段与改后分段包含真值都是 70/70；未完成的 84 条两边是同样 7 个案例。±60 全对显示宽度中位 32.5 → 21.5。
• 未过项：tests/test_repo_privacy_markers.py 的 R003 命中两份回放 JSON 里 6 处钟点字符串（修复单 TASK-rectification-narrower-delivery-fix-20261019.md）。
• 产品在 issue #77 选 B：由 Claude 转换数据文件。做法：区间端点由 HH:MM 改为相对本条 credible_range 起点的整数分钟（display_fixture 相对其最早起点），跨午夜按模 1440 处理；文件顶层加 clock_encoding 说明。不改任何程序。
• 核对：每条记录的 truth_in_envelope、truth_in_display、remaining_minutes、display_width_minutes 等结论字段转换前后逐条相等；每条区间总宽度转换前后相等；living_display_intervals 宽度之和等于 display_width_minutes。转换后两份文件不含任何 "HH:MM" 字符串，隐私测试通过。