Jyotisha/docs/tasks/TASK-rectification-holdout-expansion-20260929.md

TASK · 生时校正：把开放评价集从 20 例扩到 ≥60 例（v5，2026-09-29）

基线

• origin/staging @ b9133154（写作时 head；开工时以最新 origin/staging 为准）。
• 分支 codex/rectification-holdout-expansion-20260929，工作树 .worktrees/rectification-holdout-expansion-20260929。
• 串行关系：本单是 TASK-rectification-scoring-research-20260929.md 的前置。研究单的脚手架可以在 v4 上并行开发，但它的任何"过门 / 不过门"判定必须在本单交付的 v5 上做。
• 本单不改任何生产代码，不动 scripts/research/sealed_holdout_rerun.py::PRODUCTION_FILES 的 10 个冻结文件与 frozen_scoring.files（ERR-110）。

事故实证

生时校正打分方法的每一次"过门 / 不过门"都是在 20 例上判的（references/real_case_calibration/minute_rectification_holdout_v4.json，20 例公开 Rodden-AA，84 件年精度 + 59 件日精度事件）。20 例上 1 例 = 5 个百分点：

判定	数字	实际差几例
KP 宫头子主计分（R3，09-14）判 no_benefit	±10 头名 0.35 → 0.20	3 例
精度分档闸门（09-15）判 no_benefit	±10 头名 0.80 → 0.75	1 例
V1n 分盘配权（09-26）判 no_benefit	±10 头名 0.80 → 0.85，±60 宽度 56 → 73	1 例 / 若干例
W3 分位区间（09-14）按红线不放行	±30 一例真值被挤出	1 例

这些判定都可能是对的，但都在噪声线上。定论页 docs/research/rectification_minute_resolution_closure_2026_09_14.md 的"已证伪"结论，其证据强度同样只有 20 例。

根因

v4 继承 v3 的 20 例名单（docs/research/holdout_v4_build_2026_09_14.md），只补了事件数与领域数，没有扩例数。没有一份 ≥60 例、事件与出处经人工核对、口径与本仓一致（ayanamsa raman、node mode mean）的公开评价集。

决策记录（产品 2026-09-29）

• 批准扩建到 ≥60 例（目标 80 例），新建 v5，v4 原文件不动（旧研究复跑仍要逐字节一致）。
• v5 是开放评价集（truth_hidden_from_ranker=false），用来量尺度、做留一法校准；不是封存盲测。封存盲测（sealed_holdout_rerun.py）与 reported-offset 记录不因本单改变。
• 只用公开名人：Astro-Databank Rodden AA 级（出生证 / 医院记录）。不得选入本仓任何真实用户、库主、协作者或其亲友；不得用 A/B/C/DD 级。
• 事件抽取允许用模型起草，但每条事件必须人工核对来源页并记录 URL；模型草稿不得直接进数据集。
• 本单不改打分、不改闸门、不改任何常数；不得因 v5 上的基线成绩单而顺手调参。

硬红线

1. 隐私：只用公开名人；tests/test_repo_privacy_markers.py 全绿；数据集不得含任何真实用户资料。
2. 出生资料：出生时间、地点、时区逐例回到 Astro-Databank 页核对，记录 AA 等级与页面 URL；时区/夏令时按当地历史规则换算，写明依据（v3 曾有两处日期错，见 holdout_v4_build_2026_09_14.md）。
3. 事件：每例 ≥7 件带年月事件、≥4 个领域，字段与 v4 schema 一致（domain / precision / date / source_url / independent_of_birth_source=true）；事件出处必须独立于出生资料来源。
4. 分层：名单要覆盖 —— 出生年代 ≥3 个年代段；纬度带 ≥3 档（|φ| <25° / 25–45° / >45°）；南半球 ≥8 例；出生时间落在 22:00–02:00 的 ≥6 例（跨午夜路径，BUG-981～985）；北京时区（UTC+8）≥6 例（本产品主要用户）。不满足分层要求写进 PROGRESS，不得静默。
5. 基线成绩单必须能复现旧数字：v5 的 v4 子集在 minute_resolution_sweep.py / cluster_width_probe.py 上跑出的三档头名、覆盖、宽度、并列率必须与 09-14 / 09-26 已发布的数字逐格一致；不一致先查口径，不得改旧文档。
6. 生产代码零改动；run_quality_gate.py --profile quick 与开工基线逐条一致。
7. PYTHONHASHSEED=0（ERR-111）。

