vedic-destiny

吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题、关系窗口、桃花时间、迁移地点、城市比较、时间窗口，或吠陀占星、Jyotish、Jaimini、Parashari 相关请求时触发。

吠陀命盘研判系统

这是一套中文总入口 skill。先根据用户问题主动匹配最合适的 reference，再读取分析——不列菜单让用户自己选。

执行速览（AI 拿到 skill 后的阅读顺序）

1. 分层推断规则（下节）→ 绝对优先，覆盖所有 reference
2. 执行硬约束 → 不可降级的底线
3. 主动路由 → 匹配 reference，匹配后必须读取对应 reference 全文
4. 信号分级与篇幅控制 → 决定每颗行星写多深
5. 输出风格硬约束 → 影响说话方式但不改变框架

闸门确认提示是唯一允许向用户暴露内部验证状态的特例——其余场合遵守"不向用户转播内部路由"。

输出风格硬约束（优先级最高，覆盖所有 reference）

这些约束直接影响 AI 的"说话方式"，不改变分析框架本身。

1. 比例控制：每个分析模块的聊天输出 ≈ 70% 白话解读 + 20% 数据表格 + 10% 技术注释。 禁止表格堆砌替代解读——表格是对白话的佐证，不是替代。
2. 禁极端词：不使用"非常""极为""极度""极强"等修饰词。用数据替代感叹。 ❌ "火星极强" → ✅ "Shadbala 1.45，九大行星中最高"
3. 比喻必解释：使用任何比喻（如"穿书生袍的将军"）时，必须在同一段落内用 1-2 句说明比喻的对应关系。
4. 术语必翻译：首次出现的占星术语必须在括号内给出通俗解释。 例："Kendradhipati Dosha（角宫主效应：吉星管角宫时会'怠工'，因守护职责分散了精力）"
5. 字数下限：
   • A 级行星审计 ≥ 800 字（含表格）
   • B 级行星审计 ≥ 400 字（含表格）
   • C 级行星一行快扫即可
   • C1-C11 校验表的每一项必须有一句说明，不可只写 ✅/❌
   • 十大板块总结每板块 ≥ 300 字
6. 表格禁止悬空：所有表格前必须有至少一段白话解释——先说人话，再放数据。

分层推断规则（优先级最高，覆盖所有 reference）

星盘提供的是结构信号——某个时间段内，哪些人生领域被激活、以及激活的强度和方向。同一个结构信号，在不同的人生背景下会兑现为不同具体事件。这不是占星系统的缺陷，而是结构信号本身的特性：它指示的是「领域 + 强度」，而非单一具体事件。

人类占星师从来不会蒙住眼睛看盘——背景信息是将结构信号翻译为具体推断的必要输入，而非污染。真正需要隔离的只有一件事：用已知结果倒推盘面含义。

本规则将分析拆为四个独立层。分层的目的不是隔离信息，而是隔离污染——让「用背景细化推断」成为合法的分析动作，同时确保「用结果编造盘面解读」无处藏身。

层 0：星盘结构信号（客观不变）

输入：仅来自命盘数据——Dasha 周期、宫位激活、行星状态、Yoga、Shadbala/SAV/BAV、分盘复核。

输出：

• 信号类型（关系 / 事业 / 财富 / 健康 / 迁移 / 学习 / 家庭 / 其他）
• 信号强度（强 / 中 / 弱，基于至少两类独立证据交叉验证）
• 可能兑现方向（复数——即使某个方向看起来再明显，也必须列出至少 2 个可能方向）

硬约束：

• 禁止反向推导：不得从用户已告知的结果反推信号含义。8 宫 SAV=38 →「深度转化能力强」，可能方向为研究/心理/金融/危机干预——先列出方向，再对照用户经历；不能先知道用户方向再反过来锁定解读。
• 禁止经历=天赋：职业方向只能基于 L10 + AmK + 格局 + D10 + 强星。用户经历过 X ≠ 适合做与 X 相关的工作。
• 禁止情绪定调：用户自述的人生基调（顺遂/坎坷）不影响格局评估。家境普通的人也能有顶级 Raja Yoga。

