Jyotisha/docs/tasks/PROGRESS-astrologer-rulings-batch2-20261003.md

PROGRESS：占星师口径第二批（D9 修饰、Tajika 年主、Narayana Rath 版）— 2026-10-03

• 任务书：docs/tasks/TASK-astrologer-rulings-batch2-20261003.md。执行方：Claude 子代理（产品负责人要求直接执行）。
• 分支 codex/astrologer-rulings-batch2-20261003，工作树 .worktrees/astrologer-rulings-batch2-20261003，基线 origin/staging = 52b3061f。未推送。
• 上游：/workspace/yinduzhanxing origin/main = c7117f92（与任务书一致；只读，未提交、未推送）。
• BUG 编号：开工时最大号 BUG-1212；本单 BUG-1213～1215。

结论

任务	结果
T1 五大人格 D9 落陷只算减弱	完成（BUG-1213）
T2 Tajika 年主 Panchadhikari	完成（BUG-1214）；同输入与上游函数逐项相同 9/9
T3 Narayana Rath 版	实现并按原书样表回放：给定原书起运宫时大运顺序与年数 36/36 全对；起运宫只对 1/3（Table 17 选出处女、原书双鱼；Table 18 平局、原书巨蟹）→ 红线 2：未接任何用户可见面与打分
T4 旧 Narayana 如实标注	完成（BUG-1215）
T5 Rath 版替换校正试算	未做（红线 2 / 让步顺序：T3 样表不过就停在 T3）；研究记录写明原因
生时校正	本单没有改动任何冻结身份文件（PRODUCTION_FILES 与 dataset frozen_scoring.files），无需重新冻结；v5 77 例改前改后逐项相同；不升打分版本

环境

项	实际
Python	无 .venv，全部用系统 python3（3.13.5）。本机用户目录装了 PyJHora 4.8.7（API 镜像与 CI 都没有）
Node	/exec-daemon/node v22.14.0（scratchpad 临时 bin 软链）；frontend/node_modules 软链到同 lockfile 的 .worktrees/consult-career-yoga-functional-20261002/frontend/node_modules
磁盘	开工 45G 可用；评测前 45G
预检	pre_work_check.py exit 0
模型 key	无 → 名人生平回测未跑（BLOCKED）
next build	未跑（node_modules 为软链，Turbopack 拒绝；本单不改页面与路由）
一次性工作树	.worktrees/batch2-baseline-52b3061f（基线）、.worktrees/batch2-eval-921b336b（改后评测），均 --detach 新建，未切换任何别人的工作树分支

提交与任务对应

任务	提交	BUG
T1	bc03bba2	BUG-1213
T2	0afcc2d9	BUG-1214
T3	7cb332bc	BUG-1215
T4	9eb22f63、693467bf（卡片字数预算补修）	BUG-1215
golden 重采	921b336b、693467bf	—
记录（BUG 历史、CHANGELOG、本文件、任务索引、BLOCKED、T5 研究记录）	最后一个 docs 提交	—

实现说明

T1（BUG-1213）

• pancha_mahapurusha.detect_pancha_mahapurusha：D9 落陷 → status: formed、d9_dignity_modifier: "weakened"、d9_sign，原因「D9 落陷，兑现减弱」，强度部分减弱。D1 条件不成立才是 not_formed（include_not_formed=True 时返回该行）。
• 「调用方都传 D9」的做法：检测器在没收到 navamsa_sign 时由经度推出 D9（与 main_yoga_detectors.with_navamsa 同公式），所以 _detect_yogas（卡片 chart.yogas）、规则引擎（报告、卡片筛选）、/api/pancha_mahapurusha（_compute_pmc）都检查，不必逐个改调用方。规则引擎行与 API 行带 d9_dignity_modifier。
• 9 位公开名人：五大人格星都不在 D9 落陷（奥巴马萨萨 D9 水瓶、嘉兰巴德拉 D9 射手），卡片与报告结论不变；golden 只多 d9_dignity_modifier: null。

T2（BUG-1214）

