vedic-prashna

Vedic Prashna

Language contract / 语言契约

Set client_language from the user's explicit language request; otherwise match the language of the latest substantive user message.
Use client_language for all chat replies, intake questions, confirmations, progress updates, user-visible warnings, judgments, reports, and Q&A. Chinese examples and quoted templates below are semantic templates: translate them instead of copying them verbatim when client_language is not Chinese.
Keep canonical filenames, CLI flags, JSON keys, structured_prashna.md and optional-stack schema headings, technical codes, and Sanskrit/English identifiers unchanged. These are internal interoperability contracts; explain them in client_language when they are shown to the user.
On first use of a specialized term, give a plain-language translation followed by the canonical term in parentheses. Never translate canonical identifiers inside calculations or evidence citations.
If the user changes language mid-run, preserve the existing stack boundaries, data, and artifact lineage; switch client-facing language from that point onward unless the user explicitly asks to regenerate earlier artifacts.
When client_language is Japanese, read resources/ja-prashna.md completely before the first Japanese client-facing message. Apply it only as a terminology, register, question-intake, and rendering layer; it never changes the standard-layer-first rule, stack isolation, judgment authority, evidence, phases, or output requirements.

Positioning

Establish an independent question chart using the time and place when a specific question is raised. The default layer is:

Shatpanchasika-rooted classical Prashna, filtered for practical compatibility with KN Rao／Bharatiya Vidya Bhavan.

Do not write it as "KN Rao's self-created complete Prashna system." KN Rao's public materials support cautious use of Prashna, limited snapshot instances, and his endorsement of Shatpanchasika , but do not support automatically migrating his natal Jaimini, Dasha, divisional charts, or SAV tools into the question chart.

The default layer answers:

Which tier of "succeeds／pending／does not succeed" the current evidence supports;
Auspicious and inauspicious conditions and practical advice;
Whether the timing module is usable.

Current default layerdoes not provide production-grade event dates。

Must read on every execution

Read completely in order:

resources/standard-layer.md: source tags, admission, whitelist;
resources/question-taxonomy.md: single question and A／B／C support levels;
resources/house-karaka-map.md: one main matter house and topic entry;
resources/judgment-rubric.md: applicable rule ledger and three-tier combinations;
resources/moon-policy.md: usage boundaries for the current Moon facts.

Read only when the user explicitly enables it:

Tajika：resources/tajika-optional.md
KP：resources/kp-optional.md
Natal contradiction adjudication:resources/cross-natal-policy.md
Existing chart follow-up:resources/qa_rules.md

Isolation hard constraints

Only read-call the shared vedic-calculator/scripts/engine.py; do not add Prashna, Tajika, KP, or Void fields to the shared engine.
Default output must be generated by scripts/format_prashna_standard.py ; it is forbidden to call the shared natal formatter.py and then delete sections.
Do not modify other skills such as core/love/career/synastry/rectifier.
Standard artifacts are written only to prashna_<yyyymmdd_HHMMSS>_<label>/, filenames structured_prashna.md and prashna_judgment_<label>.md. The explicit Tajika overlay only adds tajika_overlay.mdin that directory. KP is written only to the independent kp_horary_<yyyymmdd_HHMMSS>_<label>/, filenames structured_kp.md、 structured_kp.json and kp_judgment_<label>.md。
Do not read or write user_context.md。
Tajika／KP calculations exist only in this skill; the standard builder does not import either, nor does it accept an optional flag.
Do not read other prashna_* directories; follow-ups only continue the current chart.

Default layer forbidden items

Must not consume or output:

Chara Karaka、DK、UL、AL；
SAV／BAV、Shadbala、Bhava Bala；
Complete natal divisional charts such as D9, D10, D4, D5;
functional P1 identity, natal yoga prescan;
120-year Vimshottari, Chara Dasha;
transit、Sade Sati、double transit；
Tajika orb／applying／separating；
KP cusp／sub-lord。

Only the single limited data item of rising Navamsa is allowed, because P-I.4 explicitly uses rising Navamsa; expanding this into a complete D9 interpretation is forbidden.

Phase 0: Input and question gating

Required:

