From e1452aaea50ec084ec1d90df26afac13b57d5787 Mon Sep 17 00:00:00 2001 From: Jesse_Chen Date: Thu, 24 Sep 2026 18:05:19 +0800 Subject: [PATCH] =?UTF-8?q?docs(bugs):=20BUG-982/983=20=E5=9B=9E=E5=A1=AB?= =?UTF-8?q?=E9=83=A8=E7=BD=B2=E4=BA=8B=E5=AE=9E=E4=B8=8E=E5=AD=98=E9=87=8F?= =?UTF-8?q?=E8=8C=83=E5=9B=B4=E6=A0=B8=E5=AF=B9=E7=BB=93=E8=AE=BA?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit b85c4a68 已随 1420471a 部署：它是已部署提交的祖先，其后 5 个提交经 is-docs-only-range.sh 核为纯文档。记录里「部署与真人验收尚未完成」改为 「仅差真人验收」，状态仍 investigating。 追加存量数据核对：报告与普通对话不会对修复前的跨午夜存量范围做错误 锚定。read_report_candidate_range 对无 intervals 的旧行只返回纯钟点， parseReportCandidateRange 遇 startTime > endTime 返回 null，两条链路 退回存储的单个代表分钟。后果是报告丢失范围展示，而非算错日期。实跑 确认，写进记录以免后来人重复排查。 Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_0199rbQDTsUbCVw84wc8BTFe --- docs/BUG_HISTORY.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/BUG_HISTORY.md b/docs/BUG_HISTORY.md index 726350b0..a13962aa 100644 --- a/docs/BUG_HISTORY.md +++ b/docs/BUG_HISTORY.md @@ -12982,7 +12982,8 @@ - 防复发：后续需完整日期/相对窗序号回归贯穿签名聚类、候选决策与交付范围，不能只测试辅助 `_primary_cluster`。 - 相关记录：BUG-623、BUG-624、BUG-639、BUG-981。 - 复发自：未发现同症状既有记录；BUG-624/639 的范围断言仍在但均是同日样本，跨午夜诊断测试覆盖的是另一条聚类路径，未覆盖本路径。 -- 修复版本：实现 `b85c4a68`，2026-09-21 经 Claude 独立验收后快进合入 `staging`；**部署与真人验收尚未完成**，故状态保持 `investigating`。证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。 +- 修复版本：实现 `b85c4a68`，2026-09-21 经 Claude 独立验收后快进合入 `staging`；随 `1420471a` 部署（2026-09-24 核对：`b85c4a68` 是已部署提交的祖先，其后 5 个提交 `is-docs-only-range.sh` 退出 0）。**仅差真人验收**，故状态保持 `investigating`。 +- 存量数据核对（2026-09-24）：报告与普通对话**不会**对修复前的跨午夜存量范围做错误锚定。`read_report_candidate_range` 对无 `intervals` 的旧行只返回纯钟点 `{start_time, end_time}`，`parseReportCandidateRange` 遇 `startTime > endTime` 即返回 `null`，两条链路随即退回存储的单个代表分钟（报告标 `provisional`、不带候选范围）。影响是这批用户的报告丢失范围展示，不是算错日期；实跑已确认。证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。 ## BUG-983 | 凌晨申报窗口的候选日期锚点可能偏到次日 @@ -13000,7 +13001,8 @@ - 防复发：必须从申报日/分钟经实际前端请求构建到后端枚举端到端校验日期，而非只验证钟点范围与“支持跨午夜”；扩窗不得重猜日期或将未知缩窄结果伪作用户选侧。 - 相关记录：BUG-098、BUG-198、BUG-979、BUG-981。 - 复发自：未发现同症状既有记录；BUG-198 时段开窗与 BUG-098 枚举回归仍在但不校验申报日期中心。离线 holdout 已有前日中心保护，未覆盖生产请求链。 -- 修复版本：实现 `b85c4a68`，2026-09-21 经 Claude 独立验收后快进合入 `staging`；**部署与真人验收尚未完成**，故状态保持 `investigating`。证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。 +- 修复版本：实现 `b85c4a68`，2026-09-21 经 Claude 独立验收后快进合入 `staging`；随 `1420471a` 部署（2026-09-24 核对：`b85c4a68` 是已部署提交的祖先，其后 5 个提交 `is-docs-only-range.sh` 退出 0）。**仅差真人验收**，故状态保持 `investigating`。 +- 存量数据核对（2026-09-24）：报告与普通对话**不会**对修复前的跨午夜存量范围做错误锚定。`read_report_candidate_range` 对无 `intervals` 的旧行只返回纯钟点 `{start_time, end_time}`，`parseReportCandidateRange` 遇 `startTime > endTime` 即返回 `null`，两条链路随即退回存储的单个代表分钟（报告标 `provisional`、不带候选范围）。影响是这批用户的报告丢失范围展示，不是算错日期；实跑已确认。证据及待验项见 `docs/tasks/PROGRESS-rectification-midnight-date-anchor-20260920.md`。 ## BUG-984 | 时段旧分数缓存不校验算法身份且聚合回执可能显示新版本