docs(tasks): 把 F2 的 engine_version 聚合缺陷查清并定序
复核结果写进 F2：engine_version 一个字段被两种含义共用——started/failed
行写前端常量（部署声称的版本），completed 行写实际产出结果的版本（命中
旧缓存即旧版本）——而聚合用与版本先后无关的字符串 max 跨行取值。
该缺陷此前一直撞对：改动前 started 写 rectification-v5，短于 completed
的 ...scoring-7，max 恰好选中正确的那行。aa46da10 把 v9EngineVersion()
缺省改成 ...scoring-8 之后，started 行在字符串序上反超，回执遂显示第 8 版
而分数实际来自第 7 版缓存。已核部署未设该环境变量，走缺省，是真实行为。
第二个缺陷：max("...-10","...-9") 实跑得到 "...-9"，聚合在第 10 版静默
反向，当前第 8 版。
定序 A 先上（started/failed 不再写版本，应用层）、B 兜底（聚合改取成功
结果那一行，只改函数体）、C 拆列本单不做；第 10 版前必须解决。A 的已知
漏洞要求实测取证，不得以「应该不会」结案，并新增一条针对版本 10 反向的
回归。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0199rbQDTsUbCVw84wc8BTFe
This commit is contained in:
Jesse_Chen
co-authored by
Claude Opus 5
Claude Opus 5
parent
3f39bafc4a
commit
f09f3d809a
@@ -293,7 +293,7 @@
|
||||
| `TASK-rectification-validation-integrity-20260920.md` | `PROGRESS-rectification-validation-20260920.md` | **生时校正验证体系补缺（纯离线评测，不改打分不改产品）**：会议要求把「推断真实出生时间」与「用户认可的参考盘」分开证明。核对结论——**产品口径侧四条已落地**（`accepted`≠`confirmed` 两条写入路径、确认门 fail-closed 且 `holdout` 为 `not_ready` 使 `confirmation_allowed` 不可能为真、采用不写 `reported_birth_time`、无任何把采用率当准确率的指标；运行时也无按生日走捷径的分支）；**缺口全在评测本身**。三条：① 封存契约 `rectification_sealed_holdout.v1.json` 的三个打分哈希互不相同（封存 `f41c298d` / 契约记录 `99730c84` / 基线实测 `b15d9ea1`），`official_eval_trial_count: 0`——当前实现**从未产出过一次有效官方盲测**，唯一跑过那次已被资料审计作废（top-1 `0.15`，发布门要 `0.60`），可见的 `0.45` 自带「不得当发布指标」标记（BUG-978）；② 全部离线评测的候选窗**以真值为圆心**（`_candidate_moments()`、`request_from_case()` 的 `true_time`），生产以申报时间为圆心（`ENGINE_SEARCH_RADIUS_MINUTES = 15`）——「真值掉出窗外」这一失败模式从不可见（BUG-979）；③ v3 封存但每例仅 3 事件、v4 有 7+ 事件却已被看过并用于调参，**无口径干净又贴近真实会话的封存集**；六题回放的 `0.80/0.55/0.35` 是「真值方向最优答」的上帝视角上界，±30/±60 仍低于发布门（BUG-980）。T1 申报偏差敏感性 sweep、T2 有效重跑 + 契约对齐 + **防复发新测试**、T3 只出 v5 采集协议、T4 记录。**硬红线：不得改 12 个打分文件、不得用封存集调参、不得把 `status` 改 `ready`。** 家庭信息（父母职业/兄弟姐妹）在拿到基线数字前不开工——现有七领域全是带日期事件，静态属性没有输入口。前置：owner-case-purge 三提交仍未合入 staging。BUG-978～980 | **已验收通过（2026-09-20，Claude 独立复算）**；独立盲测仍 blocked；门禁/部署待核验 | `932f2fff`。Claude 独立复核：T1 完整重跑 900 组合**逐例 8 字段 0 差异**、summary/specification 全等，另从 900 条逐例重算 45 格表与发布表逐位相同；T2 独立复跑 0.45/0.50/6.45/0/1.0/0.0 与哈希全序 0.05/0.10 全部一致；12 个打分文件字节未动、`status=not_ready`、`confirmation_coverage_rate=0`、实跑 `holdout_passed()`=False；新增/触及 Python 测试本机 38 条全绿；freshness 测试比对时排除 `frozen_at_utc`（BUG-693/694 教训已用上）。**执行方正确推翻任务书 T2.3**：「首次口径干净的官方盲测」与 BUG-428 防复发（已看过结果的案例不得再计入盲测）冲突，已核 BUG-428 原文，是任务书写错。环境缺口：本机 frontend 无 node_modules，tsc/lint/npm test/build 未能复核，采信执行方自报。遗留 → `TASK-rectification-cross-midnight-dasha-20260920.md`（BUG-981） |
|
||||
| `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` | — | **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`）、回执来源身份仍是产出它的版本。SQL 由 F2 优先在应用层解决，做不到**先停下报告**再定，不得自行开迁移。**四项全部可开工。**硬红线：不重标/不删历史结果，不 bump Skill，不改 V4 input contract，不引入按 `engineVersion` 拒绝打开历史会话。串行：BUG-985 合入 → 本单。BUG-984 | **待领取**（四项全部可开工） | — |
|
||||
| `TASK-rectification-cross-midnight-dasha-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 | **待领取**（四项全部可开工） | — |
|
||||
|
||||
## 命名与归档
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ b 的三条边界，违反任一条即本单不通过：
|
||||
2. **标注必须是用户可见的，不是只写进回执。** 文案先对照 `frontend/docs/VOICE.md`；若涉及界面呈现，同一提交内更新 `frontend/DESIGN.md`（`AGENTS.md` §4）。
|
||||
3. **不得因为「只读」就放宽身份记录**：回执里该结果的来源身份仍必须是产出它的那个版本，不得被开始阶段的当前版本覆盖（这与 F2 是同一条原则）。
|
||||
|
||||
**SQL 迁移**：F2 优先在应用层解决。确实无法在应用层解开「成功回执身份 vs 聚合 `max(engine_version)`」时，**不要自行开迁移，先在进度记录里写清为什么应用层做不到并停下来报告**；获准后再做，且按 §4 必须向后兼容当前已部署版本并真跑 `npm run test:db`。
|
||||
**SQL 迁移**：执行顺序已定为 **A 先上、B 兜底、第 10 版前必须解决**，展开见 F2。A 是应用层改动，不需要迁移；是否升到 B（改聚合函数体）由 F2 的实测结论决定，**不得跳过 A 直接开迁移**。若判定需要 B，按 §4 必须向后兼容当前已部署版本并真跑 `npm run test:db`（需 Docker，无 Docker 即写成环境缺口，不得宣称通过）。方案 C（拆列）本单不做。
|
||||
|
||||
## 4. 硬红线
|
||||
|
||||
@@ -69,7 +69,45 @@ b 的三条边界，违反任一条即本单不通过：
|
||||
|
||||
### F2 · 成功回执身份
|
||||
|
||||
覆盖 started 新版本 / succeeded 旧缓存版本、diagnostics、失败重试与历史回执。用户看到的成功结果身份必须来自该成功结果，不能由字符串 `max` 决定。历史回执保持原值且旧会话仍可打开。若动 SQL，新增兼容迁移并真跑 `npm run test:db`。
|
||||
#### 事实（Claude 2026-09-20 在 `25232ce4` 上复核）
|
||||
|
||||
同一个 `engine_version` 字段被两种含义共用，而聚合用的是与版本先后无关的字符串 `max`：
|
||||
|
||||
| 写入点 | 值的来源 | 真实含义 |
|
||||
| --- | --- | --- |
|
||||
| `rectification-v9-tools.ts` 的 `started` 回执（compare / diagnostics）与 `failReceipt` | `v9EngineVersion()`，即前端常量 | 「当前部署声称是哪个版本」 |
|
||||
| `completed` 回执 | `scored.persisted.algorithmVersion`（compare）、`diagnostics.algorithmVersion` | 「实际产出这个结果的版本」——命中旧缓存时就是旧版本 |
|
||||
|
||||
`frontend/supabase/migrations/20260902020000_rectification_tool_activity_timing.sql` 用 `max(tr.engine_version)` 跨该 turn 的全部回执行取值，不区分上表两种含义。
|
||||
|
||||
**这个缺陷此前一直存在，但恰好撞对；`aa46da10` 之后才变成真错误：**
|
||||
|
||||
| 时期 | started 行 | completed 行（命中旧缓存） | `max` 选中 | 正确性 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `aa46da10` 之前 | `rectification-v5` | `rectification-v5-matrix-scoring-7` | `…-7` | 碰巧正确 |
|
||||
| `aa46da10` 之后 | `rectification-v5-matrix-scoring-8` | `rectification-v5-matrix-scoring-7` | **`…-8`** | **错**：回执显示第 8 版，分数实际来自第 7 版缓存 |
|
||||
|
||||
`aa46da10` 把 `v9EngineVersion()` 的缺省从 `rectification-v5` 改成 `rectification-v5-matrix-scoring-8`（`engine-client.ts`），于是 started 行在字符串比较里反超了 completed 行。已核 `deploy/` 与 `.gitea/` **未设** `RECTIFICATION_ENGINE_VERSION`，走的就是这个缺省——**是真实行为，不是假设**。
|
||||
|
||||
**第二个缺陷**：字符串 `max` ≠ 版本新旧。实跑验证 `max("…scoring-10", "…scoring-9") = "…scoring-9"`。**该聚合在第 10 版会静默反向**，当前是第 8 版。
|
||||
|
||||
#### 执行顺序：A 先上、B 兜底、第 10 版前必须解决
|
||||
|
||||
**A（应用层，本单必做）**：`started` 与 `failed` 回执不再写 `engine_version`，只有 `completed` 写。消除最主要的错误来源，不需要迁移。
|
||||
|
||||
**A 的已知漏洞，必须实测而不是假设**：同一 turn 内若出现**多个 completed 行且版本不同**（例如 compare 命中旧缓存记 `…-7`、diagnostics 重新算记 `…-8`），`max` 仍会挑错。F2 必须给出这种组合**是否会真实出现**的证据：能构造出来就升 B，构造不出来就在进度记录里写明判定依据与边界，不得以「应该不会」结案。
|
||||
|
||||
**B（改聚合函数体，兜底）**：把 `max(engine_version)` 改成取该 turn **成功结果那一行**的身份（例如最近一条 `status='completed'` 且 `engine_version is not null` 的行），不再跨含义取最大值。只改函数体、不改表结构，向后兼容。
|
||||
|
||||
**C（拆成两列：部署版本 / 结果出处）本单不做**，但「第 10 版反向」给 B 定了时限：迟早要改，不应拖过第 10 版。若 F2 判定必须升 B，顺带把版本比较不再依赖字符串序这件事一并解决。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
- 覆盖 started 新版本 / completed 旧缓存版本、diagnostics、失败重试与历史回执。
|
||||
- 用户看到的成功结果身份必须来自**该成功结果**，不能由字符串 `max` 决定。
|
||||
- 必须有一条针对「第 10 版反向」的回归：构造 `…-9` 与 `…-10` 两行，断言聚合结果不是按字符串序挑的。
|
||||
- 历史回执保持原值，旧会话仍可打开（`BUG-621` 回归必跑）。
|
||||
- 若升 B：新增兼容迁移、不原地改已应用迁移、真跑 `npm run test:db`。
|
||||
|
||||
### F3 · 失败与覆盖边界（策略已定为 b，见 §3.2）
|
||||
|
||||
|
||||
Reference in New Issue
Block a user