# AI解盘工作流Prompt工程（AI Reading Workflow）

> **适用场景**：AI收到出生信息、PDF星盘或文字星盘后，如何一步步执行完整的解盘+推运分析
> **版本**：v5.2.0 | **更新日期**：2026-07-02
> **来源标签**: 【工具/模板】 — AI解盘执行引擎工作流
> **优先级**：⭐⭐⭐⭐⭐（AI解盘质量的决定性文件）
> **定位**：本文件是AI解盘的**执行引擎**，将Skill中所有参考资料串联成可执行的工作流
> **v3.0重大变更**：三条入口路径明确分流，引擎全自动计算无需用户逐模块触发
> **v4.0重大变更**：Step 0.5 Karaka系统自动识别（解决DK摇摆问题）、预测输出强制[A/B/C]标注、统一精度边界声明、来源标签体系引用
> **v5.0重大变更**：强制外部验证门控（MEVG）——新增核心原则"不凭记忆"、三个门控步骤（Step 3.11/4.10/5.5）嵌入工作流、与"不跳步"同级强制
> **v5.1重大变更**：事件判定骨架接入主工作流——新增 `Route -> Evidence Ledger -> Adjudication -> Output Contract` 四段式事件裁决层，并引入 marriage 专用 adjudicator。
> **v5.2重大变更**：用户追问校准协议接入主工作流——把用户的质询流程抽象为盲推隔离、具体事件选项、证据先行、相似案例分层对标、可迁移边界与反例处理。

---

## ⚠️ 核心原则

1. **不跳步**：每个阶段必须完成后才能进入下一阶段
2. **不猜测**：数据缺失时标注"缺失"，不编造数据
3. **不锚定**：先输出星盘推导，再等用户反馈，不先知道用户生活再"找依据"
4. **必标注**：每个结论标注来源系统、置信度、精度边界
5. **全自动优先**：引擎有能力自动完成的计算，绝不要求用户手动触发
6. **尊重用户数据**：用户提供的PDF/文字星盘数据即为事实来源，优先使用而非重新计算
7. **🔴🔴🔴 不凭记忆（v5.0 新增，与"不跳步"同级）**：所有解读结论必须经过外部权威来源（web_search）验证，禁止仅凭 AI 训练记忆输出。违反此原则的解读判定为无效。纯数值计算（引擎输出、SAV 点数、Dasha 时间线）可豁免。
   - ❌ 仅凭记忆说"Venus 在 Taurus 10 宫是 Malavya Yoga"
   - ✅ 先 web_search 确认形成条件 + 引用来源
   - → 完整协议：`references/mandatory-verification-gate-protocol.md`
8. **追问即校准（v5.2 新增）**：用户质疑"你用了哪些技法""哪里遗漏""真实案例是否相似""为什么这样判断"时，必须把追问视为工作流校准信号，而不是普通解释请求；需要回到证据层、相似案例层和置信度边界重新裁决。

---

## 🔴🔴🔴 用户追问校准与相似案例对标协议（v5.2）

> **目的**：把高质量用户追问转化为解盘流程约束，避免泛泛描述、记忆联想、单案例套用或把未闭环内容伪装成完整判断。

### 0.1 触发条件

只要用户出现以下任一追问，必须启动本协议：

- "不要用我之前说过的反馈"，"重新盲推"，"只用出生参数和当前项目数据"
- "你是不是遗漏了技法"，"这是不是顶级印度占星师逻辑"
- "列具体时间和事件让我选择"，"不要问概念问题"
- "相似真实案例是什么"，"这个案例到底和我哪里像"
- "为什么这样判断"，"哪些地方需要修正"
- "这个机会具体是什么"，"事件节点是什么"

### 0.2 盲推隔离模式

当用户要求盲推或禁用既往反馈时：

1. 禁止调用用户此前提供的人生事件、校时反馈、对错判断、职业身份、关系状态、偏好描述。
2. 只允许使用出生参数、当前项目现跑出的原始数据、已分级 source pack、MEVG 外部证据和真实案例校准层。
3. 输出必须声明：
   - `User Feedback Isolation: used`
   - 使用了哪些数据源
   - 明确排除了哪些会话反馈类型
4. 若系统无法保证隔离，必须写 `blocked`，不得输出伪盲推。

### 0.3 具体事件选项协议

校时、应期、转型、婚恋、事业机会、财富事件不得只问用户"你感觉像不像"或"有没有变化"。

必须改成可选择的具体事件格式：

```markdown
| 时间窗口 | 事件选项 | 技术来源 | 用途 |
|---|---|---|---|
| YYYY-MM-DD 到 YYYY-MM-DD | A. 搬家/换住处；B. 工作启动；C. 关系断联 | Dasha + Transit + Varga | 校验/预测/置信度调整 |
```

要求：

- 每个窗口至少给出 2-4 个可判断事件选项。
- 事件必须落到现实层面：入职、搬家、签约、付款、断联、公开、培训班更换、项目暂停、住处/通勤变化等。
- 不得只给心理状态、抽象主题或"能量变化"。
- 用户选择后，只能用于后续校准；不能倒灌污染"盲推模式"。

### 0.4 证据先行，结论最后

高严谨解盘必须按以下顺序组织，不得先下结论再找理由：

1. 原始 D1 + 三重参考引擎边界
2. 功能性吉凶星
3. 行星力量：Shadbala / Vimsopaka / Avastha
4. Yoga / Dosha
5. Jaimini：AK / AmK / DK / UL / A10 / Argala
6. 分盘：按问题域调取 D9 / D10 / D2 / D4 / D7 / D12 / D20 / D24 / D30 / D60
7. 多大运：Vimshottari / Narayana / Yogini / Kalachakra / Jaimini
8. Transit + VedAstro range scan
9. Tajika 年运
10. MEVG + 真实案例校准
11. 最后才输出事业、财富、婚恋、健康、迁移等结论

### 0.5 相似案例分层对标

真实案例不得只因为"同主题"就拿来类比。必须给出相似层级：

| 层级 | 含义 | 置信度作用 |
|---|---|---|
| L0 同主题 | 都是婚恋/事业/财富案例，但星盘和运势未证明相似 | 只能作背景，不得推断 |
| L1 D1 结构相似 | Lagna、关键宫主、功能吉凶、行星落宫或尊严有相似点 | 可作弱参考 |
| L2 分盘相似 | D9/D10/D2 等对应分盘支持相同主题 | 可提高主题置信度 |
| L3 Dasha 功能相似 | 不是同一颗星也可以，但必须功能等价，如旧系统瓦解、异地网络、长期责任启动 | 可作阶段类比 |
| L4 事件机制相似 | 真实案例中发生了可验证的节点，如离开旧组织、获得项目、迁移、收入来源变化 | 可校准事件形态 |
| L5 物质支撑相似 | 收入来源、平台、组织资源、合作关系、家庭/伴侣支持等现实条件相似 | 才能推断"生活会如何变好" |

