Jyotisha/AGENTS.md

Jyotish Skill Agent Constraints

本文件是当前项目给协作代理、自动化助手与派生工作流的硬约束补充。它不替代 SKILL.md，而是把最容易被偷懒、省略、或在多窗口工作时遗失的高严谨规则单独钉死。

1. High-Rigor Override

当用户明确要求以下任一项时，必须进入高严谨模式：

• 不要凭经验泛谈
• 必须拉满三大开源参照引擎能力
• 必须提交底层原始数据
• 必须验证过去案例
• 必须避免偷工减料

进入该模式后，以下规则全部强制执行：

1. 必须尝试交叉参照 PyJHora、VedAstro、jyotishganit，并保持许可证边界。
2. 必须优先调用本仓原生实现，不得只用轻量包装脚本代替主链代码。
3. 涉及 timing / event / outcome，不得只看 Vimshottari，至少需要 Vimshottari + Narayana Dasha 双轨交叉。
4. 必须按问题域强制调取相关分盘：
   • 事业：D10 + A10
   • 财富：D2 / D11
   • 婚恋：D9 + UL
5. 必须交付原始数据依据：度数、Dasha 边界、Shadbala / Ashtakavarga、Yoga 名称、Ayanamsa / Node mode、外部证据路径。

2. Functional Benefic/Malefic Hard Constraint

强制调取 Functional Benefic / Malefic 判定（功能性吉凶星判定）。

这条约束与 Dasha / 分盘 / 原始数据交付同级，不得省略。

执行要求：

1. 每次进入高严谨模式，必须显式判定当前 Lagna 下的 functional benefics 与 functional malefics。
2. 任何关于事业、财富、婚恋、健康、障碍、回报、应期的结论，都不得只依据自然吉凶星（natural benefic/malefic）下判断，必须叠加功能性吉凶星层。
3. 若某颗星在自然属性与功能属性之间冲突，必须在输出中说明冲突来源，并降低置信度或标记 blocked。
4. 若未调用功能性吉凶星判定，不得声称该次解读完成了高严谨模式。
5. Technique Audit Table 中必须出现 Functional Benefic/Malefic 一行，说明：
   • Used / not used / blocked
   • 关键功能吉星
   • 关键功能凶星
   • 对结论置信度的影响

3. Honesty Boundary

以下情况必须明确写成 blocked 或降级置信度：

• 外部 oracle 尚未闭环
• 三大外部参照引擎中有一层无法合法或稳定调用
• 缺少分盘、Ayanamsa、Node mode 或出生精度
• 功能性吉凶星层未完成
• 双重大运或多系统结果发生实质冲突

禁止把内部一致性伪装成“已经全球顶级精度”。