• 从上游 c7117f92 原样移植：calc_panchadhikari_year_lord、TRI_RASI_DAYTIME_LORDS / NIGHTTIME_LORDS、PLANET_TO_INDEX / INDEX_TO_PLANET、_PYJHORA_PVB_SIDECAR_CACHE、带岁差参数的 _resolve_year_lord_panchavargiya_score / _external_pyjhora_panchavargiya_score*、references/tajika_panchavargiya_rules.json（git blob e8c15ac3 与上游一致）及其加载器。本仓原有的三个 PyJHora 查询函数引用了未定义的名字（无调用方，所以没暴露），一并由移植修好。
• 没有移植：上游 _resolve_external_pyjhora_python 的差异（多了 .workbuddy 路径候选，AGENTS §9 不得把镜像当运行主仓）、上游 saham_daynight 的昼夜判定修改、上游 _calc_native_panchavargiya_bala（规则 JSON 的消费者，不在授权范围；年主选法本身也不用它）。规则 JSON 已入库并有加载，但目前没有消费者——列入下轮问题。
• 本地差异两处（都写在代码与 BUG 记录里）：
  1. Muntha：上游 Muntha 主候选 = 年盘上升 + 年数；本仓 Muntha = 本命上升 + 已满年数（问 3 维持）。加关键字参数 muntha_sign_idx，生产调用方传入；不传与上游一致。
  2. Panchavargiya 引擎：上游把年盘 JD 交给 PyJHora，本机有 PyJHora 时进程内调用，且不设岁差（全局状态），同一输入跨进程得分不同（实测 9 盘里 9 盘候选分数不同、1 盘年主不同）；生产与 CI 没有 PyJHora。产品路径因此一律用 native_proxy，标注「Panchavargiya 为本地近似计算」；JYOTISH_YEAR_LORD_PYJHORA_REFERENCE=1 恢复上游查询，仅研究用。
• 两个生产者（solar_return_full_report、cmd_tajika）共用 tajika_year_lord.select_annual_year_lord；cmd_tajika 现在自己算一次太阳返照盘。冲突门照常比较（测试三年同盘两侧一致）。
• 输出：candidates（上游原样）、candidate_list（来源、星、星座、吉 / 凶相位照年盘上升、Panchavargiya 分数、engine、是否当选）、selection_basis、selection_basis_text（中）/ _en、muntha_basis、source。卡片 varshesha_basis 与报告两处「Selection basis」显示这句话；英文版靠 pl9_reader_english_terms.REGEX_EN 五条模板。
• 年运里 Mudda Dasha 与 Tri-Pataka 从「年主」起排（原逻辑），所以随新年主变化——卡片 golden 的 Mudda 分段因此变了（3 张盘里 3 张 varshesha_basis 变、1 张年主变）。
• 上游 tests/test_tajika.py 没有 Panchadhikari 用例；上游 tests/test_cli_smoke.py 的两条年主用例依赖私有本地盘（domi_birth_args，没有时 skip），未移植。改为 tests/test_tajika_panchadhikari_year_lord.py（合成经度覆盖四个分支）。

9 位公开名人 2026 年年盘：本仓 vs 上游 c7117f92

同输入（同一张太阳返照盘、上游签名、不传 muntha_sign_idx、无 PyJHora）调用两边的 calc_panchadhikari_year_lord：9/9 逐项相同（上游函数在上游 scripts/ + references/ 抽出的独立目录里运行）。产品路径与上游的差别只来自 Muntha 起点：

名人	旧年主（Muntha 主）	上游年主（选法）	本仓年主（选法）	本仓 Muntha / 上游 Muntha
乔布斯	太阳	金星（凶相位最强）	金星（凶相位最强）	狮子 / 天秤
奥巴马	水星	水星（唯一吉相位）	水星（唯一吉相位）	双子 / 水瓶
泰勒	水星	水星（吉相位最强）	水星（吉相位最强）	处女 / 天秤
梦露	火星	水星（吉相位最强）	月亮（吉相位最强）	天蝎 / 双子
嘉兰	土星	火星（唯一吉相位）	火星（唯一吉相位）	水瓶 / 狮子
皮雅芙	土星	火星（唯一吉相位）	火星（唯一吉相位）	水瓶 / 处女
卡罗	月亮	土星（吉相位最强）	土星（吉相位最强）	巨蟹 / 射手
小布什	木星	月亮（凶相位最强）	月亮（凶相位最强）	双鱼 / 狮子
齐达内	火星	太阳（唯一吉相位）	火星（唯一凶相位）	天蝎 / 狮子

年主相对旧口径变了 6/9；本仓与上游不同 2/9（梦露、齐达内），都是 Muntha 起点不同造成的。

T3（BUG-1215，未接）

