Jyotisha/docs/research/upstream_notice_2026_10_16.md

致 skill 作者：10-16 版的代码问题与口径问题（2026-10-16）

核对对象：yinduzhanxing 3c2dad95（main，2026-10-16）。

您好，谢谢 10-08 以来的这批修正（Pinda、Argala、Bhava Bala、Avastha、KP、Saham、Yoga、Dasha）。我们逐条对照了自己的代码，大部分会跟进。下面分两部分：

• 第一部分：在 3c2dad95 上仍然存在的代码问题，都能用贵方自己的测试或一行命令复现。
• 第二部分：几处口径选择，需要您告诉我们出处或怎么取舍。

两部分都有答复后，我们再同步。

---

第一部分　代码问题

1. 星宿大运拆解：第一大运的小运被按「剩余年数」重新切分（贵方自己的测试失败）

• 位置：nakshatra_dasha.calc_nakshatra_dasha_breakdown。第一大运把 first_remaining（出生时剩余的年数）交给 _calc_vimshottari_antardasha_full，等于把剩余这段当成一个完整大运，重新切成 9 段小运。
• 正确做法：小运从完整大运的真实起点开始排，排完再裁到出生之后。cmd_dasha 在 3c2dad95 里已经这么做了，这里漏了。
• 复现：python3 -m pytest -q tests/test_nakshatra_native_dasha_clock.py::test_first_remaining_md_is_not_repartitioned_into_new_ads，在 3c2dad95 上失败。用例里月亮在 Ashwini 中点，当前小运应为 Rahu，引擎给的是 Ketu。
• 影响：仍处在第一大运的人（儿童、青少年；第一大运很长时成年人也会），「当前小运」和随后的 Tara 分析会落在错的星上。

2. 星宿起点上的大运余额：3c2dad95 只修好了 22/27

• 复现：python3 -m pytest -q tests/test_nakshatra_native_dasha_clock.py，test_native_vimshottari_exact_star_birth_balance 的 [7] [11] [14] [22] [25] 五项失败。
• 现象：月亮恰好在这几个星宿的起点时，序号被判到前一个星宿，大运表里多出一行零长度的大运。
• 原因：星宿序号和星宿内进度仍然分开算（一个用除法取整，一个用取余），浮点误差下两者不一致。
• 建议：从同一个量一次算出序号和进度（例如 q = lon / span；idx = floor(q)；progress = q - idx），再做边界夹紧：progress 极接近 1 时进位到下一星宿。27 个起点应全部通过。

3. dasha_analyzer.lon_to_nakshatra 仍是旧写法

• 这个函数还是 idx = int(moon_lon / nak_span)、progress = (moon_lon % nak_span) / nak_span，与第 2 条修复前的写法相同，这次没有一起改。
• 它在边界上会有和第 2 条一样的问题，建议一并改成同一种算法。

4. 新的 PVR Shayanadi 没有接进主链

• avastha_calculator.calculate_pvr_shayanadi 只在调用方传了 activity_context（月亮经度、上升经度、离日出的小时数）时才会生效。
• 但在 scripts/ 下，没有任何调用方传这个参数，所以报告和数据包里的 Shayanadi 实际输出仍是 simplified_heuristic（按星座元素分类）。
• 请确认：是有意先不接，还是漏接了？

5. Gulika 的夜晚结束时刻是「日出 + 1 天」，不是真实的下一次日出

• 位置：gulika.py 的两处 end_jd = ... daynight["sunrise_jd_ut"] + 1.0。
• 这和 872eaecf 在 saham_daynight 里修掉的是同一类问题：用固定一天平移代替真实的相邻事件。高纬度、换季时差几分钟，Gulika 所在的段会跟着偏。

6. Saham 例外规则：两个文件检查的弧方向相反