输出案例时必须说明：

- 这个案例和命主在哪些层相似
- 哪些层不相似
- 哪些内容可迁移
- 哪些内容不可迁移
- 因不相似而降低了哪部分置信度

### 0.6 反例与用户排除案例处理

- 反例不能静默删除；必须标注它为什么是反例、它压低了哪个判断。
- 若用户明确说"不要考虑某个案例"，该案例标记为 `user-excluded`，不进入主校准，但保留为审计记录。
- 正例不能单独决定结论；必须经过分盘、大运、事件机制和 MEVG 仲裁。
- 单一名人案例只能校准"事件机制"，不得复制成用户个人命运模板。

### 0.7 转型与机会的现实机制检查

当判断事业转型、婚恋落实、财富改善或人生阶段转折时，必须追问并输出"机会如何落地"，至少拆成：

1. 旧系统断裂：离开组织、旧项目停摆、关系断联、身份失效。
2. 过渡平台：课程、讲座、试稿、短项目、朋友介绍、异地网络、线上发布。
3. 资源入口：谁提供机会，平台是什么，收入从哪里来。
4. 责任测试：合同、制作、交付、管理、公开评价、长期责任。
5. 结果显化：付款、职位、署名、公开关系、稳定合作、可重复收入。

若无法证明"资源入口"或"收入来源"，不得说"情况会变好"，只能说"有转向信号但物质改善待验证"。

### 0.8 时间节点输出粒度

所有预测窗口必须拆成不同层级：

| 节点 | 含义 |
|---|---|
| Contact | 初次接触、消息、介绍、线索出现 |
| Activation | 开始行动、沟通密集、试稿/面试/约见 |
| Confirmation | 确认合作、确认关系、确认资源 |
| Manifestation | 公开、到账、签约、入职、搬迁完成 |
| Responsibility Test | 压力测试、延期、责任加重、现实磨合 |

禁止把这些全部混成一句"会有机会"或"会确定关系"。

---

## 🔴🔴🔴 性别前置检查（必读！每次解盘前必须确认！）

> **⚠️ 这是从多次用户纠正中提炼的硬性规则，违反会导致全盘分析方向错误！**

### 规则1：性别决定征象星体系

**分析配偶/婚姻/感情之前，必须先确认命主性别！**

| 性别 | 日/夜盘 | 丈夫征象星 | 妻子征象星 |
|------|---------|-----------|-----------|
| **女性** | 日盘（白天出生） | **木星 Jupiter**（入Sect，权重最高）+ **火星 Mars**（出Sect，次之） | — |
| **女性** | 夜盘（夜晚出生） | **火星 Mars**（入Sect，权重升高）+ **木星 Jupiter**（出Sect，权重降低） | — |
| **男性** | 日盘 | — | **金星 Venus**（出Sect）+ **月亮 Moon** |
| **男性** | 夜盘 | — | **金星 Venus**（入Sect，权重最高）+ **月亮 Moon** |

### 规则2：DK系统是性别中立的

- DK（Darakaraka）= 度数最低的行星，**不分男女**
- 但DK必须与上述性别征象星交叉验证，不能替代
- **禁止**："女命只看木星" 或 "男命只看金星" 的单一判据

### 规则3：具体纠正记录

以下错误曾反复发生，务必避免：

- ❌ **错误**：分析女性命盘时用"她"描述配偶（配偶应为"他"）
- ❌ **错误**：女性日盘用Venus作为丈夫征象星（应用Jupiter+Mars）
- ❌ **错误**：忽略昼夜区分对征象星权重的影响
- ❌ **错误**：只看DK不看传统征象星，或只看传统征象星不看DK
- ✅ **正确**：多层交叉确认（DK + 7宫主 + 天然征象 + 昼夜区分）

### 规则4：案例分析示例

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

## 🔴🔴🔴 度数精确判断 & 象不单论（必读！）

> **⚠️ 用户多次纠正的核心规则——违反会导致结论严重失真！**

### 规则5：庙旺落陷必须看精确度数，禁止仅凭落宫武断判断

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

### 规则6：象不单论——任何单一配置不能单独下结论

**❌ 错误做法**：
- "DK落12宫 = 地下关系" → 直接判死刑
- "Mars落陷 = 配偶不好" → 单一负面标签
- "7宫主Saturn = 婚姻延迟" → 不看其他条件

**✅ 正确做法**：每个结论必须至少2个系统交叉验证

| 单一配置 | 不能单独说 | 必须结合 |
|----------|-----------|---------|
| DK落12宫 | "关系必然隐藏" | 12宫主状态、7宫主、过境触发、Dasha |
| Mars落陷 | "配偶不好/婚姻差" | Neecha Bhanga是否成立、D9状态、Yogakaraka身份、Vargottama |
| Saturn 7宫主 | "婚姻延迟" | Saturn入庙/受克？UL位置？D9 7宫？ |
| 任何落陷星 | "这颗星是坏的" | 深陷点距离、落陷取消、功能角色（Yogakaraka？） |

### 规则7：分析输出格式要求

分析任何行星或配置时，必须包含以下信息才算完整：

```markdown
## [行星名]@[星座] [度数]° — 综合评定

| 维度 | 结果 |
|------|------|
| 落宫 | X宫 |
| 基础尊严 | 入庙/入旺/本垣/友星/中立/敌星/落陷 |
| 精确度数 | X°XX'（距深陷/入旺点XX°） |
| 渐变评定 | 极深/深/中等/浅 |
| Avastha生命阶段 | 婴儿/青年/成年/老年/衰退 |
| D9 Navamsa状态 | [星座]/[尊严] |
| 功能角色 | 宫主星(X,Y宫) / Yogakaraka / AK/DK等 |
| 特殊条件 | Neecha Bhanga/燃烧/逆行/Vargottama/Pushkara |
| **综合评定** | ⭐ X/5 — [一句话总结] |
```

---

## 🔴🔴🔴 Karaka系统自动识别（必读！每次解盘前必须确认！）

> **⚠️ DK身份反复出错的根因——不同软件/学派使用不同的Karaka系统！**

### 规则8：识别Karaka系统来源

**在进入任何分析之前（路径A/B/C完成后、阶段二之前），必须强制执行以下检查：**