• 新 scripts/narayana_rath.py（不改冻结的 narayana_dasha.py，复用其中 Table 10/11/13/14、select_narayana_seed_sign、年数与双主星函数）。年数用 jaimini_odd_footed_dignity_v2（账本 upadesa_1125_1126_odd_even_count、upadesa_1127_fixed_sign_exception、upadesa_bphs_exalt_debil_adjustment），双主星 jaimini_dual_lord_source_v1（upadesa_dual_lord_strength_chain，账本标 partial）。计都在起运宫时大运把 Table 10 方向反过来（账本只给了子运表 Table 14）；子运从大运星座起 12 等分，土星在该宫用 Table 11、计都用 Table 14。第二周期 12 减首周期年数。
• 输出：profile: sanjay_rath、seed_sign、seed_basis、direction、dual_lord_rule、mahadasha（含年数）、source、status（平局为 parameter_sensitive，alternatives 列两种起法）。
• 移植（原样，blob 与上游一致）：references/oracle/sanjay_rath_narayana_book_ledger_2026_08_28.json、docs/research/sanjay_rath_narayana_book_ledger_2026_08_28.md、references/oracle/chara_narayana_book_golden_cases_2026_08_28.json。注意：任务书说三张 Rath 样表在 chara_narayana_book_golden_cases 里，实际该文件是 K.N. Rao / Goel 的 Chara、Narayana 样表；Rath 的 Table 15 / 17 / 18 在规则账本 JSON 的 golden_cases 里。两份都已移植。
• 样表盘出生资料（公开资料，fixture 注明出处）：Sri Aurobindo 1872-08-15 05:00 LMT 加尔各答；书中「标准盘」1963-08-07 21:15 IST Sambalpur；Indira Gandhi 1917-11-19 23:11 IST Allahabad。Lahiri。

样表	原书起运宫	本仓选出	顺序（给定原书起运宫）	年数（给定原书起运宫）
Table 15	巨蟹	巨蟹 ✓	12/12	12/12
Table 17	双鱼	处女 ✗	12/12	12/12
Table 18	巨蟹	平局（巨蟹 / 摩羯）	12/12（土星在巨蟹 → Table 11）	12/12

• 差距分析与两种可能的修法见 docs/research/narayana_rath_rectification_trial_2026_10_03.md。这需要占星师给口径，不能自己拟合。
• tests/test_narayana_rath_book_tables.py 把现状钉住（含「没有任何脚本导入 narayana_rath」），口径确定后同步改测试。

T4（BUG-1215）

• 新 scripts/narayana_legacy_label.py，在消费层（咨询 modules.narayana_dasha、全量解读 Step 4.13、cmd_narayana_dasha）加 profile: legacy_reference_only、algorithm_note（「旧算法（从上升起、一律顺行），待替换为 Sanjay Rath 版」及英文）、algorithm_label（「旧算法（从上升起、一律顺行）」）。narayana_dasha.py 在冻结身份里，不动（ERR-115 做法）。
• 用户可见处：咨询数据卡 timing.narayana.algorithm（原样抄短标签）；参考版报告「Narayana Dasha 交叉时间轴」段和 dasha 家族表 p89 加「算法：…」行（英文版有对照）；CLI 文本输出。读者版（reader_main）不显示 Narayana，星盘页不显示 Narayana（只有审计面板一行静态技法名），前端个人报告的「Narayana 大运」证据行读的键与引擎实际输出不符、对真实数据不出现——这三处未改。
• 卡片字数：全文标签让乔布斯婚恋卡到 12,028（上限 12,000）。卡片改抄引擎给的短标签，Narayana 子运 / 次子运行去掉 years（可由起止年龄算出）；最大卡 11,979（基线 11,983）。
• K.N. Rao：全仓用户可见文案没有挨着 Narayana 的「K.N. Rao / kn_rao」；唯一相关处是 narayana-dasha 命令行没有使用方的 --variant-profile（选项里有 kn_rao），已删。report_builder.py 的「Parashari Jyotish | KN Rao School」不涉及 Narayana，未动。

改动的既有断言（原值 / 新值 / 原因）