• tajika._calc_formula_saham：检查上升是否落在「第一操作数 → 第二操作数」的顺行弧上，不在就加一宫。
• raman_sahams.build_raman_sahams：检查第三操作数是否落在「B → A」的顺行弧上，不在就算例外。注释里还特别写了「not A to B」。
• 同一条传统规则，两处方向正好相反。saham_rules.json 的 7 条公式第三项都是上升，所以 tajika 那边的检查对象和 raman 是同一颗点，只有方向不同。
• 请确认哪个方向对；另一处是否也要改？

7. Argala 新增的「待比较」状态没有裁决方

• e7301feb 之后，同数时输出 strength_comparison_required，复核文档也写明强弱裁决「留待单独复核」。
• 我们在三张虚构盘上试过：每张盘有 0～7 个宫变成待比较，obstructed_houses 全部清空。也就是说，在补上裁决之前，下游大量拿到的是「不确定」。
• 第二部分问 3 是同一件事的口径问题。

---

第二部分　口径问题（请在空格里回答，附书页即可）

问 1　Deeptadi 的 Khala：用 Science of Light 还是 PVR？

7d545039 采用 Science of Light 的定义（落陷 = Khala），代码里注明「不是 PVR 的凶星座定义」。

☐ Science of Light（落陷）　☐ PVR（落在凶星的星座）　☐ 其他：＿＿＿＿　书页：＿＿＿＿

附问： 一颗星同时满足多个标签时（例如既落陷又燃烧），单标签按什么优先级取？代码里写的是「legacy heuristic」。

优先顺序：＿＿＿＿＿＿＿＿　书页：＿＿＿＿

问 2　日出日落：为什么用「日面中心、不计大气折射」（BIT_HINDU_RISING）？

我们实测，它和常规日出相比，同一天最多差约 7 分钟（伦敦冬季）。这会牵动昼夜判定、Hora / Ghati / Pranapada 的起点、Gulika 和 Tajika 的昼夜公式。

1. 这个口径的出处是？　＿＿＿＿＿＿＿＿　书页：＿＿＿＿
2. 是否所有用到日出的地方（Panchanga、Gulika、Hora、Ghati、Saham 昼夜）都应统一用它？

☐ 全部统一　☐ 只用于部分：＿＿＿＿＿＿＿＿

问 3　Argala 同数时，强弱怎么比？

PVR 原文只说「compare the strengths」。

1. 比较用哪种强弱？

   ☐ Shadbala　☐ Rasi 强弱（按 Jaimini / Narayana 那套规则）　☐ 其他：＿＿＿＿　书页：＿＿＿＿

2. 特殊三宫（第 3 宫）「两颗以上凶星」形成 Argala 的门槛，是否也要比强弱？

   ☐ 是　☐ 否　书页：＿＿＿＿

问 4　Bhava Bala 的视线力：吉星集合

a4d4a249 里吉星取月亮、木星、金星，水星算中性（复核文档说这是 jyotishganit 的方法选择）。

☐ 固定这样取　☐ 按条件：月亮盈为吉、亏为凶，水星随同宫星　☐ 其他：＿＿＿＿　书页：＿＿＿＿

问 5　Yoga Pinda：确认以 PVR 为准

• 我们用 PyJHora 4.8.7 随机对拍 300 盘，Pinda 全部对不上。原因在 PyJHora 的 Ekadhipatya：它只削本行星那一行、把 Lagna 算作占位、同值时把空宫抬到占位宫的值。
• 处女座的星座权重：PVR 表 28 取 6，Prasna Marga 取 5。

☐ 以 PVR 为准（处女 6，按 PVR 例 43 = 152 校验）　☐ 其他：＿＿＿＿

---

附：我们这边的情况（供参考）

• 第一部分第 1～3 条，我们的代码和贵方一样存在，会等您定下写法后一起修，避免两边分叉。
• 上游的 Pinda、Argala、Bhava Bala、KP 四项修正，我们试移植后贵方新测试 21/21 通过。
• Avastha 我们落后更多：还停在 e628118d 之前，会在问 1 答复后一批跟进。
• 瑜伽燃烧（c3346847）我们另有处理，不跟进；Raman Saham 和三个研究工具（ac23c2ee、8abbfd91、c74fd96c）不涉及我们的产品。