Jyotisha/TASK-rectification-tails-20260901.md

任务书 · Round A/2 收尾小尾巴：存量断言、存量快照重算、真实环境点测单（2026-09-01）

基线：origin/staging @ 8743dcb1。

0. 背景

Round A（20df8c60）与 Round 2（8743dcb1）已验收：tsc 通过、前端 rectification-*.test.ts 738 项 0 fail、skill-registry 16/16、红线 grep 零命中、引擎相关 Python 测试 77 项中 76 过。本轮只处理验收时发现的三个尾巴，不改动两轮已落地的策略语义。

1. 硬红线

1. 不改 deliveryCapability / canConfirmExactMinute / 引擎门语义——Round A/2 的策略一律不动。
2. 不改 .gitea/workflows/** 的触发条件之外的内容；任务 B 若涉及 CI 配置，只允许增加被漏跑的测试路径，不得移除或放宽既有检查。
3. cd frontend && ./node_modules/.bin/tsc --noEmit 通过（不要用 npx tsc）；前端 rectification-*.test.ts 不低于 738 且 fail=0。
4. Python 测试用仓库 .venv（python3 -m venv .venv && .venv/bin/pip install -r requirements.txt；系统缺 python3-dev/g++ 时先装，否则 pyswisseph 编译失败）。
5. 无凭据不得声称任务 C 已执行；把点测单原样交给有权限的人。

任务 A（P1）· 修陈旧断言：window_scan transitions 的 from_sign/to_sign

tests/test_rectification_diagnostics_clusters.py 的 test_window_scan_reports_d9_diversity_with_sign_names 现红：断言期望 transitions 只有 layer/at/user_meaning，而 window_scan 实际早已输出 from_sign/to_sign（生产快照可证， 且该失败在 de84f069 基线上即可复现——非 Round A/2 引入）。

• 修法：给期望值补上 from_sign/to_sign 两个字段（以引擎实际输出为准，不要反过来删字段——from_sign/to_sign 是前端 varga 对比展示在用的公开合同）。
• 修完跑：PYTHONPATH="$PWD:$PWD/scripts" .venv/bin/python -m unittest discover -s tests -p "test_*rectification*.py"，要求全绿（77+ 项 0 fail）。

任务 B（P1）· 查并补 CI 漏跑的 Python 测试

上述断言红了却无人发现，说明 CI 没有跑 tests/test_*rectification*.py 这批（或跑了但结果被忽略）。

1. 检查 .gitea/workflows/** 与相关脚本，确认 Python 引擎测试是否在任何 pipeline 中执行；把结论（在哪个 workflow、哪一步、为何漏）写进 PR。
2. 若确实漏跑：在既有 CI 中增加一步跑 tests/test_*rectification*.py（含 pyswisseph 依赖安装或使用现成镜像）；若 CI 环境装不了 swisseph，至少加纯逻辑子集（test_rectification_engine_convergence.py 等不依赖历表的用例）并在 PR 里说明取舍。
3. 红线 2：只增不减。

任务 C（P0，人工）· 真实环境点测单

两轮 commit 均未做真实环境验证（BUG-463 已如实注明）。部署 staging 后按单执行，逐项记录：

1. 新账号开 case：opening 自然开场，无固定问卷倾倒。
2. 依次提供 3 个领域、5 条带年份/月份事件（含至少 1 条日级），确认逐条 confirmed、复述用 display_date_label。
3. 答完服务器区分题；期间任意时刻 current_question 非空或已可采用（非终态出口闸）。
4. occupation 被问到后回答或拒答；随后候选卡出现，can_adopt=true、can_confirm_exact_minute=false。
5. 点采用：RPC 成功、状态 candidate_accepted、写入 accepted（不是 confirmed）、进入 verify_adopted_time 核前事（最多两件）。
6. 前事核对"对不上"路径：可改选其他候选。
7. 采用后叙述包含可信区间 + 代表分钟 + "不是已确认唯一出生分钟"边界句；若有 prospective_probes，出现前瞻窗口叙述。
8. 事故 case f83d9b42（如仍可访问）：GET 刷新后应直接可采用；采用成功后记录。
9. 新证据触发重算后，receipt algorithm_version 应为 rectification-v5-matrix-scoring-7、policy_version 为 ...-v3，audit 表出现"换运贴近度"行。

任何一项不符，开新 BUG 记录，不要现场改代码。

任务 D（P2）· 存量快照按新引擎重算的触达

现状：scoreableSnapshotCurrentFromDossier（decision-from-dossier.ts:327 附近）构造 stored/current 时两侧 scoringPolicyVersion 取自同一快照，policy v2→v3 在该路径检测不到；存量 case 要等下一次证据/答案变化触发 compare 才会用 v7 引擎重打分。采用不受影响（receipt accept_allowed 已可用），受影响的只是换运贴近度的重打分时机。

按影响小到大三选一实现（在 PR 里说明选择理由）：

1. 推荐：在服务端 compare 触发判断处（tool-service 相同指纹跳过 compare 的路径）把"stored policy_version ≠ 引擎当前版本"也视为需要重算的条件——引擎当前版本从 /api/rectification/v5/score 响应或既有 RECTIFICATION_ENGINE_VERSION 配置获得，不要在 TS 里硬编码 v3 字符串常量。
2. 或：给 case GET/turn 路径加"快照 policy 落后即标 scoring_policy_changed 过期"，复用 snapshot-source.ts 已有的过期原因与文案。
3. 或（最小）：只写一份运维说明：存量 case 在下一次证据变化时自然升级，不做代码改动——若选此项，必须在 PR 里论证为什么可接受。

约束：重算必须走既有 compare 链路与幂等键，不得静默批量后台重算所有 case（成本与计费边界）；重算后旧 result 走既有 invalidated_at/superseded 语义。

验收标准

1. 任务 A：Python rectification 测试全绿（77+ 项 0 fail），贴前后输出。
2. 任务 B：CI 结论写进 PR；若补了 workflow，贴一次绿色运行记录。
3. 任务 C：点测单逐项结果（执行人、时间、每项 pass/fail）附在 PR 或运维记录。
4. 任务 D：所选方案 + 理由 + 对应测试（方案 1/2 需要新增至少一条"policy 落后触发重算/过期"的断言）。
5. tsc --noEmit exit 0；前端 rectification-*.test.ts ≥738 且 fail=0；skill-registry.test.ts 16/16。