docs(tasks): BUG-984 的 F3 策略拍板选 b,四项全部可开工
产品 2026-09-20 拍板:版本接口取不到可信身份时,旧缓存只读展示并显著 标注「按旧算法产出」,不拒绝重算(否决 a)、不照常复用(否决 c)。 写入 b 的三条边界:只读结果必须由服务端拒绝采用/确认且要有定向用例 (入口靠删不靠藏);标注必须用户可见并对照 VOICE.md,涉界面同提交更新 DESIGN.md;回执来源身份仍须是产出它的版本,不被开始阶段版本覆盖。 SQL 迁移不放开:F2 优先应用层解决,做不到先在进度记录写明原因并停下 报告,获准后再做且必须向后兼容并真跑 test:db。 F3 解锁,本单四项全部可开工。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0199rbQDTsUbCVw84wc8BTFe
This commit is contained in:
co-authored by
Claude Opus 5
parent
0ca3871dd8
commit
a3577ce2fa
@@ -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()` 缺省串,全仓只写不比、无相等性门控),**不得动 `skill_version`**(BUG-621:open RPC 要求绑定 Skill 等于当前版本,bump 会让历史校正打不开)。硬红线:只改「按候选日期取 dasha 起始」,不得动 kernel/cap/share 任一常数;确认门不变。BUG-981 | **已 review:核心修复通过,但暂不合入** —— 阻塞于 `TASK-rectification-cross-midnight-gate-fix-20260920.md`(BUG-985) | 实现 `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` | — | **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 通过(2026-09-20,Claude 独立复跑)**,待合入 staging | 实现 `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 放行:**F1/F2/F4 可立即开工**;**F3 卡在一条未拍板策略**——版本接口取不到可信身份时旧缓存该拒绝重算(a)还是只读展示并标注(b),Claude 建议 b(a 会把接口抖动放大成长等待,且时段扫描受 `JYOTISH_HEAVY_COMPUTE_CONCURRENCY=2` 限流),选 b 须确认旧结果不可被 `accepted`。硬红线:不重标/不删历史结果,不 bump Skill,不改 V4 input contract,不引入按 `engineVersion` 拒绝打开历史会话。串行:BUG-985 合入 → 本单。BUG-984 | **待领取**(F3 待拍板) | — |
|
||||
| `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 | **待领取**(四项全部可开工) | — |
|
||||
|
||||
## 命名与归档
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# TASK · 跨午夜修复验收补单:缓存与结果身份(2026-09-20)
|
||||
|
||||
> 状态:**待领取**(2026-09-20 产品放行)。**F1 / F2 / F4 可立即开工**;只有 F3 依赖 §3 中仍未拍板的一条策略,未拍板前不得实施 F3。
|
||||
> 状态:**待领取,四项全部可开工**(2026-09-20 产品放行,F3 策略已于同日拍板选 b,见 §3.2)。
|
||||
> 本单是 BUG-981 的**端到端验收阻塞项**(F3 调用链已查证,见 §0):核心修复合入后,新建 / 无缓存 / 证据变化的 Case 走已修路径,但证据未变的历史跨午夜时段缓存命中仍返回修复前分数。在本单闭环前,对外只能说「新算的会对」,**不得声称跨午夜问题已修**。
|
||||
|
||||
## 0. 基线与串行依赖
|
||||
@@ -37,21 +37,21 @@
|
||||
|
||||
由此可直接开工的是 F1(先红测时段旧缓存)、F2(成功回执身份)、F4(回归、记录、部署)。这三项不依赖 §3.2 的未决点。
|
||||
|
||||
### 3.2 未定(**只卡 F3,未拍板不得实施**)
|
||||
### 3.2 已定:版本接口取不到可信身份时,旧缓存**只读展示并标注**(2026-09-20 产品拍板选 b)
|
||||
|
||||
**版本接口(`readV9EngineScoringIdentity()`)取不到可信当前身份时,旧缓存怎么办?**
|
||||
`readV9EngineScoringIdentity()` 取不到可信当前身份时:
|
||||
|
||||
| 方案 | 行为 | 代价 |
|
||||
| --- | --- | --- |
|
||||
| a. 拒绝复用,强制重算 | 身份不明即不信旧结果 | 版本接口抖动会让用户等一次完整重算;时段扫描是重计算,`JYOTISH_HEAVY_COMPUTE_CONCURRENCY` 默认 2,可能排队或 429 |
|
||||
| b. 只读展示旧结果并显著标注「按旧算法产出」 | 不阻塞用户,但不把旧结果算作当前已验证 | 需要一处用户可见文案;要确保它不进入采用 / 确认路径 |
|
||||
| c. 照常复用 | 无额外成本 | 与 §3.1 已定原则直接冲突,**不在候选内** |
|
||||
- **不拒绝、不强制重算**(否决 a)。理由:时段扫描是重计算且受 `JYOTISH_HEAVY_COMPUTE_CONCURRENCY`(默认 2)限流,把一次外部接口抖动放大成用户侧长等待,代价与本单要防的风险不对等。
|
||||
- **不照常复用**(否决 c,与 §3.1 直接冲突)。
|
||||
- **采用 b**:旧结果可以**只读展示**,但必须显著标注为「按旧算法产出」,且**不得被当作当前已验证结果**。
|
||||
|
||||
**Claude 建议 b。** 理由:a 会把一次外部接口抖动放大成用户侧的长等待,而本单要防的是「把旧结果冒充成当前已验证结果」,不是「不许看到旧结果」;b 同时满足 §3.1 与 §4 的红线。若选 b,文案需对照 `frontend/docs/VOICE.md`,且必须确认旧结果不可被采用(`accepted`)——这条写进 F3 验收。
|
||||
b 的三条边界,违反任一条即本单不通过:
|
||||
|
||||
**是否新增向后兼容 SQL 迁移**(用于把成功回执身份与聚合 `max(engine_version)` 解耦):只有在 F2 无法在应用层解决时才做;若做,按 §4 必须向后兼容当前已部署版本并真跑 `npm run test:db`。是否允许动 SQL 一并在本节拍板。
|
||||
1. **只读结果不得进入采用 / 确认路径。** 它不能被 `accepted`,更不能被 `confirmed`;交付卡、候选选择等任何写入入口都不得接受它。
|
||||
2. **标注必须是用户可见的,不是只写进回执。** 文案先对照 `frontend/docs/VOICE.md`;若涉及界面呈现,同一提交内更新 `frontend/DESIGN.md`(`AGENTS.md` §4)。
|
||||
3. **不得因为「只读」就放宽身份记录**:回执里该结果的来源身份仍必须是产出它的那个版本,不得被开始阶段的当前版本覆盖(这与 F2 是同一条原则)。
|
||||
|
||||
未拍板前,F3 只能做到「把四种状态(无覆盖 / 完整覆盖 / 部分覆盖 / 接口超时或错误)各自的当前行为测出来并记录」,不得写入新策略。
|
||||
**SQL 迁移**:F2 优先在应用层解决。确实无法在应用层解开「成功回执身份 vs 聚合 `max(engine_version)`」时,**不要自行开迁移,先在进度记录里写清为什么应用层做不到并停下来报告**;获准后再做,且按 §4 必须向后兼容当前已部署版本并真跑 `npm run test:db`。
|
||||
|
||||
## 4. 硬红线
|
||||
|
||||
@@ -71,9 +71,16 @@
|
||||
|
||||
覆盖 started 新版本 / succeeded 旧缓存版本、diagnostics、失败重试与历史回执。用户看到的成功结果身份必须来自该成功结果,不能由字符串 `max` 决定。历史回执保持原值且旧会话仍可打开。若动 SQL,新增兼容迁移并真跑 `npm run test:db`。
|
||||
|
||||
### F3 · 失败与覆盖边界
|
||||
### F3 · 失败与覆盖边界(策略已定为 b,见 §3.2)
|
||||
|
||||
分别测试无环境覆盖、完整覆盖、部分覆盖、版本接口超时/错误。按已批准策略说明何时重算、何时只读旧结果、何时拒绝复用;每种状态不得混淆当前身份与来源身份。
|
||||
分别测试无环境覆盖、完整覆盖、部分覆盖、版本接口超时 / 错误四种状态。每种状态不得混淆当前身份与来源身份。
|
||||
|
||||
验收标准:
|
||||
|
||||
- 四种状态各有定向用例,断言身份取不到时走**只读展示**而非重算或静默复用。
|
||||
- **必须有一条用例断言:只读结果调用采用路径会被拒绝。** 不是「界面上没有按钮」,是服务端拒绝——参照本仓既有做法,入口靠删不靠藏。
|
||||
- 标注文案在用户可见层出现,且与 `frontend/docs/VOICE.md` 对照过;涉及界面则同一提交更新 `frontend/DESIGN.md`。
|
||||
- 只读结果的回执来源身份仍是产出它的版本,不被开始阶段版本覆盖。
|
||||
|
||||
### F4 · 回归、记录与部署
|
||||
|
||||
|
||||
Reference in New Issue
Block a user