文件 / 测试	原值	新值	原因
tests/test_pancha_mahapurusha_main_detector.py::test_d9_debilitation_still_cancels_when_the_caller_gives_d9	给 D9 落陷 → is_valid False、cancelled；不给不查	改名 test_d9_debilitation_only_weakens：formed、weakened、原因「D9 落陷，兑现减弱」；不给也由经度推出	问 1（BUG-1213）
同文件 test_a_rejected_yoga_does_not_come_back_by_another_path	被拒样例 = 上升巨蟹木星入旺但 D9 落陷	被拒样例 = 双鱼上升、木星巨蟹第 9 宫（D1 不成立）	D9 落陷不再拒绝格局
同文件 test_reduced_yoga_reaches_the_card_with_its_reasons	土星摩羯 10°	土星摩羯 2°，断言不变	摩羯 10° 的 D9 是白羊（落陷），新规则会多一条减弱；本用例只测凶星照
tests/test_year_lord_basis_label.py 三条	「暂用 Muntha 主星；占星师口径为 Panchavargiya，待接入」；年主 == Muntha 主星	选法依据一句话（中 / 英、无中文残留）；年主与 Muntha 主星都在候选里，Muntha 用本命起点	BUG-1214
tests/test_report_reader_main.py::test_real_annual_producers_agree_without_identical_metadata	左有 year_lord_sign、右没有	两侧年主、候选、选法一致	两个生产者同一选法
同文件 test_reader_annual_cells_use_real_distinct_years_and_keep_return_dates	「Muntha 所在星座的守护星（当前本地口径）」（开工基线即失败：BUG-1212 改了该文案而本条未跟改）	每个年度都有含「年盘上升」的选法依据	BUG-1214
同文件 test_reader_annual_conflict_keeps_both_real_producer_values	「太阳返照：火星；Tajika：金星（两者不同）」	「太阳返照：火星；Tajika：月亮（两者不同）」并断言两年年主	次年年主按新选法
frontend/tests/consult-evidence-card-20260927.test.ts	—	新增一条：timing.narayana.algorithm 为短标签	BUG-1215（新增，不改旧断言）

测试

项	结果
新增 Python 测试	test_tajika_panchadhikari_year_lord.py（15）、test_narayana_rath_book_tables.py（10）、test_narayana_legacy_label.py（4），T1 新增 3 条
定向回归（五大人格、格局合并、年运包、Muntha、读者版中英、英文版、太阳返照时区、Tajika、CLI 冒烟、咨询原生层、冻结完整性 / 新鲜度）	全过；唯一失败 test_report_english_dictionary.py::test_every_han_string_has_an_english_sibling 开工基线同样失败（第一批给 mahapurusha_* 规则加的 reference_only_reason 没有英文对照），不在本单范围，未改
tests/run_all.py	102/102
run_quality_gate.py --profile quick --skip-frontend-runtime（系统 python3）	Quality gate passed，exit 0：1047 passed、1 skipped
隐私 tests/test_repo_privacy_markers.py	通过（记录提交后复跑）
tsc --noEmit	0 错
npm run lint	0 error（126 warnings，与开工同数）
npm test（Node 22.14）	开工基线 4929 项 / fail 24 / cancelled 0；收尾 4929 项 / fail 24 / cancelled 0，失败清单与基线逐条相同（24 条均为 DB / Docker / 部署类）。确认门 rectification-confirmation-gate.test.ts 通过（本单未重新冻结，读取路径无需改）。中途一次多出 1 条（卡片 12,000 字预算），已在 693467bf 修复

生时校正评测（v5 77 例）

• 命令：python3 scripts/research/holdout_v5_baseline.py --dataset v5 --out-dir <dir> --json-out <dir>/summary.json，PYTHONHASHSEED=0、JYOTISH_API_CHART_CACHE_TTL_SECONDS=0；改前 52b3061f、改后 921b336b（T1–T4 全部引擎改动之后；之后的 693467bf 只改前端、标签模块与 golden），各在一次性工作树。
• 本单无试算开关（T5 未做），「开关关闭时逐项相同」即改前改后逐项相同：

指标（v5 77 例）	±10	±30	±60
先验头名 前 / 后	0.1818 / 0.1818	0.0909 / 0.0909	0.0779 / 0.0779
六题回放头名 前 / 后	0.6364 / 0.6364	0.4935 / 0.4935	0.3117 / 0.3117
线上区间回放头名 前 / 后	0.6623 / 0.6623	0.5584 / 0.5584	0.4026 / 0.4026
覆盖（回放）前 / 后	0.987 / 0.987	0.987 / 0.987	0.987 / 0.987
中位宽度（回放）前 / 后	13 / 13	33 / 33	65 / 65
futile_collect 真值在区间（truth 方向）前 / 后	76 / 76	75 / 75	76 / 76

