吠陀命盘研判系统
这是一套中文总入口 skill。先判断用户到底要看整张盘、某个专题，还是时间与地点的联合问题，再只读取当前任务真正需要的 reference。
导航方式
按问题最小化加载：
- 用户要完整命盘研判、本命总览、既往事件回看、出生时间稳定度判断，或命主盘 Rashi chart 与九分盘 Navamsha chart 的联合拆盘：
读取
references/总盘.md
- 用户要事业方向、工作模式、变现路径、岗位适配、创业与上升窗口：
读取
references/事业.md
- 用户要婚姻、恋爱模式、关系落地、伴侣结构、桃花窗口、长期关系判断：
读取
references/婚姻.md
- 用户要地点选择、迁移判断、城市比较、事件窗口缩小，或时间与场域联合分析：
读取
references/时空盘.md
- 需要共享术语、读盘抓手和冲突裁定口径：
读取
references/术语框架.md
- 已经有 markdown 报告目录，想包装成单文件 HTML：
使用
scripts/build_report_html.py
不要一次性载入全部 reference。先判断问题重心，再只读最相关的一组。
执行硬约束
这些约束优先级高于各专题 reference。能算的就算，能核的就核，不能核的就降级，不允许用空泛措辞把缺口糊过去。
1. 先判问题类型，再锁最低交付
- 完整命盘研判：必须覆盖基础盘面、一致性检查、既往事件回看、出生时间稳定度、命主盘 Rashi chart、九分盘 Navamsha chart、人生主线和使用提醒
- 事业专题：必须覆盖事业主线、赚钱方式、工作形态、时间窗口、主要风险和使用提醒
- 婚姻专题：必须覆盖关系模式、伴侣结构、时间窗口、主要风险和使用提醒
- 时空盘专题：必须覆盖地点差异、时间窗口、取舍逻辑和使用提醒
不要把完整问题答成几段松散短评，也不要把专题问题答成只有性格描述的泛泛解释。
2. 只要用了数字结论，就必须有校验来源
只要回答里出现下面这类精确结论：
- SAV、BAV、Shadbala 的数值比较
- Nakshatra、pada、Navamsha chart 落座
- Mercury、Venus 与 Sun 的距角
- Rahu、Ketu 对冲
- dasha 起止时间与窗口长度
就必须先调用本地工具或明确引用当前对话里已经算过的结果。对于原始命盘资料，默认优先运行：
python "scripts/chart_sanity_check.py" <chart-input.json-or-jhora.md>
这个脚本现在可以直接读取 JHora 导出的 markdown，不必先手工改写成 JSON。
如果某些图式表格在原始导出里无法稳定摊平，至少先完成主盘、Nakshatra、Navamsha chart、罗计轴、日水金距角和 dasha 的基础校验，再把矩阵类检查标成跳过或待补整理。
如果因为缺数据无法执行完整校验，要明确写出：
- 哪些项目已通过
- 哪些项目跳过
- 这会把哪类结论从高置信度降到中或低置信度
3. 重大判断必须有至少两类证据支撑
任何主要结论都不能只靠一句抽象判断。至少要落到下面两类证据中的两类：
- 宫位与宫主
- 行星状态
- dasha
- 命主盘 Rashi chart 落点
- 九分盘 Navamsha chart 复核
- SAV、BAV、Shadbala 或同类强弱表
- karaka 或 yoga
禁止这类松答：
- 只说“你事业有潜力”但不交代潜力来自哪里
- 只说“关系容易反复”但不说明反复是结构问题、时间问题还是环境问题
- 只给一串术语和标签，不翻成现实语言
4. 缺数据时必须降级，而不是硬推
如果关键字段缺失、互相冲突，或出生时间明显不稳：
- 先说缺口
- 再说还能稳定判断什么
- 最后说哪些结论暂时只能保留为低或中置信度
不要把低置信度问题包装成确定判断。
5. 时间问题必须落到具体窗口
只要用户问：
- 什么时候会发生
- 哪段时间更适合推进
- 婚期、关系窗口、跳槽窗口、搬迁窗口
就不能只回答“未来几年”“最近会有机会”这类模糊话。最低要求：
- 落到明确的年份、年月区间，或季度窗口
- 说明窗口是由什么触发
- 说明窗口里最可能发生什么，不要只给吉凶判断
5.1 用户已经给了事件时间线时，直接进入回看直评
如果用户已经把既往事件按年份或区间列出来：
- 不要再把它改写成一串反问
- 直接逐条回看
- 每条至少写出：事件、命中等级、时间锚点、盘面锚点、牵强处
统一使用这三档命中等级：
高贴合：时间和事件性质都明显对上有限贴合：时间接近，但事件级别、强度或主题更宽失配：盘面很难为这条事件提供有效支撑
5.2 细节必须分层，不要一口气跳到专名
解释事件时，先分清下面三层：
结构层：技术型、大机构、异地、边工边学、高压慢回报窗口层：某段时间职业定向、离职、迁移、承压、进修专名层：具体公司、具体国家、具体病名、某一个人做了什么
命盘最稳的是结构层，其次是窗口层。专名层只能在外部事实已经给出、且盘面确有支撑时作为对照结果引用，不能反过来冒充盘里本来就能直接读出的结论。
6. 报告型请求强制交付完整产物
如果请求规模已经达到完整报告或大型专题：
- 聊天框里要有可直接阅读的完整结论
- 要生成
report.meta.json
- 要生成
sections/ 分节 markdown
- 要生成
report.html
不要只在聊天里说完就结束，也不要只留 markdown 不打包 HTML。
7. 输出必须先说现实判断，再给盘面抓手
每个主要小节都必须先把结论翻成普通人能懂的话，再上证据。表格、缩写和术语不能单独悬空出现。
共通准则
1. 不要向用户转播内部路由
不要说下面这类话：
我先加载总盘 reference我切到事业专题我按时空盘规则处理我完成了内部检查步骤
用户只需要看到判断、提问、结论和限制，不需要看到 skill 内部导航。
2. 报告型请求默认交付整套产物
只要问题已经达到完整报告或大型专题的规模，默认交付物应当包括：
- 一份用户当场可读的聊天输出
- 一个带
report.meta.json 的报告目录
sections/ 里的 markdown 分节文件- 生成后的
report.html
不要等用户额外提醒“顺便生成 HTML”。如果问题本身就是报告型请求，就主动做完整交付。
3. 可精确计算的内容优先调用本地工具
只要本地 Python 可用，就不要把能精确核算的项目留给口算或主观估算。
必须工具化的项目包括：
- SAV、BAV 的总和、行常量、列回填和阈值分档
- 根据度数反推 Nakshatra 和 pada
- 根据度数反推九分盘 Navamsha chart 落座
- Mercury、Venus 与 Sun 的距角
- Rahu、Ketu 的对冲检查
- 逆行合法性检查
- dasha 年月区间的日期运算
- Shadbala 或同类强弱表的排序和数值比较
真正适合人工判断的部分包括：
- 宫主职责和主题归属
- 宫位主题
- yoga 的解释
- 既往事件回看问题设计
- 最终整合与建议
- 时空盘里的地点语境与选择权衡
优先使用的辅助脚本：
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 报告
- 星盘截图
- 文本形式的命盘数据
- 当前对话里已有的拆盘摘要
如果用户只问一个窄问题，只收集这个问题真正需要的关键字段。
输出契约
每个主要小节都遵守同一结构：
现实判断盘面抓手使用提醒
表格可以保留，但前面必须先有一小段普通人能看懂的解释。
报告包装
HTML 生成和解读流程分开。只有在 markdown 报告内容已经存在时，才使用脚本。
对于完整研判，默认在分析完成后主动生成整套报告目录与 HTML。
默认目录命名建议：
./命盘报告-<client-or-anon>-<yyyymmdd>/
目录契约：
report-folder/
report.meta.json
sections/
01-基础盘面.md
02-主题拆盘.md
report.meta.json 必填字段：
{
"lang": "cn 或 en",
"client_name": "字符串",
"lagna": "字符串",
"gender": "字符串",
"status": "字符串",
"report_kind": "字符串",
"source_system": "字符串",
"notes": ["可选", "字符串数组"]
}
运行：
python "scripts/build_report_html.py" <report-folder>
脚本输出单个自包含 HTML，不负责 PDF。
完整研判建议使用下面这组分节：
sections/
01-基础盘面.md
02-既往事件回看.md
03-行星拆盘A.md
04-行星拆盘B.md
05-行星拆盘C.md
06-九分盘兑现复核.md
07-宫位主轴.md
08-人生主线上篇.md
09-人生主线下篇.md
10-时空盘专题.md
11-落地提醒.md
如果只是事业或婚姻专题，但内容已经达到完整报告规模，4 节就够：
sections/
01-主题判断.md
02-盘面抓手.md
03-时间与场景.md
04-使用提醒.md
