Jyotisha/skills/jyotish-birth-time-rectification/references/conversation-strategy.md

Conversation Strategy（V10）

生时校正访谈按 skill 路径 C：从候选簇差异生成 A/B/C/D 主题问卷，而不是 10–15 条事件长表，也不是无结构闲聊。服务器持有事实、状态、权限、焦点与长会话记忆；Agent 负责意图理解、把问卷说清楚、并选择一个有信息增益的下一步。

1. 每轮上下文优先级

每轮先按以下优先级理解会话：

1. 当前 Case 的服务器状态与读写权限。
2. CaseConversationSummary：confirmed evidence、pending revisions、active focus、declined/skipped topics、candidate divergence、method_followup_plan、last result policy。不要把 missing_evidence_categories 当下一问。
3. 当前用户消息。
4. recent turns：只作为有界原文引用窗口，辅助 quote grounding 和局部措辞理解。

recent turns 不是权威记忆，不得依赖“上一条 assistant 问了什么”的倒推、正则匹配或被截断的聊天记录重建 Case 状态。summary 与局部文本不一致时，以服务器状态为准；若用户意图仍不唯一，只澄清一个关键点。

2. OpeningPolicy

首次开场只使用服务器 opening brief 中的 Case 状态、出生时间不确定类型、已有证据摘要与当前可询问范围，并自然满足：

• 降低回忆负担：从候选簇差异生成 A/B/C/D 点选卡。choice_frame 只提供冲突节点和四选项角色 hint；题干和 A/B/C/D 由 Agent 写入 set-focus.expectedAnswerSchema.choice。正文不要复述选项。「先这样」由服务器补全。不索要 10–15 条事件长表。
• 接受“大概某年 / 那几年 / 某个阶段”等模糊日期，不诱导猜月份、日期或精确时点。
• 不要求一次说完，允许分多轮补充、修正、暂停或换方向。
• 至多一个主问题；开场可以零问题。
• 不固定复述身份、流程、领域列表、证据数量要求或 opening brief 原文。

示例方向（不是固定话术）：“2016 年前后，更像哪一件？点下面的选项即可。”

3. 一轮的基本形态

1. 先判断用户意图：新事件、批量事件、补日期、修正旧事实、回答上一问、确认/否认、询问进度或原因、拒答/换方向、查看或采用候选。
2. 先读取服务器 Case、summary 与 active focus；静默完成必要的工具调用后再输出答案。正文不叙述内部执行步骤，也不生成 Activity/技法凭证文案。
3. 自然回应本轮内容，不固定以“收到 / 已记录”开头，不机械复读，不擅自解释事件的“人生意义”。
4. 清晰项先处理；若仍需追问，只保留一个最有信息增益的主问题。完整回复可以没有问题。
5. 不允许在同一回复中既要求补证据、又提供采用候选；不生成三条推荐问题。
6. next_user_action.id=adopt_representative 时本轮只解释结果并邀请采用，零追问（除非有 active focus）。仍有挡住出牌的 next_followup 时不得出示采用卡。提出门看 propose_allowed。精度阶段追问和占问不挡出牌；职业仍挡。不得询问外貌、体质、胎记或疤痕。宽度大于 5 仍可出示代表性时间卡，不得为把不可分区间问到 5 分钟以内而继续 A/B/C/D。

4. ConversationFocus

active ConversationFocus 是承接型意图的唯一目标来源。它由服务器持久化并提供 focusId、目标 evidenceId（如有）、intent、预期回答结构和状态。

• “是的 / 不是 / 对 / 不对 / 大概那年 / 后来改了 / 不记得 / 不想回答 / 换个方向”只有在存在唯一 active focus 时才能解释为回答、拒答、确认或修订。
• 拒绝、跳过、解决 focus 时，工具调用必须引用 active focusId；修订既有 evidence 时同时引用目标 evidenceId。用户对已有 pending 说“对/是”时，确认工具可以省略 focusId；opening focus（无 target_evidence_id）不得因第一条确认被 resolve。
• 无 active focus、focus 已非 active、目标已被 supersede、或一句话可能指向多个问题时，简短问清“你指的是哪一件/哪一个时间点”；不得猜测，不调用 evidence 写工具。
• 脱离 active focus 的“是的 / 不是”不是新事件。不得从 assistant 上一句倒推目标，不得只用 pending revision 构造 active_followup。
• 当前消息若主动、明确陈述全新事件，可独立进入 evidence 流程；需要追问时由服务器建立新 focus。
• 服务器验证 focus 已失效时，停止该动作并基于最新 summary 重新回应，不沿用旧目标。

5. 自然叙述与批量 evidence

用户一段话中可以包含多件事件。应优先走服务器批量服务：

• 每件事件分别保留原话 quote、kind、domain、主体和日期精度，不合并，不要求逐条重发。
• 服务器对每项独立返回 accepted、needs_clarification 或 rejected。一项失败不改变其他项结果。
• 新事件优先走批量服务；一句里两件及以上事件时只允许批量。清晰项在批量路径上可由服务器直接 confirmed，不要再逐条 propose+confirm。不要让模糊项阻塞清晰项。
• 多个模糊项同时存在时，只选择信息增益最高的一项追问一个关键点，其余维持待澄清，不连续抛出问题清单。
• needs_clarification 只问缺失的关键事实；不猜日期、主体、事件身份、动机、因果、主动/被动或人物关系。
• rejected 如需解释，只说明用户可理解的边界，不伪装成已记录。
• 批量 evidence item 的 accepted 是服务处理结果，不是候选采用状态；清晰项的最终 status 以服务器返回为准，批量路径上可以为 confirmed。
• 询问进度/原因、拒答、查看结果、采用候选，以及无唯一 active focus 的承接词，都不是新事件。

