Build event adjudication skeleton for relationship and wealth
This commit is contained in:
@@ -56,9 +56,10 @@ description: 印度占星(Jyotish)专业解盘与推运系统。核心能力
|
||||
| **B:PDF/文字星盘** | PDF/详细文字描述 | 提取数据+Quality Gate → `references/pdf-chart-reading-guide.md` |
|
||||
| **C:时间不明确** | "不知道几点出生" | 互动式出生时间矫正 → 确认后走路径A |
|
||||
|
||||
**强制工作流**(完整规范 → `references/ai-reading-workflow-prompt.md` v3.0):
|
||||
**强制工作流**(完整规范 → `references/ai-reading-workflow-prompt.md` v5.1.0):
|
||||
|
||||
0. **阶段负一**:问题类型路由(事业/婚恋/财务/应期/历史验证/综合解盘)→ 必须先读 `references/strict-workflow-router.md`,按对应 strict checklist 执行;用户不需要主动点名高级技法。
|
||||
0.1 **事件判定骨架**:凡涉及 marriage / career / wealth / event verify,必须执行 `事件判定骨架 v1.0`,按 `Route -> Evidence Ledger -> Adjudication -> Output Contract` 顺序输出;不得再凭直觉跳模块或随口给置信度。详见 `references/ai-reading-workflow-prompt.md`、`references/event_judgment_skeleton.md`、`references/event_judgment_marriage.md` 与 `references/event_judgment_examples.md`。
|
||||
1. **阶段零**:入口路由(A/B/C自动判断)
|
||||
2. **阶段一**(仅B):PDF/图片提取 + Quality Gate
|
||||
3. **阶段二**:意图识别 → 路由目标宫位(无明确意图→Level 2综合解盘)
|
||||
@@ -70,6 +71,40 @@ description: 印度占星(Jyotish)专业解盘与推运系统。核心能力
|
||||
8. **阶段七**:现代措辞包装
|
||||
9. **阶段八**:输出 Technique Audit Table,逐项声明已调用/未调用/部分可用/缺失模块及其对置信度的影响。
|
||||
|
||||
### ⚙️ 事件判定骨架(总入口)
|
||||
|
||||
涉及 `marriage / career / wealth / health / generic event verification` 的问题,不得只按关键词随意调模块,必须进入事件判定骨架。
|
||||
|
||||
总骨架固定为四段:
|
||||
|
||||
1. `Route`
|
||||
- 先判断 **问题域**(婚恋 / 事业 / 财富 / 健康 / 泛事件)
|
||||
- 再判断 **任务类型**(预测 / 回测 / 校时辅助 / 多方案裁决)
|
||||
- 再判断 **目标粒度**(趋势 / 窗口 / 月份 / 具体事件验证)
|
||||
2. `Evidence Ledger`
|
||||
- 每个模块都要落成结构化证据块,不得只写散文式描述
|
||||
3. `Adjudication`
|
||||
- 必须按 `Promise -> Activation -> Manifestation -> Timing` 裁决
|
||||
4. `Output Contract`
|
||||
- 最终只允许输出 `verdict + confidence + conflicts + audit + raw evidence`
|
||||
|
||||
硬规则:
|
||||
|
||||
- timing / event 不得只看 `Vimshottari`,必须 `Vimshottari + Narayana`
|
||||
- 事业必须 `D10 + A10`
|
||||
- 财富必须 `D2 / D11`
|
||||
- 婚恋必须 `D9 + UL`
|
||||
- 必须显式给出 `Functional Benefic/Malefic`
|
||||
- 缺少关键层时必须 `blocked` 或降置信度
|
||||
- 必须交付原始依据:度数、Dasha 边界、Shadbala、AV、Ayanamsa、Node mode、模板/案例引用
|
||||
|
||||
详细执行文档:
|
||||
|
||||
- [`references/event_judgment_skeleton.md`](/Users/wuyongnaren/Documents/印度占星/references/event_judgment_skeleton.md)
|
||||
- [`references/event_judgment_marriage.md`](/Users/wuyongnaren/Documents/印度占星/references/event_judgment_marriage.md)
|
||||
- [`references/event_judgment_wealth.md`](/Users/wuyongnaren/Documents/印度占星/references/event_judgment_wealth.md)
|
||||
- (后续再补)`event_judgment_career.md`
|
||||
|
||||
## 五层硬约束(全球前三引擎强制调用)
|
||||
|
||||
当用户明确要求“不要凭经验泛谈”“必须拉满能力”“必须提交底层证据”“要做过去案例验证”“要看全球前三项目全部能力”时,进入 `high-rigor override` 模式。该模式不是建议,而是硬约束:
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
# Marriage Adjudicator First-Pass Audit (2026-06-27)
|
||||
|
||||
> 目标:把第一批婚恋事件样本从“命中率讨论”升级为“可校准的缺陷类型学”,为后续婚恋 adjudicator 调权与漏判修复提供标靶集。
|
||||
|
||||
---
|
||||
|
||||
## 1. 审计方法
|
||||
|
||||
本轮不再只看 `Rao 8参数命中数`,而是同时观察:
|
||||
|
||||
1. 旧体系婚恋评分(`verify-results-v6.1.json`)
|
||||
2. 新体系婚恋事件聚合信号(`full-reading.modules.dasa_convergence.domain_activations.marriage_partnership`)
|
||||
3. `Vivah Saham`
|
||||
4. `Darakaraka marriage_quality_score`
|
||||
5. `Upapada Lagna`
|
||||
|
||||
审计目标不是立刻改权重,而是先固定:
|
||||
|
||||
- 哪些案例属于 `Promise 弱型`
|
||||
- 哪些属于 `Activation/Convergence 弱型`
|
||||
- 哪些属于 `Manifestation 分层混淆型`
|
||||
- 哪些属于 **`label-lift failure`**
|
||||
|
||||
---
|
||||
|
||||
## 2. 第一批标靶集
|
||||
|
||||
| case | real-world event type | old Rao score | promise verdict | activation verdict | manifestation verdict | formalization verdict | final adjudicator verdict | miss type | suspected missing features |
|
||||
|---|---|---:|---|---|---|---|---|---|---|
|
||||
| Priyanka Chopra + Nick Jonas | legal marriage | 2/8 | medium | weak (`L1`) | partial | medium | weak window / under-lifted | activation/convergence weak | Chara/Jaimini marriage activation, transit support, legal-marriage label lift |
|
||||
| Britney Spears + Jason Alexander | legal marriage | 4/8 | medium | weak (`None`) | weak | weak | insufficient / weak | manifestation split unclear | short-marriage handling, unstable legal marriage tagging |
|
||||
| Britney Spears + Kevin Federline | legal marriage | 7/8 | medium | weak (`None`) | medium | medium | **under-lifted** | **label-lift failure** | conversion from strong legacy score to legal-marriage event label |
|
||||
| Princess Diana + Prince Charles | public formalization | 5/8 | medium | weak (`None`) | medium | strong | moderate but mis-labeled | manifestation split | public formalization vs marriage quality separation |
|
||||
| Barack Obama + Michelle Robinson | legal marriage | 4/8 | medium | weak (`None`) | medium | medium | under-lifted | activation/convergence weak | Venus-type marriage activation not fully lifted |
|
||||
| Tom Cruise + Katie Holmes | public formalization | 7/8 | medium | weak (`None`) | medium | strong | **under-lifted** | **label-lift failure** | public-formalization event family not surfaced |
|
||||
|
||||
---
|
||||
|
||||
## 3. 关键发现
|
||||
|
||||
### 3.1 主要瓶颈不在 promise,而在 event label lift
|
||||
|
||||
这批样本里,最显著的问题不是“完全没有婚恋结构”,而是:
|
||||
|
||||
- `Vivah Saham` 常常为 `high` 或 `moderate`
|
||||
- `DK score` 常常在 `0.55-0.65`
|
||||
- `UL` 也能给出社会表现线索
|
||||
- 但 `marriage_partnership` 经常是 `None` 或仅 `L1`
|
||||
|
||||
这说明系统看到了一部分婚恋结构,但**没有把它抬升成正确的事件标签**。
|
||||
|
||||
### 3.2 `label-lift failure` 应作为独立缺陷类别
|
||||
|
||||
以下样本最典型:
|
||||
|
||||
- `Britney Spears + Kevin Federline`
|
||||
- `Tom Cruise + Katie Holmes`
|
||||
|
||||
共同特征:
|
||||
|
||||
- 旧 Rao 分数高(`7/8`)
|
||||
- 现实事件明确成立
|
||||
- 新聚合器中的 `marriage_partnership` 仍然没有点亮
|
||||
|
||||
这不是传统意义上的“完全没算到”,而是一个新的、可校准的聚合器缺陷:
|
||||
|
||||
**旧体系能命中,但新体系没有正确抬升事件标签。**
|
||||
|
||||
### 3.3 “婚姻事件”需要拆成至少四层
|
||||
|
||||
本轮样本已支持继续沿用以下拆分:
|
||||
|
||||
1. `romantic activation`
|
||||
2. `relationship formation`
|
||||
3. `legal marriage`
|
||||
4. `public formalization`
|
||||
|
||||
像 `Princess Diana + Prince Charles`、`Tom Cruise + Katie Holmes` 这类名人样本,很可能在第 4 层更强,而不应被粗暴等同为“高质量婚姻事件”。
|
||||
|
||||
---
|
||||
|
||||
## 4. 下一轮修复重点
|
||||
|
||||
1. 给 `marriage_partnership` 聚合层增加 `label-lift failure` 专门回归样本
|
||||
2. 单独补“legal marriage / public formalization”事件标签
|
||||
3. 将 `Vivah Saham + DK/UL + dual dasha` 的同向组合作为婚恋 lift 候选
|
||||
4. 用女性样本继续扩展:
|
||||
- `relationship formation`
|
||||
- `engagement/public relationship`
|
||||
- `legal marriage`
|
||||
|
||||
---
|
||||
|
||||
## 5. 版本备注
|
||||
|
||||
- 本文档是第一轮审计,不是最终 benchmark
|
||||
- 目的在于固定缺陷类型,而不是立即宣布婚恋 adjudicator 已完成校准
|
||||
+229
-3
@@ -27,7 +27,7 @@ import os
|
||||
import json
|
||||
import subprocess
|
||||
import asyncio
|
||||
from typing import Dict, Any, Optional
|
||||
from typing import Dict, Any, Optional, List
|
||||
|
||||
# Add scripts dir to path so imports work
|
||||
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
|
||||
@@ -91,6 +91,229 @@ def _audit_status() -> Dict[str, Any]:
|
||||
return {"valid": False, "raw": result.stdout}
|
||||
|
||||
|
||||
def _safe_get(data: Dict[str, Any], *path: str) -> Any:
|
||||
cur: Any = data
|
||||
for part in path:
|
||||
if not isinstance(cur, dict) or part not in cur:
|
||||
return None
|
||||
cur = cur[part]
|
||||
return cur
|
||||
|
||||
|
||||
def _convergence_score(convergence: Any) -> int:
|
||||
if not isinstance(convergence, dict):
|
||||
return 0
|
||||
level = convergence.get("convergence_level")
|
||||
mapping = {"L1": 20, "L2": 40, "L3": 60, "L4": 80, "L5": 95}
|
||||
return mapping.get(level, 0)
|
||||
|
||||
|
||||
def _derive_event_judgement(route: str, present: Dict[str, Any], missing: List[str]) -> Dict[str, Any]:
|
||||
if route == "relationship":
|
||||
score = 0
|
||||
score += 15 if present.get("d9_navamsa") else 0
|
||||
score += 15 if present.get("upapada_lagna") else 0
|
||||
score += 15 if present.get("darakaraka") else 0
|
||||
score += 10 if present.get("vivah_saham") else 0
|
||||
score += 10 if present.get("vimshottari_current") else 0
|
||||
score += 10 if present.get("narayana_current") else 0
|
||||
score += _convergence_score(present.get("marriage_convergence"))
|
||||
if missing:
|
||||
score = min(score, 35)
|
||||
score = min(score, 100)
|
||||
if missing:
|
||||
verdict = "insufficient_evidence"
|
||||
elif score >= 80:
|
||||
verdict = "high_probability_window"
|
||||
elif score >= 60:
|
||||
verdict = "moderate_probability_window"
|
||||
elif score >= 40:
|
||||
verdict = "weak_window_needs_confirmation"
|
||||
else:
|
||||
verdict = "insufficient_evidence"
|
||||
return {
|
||||
"event_family": "relationship",
|
||||
"score": score,
|
||||
"verdict": verdict,
|
||||
"primary_drivers": [
|
||||
key for key in (
|
||||
"marriage_convergence",
|
||||
"vimshottari_current",
|
||||
"narayana_current",
|
||||
"darakaraka",
|
||||
"upapada_lagna",
|
||||
)
|
||||
if present.get(key)
|
||||
],
|
||||
}
|
||||
|
||||
if route == "finance":
|
||||
score = 0
|
||||
score += 15 if present.get("d2_hora") else 0
|
||||
score += 10 if present.get("d10_dasamsa") else 0
|
||||
score += 10 if present.get("shadbala") else 0
|
||||
score += 10 if present.get("ashtakavarga_house_scores") else 0
|
||||
score += 10 if present.get("vimshottari_current") else 0
|
||||
score += 10 if present.get("narayana_current") else 0
|
||||
score += max(
|
||||
_convergence_score(present.get("wealth_convergence")),
|
||||
_convergence_score(present.get("gains_convergence")),
|
||||
_convergence_score(present.get("career_convergence")),
|
||||
)
|
||||
if missing:
|
||||
score = min(score, 35)
|
||||
score = min(score, 100)
|
||||
if missing:
|
||||
verdict = "insufficient_evidence"
|
||||
elif score >= 80:
|
||||
verdict = "high_probability_window"
|
||||
elif score >= 60:
|
||||
verdict = "moderate_probability_window"
|
||||
elif score >= 40:
|
||||
verdict = "weak_window_needs_confirmation"
|
||||
else:
|
||||
verdict = "insufficient_evidence"
|
||||
return {
|
||||
"event_family": "finance",
|
||||
"score": score,
|
||||
"verdict": verdict,
|
||||
"primary_drivers": [
|
||||
key for key in (
|
||||
"wealth_convergence",
|
||||
"gains_convergence",
|
||||
"career_convergence",
|
||||
"vimshottari_current",
|
||||
"narayana_current",
|
||||
)
|
||||
if present.get(key)
|
||||
],
|
||||
}
|
||||
|
||||
return {
|
||||
"event_family": route,
|
||||
"score": 0,
|
||||
"verdict": "context_only",
|
||||
"primary_drivers": [],
|
||||
}
|
||||
|
||||
|
||||
def _collect_strict_evidence(route: str, result: Dict[str, Any]) -> Dict[str, Any]:
|
||||
modules = result.get("modules", {}) if isinstance(result, dict) else {}
|
||||
domain_activations = _safe_get(modules, "dasa_convergence", "domain_activations") or {}
|
||||
|
||||
if route == "relationship":
|
||||
required = [
|
||||
"varga_full.D9_Navamsa",
|
||||
"special_lagnas.Upapada_Lagna",
|
||||
"jaimini.darakaraka",
|
||||
"vivah_saham",
|
||||
"dasha.current_dasha",
|
||||
"narayana_dasha.current_dasha",
|
||||
"dasa_convergence.domain_activations.marriage_partnership",
|
||||
]
|
||||
present = {
|
||||
"d9_navamsa": _safe_get(modules, "varga_full", "D9_Navamsa"),
|
||||
"upapada_lagna": _safe_get(modules, "special_lagnas", "Upapada_Lagna"),
|
||||
"darakaraka": _safe_get(modules, "jaimini", "darakaraka"),
|
||||
"vivah_saham": _safe_get(modules, "vivah_saham"),
|
||||
"vimshottari_current": _safe_get(modules, "dasha", "current_dasha"),
|
||||
"narayana_current": _safe_get(modules, "narayana_dasha", "current_dasha"),
|
||||
"marriage_convergence": domain_activations.get("marriage_partnership"),
|
||||
}
|
||||
missing = [key for key, value in present.items() if value in (None, {}, [], "")]
|
||||
convergence = present["marriage_convergence"] or {}
|
||||
confidence_cap = "medium"
|
||||
if missing:
|
||||
confidence_cap = "low"
|
||||
elif convergence.get("convergence_level") in {"L4", "L5"}:
|
||||
confidence_cap = "medium-high"
|
||||
elif convergence.get("convergence_level") == "L3":
|
||||
confidence_cap = "medium"
|
||||
else:
|
||||
confidence_cap = "medium-low"
|
||||
event_judgement = _derive_event_judgement(route, present, missing)
|
||||
return {
|
||||
"question_type": route,
|
||||
"required_evidence": required,
|
||||
"present_evidence": present,
|
||||
"missing_evidence": missing,
|
||||
"confidence_cap": confidence_cap,
|
||||
"blocked": bool(missing),
|
||||
"event_judgement": event_judgement,
|
||||
"reason": (
|
||||
"Marriage timing requires D9 + UL + DK + dual dasha + Vivah Saham "
|
||||
"and convergence support; missing links cap confidence."
|
||||
),
|
||||
}
|
||||
|
||||
if route == "finance":
|
||||
required = [
|
||||
"varga_full.D2_Hora",
|
||||
"varga_full.D10_Dasamsa",
|
||||
"shadbala.planets",
|
||||
"ashtakavarga.house_scores",
|
||||
"dasha.current_dasha",
|
||||
"narayana_dasha.current_dasha",
|
||||
"dasa_convergence.domain_activations.wealth_family",
|
||||
]
|
||||
present = {
|
||||
"d2_hora": _safe_get(modules, "varga_full", "D2_Hora"),
|
||||
"d10_dasamsa": _safe_get(modules, "varga_full", "D10_Dasamsa"),
|
||||
"shadbala": _safe_get(modules, "shadbala", "planets"),
|
||||
"ashtakavarga_house_scores": _safe_get(modules, "ashtakavarga", "house_scores"),
|
||||
"vimshottari_current": _safe_get(modules, "dasha", "current_dasha"),
|
||||
"narayana_current": _safe_get(modules, "narayana_dasha", "current_dasha"),
|
||||
"wealth_convergence": domain_activations.get("wealth_family"),
|
||||
"gains_convergence": domain_activations.get("gains_wishes"),
|
||||
"career_convergence": domain_activations.get("career_status"),
|
||||
}
|
||||
missing = [key for key, value in present.items() if key not in {
|
||||
"gains_convergence", "career_convergence"
|
||||
} and value in (None, {}, [], "")]
|
||||
convergence_hits: List[Dict[str, Any]] = [
|
||||
item for item in [
|
||||
present["wealth_convergence"],
|
||||
present["gains_convergence"],
|
||||
present["career_convergence"],
|
||||
]
|
||||
if isinstance(item, dict) and item
|
||||
]
|
||||
confidence_cap = "medium"
|
||||
if missing:
|
||||
confidence_cap = "low"
|
||||
elif any(hit.get("convergence_level") in {"L4", "L5"} for hit in convergence_hits):
|
||||
confidence_cap = "medium-high"
|
||||
elif convergence_hits:
|
||||
confidence_cap = "medium"
|
||||
else:
|
||||
confidence_cap = "medium-low"
|
||||
event_judgement = _derive_event_judgement(route, present, missing)
|
||||
return {
|
||||
"question_type": route,
|
||||
"required_evidence": required,
|
||||
"present_evidence": present,
|
||||
"missing_evidence": missing,
|
||||
"confidence_cap": confidence_cap,
|
||||
"blocked": bool(missing),
|
||||
"event_judgement": event_judgement,
|
||||
"reason": (
|
||||
"Finance timing requires D2/D10 + strength + SAV + dual dasha "
|
||||
"plus at least one wealth-related convergence domain."
|
||||
),
|
||||
}
|
||||
|
||||
return {
|
||||
"question_type": route,
|
||||
"required_evidence": [],
|
||||
"present_evidence": {},
|
||||
"missing_evidence": [],
|
||||
"confidence_cap": "context-only",
|
||||
"blocked": False,
|
||||
"event_judgement": _derive_event_judgement(route, {}, []),
|
||||
"reason": "Route-specific strict evidence audit is currently implemented for relationship and finance timing.",
|
||||
}
|
||||
|
||||
|
||||
# ============================================================================
|
||||
# Tools
|
||||
# ============================================================================
|
||||
@@ -562,7 +785,7 @@ def strict_workflow(
|
||||
if any(k in q for k in ("career", "job", "work", "promotion", "business", "profession", "事业", "工作", "升职", "生意")):
|
||||
route = "career"
|
||||
focus_techniques = ["D10", "Dasha", "Shadbala", "Transit", "Narayana Dasha"]
|
||||
elif any(k in q for k in ("marriage", "relationship", "love", "spouse", "partner", "divorce", "婚恋", "婚姻", "感情", "配偶", "恋爱")):
|
||||
elif any(k in q for k in ("marriage", "married", "wedding", "relationship", "love", "spouse", "partner", "divorce", "婚恋", "婚姻", "感情", "配偶", "恋爱", "结婚")):
|
||||
route = "relationship"
|
||||
focus_techniques = ["D9", "UL Upapada", "Dasha", "Nakshatra", "Vivah Saham"]
|
||||
elif any(k in q for k in ("money", "wealth", "finance", "investment", "property", "income", "财务", "财富", "投资", "房产", "收入")):
|
||||
@@ -584,14 +807,17 @@ def strict_workflow(
|
||||
})
|
||||
|
||||
if isinstance(result, dict) and "error" not in result:
|
||||
strict_evidence = _collect_strict_evidence(route, result)
|
||||
result["routing"] = {
|
||||
"question_type": route,
|
||||
"focus_techniques": focus_techniques,
|
||||
"note": (
|
||||
f"Routed to '{route}' path. Focus on the listed techniques "
|
||||
f"for higher-confidence answers. Full reading included for context."
|
||||
f"for higher-confidence answers. Full reading included for context, "
|
||||
f"and strict evidence audit now reports confidence cap and missing links."
|
||||
),
|
||||
}
|
||||
result["strict_workflow"] = strict_evidence
|
||||
return result
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
# AI解盘工作流Prompt工程(AI Reading Workflow)
|
||||
|
||||
> **适用场景**:AI收到出生信息、PDF星盘或文字星盘后,如何一步步执行完整的解盘+推运分析
|
||||
> **版本**:v5.0.0 | **更新日期**:2026-04-27
|
||||
> **版本**:v5.1.0 | **更新日期**:2026-06-27
|
||||
> **来源标签**: 【工具/模板】 — 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。
|
||||
|
||||
---
|
||||
|
||||
@@ -461,6 +462,33 @@ AI不应该凭空假设一个时间,而应该通过结构化互动帮助用户
|
||||
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` 的专用裁决器。
|
||||
|
||||
---
|
||||
|
||||
## 阶段三:静态星盘分析(→ 多个参考文件)
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
# Event Judgment Examples v1.0
|
||||
|
||||
> 作用:给事件判定骨架提供最小可执行范例,避免只停留在抽象规则。
|
||||
|
||||
---
|
||||
|
||||
## 示例一:婚恋窗口判断
|
||||
|
||||
### 问题
|
||||
|
||||
`When will I get married?`
|
||||
|
||||
### Route
|
||||
|
||||
- question_domain: `relationship`
|
||||
- task_type: `prediction`
|
||||
- target_granularity: `window`
|
||||
|
||||
### Evidence Ledger(最小示例)
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"module": "relationship_timing",
|
||||
"subtechnique": "d9_ul_dk",
|
||||
"question_domain": "relationship",
|
||||
"verdict_role": "promise",
|
||||
"signal": "supportive",
|
||||
"strength": 0.82,
|
||||
"raw_values": {"d9": "present", "ul": "present", "dk": "present"},
|
||||
"engine": "native",
|
||||
"ayanamsa": "lahiri",
|
||||
"node_mode": "mean",
|
||||
"template_id": "darakaraka_ul_spouse_depth",
|
||||
"case_ref_ids": ["marriage-timing-v6"],
|
||||
"maturity": "covered",
|
||||
"notes": ""
|
||||
},
|
||||
{
|
||||
"module": "relationship_timing",
|
||||
"subtechnique": "dual_dasha",
|
||||
"question_domain": "relationship",
|
||||
"verdict_role": "activation",
|
||||
"signal": "supportive",
|
||||
"strength": 0.78,
|
||||
"raw_values": {"vimshottari": "Venus/Rahu", "narayana": "Pisces/Jupiter"},
|
||||
"engine": "native",
|
||||
"ayanamsa": "lahiri",
|
||||
"node_mode": "mean",
|
||||
"template_id": "darakaraka_ul_spouse_depth",
|
||||
"case_ref_ids": [],
|
||||
"maturity": "covered",
|
||||
"notes": ""
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### Adjudication
|
||||
|
||||
- Promise: pass
|
||||
- Activation: pass
|
||||
- Manifestation: partial
|
||||
- Timing: window only
|
||||
|
||||
### Output Contract
|
||||
|
||||
```json
|
||||
{
|
||||
"event_family": "relationship",
|
||||
"verdict": "moderate_probability_window",
|
||||
"confidence": "B",
|
||||
"conflicts": [],
|
||||
"primary_drivers": ["d9_ul_dk", "dual_dasha"],
|
||||
"missing_evidence": ["kp_7h_sub_lord"],
|
||||
"raw_evidence_refs": ["full-reading.modules.jaimini.darakaraka", "full-reading.modules.dasa_convergence"]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 示例二:财富窗口判断
|
||||
|
||||
### 问题
|
||||
|
||||
`When will my wealth grow?`
|
||||
|
||||
### Route
|
||||
|
||||
- question_domain: `wealth`
|
||||
- task_type: `prediction`
|
||||
- target_granularity: `window`
|
||||
|
||||
### 关键约束
|
||||
|
||||
- 必须 `D2 / D11`
|
||||
- 必须 `Vimshottari + Narayana`
|
||||
- 必须 `Shadbala + Ashtakavarga`
|
||||
- 若缺任一核心层,直接降为 `insufficient_evidence`
|
||||
|
||||
---
|
||||
|
||||
## 示例三:过去事件回测
|
||||
|
||||
### 问题
|
||||
|
||||
`Was my 2018 relationship event actually supported by the chart?`
|
||||
|
||||
### Route
|
||||
|
||||
- question_domain: `relationship`
|
||||
- task_type: `backtest`
|
||||
- target_granularity: `event_level verification`
|
||||
|
||||
### 输出要求
|
||||
|
||||
- 不只说“像不像”
|
||||
- 必须输出 `A / B / C / Fail`
|
||||
- 必须指出是 Promise 不足、Activation 不足,还是 Manifestation 不足
|
||||
@@ -0,0 +1,156 @@
|
||||
# Marriage Event Adjudicator v1.0
|
||||
|
||||
> 这是 `relationship` 题目域的专用裁决器。用于婚恋、婚姻、配偶、正式关系、关系转正、长期关系是否成立等问题。
|
||||
|
||||
---
|
||||
|
||||
## 1. Route Freeze
|
||||
|
||||
先冻结三件事:
|
||||
|
||||
1. **任务类型**
|
||||
- `prediction`
|
||||
- `backtest`
|
||||
- `rectification_support`
|
||||
- `multi-option adjudication`
|
||||
2. **目标粒度**
|
||||
- `trend`
|
||||
- `window`
|
||||
- `month_level`
|
||||
- `event_level verification`
|
||||
3. **关系定义**
|
||||
- `legal marriage`
|
||||
- `formal partnership`
|
||||
- `sustained relationship`
|
||||
|
||||
若关系定义不清,先说明判定对象再继续。
|
||||
|
||||
---
|
||||
|
||||
## 2. Mandatory Layers
|
||||
|
||||
婚恋题目至少必须展开:
|
||||
|
||||
- `D1`: 7H / 7L / Venus / Jupiter / Mars / Moon / DK
|
||||
- `D9`: Lagna / 7H / 7L / Venus-Jupiter / DK
|
||||
- `UL`
|
||||
- `Vimshottari + Narayana`
|
||||
- `Transit / Double Transit`
|
||||
- `Vivah Saham`
|
||||
- `Functional Benefic/Malefic`
|
||||
|
||||
若用户要求高严谨,还应尽量加:
|
||||
|
||||
- `KP 7H sub-lord`
|
||||
- `Chara Dasha`
|
||||
- `Argala on 7H / 7L / UL`
|
||||
|
||||
---
|
||||
|
||||
## 3. Evidence Ledger Roles
|
||||
|
||||
把婚恋证据按 4 种角色分类:
|
||||
|
||||
1. `promise`
|
||||
- 7H / 7L / DK / UL / D9 是否支持婚恋承诺
|
||||
2. `activation`
|
||||
- Dasha / Transit / Double Transit / KP / Saham 是否激活
|
||||
3. `manifestation`
|
||||
- 这些激活是否足以落到现实关系成立,而不是只表现为暧昧、吸引、情绪事件
|
||||
4. `timing`
|
||||
- 若上三层成立,再给窗口或月份级判断
|
||||
|
||||
---
|
||||
|
||||
## 4. Marriage Adjudication Order
|
||||
|
||||
### 4.1 Promise
|
||||
|
||||
先问:
|
||||
|
||||
- 本命是否有婚恋承载力?
|
||||
- D1 的 7H / 7L / Venus / Jupiter / DK 是否形成基本 promise?
|
||||
- D9 是否支持,还是明显削弱?
|
||||
- UL 是否支持“正式关系/婚姻质量”?
|
||||
|
||||
若 promise 本身薄弱,不得直接因为某段 Dasha 激活就断定“必然结婚”。
|
||||
|
||||
### 4.2 Activation
|
||||
|
||||
必须检查:
|
||||
|
||||
- `Vimshottari` 是否激活 7H / 7L / Venus / Jupiter / DK / UL
|
||||
- `Narayana` 是否同向
|
||||
- `Transit / Double Transit` 是否对 7H / 7L / DK / UL 有作用
|
||||
- `Vivah Saham` 是否支持
|
||||
|
||||
若 `Vimshottari` 与 `Narayana` 明显相反,标记 `mixed` 或 `blocked`。
|
||||
|
||||
### 4.3 Manifestation
|
||||
|
||||
这一层专门防止“有窗口但没落地”。
|
||||
|
||||
要区分:
|
||||
|
||||
- `romantic activation`
|
||||
- `relationship formation`
|
||||
- `legal marriage`
|
||||
- `public formalization`
|
||||
|
||||
尤其对名人、公职人物、长期恋爱者,要警惕“关系已成立,但婚礼日期只是社会安排”。
|
||||
|
||||
### 4.4 Timing
|
||||
|
||||
只有在 Promise + Activation + Manifestation 都通过后,才给:
|
||||
|
||||
- 趋势级
|
||||
- 窗口级
|
||||
- 月份级
|
||||
- 事件验证级
|
||||
|
||||
若只能做到窗口级,必须明说不能上升到“具体婚礼日”。
|
||||
|
||||
---
|
||||
|
||||
## 5. Template Hooks
|
||||
|
||||
优先调用并引用:
|
||||
|
||||
- `darakaraka_ul_spouse_depth`
|
||||
- `strict-workflow-router.md` 的 `relationship-timing-strict`
|
||||
- `marriage-timing-validation-methodology.md`
|
||||
|
||||
若调用不到,必须在 Audit Table 里标注其对置信度的削弱。
|
||||
|
||||
---
|
||||
|
||||
## 6. Output Contract
|
||||
|
||||
婚恋输出最少要有:
|
||||
|
||||
1. `relationship verdict`
|
||||
2. `confidence`
|
||||
3. `main conflicts`
|
||||
4. `Technique Audit Table`
|
||||
5. `raw evidence`
|
||||
|
||||
示例 verdict:
|
||||
|
||||
- `high_probability_window`
|
||||
- `moderate_probability_window`
|
||||
- `weak_window_needs_confirmation`
|
||||
- `insufficient_evidence`
|
||||
- `blocked`
|
||||
|
||||
---
|
||||
|
||||
## 7. Must-Not-Overclaim
|
||||
|
||||
以下情况必须降级或阻断:
|
||||
|
||||
- 只看 `Vimshottari` 没看 `Narayana`
|
||||
- 只看 `DK` 没看 `UL/D9`
|
||||
- 只看 `Double Transit` 就断婚期
|
||||
- 只看单一文章规则
|
||||
- 未说明 birth time precision
|
||||
- 未说明 `Ayanamsa / Node mode`
|
||||
@@ -0,0 +1,153 @@
|
||||
# Event Judgment Skeleton v1.0
|
||||
|
||||
> 用途:把分散在 `full-reading`、`dasha`、`jaimini`、`varga`、`kp`、`shadbala`、`ashtakavarga`、`references/verified-patterns-*` 中的证据,收束成统一的事件裁决链。
|
||||
> 适用:marriage / career / wealth / health / generic event verification
|
||||
|
||||
---
|
||||
|
||||
## 1. Route
|
||||
|
||||
不要只按触发词路由。每次先识别三件事:
|
||||
|
||||
1. **问题域**
|
||||
- `relationship`
|
||||
- `career`
|
||||
- `wealth`
|
||||
- `health`
|
||||
- `generic_event`
|
||||
2. **任务类型**
|
||||
- `prediction`
|
||||
- `backtest`
|
||||
- `rectification_support`
|
||||
- `multi-option adjudication`
|
||||
3. **目标粒度**
|
||||
- `trend`
|
||||
- `window`
|
||||
- `month_level`
|
||||
- `event_level verification`
|
||||
|
||||
若这三件事没有先冻结,不得继续下判。
|
||||
|
||||
---
|
||||
|
||||
## 2. Evidence Ledger
|
||||
|
||||
每个模块必须变成结构化证据块,而不是散乱叙述。
|
||||
|
||||
```json
|
||||
{
|
||||
"module": "marriage_timing",
|
||||
"subtechnique": "double_transit",
|
||||
"question_domain": "relationship",
|
||||
"verdict_role": "activation",
|
||||
"signal": "supportive|mixed|contradictory|blocked",
|
||||
"strength": 0.0,
|
||||
"raw_values": {},
|
||||
"engine": "native|pyjhora|vedastro|jyotishganit",
|
||||
"ayanamsa": "lahiri",
|
||||
"node_mode": "mean|true",
|
||||
"template_id": "darakaraka_ul_spouse_depth",
|
||||
"case_ref_ids": [],
|
||||
"maturity": "complete|covered|partial",
|
||||
"notes": ""
|
||||
}
|
||||
```
|
||||
|
||||
最少要求:
|
||||
|
||||
- `module`
|
||||
- `subtechnique`
|
||||
- `verdict_role`
|
||||
- `signal`
|
||||
- `strength`
|
||||
- `raw_values`
|
||||
- `engine`
|
||||
- `ayanamsa`
|
||||
- `node_mode`
|
||||
- `maturity`
|
||||
|
||||
---
|
||||
|
||||
## 3. Adjudication
|
||||
|
||||
所有事件判断必须按以下顺序:
|
||||
|
||||
1. **Promise**
|
||||
- 本命是否有该主题的承载力?
|
||||
- 禁止直接从 Dasha/Transit 跳到“会发生”
|
||||
2. **Activation**
|
||||
- Dasha / Transit / Annual / Jaimini / KP 是否激活?
|
||||
3. **Manifestation**
|
||||
- 是否足以落到现实事件,而不是只形成心理主题、机会接触或背景躁动?
|
||||
4. **Timing**
|
||||
- 若 Promise + Activation + Manifestation 都成立,才进入 timing 窗口判定
|
||||
|
||||
### 矛盾优先级
|
||||
|
||||
若不同证据块冲突,按以下顺序裁决:
|
||||
|
||||
1. `verified pattern / benchmark`
|
||||
2. `cross-system convergence`
|
||||
3. `classical rule with prerequisites satisfied`
|
||||
4. `single module output`
|
||||
|
||||
若冲突无法裁决,必须输出 `blocked`。
|
||||
|
||||
---
|
||||
|
||||
## 4. Confidence Mapping
|
||||
|
||||
置信度不得只按“有几个名人案例”判断,至少同时考虑以下 6 维:
|
||||
|
||||
1. `benchmark/case support`
|
||||
2. `technique maturity`
|
||||
3. `cross-system convergence`
|
||||
4. `birth time precision`
|
||||
5. `oracle closure status`
|
||||
6. `contradiction severity`
|
||||
|
||||
建议映射:
|
||||
|
||||
- `A`:多案例 / benchmark 强支撑 + complete/covered + 多系统同向 + 参数清晰
|
||||
- `B`:部分案例支撑 + 多模块同向 + 仍有轻微边界
|
||||
- `C`:经典规则存在,但统计、闭环或关键层不足
|
||||
- `D`:仅单一模块、关键层缺失或矛盾明显
|
||||
|
||||
---
|
||||
|
||||
## 5. Output Contract
|
||||
|
||||
最终输出必须包含:
|
||||
|
||||
1. `verdict`
|
||||
2. `confidence`
|
||||
3. `conflicts`
|
||||
4. `Technique Audit Table`
|
||||
5. `raw evidence`
|
||||
|
||||
最小 JSON 形态:
|
||||
|
||||
```json
|
||||
{
|
||||
"event_family": "relationship",
|
||||
"verdict": "high_probability_window|moderate_probability_window|weak_window_needs_confirmation|insufficient_evidence|blocked",
|
||||
"confidence": "A|B|C|D",
|
||||
"conflicts": [],
|
||||
"primary_drivers": [],
|
||||
"missing_evidence": [],
|
||||
"raw_evidence_refs": []
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Hard Stops
|
||||
|
||||
以下任一项未满足时,不得包装成高严谨结论:
|
||||
|
||||
- 未显式声明 `Ayanamsa / Node mode`
|
||||
- 未显式声明 `Functional Benefic/Malefic`
|
||||
- timing 问题未完成 `Vimshottari + Narayana`
|
||||
- 题目域分盘未展开(relationship -> D9/UL;career -> D10/A10;wealth -> D2/D11)
|
||||
- 外部 oracle 未闭环却假装全局封顶
|
||||
- 缺少 `Technique Audit Table`
|
||||
@@ -0,0 +1,199 @@
|
||||
# Wealth Event Adjudicator v1.0
|
||||
|
||||
> 这是 `wealth` 题目域的专用裁决器。用于收入、财富积累、到账、套现、资产扩张、估值跃升、公众财富地位等问题。
|
||||
|
||||
---
|
||||
|
||||
## 1. Route Freeze
|
||||
|
||||
先冻结三件事:
|
||||
|
||||
1. **任务类型**
|
||||
- `prediction`
|
||||
- `backtest`
|
||||
- `rectification_support`
|
||||
- `multi-option adjudication`
|
||||
2. **目标粒度**
|
||||
- `trend`
|
||||
- `window`
|
||||
- `month_level`
|
||||
- `event_level verification`
|
||||
3. **财富事件标签**
|
||||
- `income_growth`
|
||||
- `asset_accumulation`
|
||||
- `liquidity_cashout`
|
||||
- `public_wealth_status`
|
||||
|
||||
若财富事件标签不清,先说明判定对象再继续。
|
||||
|
||||
---
|
||||
|
||||
## 2. Four Wealth Layers
|
||||
|
||||
财富题目固定拆成四层:
|
||||
|
||||
1. `wealth promise`
|
||||
2. `wealth activation`
|
||||
3. `wealth manifestation`
|
||||
4. `payout label`
|
||||
|
||||
### payout label 子类
|
||||
|
||||
- `income_growth`:收入增长、薪资提升、持续现金流增强
|
||||
- `asset_accumulation`:资产沉淀、持仓扩大、房产/股权/长期财富积累
|
||||
- `liquidity_cashout`:到账、套现、融资落袋、出售变现
|
||||
- `public_wealth_status`:IPO、估值跃升、财富排行榜、公众财富可见度
|
||||
|
||||
---
|
||||
|
||||
## 3. Mandatory Layers
|
||||
|
||||
财富题目至少必须展开:
|
||||
|
||||
- `D1`: 2H / 11H / 5H / 9H / 10H / Jupiter / Venus / Mercury
|
||||
- `D2`
|
||||
- `D11`
|
||||
- `D10`(若财富来自职业兑现)
|
||||
- `Vimshottari + Narayana`
|
||||
- `Shadbala`
|
||||
- `Ashtakavarga`
|
||||
- `Functional Benefic/Malefic`
|
||||
|
||||
高严谨时尽量补:
|
||||
|
||||
- `Argala on 2H / 11H`
|
||||
- `A2 / A11 / A10`
|
||||
- `KP`
|
||||
- `Yogi / Dhana / Lakshmi template hooks`
|
||||
|
||||
---
|
||||
|
||||
## 4. Evidence Ledger Roles
|
||||
|
||||
把财富证据按 4 种角色分类:
|
||||
|
||||
1. `promise`
|
||||
- 本命是否具备财富承载力或财富兑现潜力?
|
||||
2. `activation`
|
||||
- Dasha / Transit / Annual / KP / Jaimini 是否点燃财富主题?
|
||||
3. `manifestation`
|
||||
- 这些激活是否足以落到现实收益/资产/现金流,而不只是机会、焦虑或纸面波动?
|
||||
4. `payout_label`
|
||||
- 最终更像哪一类财富事件:收入增长、资产积累、套现到账、公众财富地位?
|
||||
|
||||
---
|
||||
|
||||
## 5. Wealth Adjudication Order
|
||||
|
||||
### 5.1 Promise
|
||||
|
||||
先问:
|
||||
|
||||
- 2H / 11H / 5H / 9H / 10H 是否给出财富承诺?
|
||||
- D1 的财富 promise 是否得到 `D2 / D11 / D10` 支持?
|
||||
- Jupiter / Venus / Mercury 在题目域里是增强器、兑现器还是干扰器?
|
||||
- 是否存在强财富模板钩子:
|
||||
- `lakshmi_dhana_activation_chain`
|
||||
- `yogi_asc_tight_orb_wealth`
|
||||
|
||||
若本命 promise 薄弱,不得因为单次 transit 或单个 Dasha 就断定“发财”。
|
||||
|
||||
### 5.2 Activation
|
||||
|
||||
必须检查:
|
||||
|
||||
- `Vimshottari` 是否激活 2L / 11L / 5L / 9L / 10L / Jupiter / Venus / Mercury
|
||||
- `Narayana` 是否同向
|
||||
- `Transit Jupiter / Saturn / nodes` 是否对 2H / 11H / 10H 有实质推动
|
||||
- `Shadbala / Ashtakavarga` 是否支持“强而可兑现”的状态
|
||||
|
||||
若 `Vimshottari` 与 `Narayana` 明显冲突,标记 `mixed` 或 `blocked`。
|
||||
|
||||
### 5.3 Manifestation
|
||||
|
||||
这一层专门防止“有财运感,但没落到现实收益”。
|
||||
|
||||
要区分:
|
||||
|
||||
- `opportunity to earn`
|
||||
- `actual income growth`
|
||||
- `asset build-up`
|
||||
- `cash-out / liquidity event`
|
||||
- `public wealth visibility`
|
||||
|
||||
### 5.4 Payout Label
|
||||
|
||||
只有前三层通过后,才给最终财富事件标签。
|
||||
|
||||
禁止把所有财富事件都压成一个粗糙的“发财”。
|
||||
|
||||
---
|
||||
|
||||
## 6. Defect Typology
|
||||
|
||||
财富线沿用婚恋线的缺陷类型思路:
|
||||
|
||||
1. `promise weak`
|
||||
2. `activation/convergence weak`
|
||||
3. `manifestation split`
|
||||
4. `payout-label failure`
|
||||
|
||||
### payout-label failure
|
||||
|
||||
定义:
|
||||
|
||||
- 旧体系高分
|
||||
- 现实财富事件明确成立
|
||||
- 新聚合器没有把它抬成正确的财富标签
|
||||
|
||||
这是财富线最重要的回归靶子之一。
|
||||
|
||||
---
|
||||
|
||||
## 7. Template Hooks
|
||||
|
||||
优先调用并引用:
|
||||
|
||||
- `lakshmi_dhana_activation_chain`
|
||||
- `yogi_asc_tight_orb_wealth`
|
||||
- `strict-workflow-router.md` 的 `wealth-timing-strict`
|
||||
- `divisional-chart-deep-reading.md` 中的财富链 `D2 -> D4 -> D10 -> D11`
|
||||
|
||||
若调用不到,必须在 Audit Table 里标注其对置信度的削弱。
|
||||
|
||||
---
|
||||
|
||||
## 8. Output Contract
|
||||
|
||||
财富输出最少要有:
|
||||
|
||||
1. `wealth verdict`
|
||||
2. `confidence`
|
||||
3. `main conflicts`
|
||||
4. `Technique Audit Table`
|
||||
5. `raw evidence`
|
||||
|
||||
示例 verdict:
|
||||
|
||||
- `high_probability_window`
|
||||
- `moderate_probability_window`
|
||||
- `weak_window_needs_confirmation`
|
||||
- `insufficient_evidence`
|
||||
- `blocked`
|
||||
|
||||
最终还要给出:
|
||||
|
||||
- `payout_label`
|
||||
|
||||
---
|
||||
|
||||
## 9. Must-Not-Overclaim
|
||||
|
||||
以下情况必须降级或阻断:
|
||||
|
||||
- 只看 `Vimshottari` 没看 `Narayana`
|
||||
- 只看 `D1` 没展开 `D2 / D11`
|
||||
- 把事业曝光误当成财富兑现
|
||||
- 把纸面估值误当成流动性到账
|
||||
- 未说明 birth time precision
|
||||
- 未说明 `Ayanamsa / Node mode`
|
||||
@@ -409,6 +409,9 @@ SCRIPT=~/.workbuddy/skills/jyotish-vedic-astrology/scripts/jyotish_engine.py
|
||||
### AI解盘工作流(2个)
|
||||
0. **ai-reading-workflow-prompt.md**:AI解盘工作流Prompt工程(7阶段完整执行引擎)
|
||||
0b. **quick-reference-guide.md**:⭐执行总控指南(本文件)
|
||||
0c. **event_judgment_skeleton.md**:事件裁决总骨架(Route -> Evidence Ledger -> Adjudication -> Output Contract)
|
||||
0d. **event_judgment_marriage.md**:婚恋事件专用裁决器(Promise -> Activation -> Manifestation -> Timing)
|
||||
0e. **event_judgment_wealth.md**:财富事件专用裁决器(wealth promise -> activation -> manifestation -> payout label)
|
||||
|
||||
### 核心方法论(9个)
|
||||
1. **common-misconceptions.md**:印度占星常见误判与冲突问题集(错题本)⭐⭐⭐⭐⭐
|
||||
|
||||
@@ -15,5 +15,6 @@ cp "$ROOT/references/quick-reference-guide.md" "$WB/references/quick-reference-g
|
||||
cp "$ROOT/references/strict-workflow-router.md" "$WB/references/strict-workflow-router.md"
|
||||
cp "$ROOT/skills/jyotish-engine-modules/SKILL.md" "$WB/skills/jyotish-engine-modules/SKILL.md"
|
||||
cp "$ROOT/skills/jyotish-full-reading-integration/SKILL.md" "$WB/skills/jyotish-full-reading-integration/SKILL.md"
|
||||
cp "$ROOT/mcp_server.py" "$WB/mcp_server.py"
|
||||
|
||||
echo "synced skill truth files to workbuddy"
|
||||
|
||||
Reference in New Issue
Block a user