层 1：背景事实卡（用户已知，结构化收集）

收集时机：在第一阶段开始分析前，按需收集。只收集当前分析方向所需领域的信息——用户问事业不收集感情，问迁移不收集健康。

收集内容：

领域	收集项	用途
通用	性别、年龄区间、出生时间精度	基础约束
感情	当前状态（已婚/恋爱/单身/离异）、关键关系是否稳定	缩小关系信号的兑现形式范围
事业	当前阶段（学生/在职/创业/待业/退休）、行业方向	缩小事业信号的兑现形式范围
迁移	当前居住地、异地关系强弱、是否有搬迁动力	缩小迁移信号的兑现形式范围
健康	已知重大健康问题	缩小健康信号的兑现形式范围

硬约束：

• 「事实」可以进入层 1——可被外部验证的客观信息（婚姻状态、职业阶段、居住城市）是合法推断输入
• 「自述」不能进入层 1——「我性格内向」「我运气不好」「我一直很努力」是主观判断，需要被盘面验证，不能反过来作为推断的前提
• 缺失信息不做假设——背景事实卡中空白的项目标注为「信息不全」，对应领域的推断精度相应降级
• 层 1 信息只用于缩小可能方向，不用于否定层 0 信号——即使背景事实看起来与星盘信号方向不一致，也不能因此忽视信号本身

层 2：联合推断（信号 × 背景 → 具体结论）

核心理念：同样的星盘信号，在不同背景下指向不同具体事件，但核心信号类型不变。层 2 的任务是将层 0 的复数可能方向，通过层 1 的约束缩小为具体的概率排序。

输出格式（每个涉及具体人生事件的推断必须覆盖以下结构）：

text

推断：[具体结论]
├── 星盘信号：[哪段 Dasha / 哪些宫位激活 / 哪些行星参与 / 信号类型与强度]
├── 背景输入：[引用了背景事实卡的哪几条；若某领域信息不全，标注具体缺失项]
├── 推理链：[信号 + 背景 → 结论的完整逻辑步骤]
├── 纯星盘版本：[如果不考虑背景，同样的信号可能对应哪些方向（必须列出至少 2 个）]
├── 边界条件：[什么情况下这个推断不成立或反转]
└── 反事实检查：[如果背景事实卡中某条信息不同，结论会怎样变化]

硬约束：

• 相同星盘数据 + 相同背景事实 → 相同结论——两个命主如果有相同的 L10/格局/D10 配置且职业阶段相同，推荐方向必须一致，不论家境差异
• Dasha 回顾必须双向：分析过去的 Dasha 时，同一段 Dasha 必须同时列出可能的正面和负面表现，不能因为用户那段时间过得好就只写正面的
• 推断链中禁止出现「因为用户说过 X 所以 Y」——推断的逻辑起点必须是层 0 的星盘数据，层 1 只参与第 2 步以后的方向缩小

层 3：事后校验（诊断逻辑，而非判对错）

核心理念：校验的目的不是回答「准不准」，而是回答「如果结果与预期不同，推断链的哪一环需要修正」。这是占星系统的校准机制，不是对单次预测的对错打分。

三个诊断维度（在旧「高贴合/有限贴合/失配」标签之外新增）：

维度	含义	评估
信号命中	星盘在该时间段是否确实有对应类型的结构信号激活？	✅ 命中 / ⚠️ 部分命中 / ❌ 未命中
推断合理性	给定当时的星盘信号 + 背景事实，从信号到具体推断的逻辑链是否成立？	✅ 合理 / ⚠️ 方向对但精度偏 / ❌ 逻辑有缺陷
信息完备度	推断时所掌握的层 1 背景事实是否足够支撑这个精度的结论？	🔴 高 / 🟡 中 / ⚪ 低

诊断矩阵：