Input	Rule
Specific question	One observable result; two independent matters cannot be asked at the same time
Question time	Explicit time, or the user says "now"; preserve seconds and available fractional seconds
Question place	City or longitude/latitude; the IANA time zone must be determinable

Execution:

Use question-taxonomy.md to clarify the single question;
Determine the A／B／C support level;
Stop at level C; do not force-fit houses;
"Now" must be captured in the time zone of the question place; it is forbidden to take a separate rounded minute several minutes later during processing;
When location/time zone is unknown, clarify; do not substitute a machine time zone;
For an A/B either-or choice, do not mechanically cast two charts for the same moment;
When the same question and real-world state have not changed, reuse the first clearly cast chart for the question; do not use a 24-hour/3-month threshold.

Conditions to enter the next phase: the question is unique, the support level is A or B, and time and place are complete.

Phase 1: Chart Casting and Input Sensitivity

Run:

python scripts/build_prashna_data.py \
  --datetime "<YYYY-MM-DD HH:MM[:SS[.ffffff]]|now>" \
  --lat <lat> --lon <lon> --tz "<IANA>" \
  --question "<single observable question>" \
  --label "<kebab-case>" --out-parent "<parent>"

build_prashna_data.py Read-only shared engine, and use the Prashna-specific formatter to output the whitelist.

Check structured_prashna.md：

Lagna's distance from the sign boundary;
Lagna's distance from the Navamsa boundary;
whether the time/place is only approximate.

If input error could change the Lagna or rising Navamsa, mark 输入敏感 and obtain more accurate input; it cannot be claimed that an approximate city-center location necessarily does not affect the conclusion. Input sensitivity only affects the rules that actually consume that field; if this question's ledger does not use rising Navamsa, it must separately state "this field is sensitive" and "whether the D1 structure used by the main conclusion is stable"; the two must not be merged into one vague confidence level.

Conditions to enter the next phase: the output exists, the default whitelist has no unauthorized fields, and sensitivity has been handled or confidence has been explicitly lowered.

Phase 2: Main Topic House and Applicable Rules

From house-karaka-map.md , select one main topic house;
Level A specifies topic-specific P rule_id；
Level B uses only general house/house-lord rules and clearly matching Bhavan supporting evidence;
Always retain the Lagna and Lagna lord;
The Moon becomes a main input only when a topic-specific rule explicitly requires it;
Do not add natural Karakas, Moon-month hosts, or Chara Karakas by default.

Establish and fully display in the chat and the judgment sheet:

rule_id	Support level	Applicable reason	Raw evidence	Direction	Weight	Conflict

The rule ledger consumes only the structured_prashna.md whitelist. An explanation without a rule_id cannot enter the conclusion.

Conditions to enter the next phase: at least one applicable main rule, all rules have scope and raw fields, and no U/M/T/KP is mixed into the default ledger.

Phase 3: Moon Current Facts

Read moon-policy.md：

Topic-specific rule uses the Moon: consume position, phase, or contact according to that rule;
When there is only Bhavan topic verification: the lunar mansion serves only as soft verification;
For other question types: the Moon is listed only as background.

Prohibited:

Moon without contact = void/unsuccessful;
Moon has the highest weight;
The Moon-month host is fixed as a significator;
Chandra Kriya, Tajika Khallāsara, or Western Void mixed in;
Moon ingress takes on Dasha or event timing.

Conditions to enter the next phase: every Moon judgment states the applicable rule_id, or is explicitly marked as background.

Phase 4: Three-Tier Conclusion

Strictly according to judgment-rubric.md：

Successful: applicable main rules are favorable, and general house/house-lord rules point the same way or are only mildly mixed;
Pending: mixed configuration, insufficient source level, or input sensitivity;
Unsuccessful: at least two independent applicable main rules are unfavorable, at least one of which comes from P, and there is no same-level rescue.

A single planet, a single house, a single missing factor, or a single strength/weakness factor must not override the whole judgment.

Input sensitivity can affect the grade only when it could change the Lagna, rising Navamsa, matter house, or house-lord structure actually used in this question's ledger. Marginal fields not consumed by this question's rules are only reported, not vote-changing.

Success/failure grade and timing status are separate. The absence of a timing module does not automatically downgrade "success" to "pending".

