Jyotisha/docs/tasks/PROGRESS-rectification-engine-memoization-fix-20260915.md

PROGRESS · 等价 golden 跨机不稳（2026-09-15 / 执行 2026-09-16）

• 执行分支：codex/rectification-engine-memoization-fix-20260915
• 工作树：.worktrees/rectification-engine-memoization-fix-20260915
• 任务书：docs/tasks/TASK-rectification-engine-memoization-fix-20260915.md
• 开工 HEAD = origin/staging = 51a65d92（用户核对时是 7227b1ed，其后合入了 BUG-732）
• BUG：BUG-733（复发自 BUG-712；落库时最大号 732）

开工前置

项	结果
git status -sb 第一行	## codex/rectification-engine-memoization-fix-20260915...origin/staging
HEAD	51a65d92
BUG_HISTORY	最大号 BUG-732。本单预占 BUG-733。读完 BUG-712 / BUG-721
本机 Python	主仓 .venv 是 25 字节指针文件。本 worktree 用 Anaconda 3.11.7 --system-site-packages 建真实 venv，复用 swisseph 20230604，未升级依赖
先复现 golden	test_score_candidates_matches_baseline_golden 本机绿。live 与 golden 逐字相同：score 8.6274 / 8.6227 / 8.1701，margin_percent 5.3006。验收机上的 1.1e-3 漂移在这台 Windows / Anaconda 3.11.7 上复现不出来——golden 就是同类机器生成的。仍按任务书改比较方式，不调用 write_golden()

未改 docs/tasks/README.md 状态列。未推 staging。未改任何 scripts/ 实现。未改 tests/golden/rectification_engine_memoization_v1.json。

做了什么

条	做法
5.1	新增 test_cached_static_context_matches_uncached_fallback：同一请求、同一进程，A=带四层缓存的 static contexts，B=四键置 None。compute_event_candidate_rows 输出 ==。调用计数：A 的 calc_shadbala = 0，B = 6（3 候选 × 2 事件）。反向：test_poisoned_static_cache_diverges_from_live_rows 把第一候选的 shadbala_result 换成全零对象，分数从 12.5125 变成 12.6125，断言不再相等
5.2	test_score_candidates_matches_baseline_golden 改成分档比较。整数 / 布尔 / 字符串 / 列表身份严格相等；浮点容差 max(2e-3, 5e-4 * |expected|)，注释写明来自实测最大漂移 1.1e-3。反向：score += 1e-2 红；time = "99:99" 红
5.3	未调用 write_golden()。git diff 里该 JSON 无改动
5.4	六份检查结论见下表。同类问题只记录不修
5.5	docs/BUG_HISTORY.md 新增 BUG-733，复发自 BUG-712。证据是 5.1 同进程差分 + 两次反向验证，不是「现在绿了」

5.4 tests/golden/ 检查

文件	全精度浮点整体 ==	在哪个测试里比	怎么比
consultation_contract_keypaths_v1.json	无	tests/test_consultation_contract_golden.py	只存 keypath 与 JSON 类型（kind=keypath_types_only）。值不入库。live 是 keypath 超集 + 类型相同
ephemeris_events_raman_20260915_90d.json	无（BUG-712 已改）	tests/test_ephemeris_events.py	longitude / speed_longitude 量化到 6 位再 ==；kind / date / body / 星座字段严格相等。文件里仍存全精度，但测试不再整体 ==
golden_cases.json	无	tests/test_cli_smoke.py::test_full_reading_golden_cases_cover_user_ready_output → tests/run_golden_cases.py	路径非空、模块计数、整数不变量 ashtakavarga_sav_total == 337、日期覆盖。不是把整份引擎浮点输出整体 ==
qizheng_stem_branch_19900409.json	无（比较已量化）	tests/test_qizheng_chart_engine.py	离散字段（宫、宿、ketuMode）严格相等；siderealLon / mansionDegree 用 round(..., 2)。文件本身仍存全精度浮点（如 177.94225865978694）。若有人新写 assert result == golden 会变成 BUG-712 同类。本单只记录不修
rectification_engine_memoization_v1.json	本单之前有	tests/test_rectification_engine_memoization.py::test_score_candidates_matches_baseline_golden	改前：candidate_scores 与 decision_receipt 整体 ==。改后：离散严格、浮点容差。文件未重建
upstream_sync2/	无整体浮点 ==	见分项	relationship_einstein.json：test_upstream_sync2_goldens.py 只比键与类型。consultation_marriage_evidence_snapshot.json：shape。consultation_marriage_1990_fictional.json：test_relationship_event_class_evidence.py 比离散 Dasha 字符串。pl9_time_system_table.baseline.md：test_full_reading_conditional_dashas.py 比对 markdown 表行文本（前 5 行 ==），不是 JSON 浮点。pl9_time_system_table.md 与 pl9_export_timing.json（含 seconds: 8.647）没有任何测试读取

同类观察（不修）：qizheng golden 文件仍存全精度；ephemeris golden 文件仍存全精度（测试已量化）；upstream_sync2/pl9_export_timing.json 是无引用的浮点秒数。

测试

套件	结果
tests/test_rectification_engine_memoization.py	14 passed（原 10 + 新增 4）
tests/test_rectification_*.py	186 passed, 0 failed（14.42s）

命令使用 .\.venv\Scripts\python.exe（任务书写的 .venv/bin/python 在 Windows 不存在）。

未改任何既有断言的期望值。新增 4 条：同进程差分、缓存毒化反向、浮点 1e-2 反向、离散字段反向。原 golden 断言从整体 == 改成分档，不是放宽离散字段。未跑 run_quality_gate.py --profile quick：该 profile 在 pytest 之后会跑 npm test，本机 Windows 缺 tsx PATH（与 BUG-721 进度记录同一缺口），本单未改前端。

CHANGELOG

未改。纯测试比较方式，用户可见打分不变。

偏离

• 任务书写 .venv/bin/python，本机换成 .\.venv\Scripts\python.exe。
• 本机未能复现验收机上的 golden 红灯（舍入与生成机一致）。仍改比较方式，并保留验收机测到的 1.1e-3 作为容差依据。
• 未 git push origin HEAD:staging。
• 5.4 按让步只检查并记录，未加仓库级自动扫描守卫。