fix: make conversational rectification converge

docs/BUG_HISTORY.md

@@ -1293,18 +1293,33 @@
 - 复发自：无
 - 修复版本：待提交（待生产验收）
 
-## BUG-068 | 生时校正确认词被当成新事件且 Agent 每轮丢失对话历史
+## BUG-068 | 生时校正确认词被当成新事件且重复追问同一日期
 
 - 状态：resolved
 - 首次发现：2026-07-25
 - 最近更新：2026-07-25
 - 影响面：生时校正连续问答、事件日期确认、刷新后继续会话
 - 用户现象：Agent 问某个事件是否发生在明确年月，用户回答“是的”后，下一轮仍重复询问相同年月；确认词还可能被保存成一条日期待补充的新事件。
-- 触发条件：用户使用确认词、代词或承接上一问的简短自然语言回答，而当前轮没有再次写出完整事件和绝对日期。
-- 根因：叙事模型每轮只收到最新用户文字和事件账本，没有收到同一 case 的持久化 Assistant/User 消息序列；确定性提取器又把无法独立解析的确认词当成新事件，并用自动澄清 follow-up 覆盖模型的自然追问。
-- 修复：复用现有 turn 与 event evidence 存储，每轮向 Agent 注入同一 case 最近 40 条连续问答；确认词优先采用上一条 Agent 明确提出的日期并修正目标事件，无法落到明确日期时不生成伪事件。模型成功返回时，其 follow-up 不再被提取器的自动澄清覆盖；事件账本继续只负责审计、去重和技术候选计算。
-- 验证：新增回归覆盖“明确年月确认问题 → 是的”，断言保存为目标事件的年月修正、没有独立确认词事件，并断言叙事 prompt 末尾连续包含上一条 Assistant 问题和当前 User 回答。
-- 防复发：任何承接式回答必须以持久化会话历史为第一语境；结构化提取只能规范化可确认事实，不得决定 Agent 的下一句话。
+- 触发条件：用户使用确认词、否定词、代词或承接上一问的简短自然语言回答，而当前轮没有再次写出完整事件和绝对日期。
+- 根因：叙事模型原先每轮只收到最新用户文字和事件账本，缺少同一 case 的连续 Assistant/User 历史；即使补回历史，候选日期仍只存在于上一轮可见文案中，没有作为业务状态持久化，确定性提取器仍可能把确认词当成新事件。依赖从 Agent 文案正则反推日期也会随文案改写、语言变化或恢复路径失效。
+- 修复：复用现有 turn 与 event evidence 存储，每轮向 Agent 注入同一 case 最近 40 条连续问答；同时在共享 follow-up 合同和数据库 JSON 校验中持久化 `prompt`、`answerMode` 与 `proposedDate`。Orchestrator 在事件提取前确定性处理 yes/no：肯定时把候选日期作为 append-only correction 合并到目标 evidence，否定时不生成事件并把同一目标切换为开放式日期追问。模型成功返回时，其 follow-up 不再被提取器的自动澄清覆盖；Narrative Agent 拒绝缺少结构化候选、重复已解决问题或继续指向已完成 evidence 的输出。
+- 验证：回归覆盖“2020年10月吗？→是的”、单独“不是”、“不是，是2021年10月”、刷新/resume 后候选日期仍存在，以及同一 actionId 重放不重复写入；断言确认词不成为独立事件、修正 lineage 正确、否定后切换为 `free_text`，并断言叙事 prompt 末尾连续包含上一条 Assistant 问题和当前 User 回答。
+- 防复发：任何承接式回答必须以持久化会话历史为第一语境；确认或否认是否改变业务事实必须由持久化 follow-up 状态和确定性状态机执行，不得再从自然语言文案反推候选日期。
 - 相关记录：BUG-032、BUG-063、BUG-067
 - 复发自：无
 - 修复版本：待提交（本地可测）
+
+## BUG-069 | 生时校正最终候选被收集阶段约束退回并无限追问
+
+- 状态：resolved
+- 首次发现：2026-07-25
+- 最近更新：2026-07-25
+- 影响面：生时校正连续评分、候选收敛、VedAstro 外部验证与有限结果终止
+- 用户现象：用户连续提供多条真实经历后，本地候选已经缩小到单分钟或极窄范围，系统仍可能退回原始范围并继续追问；提问还可能停留在“为什么辞职、主动还是被动、造成什么影响”等不会改变当前评分的细节。
+- 触发条件：Technical Packet 收到单分钟候选或不足两个新建议领域；本地候选宽度已经适合外部验证但最终 margin 尚未达到确认阈值；事件达到旧的 3 条/2 领域门槛却未达到前端 4 条/3 领域门槛；候选连续多轮不再变化；或 `family/other` 背景事件被编排层计入评分覆盖。
+- 根因：收集阶段和最终确认阶段共用了错误门槛。Technical Packet 把“没有足够的新问题可问”当成候选无效，Orchestrator 又把窄候选失败静默替换为 `baseRange`；评分、技法合同和 Candidate Schema 分别使用 3/2 与 4/3 门槛，前两条事件不进入评分；plateau 只记录不终止，系统验证阻塞继续被转换成用户问题。外部验证入口还被误收紧为最终确认所需的 `width <= 5` 且 `margin >= 20%`。同时 `family/other` 虽不进入 Python 评分器，却仍帮助编排层满足事件数和领域数；Agent 也继续追问不参与当前评分的原因、主动性和影响。
+- 修复：建立前后端共享的收敛策略：第一条有效事件即评分，最终确认统一要求至少 4 条事件、3 个可评分领域、候选宽度不超过 5 分钟且 margin 不低于 20%。Technical Packet 接受单分钟和零建议领域；删除窄候选失败后退回 `baseRange` 的路径。候选在证据覆盖后连续两轮不变时结束为 `completed + pending_validation`，仅剩系统验证阻塞时直接结束有限结果，不再追问用户。外部验证单独使用最多 15 分钟的入口宽度，只要求唯一领先和必需层完整，不再提前要求最终 margin。编排层统一排除 `family/other` 的评分与确认计数，但继续持久化并展示为背景。Narrative Agent 的提示词和确定性校验同时禁止对已经进入评分的事件继续追问无计算价值详情。
+- 验证：前端 7 个聚焦测试文件共 158 项通过，覆盖结构化日期确认、单事件起评、单分钟候选、plateau/系统阻塞终止、家庭背景不进入评分计数和已评分事件详情追问拦截。Python 聚焦测试覆盖长对话窄化后恢复 VedAstro 调用、4 条/3 领域统一门槛、官方分钟快照判别与 Technique Contract，全部通过。
+- 防复发：必须区分“开始本地评分”“进入外部验证”“允许最终确认”三个阶段；没有新问题可问不得解释为候选无效。只有评分器实际支持的领域可以推进收敛计数，模型提问必须能改变日期、事件身份或评分领域，否则由确定性校验拒绝。
+- 相关记录：BUG-064、BUG-066、BUG-068
+- 修复版本：待提交（本地可测）