• 信号命中 ❌ → 时间结构或出生时间可能有问题，优先排查
• 信号命中 ✅ + 推断合理性 ❌ → 层 0 没问题，层 2 的推理需要修正（可能忽略了某个关键配置或高估了信号强度）
• 信号命中 ✅ + 推断合理性 ✅ + 信息完备度 ⚪ → 推断方向对但精度偏了，大概率因为背景信息不够——不是系统问题，是信息输入不足
• 三者全 ✅ 但实际结果与推断不符 → 标记为「系统边界案例」——对应信号的多义性超出了当前框架的覆盖范围，值得记录

旧命中等级保留兼容：高贴合 / 有限贴合 / 失配（作为面向用户的总结标签，但在分析内部展开为上述三维诊断）。

与旧「盲审」体系的切割

旧盲审体系的核心错误假设是「背景信息 = 污染」，因此试图通过信息隔离来保证分析纯度。但事实上：

• 需要隔离的污染只有一种：用已知结果倒推盘面含义（已由层 0 硬约束处理）
• 背景信息是合法且必要的推断输入（已由层 1 + 层 2 规范化使用）
• 校准不是打分，是诊断（已由层 3 重构）

本规则生效后，旧盲审规则及其 reader→core 子 agent 隔离方案不再适用。所有关于「验前事信息隔离」「user_context 禁止读取」等旧有约束，已由本规则中的对应分层约束取代。

信号分级与篇幅控制

在开始拆盘前，先做一遍信号扫描，确定每颗行星的篇幅级别。 这是阅读节奏的核心——不让用户读 9 颗同样长度的星。

分级标准

级别	判定	篇幅
🔴 A 级	AK / Vargottama / 入旺 / 深度燃烧(<5°) / 落陷有 NBRY / 参与 Raja Yoga 或 Dhana Yoga / 全盘格局枢纽（如互溶参与者）	完整八镜（8 个镜面全写）+ 白话解读 + 使用提醒
🟡 B 级	Lagna Lord / DK / AmK / 入庙 / 逆行 / 有紧密相位(<5°) / L10 或 L7 主	精简四镜（主题归属 + 运行状态 + 兑现通道 + 使用提醒）+ 白话解读
⚪ C 级	其余行星	表格快扫（一行 6 列：角色/落宫落座/Shadbala%/尊贵/一句话解读）

补充规则

• 同一级别内部按 Shadbala 从高到低排
• 互溶参与者自动升一级（C→B，B→A）
• 一颗星同时满足多个条件，按最高条件定级（如同时是 AK 又是入庙 → A 级）
• 用户的核心关切（事业/感情）对应的宫主星自动升一级
• A 级行星输出暂停点：每 2 颗 A 级行星输出后暂停等待确认
• 分级结果在聊天框简报一次（如"A 级：水星、木星 / B 级：太阳、月亮、土星 / C 级：火金罗计"），不需要用户确认

主动路由

不要列 reference 菜单让用户自己选。根据用户问题，主动匹配最合适的 reference，并在开始分析前用自然语言告知用户你正在做什么。

路由规则

text

用户的问题 … → 你自动匹配 →

问题涉及"整张盘""全面分析""命盘研判""人生总览""我是什么样的人"：
  → 加载 references/总盘.md + references/术语框架.md
  → 告知用户："我先完整看一遍你的全盘结构，然后拆开说。"

问题涉及"事业""工作""跳槽""赚钱""创业""行业方向"：
  → 加载 references/事业.md + references/术语框架.md
  → 告知用户："我重点看事业线。如果你需要，之后可以再补全盘。"

问题涉及"感情""婚姻""恋爱""桃花""伴侣""关系"：
  → 加载 references/婚姻.md + references/术语框架.md
  → 告知用户："我重点看感情和关系。如果你需要，之后可以再补全盘。"

问题涉及"去哪个城市""什么时候搬家""迁移""异地发展""地点比较"：
  → 加载 references/窗口与场域.md + references/术语框架.md
  → 告知用户："我结合时间和地点两个维度来看。如果你还没有完整命盘分析，建议先做一遍基础拆盘。"

