Harden skill rigor constraints and sync reading quality tools

2026-06-27 18:52:10 +08:00
parent 7600986e34
commit b884b8e7ea
30 changed files with 1262 additions and 56 deletions
@@ -0,0 +1,203 @@
+# 生时校正分盘调用决策树
+
+> 目标：把生时校正从“所有分盘一起上”改成“按证据价值和过拟合风险分层调用”。
+> 结论先行：**不是所有分盘一股脑上。**
+
+## 1. 总原则
+
+生时校正时，优先级应当是：
+
+1. `Dasha + dated events`
+2. `D9`
+3. `D10`
+4. `D7 / D12 / D24 / D4 / D2` 按主题选
+5. `Nakshatra / Pada / house shifts`
+6. `D30`
+7. `D60`
+
+一句话版本：
+
+**Dasha 定框，D9/D10 定核心，D12/D7/D24 等按题补刀，D30/D60 最后谨慎使用。**
+
+这和当前仓库里已有的校时权重一致：
+
+- `Dasha` 40%
+- `分盘一致性` 35%
+- `宫位变化` 15%
+- `Nakshatra Pada` 10%
+
+对应实现见：
+
+- [jyotish-app/rectification-engine.js](/Users/wuyongnaren/Documents/印度占星/jyotish-app/rectification-engine.js)
+- [references/varga-system-quick-reference.md](/Users/wuyongnaren/Documents/印度占星/references/varga-system-quick-reference.md)
+
+## 2. 第一层：主引擎
+
+### Dasha + dated events
+
+这是第一裁判，不是某一张分盘。
+
+先用真实事件把时间框住：
+
+- 结婚 / 分手 / 离婚
+- 入职 / 升职 / 创业 / 换工作
+- 搬迁 / 出国 / 移民
+- 生育 / 流产 / 子女关键年份
+- 健康危机 / 手术 / 事故
+- 重大财富变化 / 破财
+
+如果没有 dated events，只靠分盘做校时，风险会显著上升。
+
+## 3. 第二层：核心分盘
+
+### D9
+
+最适合验证：
+
+- 婚姻 / 关系质量
+- 亲密关系成熟度
+- 配偶画像
+- 内在命运路线是否与 D1 同向
+
+### D10
+
+最适合验证：
+
+- 事业显化
+- 职业兑现
+- 升职 / 名声 / 社会角色
+- 事业方向切换是否成立
+
+如果用户提供的事件主要是婚恋和事业，**D9 + D10 是最值钱的双核**。
+
+## 4. 第三层：主题分盘补刀
+
+当 Dasha 已经定出大框，但两个候选时间都还能解释时，再按主题调专项分盘：
+
+| 事件主题 | 优先分盘 | 用法 |
+|---|---|---|
+| 婚姻/关系 | `D9` | 核心，不是补充 |
+| 事业/升职/换工作 | `D10` | 核心，不是补充 |
+| 子女/生育 | `D7` | 用于拉开生育相关年份与子女主题差异 |
+| 父母/家族 | `D12` | 辅助裁判，不是第一裁判 |
+| 教育/考试 | `D24` | 学业、考试、研究路线 |
+| 房产/搬迁 | `D4` | 房产、居所、迁移、家庭落点 |
+| 财富/收入变化 | `D2` | 收入、资产、财务结构变化 |
+| 健康/事故/创伤 | `D30` | 只在有明确健康事件时用 |
+
+其中 `D12` 的角色要说清楚：
+
+- 它很有价值
+- 但通常在 `D9/D10` 不能彻底拉开差距时再上
+- 所以它是**辅助裁判**，不是**第一裁判**
+
+## 5. 第四层：细分钟收口层
+
+这一层适合最后 2-10 分钟的缩窄，不适合一开始就拍板：
+
+- `Nakshatra / Pada`
+- 特殊 Lagna
+- 敏感点
+- 分盘上升切换点
+- 宫位变动
+
+它们的作用是：
+
+- 在大框已经基本收敛后
+- 继续缩小到更细的分钟段
+
+不应让这一层反过来主导整体结论。
+
+## 6. 第五层：超高敏层，慎用
+
+### D30
+
+可用，但前提是用户有明确的：
+
+- 健康危机
+- 手术
+- 创伤
+- 事故
+- 极端压力事件
+
+### D60
+
+只适合在已经高度收敛后，作为最后参考。
+
+不要让 `D60` 反过来主导校时结论。原因很简单：
+
+- 对出生时间太敏感
+- 在事件样本不足时特别容易过拟合
+- 很容易出现“解释很漂亮，但时间其实没校准好”
+
+## 7. 实战决策树
+
+### Step 1
+
+先问：有没有 5 个以上带年份或日期的真实事件？
+
+- 没有：先补事件，不急着堆分盘
+- 有：进入 Dasha 定框
+
+### Step 2
+
+事件主要落在哪个主题？
+
+- 婚姻/关系 -> `D9`
+- 事业/升职/换工作 -> `D10`
+- 子女/生育 -> `D7`
+- 父母/家族 -> `D12`
+- 教育/考试 -> `D24`
+- 房产/搬迁 -> `D4`
+- 财富/收入 -> `D2`
+- 健康/事故/创伤 -> `D30`
+
+### Step 3
+
+如果两个候选时间在核心分盘上仍都说得通：
+
+- 再看 `Nakshatra / Pada / house shifts`
+- 再看更窄的分盘上升切换
+
+### Step 4
+
+只有当 Dasha + 核心分盘 + 主题分盘都已经明显收敛后，才允许上 `D60` 做最后参考。
+
+## 8. 时间敏感度提醒
+
+仓库当前已有的分盘时间精度要求：
+
+- `D9 / D10`: `±2分钟`
+- `D2/D3/D4/D7/D12`: `±5分钟`
+- `D30`: `±1分钟`
+- `D60`: `±30秒`
+
+因此：
+
+- `D9/D10` 足够敏感，适合作为校时主力
+- `D30/D60` 过于敏感，适合作为后段验证
+
+## 9. 禁止做法
+
+以下做法不推荐：
+
+- 一开始就把所有分盘全开
+- 用 `D60` 反向主导时间结论
+- 没有 dated events 时过度依赖高敏分盘
+- 用单一分盘推翻 `D1 + Dasha + 核心分盘` 的同向证据
+
+## 10. 落地口径
+
+校时时，默认解释顺序应是：
+
+1. `Dasha + dated events`
+2. `D9`
+3. `D10`
+4. 主题专项分盘
+5. `Nakshatra / Pada / house shifts`
+6. `D30`
+7. `D60`
+
+如果需要一句给用户看的简明口径，就用这句：
+
+**校时主力不是“所有分盘”，而是“Dasha 定框，D9/D10 定核心，D12/D7/D24 等按题补刀，D30/D60 最后谨慎使用”。**
@@ -299,6 +299,50 @@
        "Upgrade only when D1 promise, D9 support, UL condition and timing all point in the same direction."
      ]
    },