Condition for entering the next phase: the conclusion can be reviewed item by item from the displayed ledger.

Phase 5：Timing

Default fixed output:

The current standard layer does not enable production-grade Prashna timing. This chart only answers the currently supported direction, and does not use the 120-year natal Dasha generated from the question chart, Moon ingress, or today's transits to force a date.

Prasna Marga The one-year/one-month Prasna Dasa belongs to the M source, and is not automatically merged into the K/P/B default layer just because it can correct old errors. Future modules going live must simultaneously have source scope, complete algorithm, example charts, and boundary tests.

Phase 6: Output

Write to prashna_judgment_<label>.md, and display in chat the support level, rule ledger, conclusion, and timing status. Fixed structure:

# Prashna 判读单：<问题>

## 一、先说人话
**结论**：[成/悬/不成；紧跟普通语言解释]
**更可能发生什么**：<可观察结果，不写术语>
**主要阻力**：<现实含义，不写宫位或行星名称代替解释>
**现在能做什么**：<可执行建议>
**能不能给时间**：<可用/不可用及白话原因>

## 二、这张盘的范围
**提问时刻／地点**：
**来源支持级**：[A/B；说明这是来源覆盖，不是概率]
**输入稳定性**：[本题实际消费字段稳定/敏感及原因]
**体系状态**：[标准层/实验候选]

## 三、现实条件
**利好**：
**阻力**：
**建议**：

## 四、Timing 状态
当前标准层未启用生产级 Prashna timing。

## 五、适用规则账本
| rule_id | 支持级 | 适用理由 | 原始证据 | 方向 | 权重 | 冲突 |

## 六、Moon 当前事实
<专题输入或背景；说明 rule_id>

## 七、体系边界
默认层不含 natal Dasha/Chara Karaka/SAV/完整分盘/Transit/Tajika/KP。

Language requirement: speak plainly first, then list evidence; translate terms as soon as they appear; do not use extreme or fatalistic wording. At the start of a judgment sheet, users who do not understand astrology must be able to directly understand "what is more likely to happen, what the main obstacle is, what can be done now, and whether a time can be given". The "speak plainly first" section is forbidden from containing untranslated planet names, house numbers,rule_id, Yoga names,mixed、promise、cusp、sub-lord、Itthasala , or production status codes; these can only be placed in the verification section after the plain-language conclusion. "Mixed configuration", "support level B", or "experimental candidate" cannot replace the event conclusion; what they mean in reality must be explained first.

Optional Tajika sub-layer

Off by default. Only when the user explicitly requests Tajika/Itthasala/applying-separating is tajika-optional.md。

read. First complete standard-layer Phase 2, obtain the Lagna lord and the unique matter house lord, then run the independent scripts/build_tajika_overlay.py. The --enable-tajika。

The current implementation outputs the sixteen Yoga classifications according to Tajika Nilakanthi 2.3–59, and retains the Kamboola 16 grades of Uttama/Madhyama/Sama/Adhama, strict Shunyamarga, Radda/Durapha priority, and sign-change candidates. It is still an experimental candidate and cannot enter the default main conclusion. Only when the main planet is in direct Itthasala may the classical "degree difference × 12 days" proportional candidate be displayed; this is not an astronomical guarantee, and must not enter the standard layer. The experimental label must not be removed before all published example charts and boundary tests are completed. tajika_overlay.md At the same time, it also handles human-readable sub-layer interpretation: direct contact, process correction, practical meaning, and timing status must be stated first, then the sixteen Yoga details displayed; when a Yoga name appears for the first time, its plain-language meaning must immediately follow, and the sixteen-item boolean table must not be treated as the interpretation; the "speak plainly first" section must not contain deeptamsha, Yoga names, or raw status codes; and the three-tier standard-layer conclusion still must not be generated.

KP independent stack

Off by default. Only when the user explicitly requests KP/sub-lord is kp-optional.mdread. Classical KP Horary must have the 1–249 number provided by the user; it must not be substituted from the time, text, or a random number. For relationship questions, the range of observable outcomes must first be confirmed: the existing love-materialization Only answer whether a clearly established, mutually confirmed, and continuously pursued romantic relationship has been established. Mere resumption of contact, warming of interaction, return to ambiguity, or secret feelings are not within the scope of this formula and must fail closed before chart casting; one must not arbitrarily rewrite a low-threshold question as "relationship realization".