任务分解

• T1 选例协议与名单（BUG-1090）
  • 写 docs/research/holdout_v5_protocol_2026_09_29.md：入选标准、分层配额、排除规则（同一家族多人只取一人；出生时间"rectified"或"from memory"一律排除）、来源记录格式。
  • 名单 ≥60（含 v4 的 20 例），每例：姓名、Astro-Databank URL、AA 等级、出生日期/时间/地点/时区依据。
  • 验收：名单文件 references/real_case_calibration/holdout_v5_roster.json；分层统计表进 PROGRESS；隐私守卫全绿。
• T2 事件抽取与核对
  • 每例 ≥7 件、≥4 领域；领域用 scripts/active_rectification_event_engine.py::DOMAIN_CONFIG 的键；精度诚实标注（year / month / day），不得把"某年"写成"某年 1 月"。
  • 每条事件记录 source_url 与核对人；模型草稿另存 _draft，不进数据集。
  • 验收：schema 校验测试 tests/test_holdout_v5_schema.py（字段、精度、领域、每例计数、URL 非空、independent_of_birth_source 全真）；抽样 10% 由 Claude 验收时二次核对来源页。
• T3 构建脚本
  • scripts/research/holdout_v5_build.py：从 roster + 事件文件生成 references/real_case_calibration/minute_rectification_holdout_v5.json，三档半径写在数据集上，口径字段（ayanamsa / node mode / 步长）显式写入。
  • 验收：两次构建逐字节一致；v4 的 20 例在 v5 中的出生资料与事件与 v4 逐字段一致（新增事件除外）。
• T4 基线成绩单
  • 线上算法在 v5 上跑 minute_resolution_sweep.py（五指标）与 cluster_width_probe.py（含淘汰的六题回放：头名、真值在区间、宽度中位、并列率、熵降），三档半径。
  • 另按 futile_collect_stop_replay.py 口径跑 truth / opposite 六格。
  • 验收：JSON 进 docs/research/holdout_v5_baseline_2026_09_29.json；v4 子集数字与已发布数字逐格一致（硬红线 5）；全集数字进 PROGRESS 表。
• T5 文档
  • docs/research/holdout_v5_build_2026_09_29.md（协议、分层统计、与 v4 差异、基线成绩单、复跑命令）；docs/research/ACTIVE_FRONTS.md 加索引；定论页 §7 之后追加"§8 v5 已建，后续判定以 v5 为准"。
  • 验收：文档齐；docs/tasks/README.md 状态板更新。

让步顺序

T1 > T2 > T3 > T4 > T5。例数 < 40 不算完成，40–59 例可先交付一版并在 PROGRESS 写明缺口与下一批计划；研究单的判定等到 ≥60 例。

开工前置命令

git fetch origin --prune
git worktree add -b codex/rectification-holdout-expansion-20260929 .worktrees/rectification-holdout-expansion-20260929 origin/staging
cd .worktrees/rectification-holdout-expansion-20260929
export PYTHONHASHSEED=0
.venv/bin/python -m pytest tests/test_repo_privacy_markers.py tests/test_minute_resolution_research.py tests/test_cluster_width_research.py -q   # 基线
.venv/bin/python scripts/research/minute_resolution_sweep.py --help

BUG 编号

开工时核对 docs/BUG_HISTORY.md 最大号（写作时 BUG-1089）。本单：BUG-1090（评价集 20 例欠力，所有打分判定在噪声线上）。由执行方以 investigating 登记，v5 交付后改 resolved，证据是 T4 成绩单与 T2 schema 测试。关联 BUG-560、BUG-1089。