```
Step 0.5: Karaka 系统识别与声明
```

#### 8.1 三大主流Karaka系统对照表

| 系统 | 来源 | 行星数 | DK(Darakaraka)定义 | 特征 |
|------|------|--------|-------------------|------|
| **K.N. Rao 7星制** | K.N. Rao 学派 | 7颗（排除Rahu） | 度数最低的行星 | 最广泛使用的传统体系 |
| **JH 8-Karaka制** | JHorosoft / JHoroWatch 软件 | 8颗（含Rahu，含PiK） | 第7低度数行星（含PiK排序） | PDF标记AK/AmK/BK/MK/**PiK**/PK/GK/DK |
| **Sanjay Rath 8星制** | Sanjay Rath 学派 | 8颗（含Rahu，无PiK） | 排除Mars后的最低度数 | 与7星制的唯一差异：DK可能≠Mars |

#### 8.2 自动识别规则

| 数据来源 | 识别信号 | 应使用系统 | DK提取方式 |
|---------|---------|-----------|-----------|
| **PDF含PiK标记** | PDF中明确列出 `PiK = Putrakaraka` | **JH 8-Karaka制** | 按度数排序第7位（从高到低：AK→AmK→BK→MK→PiK→PK→GK→DK） |
| **PDF有8个Karaka但无PiK** | 列出AK/AmK/BK/MK/PK/GK/DK共7个+Rahu=AK | **Sanjay Rath 8星制** | 排除Rahu和Mars后取最低度数（或按PDF标注） |
| **PDF只有7个Karaka** | 只列出 AK~DK 共7个 | **K.N. Rao 7星制** | 所有7星中度数最低者 |
| **引擎计算(full-reading)** | Python引擎输出 | **K.N. Rao 7星制（默认）** | 引擎内置7星逻辑 |
| **用户未提供数据** | 仅口头描述 | **询问用户或默认7星** | 标注"待确认" |

#### 8.3 常见陷阱与纠正

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

#### 8.4 强制输出格式

每份解盘报告必须在开头声明：

```markdown
### 📐 分析参数
- **Karaka系统**：[K.N. Rao 7星 / JH 8-Karaka / Sanjay Rath 8星]
- **DK（配偶星）**：[行星名]（[度数]°，排名第[X]低）
- **数据来源**：[full-reading引擎 / JH PDF / PL截图 / 文字描述]
- 若DK在不同系统中可能不同 → 同时注明：
  > ⚠️ 注意：若采用Sanjay Rath 8星制，DK可能为[替代行星]而非[Mars]
```

---

## 🔴 阶段零：入口路由（三条路径）

### 用户消息到达后，AI立即判断走哪条路径：

```
用户消息到达
  │
  ├─→ 【路径A】用户提供了精准出生信息（日期+时间+地点）
  │     → 直接调用 full-reading 引擎全链路计算
  │     → 跳到阶段二
  │
  ├─→ 【路径B】用户提供了PDF/图片星盘 或 丰富的文字星盘描述
  │     → 提取文档中的所有星象数据（落宫、度数、Dasha等）
  │     → 直接基于提取的数据进行推算分析
  │     → 跳到阶段二
  │
  └─→ 【路径C】用户出生时间不明确 或 仅知道大概时间
        → 启动互动式出生时间矫正
        → 矫正完成后走路径A
```

---

### 路径A：精准出生信息 → full-reading 全自动计算

**触发条件**：用户提供了明确的出生日期+时间+地点（三者齐全）

**示例输入**：
- "1990年1月1日 12:00（示例） 示例城市"
- "我出生于 1990-08-15 早上6:30 北京"
- "April 17, REDACTED_YEAR, 2:45 PM, San Francisco, China (36.6N, 114.5E)"

**执行指令**（一条命令搞定所有计算）：

```bash
python3 scripts/jyotish_engine.py full-reading \
  --year YYYY --month MM --day DD --hour HH --minute MM \
  --lat XX.XX --lon XX.XX --tz X
```

**此命令自动执行13个计算步骤**：
1. chart — 核心星盘（上升、行星位置、宫位）
2. dasha — Vimshottari大运时间线
3. yoga — Yoga格局识别
4. varga_full — BPHS十六分盘（D2-D60）
5. aspects — 度数精确相位系统
6. jaimini — Chara Karaka + Chara Dasha + Karakamsha
7. nakshatra_adv — Tara Bala + Sub-Lord
8. argala — Argala门闩系统
9. tajika — Tajika年运盘
10. shadbala — 六重力量
11. ashtakavarga — 八分法
12. validation — R1-R10数学验证
13. audit — P1-P12行星审计

**输出结构**：
- `chart`：完整星盘数据
- `modules`：12个模块各自的结果
- `summary`：计算耗时、模块数、错误数
- `errors`/`warnings`：异常信息

**数据质量门**：

| 字段 | 检查项 | 判定 |
|------|--------|------|
| `summary.errors` | 是否为空 | 空则继续，非空需评估 |
| `summary.modules_computed` | 是否≥10 | ≥10正常，<10说明多模块失败 |
| `chart.ascendant` | 是否有上升星座 | 无则计算失败，需排查 |

**完成后**：直接跳到阶段二（意图识别）

---

### 路径B：PDF/文字星盘 → 数据提取 + 直接推算

**触发条件**：用户上传了PDF星盘、截图，或提供了详细的文字星盘描述

**示例输入**：
- 上传11页JhoroWatch PDF
- 上传Parashara's Light截图
- 文字描述："我的上升是狮子座，太阳在白羊座9宫，月亮在水瓶座7宫..."

**⚠️ 核心原则：用文档的数据，不重新排盘**

用户提供的PDF/文字星盘中的数据就是**事实来源**。AI不需要从出生时间重新计算星盘，而是直接使用文档中已有的：
- 行星落宫落座
- Dasha时间线
- Shadbala分数
- Ashtakavarga点数
- Yoga列表
- 分盘数据

**执行步骤**：

```
1. 识别来源（JH / Parashara's Light / 其他软件）
2. 逐页/逐段提取所有星象数据
3. 填充标准JSON Schema（见下方模板）
4. 执行数据完整性门（Quality Gate）
5. 如有出生时间+地点，额外调用 full-reading 补充计算
6. 输出提取报告
```

**数据提取模板**：