三段输出文件（sweep、cluster_width、合并 summary 含 futile_collect）去掉耗时与路径字段后 逐项相同（IDENTICAL ×3）。红线（任一档降 > 1pt）未触发。

• 冻结身份：本单改动的文件都不在 sealed_holdout_rerun.PRODUCTION_FILES 与 dataset frozen_scoring.files 里，test_rectification_validation_integrity_gate / test_sealed_holdout_contract_freshness 通过，无需按 ERR-110 重新冻结，rectification-confirmation-gate.test.ts 的冻结记录路径不用改。ALGORITHM_VERSION 仍为 rectification-v5-matrix-scoring-10，不涉及 BUG-621。

名人生平回测

卡片字段变了（年运依据与 Mudda 分段、Narayana 标签、子运去 years）。本机无模型 key，未跑，写入 BLOCKED.md。

其他观察（不在本单范围，未改）

• 生产里 _resolve_external_pyjhora_python 每张年盘会起一次子进程探测 PyJHora（python 与 python3 路径不同时）；产品路径现在不调用它，无影响。
• 上游 saham_daynight 的昼夜判定已改为 Hindu rising 与同一民用日窗口，本仓未同步；9 盘年主比对没受影响，Sahams 的昼夜可能受影响，建议另开同步单。
• 第一批遗留：test_report_english_dictionary 基线即失败（见上）。

下轮问占星师

1. Narayana 起运宫第二级（「木星、水星或宫主」那一级）：是只数相位，还是同宫也算？木星既是木星又是该宫主时算一次还是两次？——原书 Table 17（双鱼起）只有「同宫也算、按身份各算一次」才对得上。
2. Narayana 起运宫后续各级：前几级都打平时（Table 18 Indira：巨蟹有土星、摩羯有月亮，入旺、星座性质、宫主奇偶、大运年数都相同），下一级是「含 Atmakaraka 的宫」还是「宫主为 Atmakaraka 的宫」？原书选巨蟹（土星是 AK、在巨蟹）。各级的完整次序请给书页。
3. 计都在起运宫时大运的顺序：账本只给了子运的 Table 14；大运是否同样把 Table 10 方向倒过来？土星、计都同在起运宫时谁优先？
4. Narayana 子运起点：从大运星座本身起（Table 13），还是从大运宫主所在星座起（原书 Table 25 的例子）？
5. Tajika Panchavargiya 的算法：年主比强弱用哪一套——上游现在用的是 D1/D2/D3/D9/D12 庙旺分（本地近似），还是规则 JSON 对应的 Tajika 五分法（Graha / Uchcha / Hudda / Drekkana / Navamsha，按 Tajika 友敌关系）？若是后者，我们照上游把它接上。
6. Muntha 主候选：五类候选里的 Muntha 用「本命上升 + 已满年数」（我们）还是「年盘上升 + 年数」（上游）？9 盘里有 2 盘因此年主不同。
7. Mudda Dasha 的起点：现在从年主起排（年主一变，全年月份分段都变）。经典是否从年主起，还是从出生月宿推算？

Claude 验收（2026-10-03）

• 快速门（--skip-frontend-runtime，系统 python3）通过。T1、T2、T3 的定向测试 29 条全部通过。
• tests/test_report_english_dictionary.py：第一批在 yoga_rules.json 新加的 23 条 reference_only_reason 只有中文写法的题号（甲5 / 乙14 / 甲7），缺英文对照，这条测试因此失败。快速门不包含它，所以第一批验收没发现。补修 dda966e6，给每条加了 reference_only_reason_en。yoga_rules.json 不在校正冻结身份里，冻结新鲜度测试通过。
• 前端：tsc 0 错；lint 0 error / 126 warning；npm test 4929 项，fail 24，失败名单与第一批补修后的基线逐条相同（DB / Docker / 部署类），确认门测试通过。
• 校正打分文件（active_rectification_event_engine、rectification/、narayana_dasha.py 等）没有改动；v5 逐项相同（执行方三段对比）。
• consultation-workflow.ts 只在 timing 白名单里加了 algorithmlabel，没有改提示词。
• Rath 版：三张原书样表中只有 Table 15 起运宫对上，按红线 2 不接入任何用户可见面，T5 不做。原书起运宫给定时，顺序与年数 36 行全对，差距只在「命宫与第 7 宫谁强」的判定。已列为下轮问占星师的第 1、2 题。