+    "natural_malefic_functional_role_guardrail": {
+      "title": "Natural Malefic vs Functional Role Guardrail",
+      "status": "frozen_template",
+      "authority_level": "A/B/C layered",
+      "domain": ["interpretation_boundary", "functional_role", "saturn", "mars", "rahu", "ketu"],
+      "source_refs": [
+        "AGENTS.md",
+        "SKILL.md",
+        "references/prediction-boundary-protocol.md",
+        "docs/research/malefic_overread_top10_2026_06_27.md"
+      ],
+      "trigger_patterns": [
+        "Saturn negative",
+        "Mars negative",
+        "Rahu negative",
+        "Ketu negative",
+        "功能性吉凶星",
+        "自然凶星",
+        "Rahu/Ketu 负面",
+        "土星是不是坏",
+        "火星是不是坏"
+      ],
+      "required_cross_checks": [
+        "Separate natural benefic/malefic status from functional role under the current Lagna",
+        "State the topic-domain role before giving any positive or negative conclusion",
+        "Check D1 promise plus the relevant Varga before calling the planet harmful or helpful",
+        "Check Dasha/Transit activation before upgrading from trait to event claim",
+        "For Rahu/Ketu, declare node mode/dispositor and evaluate both breakthrough and loss patterns"
+      ],
+      "confidence_ceiling": "B when natural role, functional role, topic-domain role and timing all agree; C when only natural malefic language is available or the functional role is unresolved.",
+      "forbidden_claims": [
+        "Saturn alone means failure",
+        "Mars alone means relationship destruction",
+        "Rahu or Ketu alone proves damage, scandal or collapse",
+        "A natural malefic label alone overrides functional role, D1 promise or timing"
+      ],
+      "safe_output_patterns": [
+        "Always describe the planet in four layers: natural nature, functional role, topic-domain role and current activated outcome.",
+        "Frame Saturn as delay, responsibility, structure or long-cycle payoff depending on promise and activation, not as automatic negativity.",
+        "Frame Mars as conflict, execution, surgery, competition or entrepreneurial drive depending on context, not as automatic damage.",
+        "Frame Rahu and Ketu as dual-edge amplifiers that can produce breakthrough, disruption, detachment or leakage depending on promise, dispositor and activation.",
+        "If natural and functional meanings conflict, explicitly lower confidence and let the promise/timing layer decide the practical reading."
+      ]
+    },
    "pushkara_vargottama_avastha_synthesis": {
      "title": "Pushkara / Vargottama / Avastha / RTN Synthesis Template",
      "status": "frozen_template",
@@ -414,7 +414,8 @@ SCRIPT=~/.workbuddy/skills/jyotish-vedic-astrology/scripts/jyotish_engine.py
 1. **common-misconceptions.md**：印度占星常见误判与冲突问题集（错题本）⭐⭐⭐⭐⭐
 2. **modern-language-guide.md**：现代生活措辞指南
 3. **birth-time-rectification-advanced.md**：出生时间矫正高级方法论
-4. **birth-time-rectification-cases.md**：出生时间矫正案例集
+4. **birth-time-rectification-decision-tree.md**：生时校正分盘调用决策树（Dasha 定框，D9/D10 定核心）
+5. **birth-time-rectification-cases.md**：出生时间矫正案例集
 5. **pdf-chart-reading-guide.md**：PDF星盘读取指南 v3.0
 6. **prediction-checklist.md**：预测清单
 7. **data-bridge-mapping.md**：数据桥接映射
@@ -0,0 +1,60 @@
+# Real Reading Quality Checklist
+
+> 作用：给真实解读、案例分析、代理执行和高严谨输出做统一质检。
+> 核心原则：**最容易毁掉答案质量的，不是少看一颗星，而是少看一层裁决结构。**
+
+## A. 参数冻结层
+
+1. `Ayanamsa` 是否显式声明？
+2. `Node mode` (`Mean` / `True`) 是否显式声明？
+3. 相关 `house system / bhava policy` 是否声明？
+4. 若参数层有冲突或缺失，是否明确降置信度？
+
+## B. 路由与题目域层
+
+5. 是否先读取并执行了 `strict-workflow-router.md` 对应 route？
+6. 是否按题目域强制展开相关分盘，而不是只看 D1？
+7. 是否把 `covered` 和 `complete` 分开表达，没有偷换成熟度？
+
+## C. 承诺层
+
+8. 是否先看了 D1 的 promise，而不是直接进入细节技法？
+9. 是否检查了题目域核心宫位、宫主、承诺型 Yoga？
+10. 是否避免让单一 Yoga / 单一文章规则越权？
+
+## D. 功能性角色层
+
+11. 是否显式给出 `Functional Benefic/Malefic`？
+12. 是否区分了自然属性、功能属性、题目域角色、当前激活结果？
+13. 对 `Saturn / Mars / Rahu / Ketu` 是否避免了“天然负面”式偷懒断法？
+
+## E. 分盘层
+
+14. 婚恋是否至少展开 `D9 / UL / DK`？
+15. 事业是否至少展开 `D10 / A10 / AmK/Karakamsha`？
+16. 财富是否至少展开 `D2/D11`，并回看 D1/D9/D10 的变现链？
+17. 若使用 `D30 / D60`，是否明确说明这是高敏后置层而非主裁判？
+
+## F. Timing 层
+
+18. 是否至少执行 `Vimshottari + Narayana` 双轨交叉？
+19. 若做具体事件判断，是否加入 `Transit / Double Transit / annual / KP or Chara support`？
+20. 如果 timing 只做到窗口级，而不是日期级，是否说清了边界？
+
+## G. 外部真值与诚信边界
+
+21. 是否清楚声明 `production_tuning_allowed` 的当前状态？
+22. 是否把外部 oracle 未闭环的前线（Dasha boundary / Shadbala absolute / Tajika annual）说清楚？
+23. 是否避免把内部一致性伪装成传统软件级真值冻结？
+
+## H. 输出层
+
+24. 是否输出 `Technique Audit Table` 或等价审计表？
+25. 是否给出 `used / partial / blocked / not used` 级别说明？
+26. 是否给出置信度，而不是只给断语？
+27. 是否把 must-not-overclaim 边界说清楚？
+
+## 一句话用法
+
+只要这张表里有 3-4 项没过，就不要把输出包装成“高严谨结论”。  
+只要 `参数层 + 承诺层 + 分盘层 + timing 层 + 外部真值边界` 没一起过，就不能把 skill 说成“已经无疏漏封顶”。
@@ -12,6 +12,23 @@ The user should not need to ask for Chara Dasha, A10, Argala, Shadbala, Ashtakav

 Every non-trivial reading must end with a **Technique Audit Table**.

+## 0.5 High-Rigor Override
+
+When the user asks for maximum rigor, no guessing, past-event verification, raw evidence, or full parity with top open-source Jyotish engines, the reading enters **High-Rigor Override**.
+
+Under this override, the engine must:
+
+1. Attempt cross-reference against `PyJHora / VedAstro / jyotishganit`, while respecting license boundaries.
+2. Use native repository implementations instead of lightweight summary scripts whenever a native module already exists.
+3. Require `Vimshottari + Narayana Dasha` before making major timing claims; if they materially conflict, mark the conclusion `blocked` or downgrade confidence.
+4. Force relevant divisional microscope layers:
+   - `D10` + `A10` for career
+   - `D2/D11` for wealth
+   - `D9` + `UL` for relationship
+5. Include raw outputs: exact degrees, dasha boundaries, Shadbala / AV values, Yoga names, ayanamsa / node mode, and external evidence pointers where available.
+
+If any of the above cannot be completed because of missing birth precision, external oracle gaps, license quarantine, adapter failure, or missing field mapping, the report must explicitly say `blocked` rather than silently continuing with a fake-complete conclusion.
+
 ---

 ## 1. Question router