6. 确认、修订、拒答与换方向

• 确认既有事实：必须有对应 evidenceId；确认词本身不创建新 evidence。无匹配 pending-target 的 focus 时可省略 focusId。
• 修订既有事实：必须有 active focusId 和目标 evidenceId，生成 superseding revision，不覆盖历史；pending revision 不自动确认。
• 用户明确“不知道 / 记不清”：将 active focus 解决为相应状态，不诱导猜测。
• 用户明确“不想回答 / 换个方向”：decline/skip active focus；不得换词重开同一目标。
• 用户主动重新打开曾拒绝主题时，可让服务器建立新 focus；否则 declined/skipped topics 以 CaseConversationSummary 为准。
• 用户说“目前没有 / 没有更多事件”时，停止轮换证据领域；不要求结束、暂停或保存进度。
• 若没有其他具备信息增益的问题，可以直接说明当前边界或自然结束本轮。

7. 追问策略

追问必须能澄清事实、提高真实日期精度、补足必要方法层或区分候选；否则不提。优先级：

1. 服务器 CaseConversationSummary.active focus 指定的唯一目标。
2. method_followup_plan.next_followup 指定的下一方法层。方法覆盖优先于对已覆盖领域的精度追问：有日期事件 → 感情 → 事业 → 家人（D12/D7/D3）→ 职业（挡出牌，独立于带日期事业事件）→ 占问（只问一次，不挡出牌）→ 再按精度阶段问关系盘/事业盘/居所（D4）/学业成就（D5，D24 换升并入同一问）。迁居不进领域轮询，只在 d4_refine 精度阶段问搬家/住处。财务与健康只有用户主动说才问，仍可计分。不得询问外貌、体质、胎记或疤痕。choice_frame 只提供冲突节点；题干和 A/B/C/D 由 Agent 写入点选卡，正文不复述选项。Nakshatra pada / Hora / Ghati / Bhava / Pranapada / KP 子主换升只展示，不阻断采用。next_user_action.id=adopt_representative 时 next_followup 为空，不得把 deferred_followup 当成本轮问题。仍有挡住出牌的 next_followup 时即使 selection_allowed 也继续问。
3. candidate divergence / internal_observations 显示真正能区分候选的主题。D9/D10 观察用于选题，并在出牌轮写入类型对照（校时方法，不是命运承诺）。
4. pending revision 的一个关键歧义。
5. 已有证据的必要稳定性补强。

不要按 missing_evidence_categories 轮询迁居。财务与健康只有用户主动说才问，不是 SQL 类别轮询。stop_domain_rotation=true 时停止领域清单。一轮最多一个主要问题。用户询问“为什么问这个 / 现在到哪一步 / 还需要多少信息”时，直接说明目的、当前状态和边界，不绕开问题继续索取证据。

8. 日期精度

• year：只说年份；复述用 display_date_label（如 2024年）。
• month：明确到月份；复述如 2024-05。
• quarter：明确到季度。
• day：明确到日期；复述必须是 YYYY-MM-DD，禁止说成“年份已确定为 YYYY”。
• range：只有范围，不得擅自取中点当事实；复述用 from–to。
• unknown：日期不明；可保留背景，但不得当作高权重校正证据。
• 用户确认“是 / 对”不得改 date_precision。
• 用户只补月份/季度时，只有 active focus 与目标 evidence 已由服务器明确年份，才可合并为 revision；不得猜年份。
• “大概 3 月”仍按用户真实表达保存，不升级成某一天。

9. 候选输出与终态

• 候选卡负责呈现时间、排名、相对支持度、采用动作与选中状态。
• 出牌/采用轮正文写入 skill 八法验证报告：候选窗、代表分钟、相对支持、事件–Dasha–Gochara 表、D9/D10 类型对照、技法审计表。卡片仍作 adopt 控件。
• relative_support 不是概率，不能写“准确率 70%”。80%/60% 只描述事件吻合率。
• candidate、accepted、confirmed 严格分离；accepted 不是 confirmed。
• next_user_action.id=adopt_representative 时本轮结果是采用代表性时间；正文必须说还不能确认唯一分钟。仍有 next_followup 时不得出示采用卡。
• 确认门以 confirmation_gate 为准。not_evaluated 不是 fail；holdout not_ready 时不得声称精确分钟或发布准确率。官方分钟层 passed 仍不能单独打开确认门。
• 若 indistinguishable_width_minutes > 5 或 top tied_minute_count > 1，或 confirmation_allowed=false，必须说不可分区间 / 代表性候选，不得说已定位到唯一分钟。accepted ≠ confirmed。
• accepted 后自然说明它不是唯一分钟确认即可；不强制追问，不要求用户结束、暂停或保存进度。
• terminal Case（confirmed / closed / abandoned / superseded）只读：不得新增/修订/确认 evidence，不得采用/确认候选；若用户要继续，指向显式新建 Case。