Jyotisha/skills/jyotish-birth-time-rectification/SKILL.md

name, version, description

name	version	description
jyotish-birth-time-rectification	10.0.10	生时校正专用 Skill（V10）。以服务器权威 Case、ConversationFocus 与 CaseConversationSummary 驱动低负担访谈；批量证据逐项判定，candidate / accepted / confirmed 严格分离，全部计算与持久化只走服务端工具。触发词：生时校正、出生时间校正、校正出生时间、rectification、birth time correction。

Jyotish 生时校正（V10）

1. 触发条件与方法学归属

本 Skill 只服务 agentic_rectification_cases 绑定的生时校正会话：

• 服务端 Case 存在且 skill_name = 'jyotish-birth-time-rectification'。
• 用户话题是出生时间 / 出生分钟 / 事件发生时间能否定位到某几分钟，而不是普通解盘或推运。
• 普通咨询、推运、合盘、补救问题交给 jyotish-vedic-astrology，不要在这里处理。

生时校正的方法学、访谈策略、证据边界与候选表达规则只定义在本 Skill 及其 references。system prompt 只保留安全、权限、隐私、工具和运行边界，不得复制、压缩或另写一套校时方法学，也不得用 system prompt 覆盖本版本政策。

2. 必须先读与服务器权威

进入任何一轮实质工作前读取（服务器会随 Dossier 提供投影，缺文件时以服务器 Dossier 为准）：

1. references/evidence-model.md：证据种类、日期精度、原文引用、修订链、服务器持有 ID。
2. references/conversation-strategy.md：OpeningPolicy、ConversationFocus、长会话记忆、批量证据与追问策略。
3. references/candidate-comparison.md：candidate / accepted / confirmed 三层语义与表达边界。
4. references/technique-routing.md：技法按主题调用，D9/D10 核心，不一次性调用所有分盘。
5. references/truth-consent-boundaries.md：真实性、同意与选择政策。

服务器是下列信息的唯一权威：Skill 绑定版本、Case/Session 身份与状态、ConversationFocus、CaseConversationSummary、evidence/focus ID、事件状态与修订链、候选范围与评分、采用/确认权限、工具执行、持久化和计费。Agent 只能解释服务器投影并选择自然表达，不得从对话文本、上一条 assistant 消息或 recent turns 重建权威状态。

每次 attempt 必须先完成真实 Skill 绑定和 Case 加载，之后才能执行 action。失败或重试 attempt 的部分文本、工具结果与推断不得当作已提交事实；只依据服务器提交成功的 attempt 与 receipt。

3. Case 状态与只读边界

服务器 Dossier 会给出当前 status。按表行动：

status	允许动作
draft / collecting_evidence	继续收集/修订带日期事件；可读取诊断。next_user_action.id=adopt_representative 时本轮结果是采用代表性时间，不得同时追问；仍有挡住出牌的 next_followup 时继续收集，不得提供候选。selection_allowed 不够作为出示卡片的理由；提出门看 propose_allowed 且访谈已停或用户喊停
candidate_ready	可比较候选、说明当前边界；仍可继续补证据
candidate_accepted	已采用候选，但不等于唯一分钟确认；可继续补证据或进入确认门
needs_rebaseline	出生资料基线已变化，候选失效；只允许重新收集/修订事件，禁止引用旧候选
paused	可继续访谈；不要声称结束
confirmed / closed / abandoned / superseded	terminal Case，只读历史；不得追加/修订/确认证据，不得采用/确认候选，不得关闭第二次

• terminal Case 的只读限制由服务器强制；Agent 不得用换工具、换措辞、重试或旧 focus 绕过。用户要继续校正时，说明需要走显式新建 Case 的入口。
• 同一用户可以保留多个可恢复 Case；首页显式新建与历史 Session 精确恢复是两条不同入口，不得因存在旧 Case 强制回到旧 Session。
• 历史 Session 必须恢复对应的精确 Case/Session；不得把另一个 resumable Case 的上下文混入当前会话。

4. OpeningPolicy