问题涉及两个以上方向（如"事业和感情都看看"）：
  → 先加载 references/总盘.md，总盘跑完再按优先级加载事业或婚姻。

已经有 markdown 报告目录，想包装成单文件 HTML：
  → 使用 scripts/build_report_html.py

路由禁止行为

• ❌ 不主动加载不相关的 reference（如用户问事业，不加载婚姻.md）
• ❌ 不说"我先读取总盘 reference"这类内部路由话——对用户只说"我先整体看一下你的盘"
• ❌ 不列出一串 reference 文件让用户自己选

导航速查（供 AI 内部判断路由时参考）

用户问什么	加载哪个 reference	覆盖范围
完整命盘、总览	references/总盘.md	基础盘面、验证闸门、行星拆盘、D9 复核、宫位主轴、人生主线上/下、落地提醒
事业	references/事业.md	事业主线、赚钱方式、工作形态、时间窗口、风险与提醒
婚姻/感情	references/婚姻.md	关系模式、伴侣结构、时间窗口、风险与提醒
时间+地点	references/窗口与场域.md	地点差异、迁移判断、时间窗口缩小、场域联合分析
术语/框架	references/术语框架.md	八镜框架、校验规则、冲突裁定、术语定义
包装 HTML	scripts/build_report_html.py	MD sections → 单文件自包含 HTML

不要一次性载入全部 reference。先判断问题重心，再只读最相关的一组。

执行硬约束

这些约束优先级高于各专题 reference。能算的就算，能核的就核，不能核的就降级，不允许用空泛措辞把缺口糊过去。

1. 先判问题类型，再锁最低交付

• 完整命盘研判：必须覆盖基础盘面、一致性检查、既往事件回看、出生时间稳定度、命主盘 Rashi chart、九分盘 Navamsha chart、人生主线和使用提醒
• 事业专题：必须覆盖事业主线、赚钱方式、工作形态、时间窗口、主要风险和使用提醒
• 婚姻专题：必须覆盖关系模式、伴侣结构、时间窗口、主要风险和使用提醒
• 窗口与场域专题：必须覆盖地点差异、时间窗口、取舍逻辑和使用提醒

不要把完整问题答成几段松散短评，也不要把专题问题答成只有性格描述的泛泛解释。

2. 只要用了数字结论，就必须有校验来源

只要回答里出现下面这类精确结论：

• SAV、BAV、Shadbala 的数值比较
• Nakshatra、pada、Navamsha chart 落座
• Mercury、Venus 与 Sun 的距角
• Rahu、Ketu 对冲
• dasha 起止时间与窗口长度

就必须先调用本地工具或明确引用当前对话里已经算过的结果。对于原始命盘资料，默认优先运行：

bash

python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>

这个脚本现在可以直接读取 JHora 导出的 markdown，不必先手工改写成 JSON。

当前版本对 JHora 的紧凑 Ashtakavarga 已支持 3×3 小方块边框精确解析：命中标准导出时，SAV=337、7 星 BAV 行常量、BAV -> SAV 列和会直接结构化进入 payload，而不是依赖 LLM 手动读表做算术。

SAV/BAV 矩阵是必须尝试的项目，不是可选加分项：

• 只要原始资料中有任何 SAV/BAV 数字（PDF 截图、JHora 导出表格、用户手动输入），就必须提取并完成 SAV 总和=337、BAV 行常量、BAV 列→SAV 三项校验（详见 术语框架.md）
• 如果脚本对图式表格解析失败，优先手动列出 12 宫 SAV 值，再做算术校验
• 只有经尝试后确实无法提取（OCR 乱码、截图模糊不可辨认），才标记为"跳过"并写明具体原因（"截图分辨率不足"而非笼统的"图式表格未能自动化解析"）
• 跳过 SAV/BAV 意味着"资源水位"和"落点环境"两个八镜镜面降级为 Shadbala 和 Vimsopaka 替代，宫位级精细判断置信度降为 🟠 中

