fix(rectification): use candidate dates for cross-midnight dasha scoring
Add date-isolated caches and regression coverage, align scoring identity, and freeze full research reruns while preserving historical artifacts. Record unresolved cache/receipt identity and end-to-end acceptance gaps for branch review only. Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
jesse-ux
+69
-2
@@ -12873,7 +12873,7 @@
|
||||
|
||||
## BUG-978 | 封存契约当前打分身份与资料审计状态过期
|
||||
|
||||
- 状态：resolved/partial
|
||||
- 状态：resolved
|
||||
- 首次发现：2026-09-20
|
||||
- 最近更新：2026-09-20
|
||||
- 影响面：封存 holdout 契约、当前实现评测身份与离线成绩归属。
|
||||
@@ -12900,7 +12900,8 @@
|
||||
- 验证：完整修正版 900 组合、45 格，排除 0；新增偏差与 freshness/桥接回归 28/28 通过（包含桥接重复收集），真实引擎跨日分组与逐候选重算相同。报告见 `docs/research/reported_offset_2026_09_20.md`，口径与哈希见同名 JSON。resolved 仅指离线缺少偏差维度的缺口，不代表产品分钟准确或生产跨日问题已修。
|
||||
- 防复发：锁定零偏移、窗外、口径字段、非真值破同分与跨日行为；窗口覆盖与排序命中分开记录，不以敏感性代替真实用户准确率。
|
||||
- 独立审查追加：首版偏差评测的矩阵为全窗共用一个日期，跨日时辅助 transition proximity 有偏差。已在离线适配层按候选日期分组计算并与逐候选真实引擎结果对照，不修改生产打分；原初扫统计作废。生产同类日期处理不在本单修复范围，记入 BLOCKED，不能声称生产端到端等价。
|
||||
- 相关记录：BUG-098、BUG-978。
|
||||
- 后续生产问题：候选级 Dasha 日期修复单独跟踪于 BUG-981；本记录 resolved 仍仅限离线评测缺口。
|
||||
- 相关记录：BUG-098、BUG-978、BUG-981。
|
||||
- 复发自：BUG-098；既有防复发聚焦候选公开门与同案稳定性，没有离线与生产窗心可比性的测试。
|
||||
- 修复版本：本轮执行分支，未交付。
|
||||
|
||||
@@ -12919,3 +12920,69 @@
|
||||
- 相关记录：BUG-098、BUG-428、BUG-978、BUG-979。
|
||||
- 复发自：BUG-098；原记录明确延期独立分区与校准，本轮仍无真正独立样本，不能将文档协议写成验证完成。
|
||||
- 修复版本：协议执行分支；数据集未就绪，不标 resolved。
|
||||
|
||||
## BUG-981 | 跨午夜候选共用窗口日期导致 Dasha 邻近度偏移
|
||||
|
||||
- 状态：investigating
|
||||
- 首次发现：2026-09-20
|
||||
- 最近更新：2026-09-20
|
||||
- 影响面：生产事件贡献矩阵 transition proximity、跨午夜候选排序与实现身份追溯。
|
||||
- 用户现象：跨午夜窗口的部分候选按窗口起始日计算 Dasha 边界，结果可能改变分数与排序；此前离线评测用日期分组适配绕开，生产问题仍在。
|
||||
- 触发条件：候选实际日期与请求 `birth_date` 不同，进入 `merge_transition_proximity()`。
|
||||
- 根因：helper 将请求日期用于所有候选的 Vimshottari / Narayana 起始计算及缓存键；候选的完整 `candidate_at` 未用于此层。
|
||||
- 修复：按产品已批准的任务书，先红测再改候选级日期与缓存键，不调权重；冻结重跑和 V9 版本标记同步实施。进度见 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`。
|
||||
- 验证：原实现新增测试 4 failed / 4 passed，修复后 9 项与 quick 桥接重复执行共 18 passed；另 3 项既有版本/枚举回归通过。19 个公开 AA 同日窗口、2299 个候选分数与矩阵字节不变；实跨日窗口全候选等于逐候选日期正确独算。性能配对中位 -0.87%，满足不超 +20%；口径 v3、raman/mean、±60、步长 1，旧 12 文件身份 `b15d9ea15227cd58`、新扩展生产身份 `7fffd1db612af1f2`。独立主会话日期/隐私补验 80 项通过。尚无部署证据，保持 investigating。
|
||||
- 验收边界：已有时段缓存与聚合回执身份导致 T4 未完整通过，见 BUG-984；另发现 BUG-982/983，不把候选级日期一致夸大为所有跨午夜路径端到端正确。
|
||||
- 防复发：新增生产打分层跨午夜回归并接入 quick 收集；候选枚举正确不再被视为下游日期正确的充分证据。保留 BUG-427/428 的实现身份与已曝光边界。
|
||||
- 相关记录：BUG-098、BUG-427、BUG-428、BUG-621、BUG-978、BUG-979。
|
||||
- 复发自：BUG-098 的跨午夜兼容只覆盖逐分钟枚举，未覆盖后加的 transition-proximity 层；BUG-979 已在离线适配发现，但其范围禁止改生产，因而没有消除此生产缺陷。
|
||||
- 补充回归：最终三个校正 Python glob 共 300 项，296 passed / 4 failed，四项失败与基线逐条相同、新增失败 0。算法 -8 的版本断言及真实引擎 golden 两项身份已精确同步，数值与比较器不变；独立定向 25 项通过。900/20 正式重跑的真实源码身份、历史字节与报告汇总经独立审查通过，确认门与独立性边界不变。
|
||||
- 修复版本：`codex/rectification-cross-midnight-20260920` 核心修复完成，T4 未完整通过；按产品要求仅交付独立分支供远程 review，不合入 staging、未部署，推送结果以远端 SHA 核对为准。
|
||||
|
||||
## BUG-982 | 跨午夜短簇按钟点排序被扩成全天跨度
|
||||
|
||||
- 状态：investigating
|
||||
- 首次发现：2026-09-20
|
||||
- 最近更新：2026-09-20
|
||||
- 影响面：`candidate_contrast.py`、`decision_policy.py` 的簇范围与宽度。
|
||||
- 用户现象：跨午夜连续三个分钟候选组成的短簇，被表示为从当天最早钟点到最晚钟点，宽度扩成全天。
|
||||
- 触发条件：同一签名簇跨午夜，钟点字符串排序而没有候选日期或全窗序号。
|
||||
- 根因：签名聚类及 `_cluster_span()` 丢失日期，只用钟点决定首尾；这不是本轮 Dasha 日期修复新引入的行为。
|
||||
- 修复：本轮仅独立诊断，不改聚类或交付策略；另行修复单处理。
|
||||
- 验证：纯虚构最小探针沿 `build_candidate_decisions()` 实测一簇三个连续跨午夜成员被报为 1440 分钟。未涉及真实案例资料，未标 resolved。
|
||||
- 防复发：后续需完整日期/相对窗序号回归贯穿签名聚类、候选决策与交付范围，不能只测试辅助 `_primary_cluster`。
|
||||
- 相关记录：BUG-623、BUG-624、BUG-639、BUG-981。
|
||||
- 复发自：未发现同症状既有记录；BUG-624/639 的范围断言仍在但均是同日样本，跨午夜诊断测试覆盖的是另一条聚类路径，未覆盖本路径。
|
||||
- 修复版本：未实施，见 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`。
|
||||
|
||||
## BUG-983 | 凌晨申报窗口的候选日期锚点可能偏到次日
|
||||
|
||||
- 状态：investigating
|
||||
- 首次发现：2026-09-20
|
||||
- 最近更新：2026-09-20
|
||||
- 影响面：V9 搜索窗、`engineRequestBody()` 与 `_candidate_datetimes()` 的日期传递。
|
||||
- 用户现象：申报在午夜后的范围向前跨日时，生产候选中心可能落到申报日期的次日。
|
||||
- 触发条件：申报日内早凌晨分钟采用左右搜索半径，起始钟点位于前一天，而请求仍只传未调整的申报日期。
|
||||
- 根因：前端只传钟点范围与原申报日期，生产枚举将起始钟点绑定该日、较小终止钟点推到次日；候选日期本身已错误，helper 按候选日期一致计算并不能修正上游锚点。
|
||||
- 修复：本轮仅独立诊断，不越界修改开窗或既有枚举合同；另行立单。
|
||||
- 验证：纯虚构窗口探针证明申报中心候选与申报日期的日期差为 +1 日；不含真实用户资料，未标 resolved。
|
||||
- 防复发：必须从申报日/分钟经实际前端请求构建到后端枚举端到端校验日期，而非只验证钟点范围与“支持跨午夜”。
|
||||
- 相关记录：BUG-098、BUG-198、BUG-979、BUG-981。
|
||||
- 复发自：未发现同症状既有记录；BUG-198 时段开窗与 BUG-098 枚举回归仍在但不校验申报日期中心。离线 holdout 已有前日中心保护，未覆盖生产请求链。
|
||||
- 修复版本：未实施，见 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`。
|
||||
|
||||
## BUG-984 | 时段旧分数缓存不校验算法身份且聚合回执可能显示新版本
|
||||
|
||||
- 状态：investigating
|
||||
- 首次发现：2026-09-20
|
||||
- 最近更新：2026-09-20
|
||||
- 影响面：V9 `block_scan` 缓存、工具活动回执与 turn 级聚合。
|
||||
- 用户现象：升级算法后，同证据的时段模式仍可能直接返回旧分数；开始活动显示新版、成功结果实际属于旧版，聚合字段又可能展示新版。
|
||||
- 触发条件：历史时段缓存证据指纹未变；本次运行默认版本已升，而缓存算法身份仍旧。
|
||||
- 根因：`scoreAndPersistV9Candidates()` 的时段分支在版本探测之前按证据指纹提前返回；成功回执使用旧结果身份，但 SQL 将不同阶段的 `engine_version` 取字符串最大值，而不是成功结果来源。分钟模式另有环境覆盖/探测失败回退边界，不能宣称身份无条件一致。
|
||||
- 修复：未实施，当前 Dasha 单不顺带改缓存政策或 SQL；补单 `docs/tasks/TASK-rectification-cross-midnight-dasha-fix-20260920.md` 待批准后执行。
|
||||
- 验证：独立纯虚构 TS 探针使用替身 RPC/fetch，旧时段缓存返回 `cached:true`、算法尾号 -7、fetch 次数 0；真实工具调用路径记录 started 尾号 -8 / completed 尾号 -7。聚合 SQL 的 `max(engine_version)` 已核源码，未真跑 DB，因此不伪称数据库端到端通过。
|
||||
- 防复发：后续必须分别覆盖分钟/时段缓存、实际版本接口、部分环境覆盖与接口失败，成功回执必须绑定实际结果来源；历史打开与 Skill 绑定不变，不得重标或删除旧结果来掩盖问题。
|
||||
- 相关记录：BUG-427、BUG-621、BUG-981。
|
||||
- 复发自：未发现同症状既有记录；既有分钟算法身份缓存门不覆盖提前返回的时段分支，回执测试未组合新版 started 与旧缓存 completed。
|
||||
- 修复版本：未实施；本轮 T4 仅完成默认及后端身份同步，整体验收未通过。
|
||||
|
||||
Reference in New Issue
Block a user