```markdown
## 📋 星盘数据提取报告

**来源**：[JH / PL / 文字描述] | **完整度**：[XX%]

### 基本信息
- 出生：[YYYY-MM-DD HH:MM] [地点] [性别]
- Ayanamsa：[Lahiri XX°XX'XX"]

### D1概要
- 上升：[星座] [度数]° ([Nakshatra] P[Pada])
- AL：[星座] | UL：[星座] | HL：[星座] | GL：[星座]

### 行星配置表
| 行星 | 星座 | 宫位 | 度数 | NK | Pada | 状态 | 逆行 | 燃烧 | 战争 |
|------|------|------|------|-----|------|------|------|------|------|
| Sun  |      |      |      |     |      |      |      |      |      |
| Moon |      |      |      |     |      |      |      |      |      |
| ...  |      |      |      |     |      |      |      |      |      |

### Jaimini Karakas
- AK=[行星] AmK=[行星] BK=[行星] MK=[行星] PK=[行星] GK=[行星] DK=[行星]

### 关键分盘
- D9上升：[星座] | D10上升：[星座]

### 当前Dasha
- Maha：[行星] ([起]-[止])
- Antar：[行星] ([起]-[止])
- Pratyantar：[行星] ([起]-[止])

### Shadbala摘要
- 最强：[行星] [分数]R | 最弱：[行星] [分数]R

### Ashtakavarga SAV
- 宫位：1  2  3  4  5  6  7  8  9  10 11 12
- 点数：[XX XX XX XX XX XX XX XX XX XX XX XX]

### Yoga清单
- [Yoga1]：[行星]在[X宫]
```

**数据完整性门**：

| 完整度 | 判定 | 允许的分析 |
|--------|------|-----------|
| ≥90%（P0全齐） | ✅ Pass | Level 2/3完整分析 |
| 70-89%（P0大部分） | ⚠️ Limited | Level 2，标注限制 |
| <70%（P0缺关键项） | ❌ Fail | Level 1快速概览，要求用户补全 |

**补充计算**（条件触发）：

如果PDF中包含了出生日期+时间+地点信息，AI **应当额外调用** `full-reading` 来补充PDF中可能缺失的计算（如精确相位、Argala、Tajika等v3.7新增模块），将引擎计算结果与PDF提取数据合并，以引擎结果为补充、PDF数据为基准。

**完成后**：直接跳到阶段二（意图识别）

---

### 路径C：时间不明确 → 互动式出生时间矫正

**触发条件**：
- 用户说"不知道出生时间" / "大概下午吧" / "不清楚几点"
- 用户只知道日期不知道时间
- 用户提供的出生证明时间与实际有出入

**⚠️ 核心理念：不猜时间，通过互动逐步锁定**

AI不应该凭空假设一个时间，而应该通过结构化互动帮助用户锁定精确时间。

**矫正流程**（→ `birth-time-rectification-advanced.md`）：

#### C1. 初始信息收集（第一轮互动）

**AI必须收集的基础信息**（只问一轮，最多5个问题）：

```
"为了帮你精准确定出生时间，我需要了解一些信息：

1. 你目前知道的出生时间范围是什么？（比如'下午2点到5点'、'上午'、'完全不知道'）
2. 出生地点是哪里？（城市即可）
3. 你的体型偏瘦/中等/偏壮？脸型偏圆/长/方？
4. 容易出现健康问题的部位是？（比如经常头痛/肠胃不好/腰痛等）
5. 有没有明显的胎记或疤痕？在身体什么位置？"
```

#### C2. 外表体质初筛（AI自动分析）

根据用户回答，确定上升星座范围：
- 体型+脸型+健康倾向 → 缩小到2-3个候选上升星座
- 胎记/疤痕位置 → 进一步缩小范围
- 参照 `birth-time-rectification-advanced.md` 中的外表体质对应表

#### C3. 生活事件验证（第二轮互动）

**AI请求用户提供人生重要事件**：

```
"初步判断你的上升可能在[星座A]或[星座B]。
为了进一步确认，请告诉我你人生中的一些重要转折事件，
大概5-10个就行，包括大概的时间和事件类型。比如：
- 搬家、转学、毕业
- 工作/事业的重要变化
- 开始或结束一段感情
- 亲人离世或重病
- 获奖或重大成就
- 生病或手术"
```

**AI对每个事件做Dasha+Transit验证**：
- 用候选时间分别排盘
- 检查事件时间点的Dasha周期是否激活相关宫位
- 检查Transit是否支持该事件
- 计算每个候选时间的吻合率

#### C4. D9/D10精确校正（第三轮互动，可选）

如果需要更精确（精确到±5分钟以内）：

```
"时间范围已经缩小到[XX:XX-XX:XX]。
为了进一步精确，请告诉我：
1. 你的感情模式是怎样的？（主动/被动、深刻/轻松、重视精神连接/重视现实基础）
2. 你的工作风格是怎样的？（管理型/创意型/研究型/服务型）"
```

- 感情模式 → 判定D9上升 → 缩小时间
- 工作风格 → 判定D10上升 → 缩小时间

#### C5. 矫正结果输出

```markdown
## 🔧 出生时间矫正报告

### 信息收集
- 已知时间范围：[描述]
- 外表体质：[描述]
- 事件验证：[N]个事件

### 矫正过程
- 上升候选：[星座A] / [星座B] → 判定：[星座X]
- Dasha吻合率：[XX%]
- Transit吻合率：[XX%]
- D9上升判定：[星座]（基于感情特质）
- D10上升判定：[星座]（基于事业特质）

### 矫正结果
- **矫正后出生时间**：[HH:MM]
- **置信度**：[高/中/低]（[XX%]事件吻合）
- **精度范围**：±[X]分钟

### ⚠️ 声明
出生时间矫正是基于事件反向推导的概率性方法。
矫正后的时间不能100%保证精确，但基于[X]个事件的验证，
吻合率达到[XX%]，可作为有效参考。
```

**矫正完成后**：使用矫正后的时间走路径A，调用 `full-reading` 全链路计算。

---

## 阶段二：用户意图识别与路由

### 2.0 Strict Workflow Router（v6.0.1-orchestration）

在使用下方意图路由表之前，先读取 `strict-workflow-router.md`。凡涉及事业、婚恋、财务、事件应期、历史回测、技法可靠性或高级分析，必须选择对应 strict route，并在最终输出附 Technique Audit Table。

在 Technique Audit Table 中，`Functional Benefic/Malefic` 不得只写“已使用”。必须显式列出：
- functional benefics
- functional malefics
- functional neutrals
- yogakarakas
- 对结论置信度的影响

若缺少其中任一层，不得伪装成高严谨完成态，应降级置信度或标记 `blocked`。

