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。