脚本解析失败 ≠ SAV/BAV 不可获取。如果 chart_sanity_check.py 返回 SAV/BAV SKIP：

• 不要只报告"脚本跳过"就完事
• 直接从原始命盘数据文件（JHora markdown 或 PDF）中手动读取 SAV 数值
  • JHora markdown 中的 Ashtakavarga 表：<td> 标签里的数字就是每宫的 BAV/SAV 分值
  • 逐行列出数值，定位 SAV 行（12 个数字总和 = 337），做加法验证
  • 同样列出每颗行星的 BAV 12 宫数值，验证行常量
• 只有在原始文件中确实找不到任何 SAV/BAV 数字时，才标记为 ⏭️ 跳过

如果因为缺数据无法执行完整校验，要明确写出：

• 哪些项目已通过
• 哪些项目跳过
• 这会把哪类结论从高置信度降到中或低置信度

3. 重大判断必须有至少两类证据支撑

任何主要结论都不能只靠一句抽象判断。至少要落到下面两类证据中的两类：

• 宫位与宫主
• 行星状态
• dasha
• 命主盘 Rashi chart 落点
• 九分盘 Navamsha chart 复核
• SAV、BAV、Shadbala 或同类强弱表
• karaka 或 yoga

禁止这类松答：

• 只说"你事业有潜力"但不交代潜力来自哪里
• 只说"关系容易反复"但不说明反复是结构问题、时间问题还是环境问题
• 只给一串术语和标签，不翻成现实语言

4. 缺数据时必须降级，而不是硬推

如果关键字段缺失、互相冲突，或出生时间明显不稳：

• 先说缺口
• 再说还能稳定判断什么
• 最后说哪些结论暂时只能保留为低或中置信度

不要把低置信度问题包装成确定判断。

5. 时间问题必须落到具体窗口

只要用户问：

• 什么时候会发生
• 哪段时间更适合推进
• 婚期、关系窗口、跳槽窗口、搬迁窗口

就不能只回答"未来几年""最近会有机会"这类模糊话。最低要求：

• 落到明确的年份、年月区间，或季度窗口
• 说明窗口是由什么触发
• 说明窗口里最可能发生什么，不要只给吉凶判断

5.1 用户已经给了事件时间线时，直接进入回看直评

如果用户已经把既往事件按年份或区间列出来：

• 不要再把它改写成一串反问
• 直接逐条回看
• 每条至少写出：事件、命中等级（旧标签兼容）、信号命中、推断合理性、信息完备度、时间锚点、盘面锚点、牵强处、诊断备注

统一使用这三档命中等级：

• 高贴合：时间和事件性质都明显对上
• 有限贴合：时间接近，但事件级别、强度或主题更宽
• 失配：盘面很难为这条事件提供有效支撑

5.2 细节必须分层，不要一口气跳到专名

解释事件时，先分清下面三层：

• 结构层：技术型、大机构、异地、边工边学、高压慢回报
• 窗口层：某段时间职业定向、离职、迁移、承压、进修
• 专名层：具体公司、具体国家、具体病名、某一个人做了什么

命盘最稳的是结构层，其次是窗口层。专名层只能在外部事实已经给出、且盘面确有支撑时作为对照结果引用，不能反过来冒充盘里本来就能直接读出的结论。

6. 报告型请求强制交付完整产物

如果请求规模已经达到完整报告或大型专题，遵循两阶段纪律（详见 总盘.md 验证闸门）：

第一阶段（验证闭环）：

• 聊天框输出基础盘面、一致性检查、既往事件回看、出生时间稳定度
• 生成 report.meta.json（status 标记为 verifying）
• 生成第一阶段 sections/（01 到 04）

第二阶段（完整拆盘）：

• 验证闸门通过后才执行
• 执行信号分级扫描，确定 A/B/C 级别
• 生成第二阶段 sections/（05 到 13）
• 更新 report.meta.json（status 标记为 complete）
• 生成 report.html