| 用户意图 | Strict route | 必须额外完成 |
|----------|-------------|-------------|
| 事业机会/职业方向/项目落地 | `career-timing-strict` | D1+D9+D10+Vimshottari+Jaimini+AmK/Karakamsha+AL/A10+Shadbala+AV+Argala |
| 婚恋/婚姻/伴侣/关系结果 | `relationship-timing-strict` | 性别/昼夜确认+D1+D9+DK+UL+Double Transit+KP |
| 财运/收入/到账/资产 | `wealth-timing-strict` | 2H/11H+D2/D10+Shadbala+AV+Argala+KP |
| 具体事件是否发生/何时发生 | `event-timing-strict` | 事件宫位定义+Dasha+Transit+KP+Moon trigger |
| 历史事件验证/技法可靠性 | `event-verification-strict` | 同一技法回测+命中/失败评分+个人化规则 |

### 2.1 意图路由表

| 用户意图 | 目标宫位 | 核心参考文件 | 承诺模板 |
|----------|---------|-------------|---------|
| 婚姻/恋爱/关系 | 7宫 | `strict-workflow-router.md` + `relationship-astrology-guide.md` | §1 |
| 事业/职业/工作 | 10宫 | `strict-workflow-router.md` + `house-modern-mapping.md` | §2 |
| 财富/收入/投资 | 2宫+11宫 | `strict-workflow-router.md` + `house-domain-planet-mapping.md` | §3 |
| 子女/创作 | 5宫 | `modern-life-scenarios-complete.md` | §4 |
| 健康/体质 | 1宫+6宫+8宫 | — | §5 |
| 教育/学业 | 4宫+9宫 | — | §6 |
| 出国/迁移 | 9宫+12宫 | — | §7 |
| 灵性/修行 | 9宫+12宫 | — | §8 |
| 合盘/关系匹配 | 7宫 | `strict-workflow-router.md` + `synastry` + `relationship-astrology-guide.md` | §1 |
| 综合解盘（全盘） | 全部 | `strict-workflow-router.md` + `comprehensive-reading-workflow.md` | 全部 |

**（承诺模板→ `promise-assessment-templates.md`）**

### 2.2 用户未明确意图时的默认流程

如果用户没有说具体问什么（比如只给了出生信息或上传了PDF）：
1. 执行**综合解盘工作流Level 2**（`comprehensive-reading-workflow.md`）
2. 先输出10宫位快速扫描
3. 识别最强和最弱的领域
4. 重点展开当前Dasha激活的领域
5. 主动提示用户可以深入询问任何领域

### 2.3 事件判定骨架（v5.1 新增）

凡是以下题型，必须进入事件判定骨架，不得只靠 `strict route` 后直接写结论：

- marriage / relationship
- career / offer / promotion / project landing
- wealth / payment / gains / asset timing
- generic event verification

固定执行顺序：

1. `Route`
   - 先冻结 **问题域**、**任务类型**、**目标粒度**
2. `Evidence Ledger`
   - 把每个模块落成结构化证据块
3. `Adjudication`
   - 按 `Promise -> Activation -> Manifestation -> Timing`
4. `Output Contract`
   - 只输出 `verdict + confidence + conflicts + audit + raw evidence`

详细协议：

- `references/event_judgment_skeleton.md`
- `references/event_judgment_marriage.md`

若问题属于婚恋，必须再额外执行 `event_judgment_marriage.md` 的专用裁决器。

---

## 阶段三：静态星盘分析（→ 多个参考文件）

### 3.1 执行顺序（严格按此顺序）

```
Step 3.1  宫位-行星基础分析
          → references/planets.md
          → references/signs-and-houses.md

Step 3.2  承诺评估（Promise Assessment）
          → references/promise-assessment-templates.md
          → 输出：承诺等级（完整/部分/缺失）

Step 3.3  Yoga格局识别
          → references/yoga_list.md
          → references/yoga-list-chinese.md
          → references/yoga-strength-scoring-system.md

Step 3.4  Argala检查（目标宫的2/4/5/8/11宫）
          → references/argala-complete-guide.md
          → 输出：目标宫是否被"开门"或"锁门"

Step 3.5  逆行/燃烧/行星战争检查
          → references/retrograde-combustion-war-guide.md
          → 每颗行星检查三重叠加

Step 3.6  Nakshatra深度解读
          → references/nakshatra_deities.md
          → references/nakshatra-chinese-quick-ref.md

Step 3.7  Shadbala评估
          → references/shadbala-complete-methodology.md
          → 输出：行星力量排名

Step 3.8  Ashtakavarga评估
          → references/ashtakavarga-complete-system.md
          → 输出：SAV 12宫排名 + 关键阈值判断

Step 3.9  Ketu双属性检查
          → references/ketu-dual-nature-guide.md
          → 如果命盘有Ketu，必须同时评估"放手"和"突破"

Step 3.10 分盘确认
          → references/varga-system-quick-reference.md
          → D9（关系）+ D10（事业）+ 对应领域分盘

Step 3.11 ⭐ MEVG-静态门控（v5.0 强制）
          → references/mandatory-verification-gate-protocol.md
          → 对所有静态解读声明执行 web_search 外部验证
          → 验证范围：Yoga 识别/行星尊严判断/Shadbala 异常/SAV 关键阈值/Ketu 双属性
          → 最低要求：L2≥4次搜索≥3来源，L3≥8次搜索≥5来源
          → 输出：验证状态表（检索项/查询词/来源数/状态/关键来源）
          → ❌ 未通过 → 降级置信度为[C] + 标注"验证不足"
```

### 3.2 静态分析输出模板

```markdown
## 🔍 静态星盘分析

### 承诺评估（Promise）
| 领域 | 宫位 | 宫主星 | Karaka | 分盘确认 | 承诺等级 |
|------|------|--------|--------|---------|---------|
| [领域] | [强/中/弱] | [状态] | [状态] | [✅/❌] | [完整/部分/缺失] |

### Yoga格局
| Yoga | 构成 | 强度 | 领域影响 |
|------|------|------|---------|
| [名称] | [行星]在[X宫] | [强/中/弱] | [促进/阻碍] |

### Argala分析（目标宫=[X宫]）
| 干预宫 | 行星 | 效应 | Virodha | 最终 |
|--------|------|------|---------|------|
| 2宫 | [行星] | [吉/凶]Argala | 12宫[空/行星] | [开门/锁门/对冲] |
| 4宫 | ... | ... | 10宫 ... | ... |
| 11宫 | ... | ... | 3宫 ... | ... |

### 行星异常状态
| 行星 | 逆行 | 燃烧 | 战争 | 影响 |
|------|------|------|------|------|
| [行星] | ✅/❌ | ✅/❌ | ✅/❌ | [描述] |

### Shadbala排名
1. [行星] — [分数]R（最强）
...
9. [行星] — [分数]R（最弱）

### SAV关键宫位
| 宫位 | SAV | 阈值判断 |
|------|-----|---------|
| [目标宫] | [分数] | [强>30 / 中25-30 / 弱<25] |

### 静态分析结论
- **先天承诺**：[强/中/弱] — [描述]
- **关键优势**：[列出]
- **关键障碍**：[列出]
```

