docs(tasks): rectification narrower delivery fix brief (issue #77)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LutgzyJqNhPpZy1nFsJtN3
This commit is contained in:
Jesse_Chen
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
712a0fd2a1
commit
f95eb670bc
@@ -0,0 +1,73 @@
|
||||
# TASK · 生时校正交付区间收窄 · 修复单（issue #77，第 1 次打回）
|
||||
|
||||
- 日期：2026-10-17
|
||||
- 被验提交：`56a3c081455d948b2f9dd54be8dd697ecad23447`（分支 `codex/rectification-narrower-delivery-20261016`）
|
||||
- 原任务书：`docs/tasks/TASK-rectification-narrower-delivery-20261016.md`（下称「原单」）
|
||||
- 执行方：Grok，在**同一分支**追加提交；`origin/staging` 前进时用 `git merge origin/staging`，不 rebase
|
||||
- BUG 编号：沿用你已登记的 BUG-1367～1369；新发现的缺陷从开工时 `docs/BUG_HISTORY.md` 最大号 +1 起
|
||||
|
||||
## 验收结论（Claude，Linux）
|
||||
|
||||
T1 的方向对，代码质量整体可以；但原单让步顺序写明**最少交 T0+T1**，T0 没交，T1 又有两处会让显示比真实范围更窄的缺陷，所以打回。T2、T3 没做是允许的（按让步顺序），本单不要求。
|
||||
|
||||
| 项 | 结论 | 证据 |
|
||||
| --- | --- | --- |
|
||||
| tsc / lint | 通过 | 0 错；0 error、123 条原有 warning |
|
||||
| 前端全量 `npm test` | 通过 | 5030 条（基线 5024），失败 25 条与基线逐名一致（另 1 条只在 Docker 下能跑的已知项） |
|
||||
| Python 显示单测 | 通过 | `tests/test_rectification_living_display_intervals.py` 4 passed |
|
||||
| 越界 / 隐私 | 通过 | 只动了原单 T1 范围内的文件；无个人资料 |
|
||||
| **T0 基线回放** | **未通过** | 没产出 `docs/research/rectification_narrower_delivery_baseline_2026_10_16.json` |
|
||||
| **T1 显示成员与交付区间一致** | **未通过** | 见 F2 |
|
||||
| **T1 golden 验收** | **未通过** | 用的是手造卡片，原单要求一例 ±60 回放（见 F3） |
|
||||
| T1 Python 侧 | 部分 | 见 F4 |
|
||||
|
||||
## F1 · 补 T0，并用同一套回放量 T1（必做）
|
||||
|
||||
你在进度里说现有回放脚本不记「真值在不在交付区间」、也不翻题，这是事实；**补这两项正是 T0 的工作内容**，不是阻塞理由。
|
||||
|
||||
做法：
|
||||
|
||||
1. 在研究脚本里扩展（不改生产代码）：`frontend/tests/research/rectification-segment-persisted-replay.ts` / `scripts/research/varga_resolution_persisted_replay.py` 之一（选你更顺手的，进度里写明），增加：
|
||||
- 参数：窗口 `±10/±30/±60`；答题模式 `all_correct`、`flip_1`、`flip_3`、`flip_5`（第 N 道点选题按反向作答）；轮数上限沿用生产默认（当前 8），**不得**用 6。
|
||||
- 每例输出：真值分钟；交付时的 `credible_range` / `credible_intervals`（决策包络）；分段显示区间（T1 的 `livingDisplayFromCandidates` 同口径）；两者是否包含真值；实际剩余分钟数；显示宽度；问题数。
|
||||
2. **T0**：在原单开工 SHA（`712a0fd2`）上跑 77 例 × 3 档 × 4 模式，落 `docs/research/rectification_narrower_delivery_baseline_2026_10_16.json`，写清复跑命令。
|
||||
3. **T1 判定**：在本分支上跑同一套，落 `docs/research/rectification_narrower_delivery_t1_2026_10_17.json`。按原单 §4 红线 2 比较「分段显示包含真值」与基线「包络包含真值」：
|
||||
- 全对：每档例数 ≥ 基线 −1；
|
||||
- 翻 1/3/5：每档比例 ≥ 基线 −5 个百分点。
|
||||
过不了就按原单 §6 撤回 T1 对应出口，不放宽红线。
|
||||
4. Windows 磁盘不够或 Docker 起不来时，按 `docs/research/` 盘型口径研究的「无 Docker 验收法」（预编译 PG17）跑；仍跑不了就**停下回报**，不要只交代码。
|
||||
|
||||
## F2 · 显示成员与交付区间成员不一致，可能把还活着的时段藏掉（必做）
|
||||
|
||||
`frontend/src/lib/rectification-agentic/core/candidate-window.ts::livingDisplayFromCandidates` 自己重算「谁还活着」，与交付区间的权威口径 `core/credible-range.ts::stillValidCandidates` / `unionStillValidIntervals` 有两处分歧：
|
||||
|
||||
1. **取整后比门槛。** 交付卡（`rectification-range-delivery.tsx`）和只读范围行（`rectification-agentic-chat.tsx`）传进来的是解析后的 `RectificationCandidate`，只有 `relativeSupport`，它是 `inference-adapter.ts` 里 `Math.round(posterior_score)` 再夹到 0–100 的整数。拿它比 `MIN_SEPARATION_LEAD = 8` 会在边界上出错：峰值 7.6、候选 0.4，真实差 7.2（在区间内），取整后差 8（被当成出局）。
|
||||
2. **缺区间的候选被悄悄丢掉。** 某个活着的候选没有 `cluster_intervals` 时，新函数直接跳过它，而 `unionStillValidIntervals` 遇到这种情况返回空、由调用方退回旧口径。结果是显示比真实范围窄，真值可能正落在被丢掉的那段里。
|
||||
|
||||
修法要求（实现方式你定，结果必须满足）：
|
||||
|
||||
- 显示成员**必须与 `stillValidCandidates(candidates, lead)` 完全相同**，用原始 `posterior_score` 比较，不用取整值。推荐在写盘处（有 `InferenceCandidate` 的地方）算好分段显示区间并随结果持久化，前端只读，不在 UI 侧重算；若改为持久化，读旧结果时缺字段就退回旧标题。
|
||||
- 任一活着的候选缺 `cluster_intervals` → 整体退回旧的包络标题（与 `unionStillValidIntervals` 同规则）。
|
||||
- 新增测试：① 边界例（峰值 7.6 / 候选 0.4 → 两者都在显示里）；② 一个活着的候选缺区间 → 退回旧标题；③ 对同一组候选，分段显示的成员集合 == `stillValidCandidates` 的成员集合（可用 golden 输入批量断言）。
|
||||
|
||||
## F3 · T1 验收要用回放产物，不用手造卡片（必做）
|
||||
|
||||
原单 T1 验收第 2 条：「用 golden 中一例 ±60 回放得到的候选构造交付卡，标题段数与实际剩余分钟数和回放一致」。AGENTS §7.4 也要求合同 fixture 来自真实引擎响应。F1 跑完后，从 ±60 结果里挑一例「有大于 4 分钟空档」的，落到 `frontend/tests/fixtures/`（只存候选分数与区间，不存出生资料；`fixtureProvenance` 写命令与 SHA），替换或补充 `rectification-living-display-20261016.test.ts` 里的手造输入。手造用例可以保留做边界测试。
|
||||
|
||||
## F4 · Python 侧新函数没有任何调用方（必做，小）
|
||||
|
||||
`scripts/rectification/living_display_intervals.py` 只被它自己的测试引用。原单 D1 要求报告里的范围也按分段显示；进度里写「技能报告的不可分宽度仍是决策包络」。二选一并写进进度：
|
||||
|
||||
- a. 把报告（Python 侧用户可见的范围句）接到这个函数上，补一条测试；
|
||||
- b. 如果报告范围完全由前端传入、Python 侧没有用户可见出口，就删掉这个文件和它的测试，并在进度「口径」表里写明报告范围由哪一处决定。
|
||||
|
||||
会话标题仍用数据库函数里的单段包络：原单禁止本轮改表，**这一项接受**，保持进度里的说明即可。
|
||||
|
||||
## 不要做
|
||||
|
||||
- 不做 T2、T3（让步顺序允许后交）；不改 `MIN_SEPARATION_LEAD`、`SCORE_DELTA` 等原单红线 1 的任何一项。
|
||||
- 不改既有断言来迁就新显示；要改的按「原值 / 新值 / 原因」写。
|
||||
|
||||
## 回报
|
||||
|
||||
issue #77 回报新 SHA，表格里写：T0 与 T1 的三档 × 四模式包含率对照、实际剩余分钟与显示宽度中位数、F2 三条新测试结果、F4 选了 a 还是 b。
|
||||
Reference in New Issue
Block a user