diff --git a/docs/tasks/README.md b/docs/tasks/README.md index d9715208..79006675 100644 --- a/docs/tasks/README.md +++ b/docs/tasks/README.md @@ -294,7 +294,7 @@ | `TASK-rectification-cross-midnight-dasha-20260920.md` | — | **跨午夜候选的 Dasha 边界错一天（生产打分）**：`scoring_service.py` 调 `merge_transition_proximity()` 只传**一个** `birth_date`，该函数用它算全部候选的 Vimshottari / Narayana 起始日期，候选之间只靠 `_context_time()` 的 `HH:MM` 区分、**日期被丢掉**。窗口跨午夜时午夜后候选的 dasha 边界整体错一天。Claude 验收时在生产调用链独立复现：窗口 `23:50→00:10`、21 个候选，**恰好那 11 个跨日候选分数错、10 个同日候选逐位相同**（幅度 +0.0267 / −0.0133，本例头名未变）。算术上界 = `cap/kernel_width`，day 精度 0.067 分/件，18 件可累计约 1.2 分，而随分钟变化项总量仅约 2.1 分 —— **上界是推的不是实测，真实幅度本单必须实测**。踩中路径：`late_night` 时段 `23:00–03:59`、`unknown` `00:00–23:59`、23:45 后或 00:15 前申报的 ±15 窗。连带发现：`calculation_spec()` 不含打分实现身份，修复后同一 spec hash 对应不同分数，历史 Case 静默失去可复现性（同 BUG-427 类型）。**产品 2026-09-20 已就三点拍板：A 修、B 修完重新冻结并重跑 T1/T2、C 让新旧结果可区分。** C 的做法经查证已修正：`calculation_spec_hash` 全在 **V4** 链路、**V9 零引用**，原提案 bump `INPUT_CONTRACT_VERSION` 对真实历史无效已作废；改为随修复 bump `engine_version`（`v9EngineVersion()` 缺省串用于 started/failed；成功回执及 minute 缓存身份来自后端，旧「只写不比」假设作废），**不得动 `skill_version`**（BUG-621：open RPC 要求绑定 Skill 等于当前版本，bump 会让历史校正打不开）。硬红线：只改「按候选日期取 dasha 起始」，不得动 kernel/cap/share 任一常数；确认门不变。BUG-981 | **核心修复与 BUG-985 已 review 通过，本地合并 b27d4de9；推 staging 认证失败，端到端仍受 BUG-984 阻塞** | 实现 `aa46da10`（分支 `codex/rectification-cross-midnight-20260920`，未合入 staging）。Claude 独立 review：修复后整窗打分与**逐候选独立重算 21/21 一致**；非跨午夜分数基线 vs 修复**逐位不变**（我测半径 10 六例 + 半径 60 三例，执行方证据覆盖 19 例 / 2299 候选全部 `bytes_equal`）；kernel/cap/share/`PRECISION_WEIGHTS` 一个未动；`status=not_ready`、coverage 0、`holdout_passed()` False、官方试次 0；决策 C 执行正确（`ALGORITHM_VERSION` 7→8，`INPUT_CONTRACT_VERSION` 与 `skill_version` 未动，golden 里 `calculation_spec_hash` 不变可证）；既有断言改动均带三栏说明且为加强。**P1 阻塞**：新增的 `test_same_day_public_aa_scores_keep_pre_fix_bytes` 写死 121 个浮点分数的 SHA-256，在 Claude 机器上 ordinal 2/3 红、**基线与修复分支同样红**（非修复所致），且经 `test_rectification_cross_midnight_gate.py` re-export 落入快速门 glob —— 同 glob 基线 214 passed/0 failed、`aa46da10` 4 failed，推 staging 会让门禁红。执行方自报未通过的 BUG-984 经独立确认成立且更重：`block_scan` 只比 evidence 指纹不读打分身份，而 `late_night`(299 min)/`unknown`(1439 min) 均 >120 走该分支、又恰是最易跨午夜的窗口 | | `TASK-rectification-cross-midnight-gate-fix-20260920.md` | `PROGRESS-rectification-cross-midnight-gate-fix-20260920.md` | **review 修复单：门禁级浮点哈希断言（`aa46da10` 的合入阻塞项）**：新增回归把 121 个分数的 SHA-256 写死成字面量，于是断言范围把跨机 libm/pyswisseph 差异也圈了进去。实测该组 121 个分数**全无浮点尾噪**（`repr(s)==repr(round(s,4))` 121/121），所以差异是第 4 位真的不同，靠改序列化消不掉。同一提交刚改过的 `test_rectification_engine_memoization.py` docstring 正好写着「跨机舍入已漂 1.1e-3，不得整体 `==` 比较」——教训被引用了又被踩。执行方自己的证据 JSON 用的却是正确做法（`scores_bytes_equal` = 同机基线 vs 当前）。**根因**：要证的是相对不变量（同机基线 vs 当前），却实现成绝对不变量（当前 vs 某台机器的历史哈希）。F1 改用生产代码已有的 legacy 回退路径做同机 A/B 对照（去掉 `candidate_at` 即修复前行为），验收要求**两台浮点环境不同的机器各跑一次**、且回退核心修复后该测试仍绿（证明它守的是同日不变性而非跨午夜回归的替身）；F2 bridge 重复收集（4 failed = 2×2）；F3 查证 `block_scan` 重算是否经过被修 helper —— 会则 BUG-981 在 late_night/unknown 路径等于没上线、BUG-984 升为阻塞项；F4 记录。**硬红线：不得删测试/skip/把哈希改成本机当前值消红，不得改已验收的打分代码。** 串行：本单 → `aa46da10` 合入 → BUG-984 补单。BUG-985 | **已 review 通过；BUG-985 resolved；合入推送被 Gitea 认证阻塞，远端仍 a3577ce2** | 实现 `25232ce4`（分支 `codex/rectification-cross-midnight-gate-fix-20260920`）。F1 改为同进程 A/B：在 `scoring_service.merge_transition_proximity` 调用边界剥掉 `candidate_at` 走生产既有 legacy 回退，对比 121 个分数与整份贡献矩阵的 canonical 字节；另加 `legacy_calls == [121]` 与 `static_contexts is contexts` 两道防空转保险。Claude 复核：写死哈希字面量 **0 残留**；**第三套环境（Linux + Python 3.13，与执行方 Windows 3.11.7 不同）定向 18 条全绿** → 两机验收闭环；**回退日期修复探针：同日 3 条全绿、跨午夜相关 4 条转红**，证明同日不变性与跨午夜正确性已真正分开；快速门 glob staging `1b646659` 200 passed/0 failed → `25232ce4` 216 passed/0 failed（+16，零新增失败，总数未降）；相对合并点仅动 2 个测试文件 + 文档，`scripts/`、前端、golden、打分常数零改动。BUG-985 记录含我要求的防复发条，并正确认定为 BUG-733 同形复发。**建议 BUG-985 由 `blocked` 改 `resolved`**（证据即第三环境复跑）。环境缺口：完整快速门在 Claude 机器 120 秒超时被杀，6→4 那组数以执行方记录为准 | | `TASK-rectification-cross-midnight-dasha-fix-20260920.md` | `PROGRESS-rectification-cross-midnight-fix-20260920.md` | **BUG-984 缓存与结果身份补单（BUG-981 的端到端阻塞项）**：`scoreAndPersistCurrentEvidence()` 的 `block_scan` 分支只比 `evidenceLedgerFingerprint` 即返回 `cached:true` 与旧 `algorithmVersion`，该返回发生在 `readV9EngineScoringIdentity()` **之前**；`minute` 分支则有身份门。F3 已查证完整调用链到 `merge_transition_proximity()`，故核心修复合入后，**证据未变的历史跨午夜时段缓存命中仍返回修复前分数**——在本单闭环前不得声称跨午夜问题已修。边界已按源码收窄：`late_night`(23:00–03:59) 跨日；`unknown`(00:00–23:59) 虽 >120 分钟但**本身同日**，选中跨午夜子时段后才触发（此处修正了 Claude 先前把两者并列的说法）。产品 2026-09-20 放行且**同日拍板 F3 策略选 b**：版本接口取不到可信身份时，旧缓存**只读展示 + 显著标注「按旧算法产出」**，否决 a（重算，会把接口抖动放大成长等待，时段扫描受 `JYOTISH_HEAVY_COMPUTE_CONCURRENCY=2` 限流）与 c（照常复用，与已定原则冲突）。b 的三条边界：只读结果**服务端拒绝采用/确认**（靠删不靠藏，须有定向用例）、标注必须用户可见并对照 `VOICE.md`（涉界面同提交更新 `DESIGN.md`）、回执来源身份仍是产出它的版本。**F2 的 SQL 问题已查清并定序（A 先上 / B 兜底 / 第 10 版前必须解决）**：`engine_version` 一个字段被「部署声称的版本」（started/failed 行，取前端常量）与「实际产出结果的版本」（completed 行，命中旧缓存即旧版本）共用，聚合却用与版本先后无关的字符串 `max`。**该缺陷此前一直撞对，`aa46da10` 之后才变真错**：它把 `v9EngineVersion()` 缺省由 `rectification-v5` 改为 `…scoring-8`，started 行遂在字符串序上反超 completed 行 → 回执显示第 8 版而分数来自第 7 版缓存；已核 `deploy/`、`.gitea/` 未设 `RECTIFICATION_ENGINE_VERSION`，走缺省，**是真实行为**。第二个缺陷：实跑 `max("…-10","…-9") = "…-9"`，**该聚合在第 10 版静默反向**（现为第 8 版）。A＝started/failed 不再写版本（应用层，必做）；A 的漏洞（同 turn 多个 completed 行版本不同）**必须实测取证，不得以「应该不会」结案**；B＝聚合改取成功结果那一行（只改函数体，向后兼容）；C＝拆列本单不做。**四项全部可开工。**硬红线：不重标/不删历史结果，不 bump Skill，不改 V4 input contract，不引入按 `engineVersion` 拒绝打开历史会话。串行：BUG-985 合入 → 本单。BUG-984 | **本地完成：diagnostics追加修复后全量3575→3588全绿，标准DB40/40，Static/完整28资源gzip+0.040085%，tsc/lint通过；主会话独立DB40与最终定向40全绿。未推送，真人/部署待主会话** | `codex/rectification-cross-midnight-fix-20260920`；前置认证已解除，代码基线 `3f39bafc`、文档基线 `f09f3d80`；本轮未推送 | -| `TASK-rectification-midnight-date-anchor-20260920.md` | — | **跨午夜的日期锚点与簇跨度（BUG-982 + BUG-983 合并一单）**：两条同根——线上契约只传钟点、日期不在契约里，后端按钟点大小**猜**哪端跨日。**BUG-983 是静默算错盘**：`_candidate_datetimes()` 把起始钟点无条件绑在申报日期上，前端零补偿。Claude 实测（申报日 2000-06-15）：申报 `00:10` → 候选 `06-15 23:55`…`06-16 00:25`，**申报分钟本身落在 `06-16 00:10`，+1 天**；`00:02` 同样 +1 天；`12:00` 对照正确。受影响：申报落在午夜后半径内者（±15≈1.0%、±30≈2.1%、±60≈4.2%、±120≈8.3%）；`late_night`(23:00–03:59) 更重，其 `00:00`–`03:59` 共 240 分钟**全部落在用户没申报过的日期上**。**BUG-982 影响面比原记录大**：同缺陷在链路上出现三处（`_cluster_span` / `unionStillValidRange` / `indistinguishableWidthMinutes`），原记录只写了 Python 两处。实测跨午夜簇 `23:58/23:59/00:00` 报告宽度 **1440 分钟**（真实 3）、`23:50/23:55/00:05` 报 **1431**（真实 16）；该链经 `reportWidth` 直达 **交付卡「范围 X 分钟」**，深夜用户会看到候选其实差几分钟却被告知范围一千多分钟。**与 BUG-981 的关系**：981 让每个候选按自己日期算 Dasha 是对的，但 983 给的日期本身就错，**983 不修则 981 在申报近午夜的场景等于没上线**。§3 三个待决点：**D1 `late_night` 到底指哪两段**（按出生证明口径「6/15 深夜」两段都在 15 日，现行实现一半落在 16 日；Claude 建议先问用户，答不上退「同日两段」）、D2 申报贴近午夜时允不允许窗口跨到**前一天**（Claude 建议允许并在交付说明日期也会变，依据 Part B「真值覆盖率优先于区间宽度」）、D3 日期怎么进契约（建议加窗口相对序号）。硬红线：不调打分常数/确认门阈值；不得以排除真值换窄宽度；不得只修 `_cluster_span` 就宣称 982 已修；非跨午夜必须逐位不变且用同机 A/B（不得写死跨机浮点哈希，见 BUG-985）。沿用 BUG-982/983，不新开号 | **待产品拍板**（D1/D2/D3） | — | +| `TASK-rectification-midnight-date-anchor-20260920.md` | — | **跨午夜的日期锚点与簇跨度（BUG-982 + BUG-983 合并一单）**：两条同根——线上契约只传钟点、日期不在契约里，后端按钟点大小**猜**哪端跨日。**BUG-983 是静默算错盘**：`_candidate_datetimes()` 把起始钟点无条件绑在申报日期上，前端零补偿。Claude 实测（申报日 2000-06-15）：申报 `00:10` → 候选 `06-15 23:55`…`06-16 00:25`，**申报分钟本身落在 `06-16 00:10`，+1 天**；`00:02` 同样 +1 天；`12:00` 对照正确。受影响：申报落在午夜后半径内者（±15≈1.0%、±30≈2.1%、±60≈4.2%、±120≈8.3%）；`late_night`(23:00–03:59) 更重，其 `00:00`–`03:59` 共 240 分钟**全部落在用户没申报过的日期上**。**BUG-982 影响面比原记录大**：同缺陷在链路上出现三处（`_cluster_span` / `unionStillValidRange` / `indistinguishableWidthMinutes`），原记录只写了 Python 两处。实测跨午夜簇 `23:58/23:59/00:00` 报告宽度 **1440 分钟**（真实 3）、`23:50/23:55/00:05` 报 **1431**（真实 16）；该链经 `reportWidth` 直达 **交付卡「范围 X 分钟」**，深夜用户会看到候选其实差几分钟却被告知范围一千多分钟。**与 BUG-981 的关系**：981 让每个候选按自己日期算 Dasha 是对的，但 983 给的日期本身就错，**983 不修则 981 在申报近午夜的场景等于没上线**。**产品 2026-09-20 三点全部拍板**：D1 `late_night` **先问用户「午夜前还是午夜后」，答不上退「同日两段」`[D 00:00–03:59] ∪ [D 23:00–23:59]`，一律不得跨到 `D+1`**（连锁范围：退路产生**不连续候选集**，枚举/聚类/簇跨度/交付区间/宽度/交付卡都要支持两段，**不得用「取两段最小到最大」糊成一段**——那正是 982 的同型错误）；D2 **允许窗口跨到前一天**，但交付层必须说明「若落在 23:5x 则出生日期是前一天」，不得静默改用户的出生日期（依据 Part B B4 真值覆盖率优先）；D3 **加窗口相对序号**，排序/取首尾/算跨度一律用序号、钟点只作展示 —— 序号入契约会改候选身份与缓存指纹，**必须核对 BUG-984 的 `scoringIdentityMatches` 并确认历史结果只读不被重标**。硬红线：不调打分常数/确认门阈值；不得以排除真值换窄宽度；不得只修 `_cluster_span` 就宣称 982 已修；非跨午夜必须逐位不变且用同机 A/B（不得写死跨机浮点哈希，见 BUG-985）。沿用 BUG-982/983，不新开号 | **待领取**（三点已拍板） | — | ## 命名与归档 diff --git a/docs/tasks/TASK-rectification-midnight-date-anchor-20260920.md b/docs/tasks/TASK-rectification-midnight-date-anchor-20260920.md index e52cd021..83913ea3 100644 --- a/docs/tasks/TASK-rectification-midnight-date-anchor-20260920.md +++ b/docs/tasks/TASK-rectification-midnight-date-anchor-20260920.md @@ -1,6 +1,6 @@ # TASK · 跨午夜的日期锚点与簇跨度（BUG-982 / BUG-983，2026-09-20） -> 状态：**待产品拍板后开工**。§3 有三个待决点，其中 D1 是产品语义问题，不是技术选型。 +> 状态：**待领取**（2026-09-20 产品对 D1 / D2 / D3 全部拍板，见 §3）。 > 两条 Bug 合并成一单，因为它们**根因相同**：线上契约只传钟点字符串，没有任何一侧拥有「这一分钟属于哪一天」。分开修会产生两套互相冲突的日期表示。 ## 0. 基线与交付 @@ -79,39 +79,35 @@ if end < start: end += timedelta(days=1) `BUG-098` 记录里的「跨午夜兼容」只覆盖**逐分钟枚举**能跨日，不覆盖「枚举到的日期对不对」，也不覆盖后加的簇跨度与宽度计算。 -## 3. 决策记录（**三个待决点，未拍板不得开工**） +## 3. 决策记录 -### D1（产品语义，不是技术选型）：`late_night` 到底指哪两段？ +**2026-09-20 产品对三点全部拍板，均采纳 Claude 建议。** -用户说「我出生在 6 月 15 日，深夜」。出生证明记的是**日历日期**，所以这个人的出生瞬间在 6 月 15 日——要么是 `06-15 00:00`–`03:59`，要么是 `06-15 23:00`–`23:59`。**两段都在 15 日，不是一段跨到 16 日。** +### D1 · `late_night` 语义：**先问用户，答不上退「同日两段」** -现行实现搜的是 `D 23:00` → `D+1 03:59`，其中一半落在 16 日——**一个用户没有申报过的日期**。 +出生证明记日历日期，所以「6 月 15 日深夜」出生的人，出生瞬间必定在 15 日：要么 `00:00`–`03:59`，要么 `23:00`–`23:59`。**现行实现搜 `D 23:00` → `D+1 03:59`，一半落在用户没申报过的日期上，是错的。** -| 方案 | 含义 | 代价 | -| --- | --- | --- | -| **a. 同日两段**：`[D 00:00–03:59] ∪ [D 23:00–23:59]` | 严格按申报日期 | 候选集不连续，簇、区间、交付卡都要支持「两段」；改动最大但语义最正确 | -| **b. 维持一段，但锚到申报日**：`[D-1 23:00, D 03:59]` | 把「深夜」理解为跨夜的那一夜，且申报日是**后半夜**所在的日期 | 改动小；但当用户其实是 23:xx 出生时，又把他放到了 D-1 | -| **c. 开工前先问用户是午夜前还是午夜后** | 把歧义还给用户 | 多一次提问，但一次性消除歧义；与「先等用户说」的既有口径一致 | +- **首选**：在选 `late_night` 时追问一次「是午夜之前还是午夜之后」。答午夜前 → `[D 23:00–23:59]`；答午夜后 → `[D 00:00–03:59]`。 +- **退路**：用户说不知道 / 跳过 → 搜**同日两段** `[D 00:00–03:59] ∪ [D 23:00–23:59]`，**不得**擅自选一段，更不得跨到 `D+1`。 +- 这一问必须符合本仓既有口径：**先等用户说，不用生日推年份**；答不上来要能顺畅跳过，不得变成卡住流程的必答题。新增提问对照 `frontend/docs/VOICE.md`。 -Claude 建议 **c**，并在用户答不上来时退到 a。理由：这是真歧义，不是我们能替用户推断的；本仓既有口径是「先等用户说、不用生日推年份」，同一条原则适用。 +**连锁范围（本单必须一并处理）**：退路会产生**不连续的候选集**。以下都要支持两段而不是假定一段连续区间：候选枚举、签名聚类与簇跨度、交付区间（`unionStillValidRange`）、宽度计算、交付卡的范围表述。**不得用「取两段的最小到最大」把它糊成一段**——那正是 BUG-982 的同型错误。 -### D2：申报分钟贴近午夜时，窗口允不允许跨到**前一天**？ +### D2 · 申报贴近午夜时，**允许窗口跨到前一天** -用户说「6 月 15 日 00:10」，±15 分钟意味着真实瞬间可能是 `06-14 23:55`。**若允许，等于承认出生日期本身也不确定**；若不允许，窗口要在 `00:00` 截断。 +用户说「6 月 15 日 00:10」、±15 分钟时，真实瞬间可能是 `06-14 23:55`。**允许**窗口覆盖到前一天。 -Claude 建议**允许跨到前一天，但必须在交付时说明「若落在 23:5x，出生日期是前一天」**。理由：时间不确定就必然带来日期不确定，截断会把真值排除在外，而 `AGENTS.md` Part B 的红线是「真值覆盖率优先于区间宽度」。 +依据：时间不确定必然带来日期不确定；在 `00:00` 截断会把真值排除在窗外，而 `AGENTS.md` Part B B4 的红线是**真值覆盖率优先于区间宽度**。 -### D3（技术）：日期怎么进契约？ +**附带义务**：当交付区间或被采用的候选落在前一天时，**必须在交付层说明「若落在 23:5x，出生日期是前一天」**，不得静默改变用户的出生日期。见 T4。 -| 方案 | 做法 | 评价 | -| --- | --- | --- | -| **1. 候选带完整 ISO datetime** | 契约里不再只有 `HH:MM` | 最彻底；改动面大，涉及回执、缓存指纹、golden | -| **2. 加窗口相对序号**（0..N-1） | 排序与跨度一律用序号，钟点只作展示 | 改动集中在比较逻辑；推荐 | -| **3. 每个候选加 `day_offset`** | 钟点 + 偏移天数 | 折中，但 `day_offset` 会到处传染 | +### D3 · 日期进契约的方式：**加窗口相对序号** -Claude 建议 **2**：BUG-982 的三处全部是「需要一个可比较的序」，序号能一次解决；BUG-983 则由请求侧明确锚点解决，两者不互相纠缠。 +候选除钟点外携带一个窗口内相对序号（0..N-1）。**所有排序、取首尾、算跨度一律用序号**，钟点只用于展示。 -**注意**：任何改动都会改变候选身份与缓存指纹。必须核对是否触发 BUG-984 刚建立的身份校验（`scoringIdentityMatches`），并确认历史结果按既有规则只读，不被重标。 +这样 §1.2 的三处（`_cluster_span`、`unionStillValidRange`、`indistinguishableWidthMinutes`）一次解决；BUG-983 由请求侧明确锚点解决，两者不互相纠缠。 + +**注意（红线 3 的具体化）**：序号入契约会改变候选身份与缓存指纹。**必须核对是否触发 BUG-984 刚建立的 `scoringIdentityMatches` 校验**，并确认历史结果按既有规则**只读**、不被重标。这一条写进 T2 / T3 的验收。 ## 4. 硬红线 @@ -135,7 +131,7 @@ Claude 建议 **2**：BUG-982 的三处全部是「需要一个可比较的序 ### T2 · 修 BUG-983（日期锚点） -按 D2/D3 的拍板结果，让**申报分钟锚定在申报日期上**，窗口由此向两侧展开。请求契约需要明确表达锚点，不再让后端按钟点大小猜。 +让**申报分钟锚定在申报日期上**，窗口由此向两侧展开（D2：允许向前跨到 `D-1`）。请求契约必须明确表达锚点，不再让后端按钟点大小猜。`late_night` 按 D1 实现：追问一次，答不上退同日两段。 验收标准： - T1 的 983 组全绿。 @@ -151,9 +147,9 @@ Claude 建议 **2**：BUG-982 的三处全部是「需要一个可比较的序 - `skill_verification_report.width_minutes` 与 `confirmation_gate.indistinguishable_width_minutes` 在跨午夜场景下给出真实宽度。 - 非跨午夜场景宽度逐位不变。 -### T4 · 交付层说明（若 D2 选「允许跨前一天」） +### T4 · 交付层说明（D2 已选「允许跨前一天」，本项必做） -交付卡 / 旁白需要能说明「若落在 `23:5x`，出生日期是前一天」。文案对照 `frontend/docs/VOICE.md`；涉及界面则同一提交更新 `frontend/DESIGN.md`。 +交付卡 / 旁白必须能说明「若落在 `23:5x`，出生日期是前一天」。文案对照 `frontend/docs/VOICE.md`；涉及界面则同一提交更新 `frontend/DESIGN.md`。 ### T5 · 记录 @@ -168,7 +164,8 @@ Claude 建议 **2**：BUG-982 的三处全部是「需要一个可比较的序 1. **最先保 T2（BUG-983）**。它是静默算错盘，比宽度显示错严重得多，而且不修的话 BUG-981 在这批人身上等于没上线。 2. 其次 T3 的**交付卡那一路**（`unionStillValidRange` → `width_minutes`），它是用户直接看到的数字。 3. `indistinguishableWidthMinutes` 那一路可稍后——确认门目前被 `holdout not_ready` 挡着，宽度错不改变最终判定，但仍要修。 -4. **不得砍掉「非跨午夜逐位不变」的对照**。砍了就无法把日期修复与打分变更区分开。 +4. **D1 的追问可以先上、两段退路后上**：只要追问能覆盖绝大多数用户，不连续候选集的支持可以单独一轮。但**在两段退路就绪前，`late_night` 一律不得跨到 `D+1`**——宁可只搜 `[D 00:00–03:59]` 并说明只搜了后半夜，也不要搜到用户没申报过的日期上。 +5. **不得砍掉「非跨午夜逐位不变」的对照**。砍了就无法把日期修复与打分变更区分开。 ## 7. 开工前置命令