---

## 阶段四：动态推运分析（→ 多个参考文件）

### 4.1 执行顺序

```
Step 4.1  Dasha激活评估
          → references/vimshottari_dasha_guide.md
          → 当前Maha/Antar/Pratyantar与目标领域的关系

Step 4.2  Dasa Convergence（轻量三系统法）
          → references/dasa-convergence-methodology.md §七
          → Vimsottari + Yogini + Chara 三系统交叉验证
          → 输出：Convergence等级（Level 0-3）

Step 4.3  Transit触发评估（四参考点强制）
          → references/transit-comprehensive-guide.md
          → references/transit-multi-reference-guide.md
          → 必须从Lagna + Chandra Lagna两个参考点分析
          → Level 3加上AL参考点

Step 4.4  Double Transit确认
          → 土星+木星是否同时激活目标宫位

Step 4.5  Jaimini确认
          → references/jaimini-complete-system.md
          → Karaka状态 + Chara Dasha（如有）

Step 4.6  KP确认
          → references/kp-astrology-complete-system.md
          → Cuspal Sub-Lord分析

Step 4.7  Varshaphala年运盘确认（如需要）
          → references/varshaphala-annual-chart-guide.md
          → references/tajika-yoga-complete-guide.md
```


### Step 4.8  Transit Actionable Output 强制输出（⭐ v4.1.0 新增）

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

### Step 4.9  案例检索与对比（⭐ v4.1.0 强制）

**目的**：动态预测（被发现/合作/关键事件型）必须以真实案例作为参照，不依赖纯理论推断。

**执行条件**：当用户问及以下问题时，强制执行：
- "什么时候"、"应期"、"时机"
- "被发现"、"被贵人"、"合作"、"破圈"
- "移民"、"搬迁"、"升职"
- 任何涉及具体事件类型的预测

**案例检索命令**：
```bash
# 引擎内置名人案例库
python3 scripts/jyotish_engine.py celebrity --config "Jupiter+Moon+AmK 7宫"

# WebSearch 真实案例
web_search: "astrologer content creator discovered by mentor collaboration 2024 case study"
```

**输出格式**：
```
## [B] 2026年6月2日—6月18日：Jupiter入Cancer触发事业窗口
**置信度**：⭐ [B]（高概率——基于3个独立维度）

**Actionable Output**：
- 具体时间段：6月2日起，峰值6月18日前后72小时
- 具体行动：已有内容/产品保持展示活跃度，留意主动联系
- 行动类型：⚠️ 被发现型（AmK Moon 7宫机制：被人使用工具后触发）

**案例参照**：Starcross App（0广告月入6万，内容获客+情感变现）；Neda Farr（TikTok 22万粉丝→工具创始人）
**未验证声明**：以上预测基于星盘信号与案例类比推断，未经个人历史事件验证，置信度[B]。
```

### Step 4.10 ⭐ MEVG-动态门控（v5.0 强制）

> **目的**：所有 Transit 效应、Dasha 解读、特殊天文现象（Ashtama Shani/Sade Sati/Jupiter 换座等）必须经过外部来源验证。

**触发条件**：阶段四 Step 4.1-4.9 完成后，自动执行。

**执行步骤**：

```
1. 提取所有动态解读声明（Dasha 效应、Transit 效应、Double Transit 判断等）
2. 为每个声明构建英文检索查询：
   - "[Planet] transit [Sign] [Year] Vedic astrology effects"
   - "[Planet1]/[Planet2] Dasha period effects Vedic"
   - "Ashtama Shani [Moon sign] [Year]" (如适用)
   - "Jupiter transit Cancer [Year] all ascendants" (如适用)
3. 执行 web_search（最低≥4次，Level 3≥8次）
4. 交叉验证：对比来源一致性
5. 输出验证状态表

通过标准：≥80% 动态解读有≥2个独立来源
失败处理：未验证解读全部标注"未经验证" + 置信度降级
```

**输出格式**：

```markdown
### 📋 MEVG 验证状态（动态分析）

| 检索项 | 查询关键词 | 来源数 | 状态 | 关键来源 |
|--------|-----------|--------|------|---------|
| [Dasha/Transit] | [查询词] | [N] | ✅/⚠️/❌ | [来源1, 来源2] |

**总检索次数**：[N] 次 | **验证通过率**：[X]%
**降级声明**：[列出]
```

→ references/mandatory-verification-gate-protocol.md

### 4.2 动态分析输出模板

```markdown
## ⏳ 动态推运分析

### Dasha激活
| 层级 | 行星 | 日期范围 | 与目标关系 | 评估 |
|------|------|---------|-----------|------|
| Maha | [行星] | [日期] | [描述] | [有利/中性/不利] |
| Antar | [行星] | [日期] | [描述] | [有利/中性/不利] |
| Pratyantar | [行星] | [日期] | [描述] | [有利/中性/不利] |

### Dasa Convergence（轻量三系统法）
| 系统 | 当前周期 | 激活？ | 证据 |
|------|---------|--------|------|
| Vimsottari | [Maha]-[Antar] | ✅/❌ | [说明] |
| Yogini | [Yogini名] | ✅/❌ | [说明] |
| Chara | [星座] | ✅/❌ | [说明] |
| **Convergence** | | **Level [X]** | **概率+[XX%]** |

### Transit分析
#### 从Lagna看
| 行星 | 过境[目标宫]时间 | 效应 | SAV |
|------|-----------------|------|-----|
| 土星 | [日期] | [压力/考验] | [分数] |
| 木星 | [日期] | [机遇/祝福] | [分数] |

#### 从Chandra Lagna看 ⚠️强制
| 行星 | 过境[目标宫]时间 | 心理/职业效应 |
|------|-----------------|-------------|
| 土星 | [日期] | [描述] |
| 木星 | [日期] | [描述] |

#### Double Transit
- 土星+木星同时激活目标宫：[是/否]（[时间窗口]）

### 三系统交叉验证
| 系统 | 判断 | 方向 | 置信度 |
|------|------|------|--------|
| Parashara | [描述] | [正面/负面] | [高/中] |
| Jaimini | [描述] | [正面/负面] | [高/中] |
| KP | [描述] | [正面/负面] | [高/中] |
| **一致性** | | [三系统/两系统/矛盾] | |
```