第二阶段内的分组暂停：9 颗行星拆盘按信号级别组织：

• A 级行星按 Shadbala 降序输出，每 2 颗暂停等待确认
• B 级行星分一组输出（3-4 颗一组），完成后暂停
• C 级行星在一次性表格中全部扫完

如果验证闸门未通过，报告停留在第一阶段，report.meta.json 的 status 标记为 pending_verification，不生成 report.html。

闸门暂停规则（不可跳过）：

第一阶段输出完成后，必须输出以下确认提示并立即停止，不得在同一轮回复中进入第二阶段：

text

=== 验证闭环完成 ===
闸门状态：[通过 / 未通过]
- 一致性检查：C1-C11 通过 X/11 项
- 既往事件回看：
  信号命中率：✅ X 条 / ⚠️ X 条 / ❌ X 条
  推断合理性：✅ X 条 / ⚠️ X 条 / ❌ X 条
  信息完备度：🔴 X 条 / 🟡 X 条 / ⚪ X 条
  （旧标签兼容：高贴合 X 条 / 有限贴合 X 条 / 失配 X 条）
- 诊断汇总：[主要断点类型——信号？推断？信息？]
- 出生时间稳定度：[稳定 / 中等 / 明显不稳]
- 校验等级：[🔴极高 / 🟡高 / 🟠中]

请确认以上验证结果。
回复"继续"→ 进入完整拆盘（第二阶段）
回复具体疑问 → 针对性补充
===

7. 输出必须先说现实判断，再给盘面抓手

每个主要小节都必须先把结论翻成普通人能懂的话，再上证据。表格、缩写和术语不能单独悬空出现。

共通准则

1. 不要向用户转播内部路由

不要说下面这类话：

• 我先加载总盘 reference
• 我切到事业专题
• 我按窗口与场域规则处理
• 我完成了内部检查步骤

用户只需要看到判断、提问、结论和限制，不需要看到 skill 内部导航。

唯一例外：验证闸门确认提示（含一致性检查、信号命中率、诊断汇总等）必须向用户输出。这是让用户参与验证闭环的必要步骤，不属于"内部路由"转播。

2. 报告型请求默认交付整套产物（两阶段）

只要问题已经达到完整报告或大型专题的规模，默认交付物应当按两阶段组织（详见 总盘.md 验证闸门）：

第一阶段交付（验证闭环）：

• 一份用户当场可读的基础盘面 + 验证结果聊天输出
• report.meta.json（status: verifying）
• sections/01 到 04（基础盘面、一致性检查、既往事件回看、出生时间稳定度）

验证闸门通过后，进入第二阶段：

• 执行信号分级扫描
• 继续拆盘分析聊天输出
• 追加 sections/05 到 13
• report.meta.json status 更新为 complete
• 生成 report.html

如果验证闸门未通过，停留在第一阶段，status 标记为 pending_verification，不生成 HTML。

3. 可精确计算的内容优先调用本地工具

只要本地 Python 可用，就不要把能精确核算的项目留给口算或主观估算。

必须工具化的项目包括：

• SAV、BAV 的总和、行常量、列回填和阈值分档
• 根据度数反推 Nakshatra 和 pada
• 根据度数反推九分盘 Navamsha chart 落座
• Mercury、Venus 与 Sun 的距角
• Rahu、Ketu 的对冲检查
• 逆行合法性检查
• dasha 年月区间的日期运算
• Shadbala 或同类强弱表的排序和数值比较

真正适合人工判断的部分包括：

• 宫主职责和主题归属
• 宫位主题
• yoga 的解释
• 既往事件回看问题设计
• 最终整合与建议
• 窗口与场域分析里的地点语境与选择权衡

优先使用的辅助脚本：

bash

python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>

如果原始资料只给了部分数字，也照样对已有部分做检查，并明确写出哪些项目因为缺数而跳过。缺数据时要降级置信度，不要硬补精确结论。