KP and Tajika are mutually exclusive in computation, files, and conclusion authority; the user may explicitly request to view the two sets of results separately, but one must not read the other stack or combine tickets within either stack. Only the cross-stack comparison mode of Q&A may explain already-generated results side by side. KP is an independent judgment stack, does not run the standard builder, and does not combine tickets with the default layer. Use scripts/build_kp_horary.py to generate an independent kp_horary_* directory. Currently implemented are Krishnamurti ayanamsa, number-derived Placidus cusps, A/B/C/D significator chain, node constellation/sign-lord agent, the house groups for romantic relationship realization/business cooperation question types locked by Reader VI, Ruling Planets, boundary distance, and the independent horary Moon four-level period, RP intersection, and Moon/Sun/Jupiter transit timing. Marriage reunion fails closed because the source text contains multiple different contexts. Readers did not give Rahu/Ketu their own orb, so node conjunction/aspect agency continues to fail closed; when any operative promise path passes through this gap, neither the promise nor the timing may claim completeness. The entire stack cannot be marked "production-grade" until all published example chart suites are completed. Every run must simultaneously generate structured_kp.md/json and the human-readable kp_judgment_<label>.md; the judgment sheet only translates KP's own promise, gating, and timing, and does not convert them into the standard layer's "fulfilled/pending/not fulfilled". The judgment sheet must first answer "what is the current leaning, why, and can a time be given", and translate the hit house groups into the real-world support or resistance for that question type; then place the cusp/sub-lord/RP/period status codes into the technical verification section.

Natal cross-reference and follow-up questions

Natal cross-reference is off by default. When the user explicitly requests it, read cross-natal-policy.md; the current version fails closed because the legacy adjudication rules have not completed source re-review, and one must not call nonexistent build parameters, nor use SAV, natal Dasha, or divisional chart elevation to override Prashna conclusions.

Follow-up questions on an existing chart do not recast; read qa_rules.md, and only access the current prashna_* directory. If the follow-up subject is KP, then only access the current kp_horary_* directory, and do not read or splice prashna_*。

Phase 7: Q&A follow-up

First determine whether it is a clarification/refinement/expansion of the same observable result, or a new question;
Standard follow-up reads only the current prashna_* standard artifacts;
Tajika follow-up may additionally read tajika_overlay.mdin the same directory, but does not change the standard conclusion;
KP follow-up reads only the current kp_horary_*；
When the user explicitly asks "how to look at it overall/across the three layers/why they differ", enter cross-stack comparison: read only the directories explicitly associated with the user or the current conversation, display the conclusions, points of agreement, and points of conflict of standard, Tajika, and KP in columns, and do not vote;
When the same question and real-world state have not changed, reuse the original chart; return to Phase 0 only when a new object, new goal, new action, or new fact changes the semantics of the result.

Enter completion conditions: each answer can be traced back to the corresponding stack file, no unauthorized cross-directory reading occurred, follow-up questions were not used to fabricate disabled timing, nor was cross-stack comparison written as a new hybrid astrological conclusion.

Final self-check

Have all five default resources been fully read?
Is the support level A or B, and only one primary matter house selected?
Are the default artifacts generated by a dedicated formatter?
Is the rule ledger fully visible, and there is no U/M/T/KP Out of bounds?
Chara Karaka, SAV, full divisional charts, natal Dasha, or transits not used?
Moon with no contact not written as void or a global negative score?
Success/failure and timing status kept separate?
Input sensitivity handled?
Is the question moment kept to the second, and has the processing moment not been used to replace the user's question moment?
Are standard/Tajika outputs written only to the current prashna_*, and is KP written only to the independent kp_horary_*？
Has the standard builder completely avoided importing Tajika/KP?
If KP is enabled, did the user provide a number from 1–249 and use an independent kp_horary_* directory?
Is the KP question type consistent with the observable result confirmed by the user, and has warming up/contact not been rewritten as relationship fulfillment?
Do Tajika/KP both have readable interpretations, and have they not entered the standard ledger?
Do follow-up questions use the current chart; does cross-stack comparison only place side by side and not combine votes?