---

## 阶段五：应期输出（→ `timing-prediction-template.md` + `prediction-output-protocol.md`）

### 5.0 ⚠️ 置信度分级与验证状态强制标注（必读！）

> **每条预测结论必须同时标注两个维度：置信度等级 + 验证状态**

#### 5.0.1 置信度三级分类（→ precision-reading-methodology.md §五）

| 级别 | 标记 | 定义 | 触发条件 |
|------|------|------|---------|
| **A-已验证** | ✅ [A] | 经过用户已知事件倒推验证的结论 | 用户提供了过往事件 + 倒推匹配度≥60% |
| **B-强推断** | ⭐ [B] | 3个以上独立维度指向同一方向，但未经事件验证 | PACDARES静态 + L3矛盾检查 + Dasha/Transit多系统一致 |
| **C-假设** | ⚡ [C] | 单一维度或理论推导，缺乏多系统支撑 | 仅凭单一配置（如"DK落12宫"）得出的结论 |

#### 5.0.2 验证状态强制声明

| 状态 | 标记 | 含义 | 输出要求 |
|------|------|------|---------|
| 已验证 | `[已验证·N/N事件吻合]` | 完成了倒推验证且通过 | 可给出相对精确的窗口 |
| 未经验证 | `[未经验证]` | 用户未提供过往事件 | 必须降低置信度至少一级；不得使用[A]标记 |
| 验证失败 | `[校准异常·需重新评估]` | 倒推匹配度<60% | **停止预测**，建议先矫正出生时间 |

#### 5.0.3 强制标注格式

**每条预测结论必须包含以下标注行：**

```
结论：[描述]
置信度：[A/B/C]
验证状态：[已验证·N/N / 未经验证]
依据：[列出1-3个核心依据]
精度边界：[见5.1统一精度表]
矛盾说明：（如有）[描述]
```

**违反示例**：
- ❌ "2027年你会结婚" —— 无标记、无置信度、无验证、无依据
- ✅ "2027Q2-Q4期间，婚姻领域处于高度活跃期 ⭐[B][未经验证]，依据：Saturn/Venus大运激活7宫+DK Mars过境恢复，精度±2-3月"

#### 5.0.4 Transit Actionable Output 强制标注（⭐ v4.1.0 新增）

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

## [B] 时间段：事件描述
**置信度**：⭐ [B]（高概率——基于N个独立维度：维度1+维度2+维度3）
**Actionable Output**：
- 具体时间段：精确日期范围
- 具体行动：明确做什么
- 行动类型：被发现型/主动出击型/等待窗口型
**案例参照**：真实案例名称+关键特征
**未验证声明**：以上预测基于星盘信号与案例类比推断，未经个人历史事件验证，置信度[X]。
```

**禁用规则**：
- ❌ 纯理论推断行动建议（"保持开放心态"）
- ❌ 无时间段的行动建议（"做好内容准备"）
- ❌ 无置信度的预测（"6月肯定会被发现"）
- ❌ 无未验证声明的 [B]/[C] 预测

→ 详细规范：references/transit-actionable-output-guide.md
→ SKILL.md 主文档：「⚠️ Transit Actionable Output 规范」章节

### 5.1 统一精度边界声明表

> **⚠️ 所有含时间预测的输出必须附此精度表对应等级的声明——不可省略！**

| Dasha层级 | 时间粒度 | 精度范围 | 适用场景 | 强制附注文案 |
|-----------|---------|---------|---------|------------|
| **Maha Dasha (MD)** | 年级 | ±1-3个月 | 人生大趋势、10年主题 | `"本分析为MD级（±1-3月），描述大方向趋势"` |
| **Antar Dasha (AD)** | 月级 | **±2-4周** | 年度主题、年度关键窗口 | `"本分析为AD级（±2-4周），描述年度能量走向"` |
| **Pratyantar (PD)** | 周级 | **±2-3天** | 月度窗口、具体事件时机 | `"本分析为PD级（±2-3天），描述月度活跃区间"` |
| **Sookshma (SD)** | 日级 | **±1-2天** | 周度参考 | `"本分析为SD级（±1-2天），周度参考性质"` |
| **Prana SSD** | 小时级 | **±6-12小时** | 日度精细参考（仅作辅助） | `"⚠️ SSD级精度为±6-12小时误差，非精确时刻，仅供参考"` |

**通用强制声明（附加到所有预测输出末尾）：**

```markdown
---
### ⚠️ 精度与诚实声明
- **本分析精度等级**：[PD/AD/MD]级（[±X天/周/月]）
- **预测本质**：占星描述的是能量场活跃度和时机概率，非绝对保证交付
- ✅ 可以描述：趋势方向、时间窗口概率、风险提示、机会信号
- ⚠️ 谨慎表述：具体月份、事件形态描述（需标注[B]或[C]）
- ❌ 绝对禁止：确定日期、"一定会发生"、指定具体人物/项目
- 若出现SSD级时间 → 必须额外标注："SSD级（±6-12小时），仅供交叉参考"
```

### 5.2 输出规范（严格遵守）

每条预测必须包含：

| 必含项 | 说明 |
|--------|------|
| **分析等级** | Level 1/2/3/4 |
| **置信度** | [A]/[B]/[C] + 验证状态 |
| **时间窗口** | 主窗口（月级）+ 次窗口（周级） |
| **承诺评估** | 本命盘有无此承诺 |
| **激活评估** | Dasha-Transit是否对齐 |
| **精度边界声明** | ⚠️ 声明预测的边界（按5.1统一精度表） |

### 5.2 禁用措辞（→ `prediction-output-protocol.md` 第四节）

**严格禁止**：
- ❌ "完美吻合" / "100%命中" / "一定会"
- ❌ "事业大爆发" / "贵人会联系你"
- ❌ 指定具体行业/项目/人物

**必须使用**：
- ✅ "X月前后，第Y宫处于高度活跃期"
- ✅ "此窗口的行星能量倾向于[增长/收缩/重组]"
- ✅ "高/中/低概率倾向，±X周/月"

### 5.4 应期输出模板

```markdown
## 📅 应期预测

### 📐 分析参数
- **Karaka系统**：[K.N. Rao 7星 / JH 8-Karaka / Sanjay Rath 8星]
- **DK（配偶星）**：[行星名]（[度数]°）
- **验证状态**：[已验证·N/N / 未经验证]