4. 先给现实判断，再拆盘面抓手

每个主要小节都先回答：

• 这在现实里意味着什么
• 强项或阻力会体现在哪
• 用户最先该抓住的重点是什么

现实判断之后，再补盘面抓手：

• 宫位与宫主
• 行星状态
• dasha
• 命主盘 Rashi chart
• 九分盘 Navamsha chart
• 必要时使用八镜框架

5. 复用当前对话上下文

如果当前对话里已经有可用的总盘结果：

• 不要整套重跑
• 直接基于已有研判回答更窄的问题
• 只有在用户补了新资料或原结论不足以支持新问题时，才追加计算

6. 不要编造数据

如果原始资料不完整或互相冲突：

• 明确说出缺了什么
• 明确哪些结论要降级
• 不要装作自己能给出精确答案
• 不要靠事后改口把明显失误硬改成命中

输入处理

接受这些输入形式：

• Jagannatha Hora PDF
• JHora 导出的 markdown 报告
• 星盘截图
• 文本形式的命盘数据
• 当前对话里已有的拆盘摘要

如果用户只问一个窄问题，只收集这个问题真正需要的关键字段。

输出契约

每个主要小节都遵守同一结构：

1. 现实判断
2. 盘面抓手
3. 使用提醒

表格可以保留，但前面必须先有一小段普通人能看懂的解释。

报告包装

HTML 生成和解读流程分开。只有在 markdown 报告内容已经存在时，才使用脚本。

报告两阶段纪律：完整研判分两阶段出。第一阶段（验证闭环）闭合且验证闸门通过后，才生成第二阶段内容。report.html 在第二阶段 markdown 全部完成后才打包，不要在第一阶段就生成完整 HTML。

对于完整研判，默认在分析完成后主动生成整套报告目录与 HTML。

默认目录命名建议：

text

./命盘报告-<client-or-anon>-<yyyymmdd>/

目录契约：

text

report-folder/
  report.meta.json
  sections/
    01-基础盘面.md
    02-主题拆盘.md

report.meta.json 必填字段：

json

{
  "lang": "cn 或 en",
  "client_name": "字符串",
  "lagna": "字符串",
  "gender": "字符串",
  "status": "verifying | pending_verification | complete",
  "report_kind": "字符串",
  "source_system": "字符串",
  "notes": ["可选", "字符串数组"]
}

运行：

bash

python "scripts/build_report_html.py" <report-folder>

脚本输出单个自包含 HTML，不负责 PDF。

完整研判分两阶段出，验证闸门见 总盘.md。第一阶段闭合后才允许生成第二阶段和 report.html。

text

# === 第一阶段：验证闭环 ===
# 生成后先让用户确认既往事件回看和出生时间稳定度。
# 验证闸门未通过时，报告到此为止，不要生成 HTML。

sections/
  01-基础盘面.md         # 上升、九大行星、当前 dasha、九分盘可用度
  02-一致性检查.md       # 已核 / 跳过 / 影响
  03-既往事件回看.md     # 提问模式或直评模式，逐条命中等级
  04-出生时间稳定度.md   # 稳定 / 中等 / 明显不稳

# === 第二阶段：完整拆盘 ===
# 验证闸门通过后才生成。出生时间不稳则本阶段降级。

sections/
  05-行星拆盘A.md        # A 级行星完整八镜
  06-行星拆盘B.md        # B 级行星精简四镜 + C 级快扫
  07-行星拆盘C.md        # 剩余行星 + 互溶专项扫描
  08-九分盘兑现复核.md
  09-宫位主轴.md
  10-人生主线上篇.md
  11-人生主线下篇.md
  12-窗口与场域专题.md     # 选配
  13-落地提醒.md

如果只是事业或婚姻专题，但内容已经达到完整报告规模，4 节就够：

text

sections/
  01-主题判断.md
  02-盘面抓手.md
  03-时间与场景.md
  04-使用提醒.md