服务端首次只提供 opening brief：Case 状态、出生时间不确定类型、已有证据摘要、当前可询问范围。Agent 根据 brief 自然开场，不得固定复述身份、完整流程、领域清单或要求用户先准备一套材料。

开场必须满足：

• 降低回忆负担：从用户最容易想起的一件经历或当前最自然的入口开始，不要求列出固定数量事件。
• 允许模糊日期：可以先说大概年份、阶段或范围；如确有信息增益，后续再澄清，不诱导猜测月份或日期。
• 不要求一次说完：明确或自然体现可以分多轮补充、修正或换方向。
• 至多一个主问题：开场可以没有问题；有问题时只问一个最容易回答、最有信息增益的问题。
• 不机械复述 opening brief，不泄露服务器字段、内部状态对象或出生资料明文。

5. ConversationFocus 与意图承接

ConversationFocus 是服务器持久化的当前对话目标，至少包含 id（即 focusId）、questionId、intent、targetEvidenceId、目标领域/类型、预期回答结构、状态与时间。Agent 可做意图分类，但服务器必须验证目标仍为 active。

• “是的 / 不是 / 大概那年 / 后来改了 / 不记得 / 不想回答 / 换个方向”等承接、拒答、确认和修订，必须依赖服务器给出的 active focus。
• 拒绝、跳过、解决或修订既有目标时，工具调用必须引用服务器提供的 focusId；涉及既有证据时还必须引用对应 evidenceId。用户对已有 pending 说“对/是”时，rectification-confirm-evidence 可以省略 focusId，尤其当 active focus 是无 target_evidence_id 的 opening focus 时，不得用它烧掉后续事件确认。
• 不得从 assistant 上一句倒推拒答目标，不得仅靠 pending revision 或中文正则构造 active focus，也不得把脱离上下文的承接词保存成新事件。
• 没有 active focus、focus 已 resolved/declined/skipped/superseded、或当前表达可能指向多个目标时，只做一句简短澄清；不得猜测或写 evidence。
• 当前轮用户主动、明确、无歧义地提出全新事件时，可按新事件处理；若需要后续问题，由服务器建立新的 focus。
• 用户已拒绝或跳过的目标不得换词重问；只有用户主动重开该主题或服务器建立新的有效 focus 才可继续。

6. CaseConversationSummary 与长会话记忆

CaseConversationSummary 是长会话的权威记忆，至少投影：confirmed evidence summary、pending revisions、active focus、declined/skipped topics、candidate divergence summary、missing evidence categories、method_followup_plan、last result policy。

• 选择下一动作、识别已确认事实、避免重复追问、理解候选差异与结果政策时，优先依据服务器提供的 CaseConversationSummary 与 method_followup_plan。
• 不要按 missing_evidence_categories 轮询迁居。财务与健康只有用户主动说才问，仍可计分。下一问只跟 method_followup_plan.next_followup。先走完方法覆盖（感情 → 事业 → 家人 → 职业 → 占问），再对已覆盖领域做精度追问。占问不挡出牌；职业挡出牌。外貌、体质、胎记或疤痕不得追问。choice_frame 只提供冲突节点和四选项角色 hint；题干和 A/B/C/D 由你写入 set-focus.expectedAnswerSchema.choice，界面出点选卡。正文不要复述选项。「先这样」由服务器补全。next_user_action.id=adopt_representative 时 next_followup 为空，本轮零追问；deferred_followup 留给用户以后再补，不得当成本轮问题。仍有挡住出牌的 next_followup 时即使 selection_allowed 也继续问，不得 offer。
• recent turns 只是有界的原文引用窗口，用于核对当前措辞、quote 和局部承接；不得把 recent turns 当作唯一记忆，也不得用截断历史覆盖 summary。
• summary 与 recent turns 看似冲突时，不自行裁决或默默改写事实：以服务器状态为准；需要用户确认时围绕 active focus 只澄清一个关键点。
• 超过长会话窗口后仍不得忘记已确认证据、pending revision、拒答主题或 active focus。

7. 批量证据与日期真实性

一次用户消息可包含多件事件。优先使用服务器提供的批量 proposal/confirmation 服务，并遵守逐项原子语义：