### 事件预测总表
| 项目 | 说明 |
|------|------|
| **事件类型** | [领域] |
| **发生倾向** | [高90%+/中70-89%/低50-69%] |
| **置信度** | [A/B/C]（[依据简述]） |

### 应期时间窗口
| 精度 | 时间窗口 | 判定依据 | 置信度 | 精度声明 |
|------|---------|---------|--------|---------|
| **主窗口(MD/AD级)** | [YYYY-MM 至 YYYY-MM] | Dasha+慢速Transit | [A/B/C] | ±[1-3月/2-4周] |
| **次窗口(PD级)** | [YYYY-MM 至 YYYY-MM] | Pratyantar+Double Transit | [B/C] | ±2-3天 |
| **精细窗口(SD级)** | [YYYY-MM-DD 至 YYYY-MM-DD] | Sookshma+快速Transit | [C] | ±1-2天 |

### 确认/延迟/取消信号
| 类型 | 信号 | 含义 |
|------|------|------|
| 确认 | [描述] | 事件在该窗口内发生的概率提升 |
| 延迟 | [描述] | 事件可能推迟 |
| 取消 | [描述] | 事件可能不发生 |

### ⚠️ 精度与诚实声明
- **本分析精度等级**：[PD/AD/MD]级（±[X]）
- **预测本质**：占星描述的是能量场活跃度和时机概率，非绝对保证交付
- ✅ 可描述：趋势、窗口概率、风险提示
- ⚠️ 谨慎：具体月份、事件形态（需标注[B]/[C]）
- ❌ 禁止：确定日期、"一定会"、指定具体人物/项目
```

### 5.5 ⭐ MEVG-预测门控（v5.0 强制）

> **目的**：确保每条预测输出都有来源支撑、置信度标注与验证结果一致、精度声明完整。

**触发条件**：阶段五 Step 5.0-5.4 完成后，自动执行。

**检查项（100% 必须通过）**：

| # | 检查项 | 通过标准 | 失败处理 |
|---|--------|---------|---------|
| 1 | 每条预测有置信度标注 | [A]/[B]/[C] 标记存在 | 补全 |
| 2 | 置信度与验证结果一致 | [B]需≥3独立维度、[A]需历史验证 | 不一致则降级 |
| 3 | 精度边界声明完整 | 精度等级+范围+强制附注文案 | 补全 |
| 4 | 未验证声明存在 | [B]/[C] 预测有未验证声明文案 | 补全 |
| 5 | MEVG 验证状态表存在 | 静态+动态验证状态表均已输出 | 补全 |

**通过标准**：5/5 项全部通过
**失败处理**：缺少任何一项即阻止输出，补全后重新检查

→ references/mandatory-verification-gate-protocol.md

---

## 阶段六：补救措施（如用户需要）

```
→ references/remedies-complete-system.md
→ references/personalized-remedies-system.md
```

仅在以下情况主动提供：
1. 用户明确要求
2. 分析中发现严重受克且用户询问如何缓解
3. Sade Sati / Kantaka Shani / Mangal Dosha等长期压力期

---

## 阶段七：现代措辞包装

**所有输出最终必须经过现代措辞包装**：
- → `references/modern-language-guide.md`
- → `references/modern-life-scenarios-complete.md`
- → `references/common-misconceptions.md`

**包装规则**：
1. 传统术语→现代措辞映射（太阳→个人品牌、月亮→心理健康）
2. 避免"好命/坏命"等绝对化表述
3. 提供"倾向性描述"而非"命运判定"
4. 直接坦率：给核心优势和挑战，不说废话

---

## 快速参考：完整工作流一页纸

```
用户消息到达
  │
  ├─ 路径判断
  │   ├─→ 【路径A】精准出生信息 → full-reading 全自动计算
  │   ├─→ 【路径B】PDF/文字星盘 → 提取数据 + 直接推算
  │   └─→ 【路径C】时间不明确 → 互动矫正 → 走路径A
  │
  ├─→ ⚠️ Step 0.5: Karaka系统识别（强制！识别7/8-Karaka制，声明DK）
  │
  ├─→ 阶段二：意图路由
  │     └─→ 用户问什么 → 目标宫位 → 对应承诺模板
  │         （无明确意图 → 综合解盘Level 2）
  │
  ├─→ 阶段三：静态分析（10步 + 1个门控）
  │     ├─→ 宫位-行星基础
  │     ├─→ 承诺评估
  │     ├─→ Yoga识别
  │     ├─→ Argala检查
  │     ├─→ 逆行/燃烧/战争
  │     ├─→ Nakshatra深度
  │     ├─→ Shadbala
  │     ├─→ Ashtakavarga
  │     ├─→ Ketu双属性
  │     ├─→ 分盘确认
  │     └─→ ⭐ Step 3.11: MEVG-静态门控（web_search验证所有静态声明）
  │
  ├─→ 阶段四：动态推运（7步 + 1个门控）
  │     ├─→ Dasha激活
  │     ├─→ Dasa Convergence三系统法
  │     ├─→ Transit四参考点
  │     ├─→ Double Transit
  │     ├─→ Jaimini确认
  │     ├─→ KP确认
  │     ├─→ Varshaphala确认
  │     ├─→ Transit Actionable Output
  │     ├─→ 案例检索与对比
  │     └─→ ⭐ Step 4.10: MEVG-动态门控（web_search验证所有动态声明）
  │
  ├─→ 阶段五：应期输出（+1个门控）
  │     ├─→ 置信度分级与验证状态标注
  │     ├─→ 统一精度边界声明
  │     ├─→ Transit Actionable Output 强制标注
  │     ├─→ 应期输出模板
  │     └─→ ⭐ Step 5.5: MEVG-预测门控（确认100%预测通过验证）
  │
  ├─→ 阶段六：补救措施（可选）
  │
  └─→ 阶段七：现代措辞包装
```

---

**版本**：5.0.0
**更新日期**：2026-04-27
**配套文件**：`pdf-chart-reading-guide.md`（PDF提取）、`birth-time-rectification-advanced.md`（出生时间矫正）、`timing-prediction-template.md`（应期模板）、`prediction-output-protocol.md`（输出规范）、`comprehensive-reading-workflow.md`（综合流程）、`promise-assessment-templates.md`（承诺模板）、`argala-complete-guide.md`（Argala检查）、`dasa-convergence-methodology.md`（Dasa Convergence）、`precision-reading-methodology.md`（精准解盘方法论+置信度分级+倒推验证协议）、`mandatory-verification-gate-protocol.md`（⭐ v5.0 强制外部验证门控协议）