Files

T

Jesse_ChenandClaude Opus 5 04479890f4 docs(tasks): research brief for house-lord and outer-planet transit rules

Measure four relaxations offline on 20 public AA cases: transit aspects to natal
house lords, tight node conjunctions, year-precision transits, and house-lord
scoring for the block stage. No production change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0193vBv6w5MV2cifdTUu9H5P

2026-09-13 16:43:47 +00:00

4.8 KiB

Raw Blame History

研究单 · 宫主触发与外行星过运能不能提高分辨力（2026-09-13）

基线：origin/staging @ 14d199e6（已部署）
分支：codex/rectification-house-lord-gochara-research-20260913
性质：离线测量，不改线上行为。有收益才另立实现单。
来源：产品负责人 2026-09-13 带回一份人工解盘推理（按宫主体系解释关系、事业、父母、搬家，并用木星/土星过运解释年份）。先量收益，再决定是否进产品。
当前 BUG 最大号 672（本单不占号）。

1. 已经有什么（开工前先确认，不要重造）

scripts/active_rectification_event_engine.py 已在 v9 计分主链里（scripts/rectification/scoring_service.py 直接 import compute_event_candidate_rows），并且已经有：

_house_lords(ascendant_index, houses)：按上升算目标宫主；
DOMAIN_CONFIG：领域 → 分盘 + 目标宫（如 relationship → D9 + 7 宫，career → D10 + 10 宫，family → D12/D7/D3 + 3/4/5/9 宫）；
functional_benefics.derive_functional_benefic_malefic：功能吉凶层；
_controlled_transit_rules：只用木星/土星，只对 day/month 精度事件，只判「过运行星落在目标宫」；
_ashtakavarga_auxiliary：有界的 SAV 辅助调整。

所以缺的不是「宫主体系」，是下面四条具体规则。

2. 要量的四条放宽

代号	改法	对应人工推理里的说法
H1	过运木星/土星与本命宫主的合冲照（容许度先取 ±3°），而不只是「落在目标宫」	「土星在摩羯一直折磨你的木星（官禄主）」「木星在巨蟹冲本命木星」「木星精准会合 6 宫主太阳」
H2	罗睺/计都与目标宫主的紧密合相（≤2°）作为该领域征象	「9 宫主入 7 宫、1° 内合罗睺 → 父亲在远方」
H3	`_controlled_transit_rules` 放宽到 `precision == "year"`（取当年年中或事件年内逐月扫描）	人工推理大量结论只有年份
H4	宫主触发用于 block 阶段选上升星座（不是选分钟）：按每个候选上升算宫主，看用户报的事件年是否落在该宫主的主限/副限或 H1 触发上	整套「双鱼上升让火星罗睺落 7 宫」的推理本质是在选上升

3. 两层指标，分开报

Block 层（预期这里才有收益）：真实上升星座是否排第一、是否进前二；相对基线的提升。

Minute 层（预期没有收益，重点是不得变差）：头名命中率与剩余范围宽度相对基线的变化。过运与本命行星位置在半小时内几乎不动，所以 H1～H3 对分钟层大概率是零信息；若测量结果显示分钟层有收益，必须先排查是不是把上升相关的量混进去了，不得直接当成好消息。

4. 数据与方法

数据：references/real_case_calibration/minute_rectification_holdout_v3.json（20 例公开 AA，source_audit_status=invalidated_after_replay，只作开发集趋势，不是发布指标）。
基线：生产 compute_event_candidate_rows 原样。
放宽项只在研究脚本里以临时 patch 实现，单项与组合各跑一遍。
Block 层：对每例取 ±2 小时窗内的各上升星座代表时刻，按用户事件打分，记录真实上升排名。
Minute 层：沿用 probe_supply_after_six.py 的回放口径，便于与上一份研究横向比较。

5. 交付

scripts/research/house_lord_gochara_supply.py + 结果表 docs/research/house_lord_gochara_2026_09_13.md：每个放宽项单独与组合，两层指标分列。
结论只写三种：有收益（block 层真实上升 top-1 提升且 minute 层不降）→ 立实现单；无收益 → 关闭；不确定 → 说明缺什么数据。
若 H1/H2 的容许度是结论的关键，附容许度敏感性（±1° / ±3° / ±5°）。

6. 硬红线

不得改线上 active_rectification_event_engine.py、scoring_service.py 的默认行为；研究脚本不得接进 API。
不得放宽既有置信度口径、确认门、SCORE_DELTA。
过运不得用于分钟级结论：结论文档里必须明写这一条，实现单也要继承。
不得把任何真实私人出生资料写进仓库（任务书、脚本、测试、结果表、Bug 历史都不行）。本单的来源是一次人工解盘，只取方法，不取案例；示例一律用公开 AA 数据。
三大外部参照引擎（PyJHora / VedAstro / jyotishganit）如参与交叉，保持许可证边界；无法稳定调用就写成 blocked，不得静默跳过。

7. 开工前置命令

git fetch origin --prune
git worktree add -b codex/rectification-house-lord-gochara-research-20260913 .worktrees/rectification-house-lord-gochara-research-20260913 origin/staging
.venv/bin/python -m pytest tests/test_active_rectification_event_engine.py -q   # 基线须先绿

4.8 KiB Raw Blame History Unescape Escape