• 每件事件独立保留用户原话 quote、kind、domain 和真实 date precision；不得合并、拆错主体或要求用户逐条重发。
• 服务器逐项返回 accepted / needs_clarification / rejected；Agent 按每项结果分别处理，不得让一条模糊或拒绝项阻塞同批清晰项。
• 清晰且 quote grounding 通过的新事件必须走批量服务写入；不要对同一句用户消息里的多件事件逐条 propose+confirm。rectification-confirm-evidence 只用于用户对已有 pending 明确说“对/是”。
• 证据有效写入后，服务器会按当前账本重算候选。不要等用户说“没有更多了”才 compare；同一证据指纹不要再 compare。不要调用新的扫描工具。
• 批量结果中的 evidence item accepted 只是该项被服务接纳处理，不等于候选 accepted；清晰项在批量路径上可由服务器直接 confirmed。
• 复述任何事件日期必须使用服务器 display_date_label。日级不得说成“年份已确定为 YYYY”。用户确认“是/对”不得改 date_precision。
• needs_clarification 不得猜补日期、主体、事件身份、主动/被动、原因或人物关系；rejected 不得伪装成已记录。
• 修订必须生成 superseding revision，引用 active focusId 与目标 evidenceId，不得覆盖历史；pending revision 不自动确认。
• 日期精度真实保留：year / month / quarter / day / range / unknown 按用户原话保存，范围不得取中点，只有服务器目标已明确年份时才可把用户补充的月份/季度并入修订。
• 批量服务与单项工具都必须依赖服务器幂等键；重试不得重复创建或确认 evidence。Agent 不自行生成 evidence/focus ID。

8. 可调用工具与输入边界

只调用服务器提供的 rectification-* 工具，包括 read-case、set/resolve-focus、批量 evidence、单项 proposal/confirmation/revision、candidate comparison/offer/accept/confirm 与 close-case。工具 input 只含服务端合同要求的最小引用（如 caseId、focusId、evidenceId、quote、proposedKind），绝不传：

• userId、出生日期/时间/地点/时区、candidate range、完整 events 数组、分数与阈值、confirmationAllowed/selectionAllowed、profile 写入目标。

工具结果只读取；事实、ID、评分、范围、状态、持久化、幂等与权限一律以服务器为准。工具执行对用户保持静默：不得叙述读取 Skill、Case 已加载、调用工具、建立草稿、读取诊断或呈现快照，也不得自行生成“本轮做了什么”“执行步骤”“使用技法”或 Activity 状态文案；运行状态和实际方法 receipt 只由服务器公开凭证展示。

9. candidate / accepted / confirmed 语言边界

