Transit Actionable Output 指南（v4.1.0）

目的：解决 Transit 分析"输出停留在星盘数据陈述层"的问题——每条 Transit 预测必须包含用户可执行的行动方案。

一、触发条件

任何以下场景自动触发本规范（无需用户要求）：

触发词	示例
"被发现"、"被赏识"、"被贵人"	"2026年6月会有贵人赏识，具体怎么被发现？"
"什么时候"、"应期"、"时机"	"什么时候有合作机会？"
"合作"、"破圈"、"突破"、"升职"	"什么时候能破圈？"
"移民"、"搬迁"、"迁居"	"什么时候会搬到大房子？"
任何涉及具体事件类型的 Transit 预测	—

二、三要素强制输出

每条 Transit 预测必须同时输出以下三要素，缺一不可：

要素1：时间段（精确到日/周/月）

✅ 6月2日—6月18日（峰值6月18日前后72小时）
✅ 2026年5月10日—5月20日
❌ "6月份"（精度不足）
❌ "今年内"（精度不足）

要素2：具体行动类型

行动类型	说明	触发信号
发布型	发布/展示已有内容	Jupiter+Venus同宫、AmK活跃
跟进型	主动联系已在沟通中的人	Mars在2/11宫、主动出击窗口
等待型	保持活跃但不主动	Jupiter入12宫前的积累期
被发现型	已有产品/工具被人主动发现	AmK Moon 7宫机制
推进型	推进已有合作/谈判	Mercury激活、合同谈判期

要素3：置信度标注

✅ [A] 已验证（倒推历史事件命中）——置信度最高
✅ [B] 高概率（3+独立维度信号一致）——次高置信度
✅ [C] 推断（1-2个维度信号，理论推断）——最低置信度，需标注未验证

每条关键结论必须标注置信度，未验证者必须附注未验证声明。

三、案例检索三步法（强制）

当动态预测（被发现/合作/破圈/关键事件型）时，必须先执行案例检索：

本节是 references/mandatory-verification-gate-protocol.md 的推运执行入口之一。所有 Transit / Dasha / 年运 / 月运 / 具体事件型推运结论，都必须在最终 Technique Audit Table 中出现：

MEVG / Global Web Evidence：记录全网外部资料采集、source tier 与 conflict arbitration。
Real Case Calibration：记录真实案例参考、公开 benchmark case，或明确 case gap。

pure calculation exemption 只适用于纯计算、纯代码、纯项目维护或不解释运势意义的原始数据输出；一旦解释 Transit 或 Dasha 对运势的意义，必须执行 MEVG 与真实案例校正。

Step 1：检索同类行星配置真实案例

# 使用引擎内置名人案例库
python3 scripts/jyotish_engine.py celebrity --config "Jupiter+Moon+AmK 7宫"

# 或 WebSearch 检索真实创作者发现路径

> **隐私保护**：本节曾包含真实用户个人星盘或人生事件资料，已移除。请使用公开名人案例、虚构 smoke case，或仅在当前会话中处理用户主动提供的数据；不得写入 skill 文件或公开仓库。

3.2 KiB Raw Blame History Unescape Escape