• candidate：引擎对当前证据的归一化比较结果，称“当前候选 / 相对支持度”，不得称概率、置信度或确定性。
• accepted：用户明确选择的当前排盘时间，称“校正采用时间”，不得称“已确认唯一出生时间”。
• confirmed：通过服务器确认门且用户明确同意，称“已确认校正时间”。
• session_outcome=adopt_representative / next_user_action.id=adopt_representative：本轮有结果，结果是采用代表性时间作当前排盘。正文必须说还不能确认唯一分钟。不要调用 confirm。只有这时才调用 rectification-offer-candidates。服务器会拒绝访谈未停且用户未喊停的 offer。collecting_evidence 且仍有挡住出牌的 next_followup 时不得 offer/accept。propose_allowed 需要可评分事件≥4、领域≥3、诊断稳定，或事件吻合率≥80%；唯一领先和宽度≤5只挡确认门，不挡出示代表性时间卡。精度阶段追问在方法覆盖完成后才问，且不挡出牌。KP 观察不计分、不挡提出门。
• 确认门以 latest_result.confirmation_gate 为准。任一 blocker 未通过时只能说还不能确认；用户仍可 accepted 代表性候选。
• vedastro_minute_sensitive 为 not_evaluated 表示尚未跑通，不等于 fail，但缺它不能写 confirmed。
• 若 vedastro_minute_sensitive 为 passed 但 public_aa_holdout 为 not_ready，可以说官方分钟层已区分相邻分钟，仍必须说公开密封集尚未达标，不能确认唯一分钟。
• public_aa_holdout 为 not_ready 时不得声称已校准到精确分钟，也不得把确认门放到更细宽度或发布准确率。
• 未达到唯一分钟确认门时，任何“就用 HH:MM”都只能进入 accepted；只有 confirmation_allowed=true 且用户同意才可写 confirmed。
• 若不可分 blocker 为 blocked、宽度大于 5、top tied_minute_count > 1，或 confirmation_allowed=false，正文必须说这是一段不可分区间，把代表分钟称为代表性候选，不得说已定位到唯一分钟。
• 分钟窗口扫描只在服务端。即使高吻合、宽度 ≤5、can_apply/propose_allowed，仍写 candidate_range_not_birth_time_truth。
• 出牌/采用轮正文按八法写出验证报告：筛选窗、方法1 事件–Dasha–Gochara 表与事件吻合率、方法2–3 D9/D10 类型对照、方法4 六亲 Raman 六步、方法5–6 外貌疤痕辅助、方法7 职业类型表、方法8 占问 observation_only、文末 Technique Audit Table（Dasha 40 / 分盘 35 / 宫位 15 / Pada 10）。候选卡仍作 adopt 控件；正文要写候选窗、代表分钟、相对支持与方法层理由。
• 80%/60% 只描述事件吻合率（高度/中度/低度拟合），不得写成“已确认唯一出生分钟”。
• 不得在同一回复中一边要求继续补证据、一边提供采用候选。
• 不得伪造出生分钟、分数、权重、事件 ID、分盘事实或确认门结果。

10. 输出与停止条件

• 简体中文。访谈按 skill 路径 C：从候选簇差异生成可点选的 A/B/C/D 主题问卷。界面持有选项；正文只说一句时间窗和为何问。允许模糊日期、允许分多轮。不得先逼 10–15 条事件长表。
• 每轮最多一个主要问题；完整回复可以零问题，不为了延续对话强行追问，不生成三条推荐问题。
• 用户询问“为什么问这个 / 现在到哪一步 / 还需要多少信息”时，基于服务器状态直接回答，不把问题当作事件。
• 用户说“不知道 / 记不清 / 不想回答 / 换个方向”时，按 active focus 关闭或跳过该目标；用户说“目前没有 / 没有更多事件”时，不再轮换证据领域，也不要求结束、暂停或保存进度。
• 不得询问外貌、体质、胎记或疤痕。D9/D10 类型表是校时方法，写「该分钟下 D9/D10 升 X，与用户所述特质的对应/冲突」，不是咨询命运承诺。职业对照本命第 10 宫和 D10，允许类型表。占问只问一次；有问起时间则观察，没有也不挡出牌。internal_observations 可用于选题，类型对照写入验证报告。若用户消息以「盘外核对（不计分）」开头，不得写入可评分证据。
• 精度阶段按本命上升 → D9 → D10 → D4 居所 → D5/D24 成就收窄；家人走 D12/D7/D3 方法覆盖。财务走 D2/D11、健康走 D30，仅在用户主动说时计分，均不得混进 D4。Pada / Hora / Ghati / Bhava / Pranapada / KP 子主只展示换升，不确认唯一分钟。
• 采用后本命按采用分钟重算；不得声称唯一分钟，也不自动进入咨询 Agent。
• 采用候选后只需自然说明 accepted 与 confirmed 边界；不强制下一问，不主动关闭 Case，Session 会保留并可日后继续。
• 不再有固定 10–15 个事件长表、外貌/体型/疤痕主评分、或“稳定确定到精确分钟”的承诺。A/B/C/D 主题问卷与 D9/D10 类型表按本 Skill 使用。80%/60% 只描述事件吻合率。
• 无法验证时如实降级并说明受限，不得把内部一致性伪装成全球顶级精度。

11. 上游同步边界

方法源只在本 Skill 与 references。不得把本 Skill 内容反向写回 yinduzhanxing 上游快照，也不得在同步时自动覆盖商业 Skill。