root/Jyotisha
2
0
Fork 0
Code Issues Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

fix: close rectification convergence gaps

Browse Source
This commit is contained in:
Jesse_Chen
2026-07-25 12:59:13 +08:00
parent 0e6ed6ba79
commit e41fae1e05
6 changed files with 118 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/BUG_HISTORY.md
+18 -3
View File
@@ -1317,9 +1317,24 @@
- 影响面：生时校正连续评分、候选收敛、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，全部通过。
- 根因：收集阶段和最终确认阶段共用了错误门槛。Technical Packet 把“没有足够的新问题可问”当成候选无效，Orchestrator 又把窄候选失败静默替换为 `baseRange`；评分、技法合同和 Candidate Schema 分别使用 3/2 与 4/3 门槛，前两条事件不进入评分；plateau 只记录不终止，系统验证阻塞继续被转换成用户问题。外部验证入口还被误收紧为最终确认所需的 `width <= 5` 且 `margin >= 20%`。同时 `family/other` 虽不进入 Python 评分器，却仍帮助编排层满足事件数和领域数；Agent 也继续追问不参与当前评分的原因、主动性和影响。原确定性校验只识别正确标注为 `event_detail` 的请求，模型可把同一详情问题错标成 `new_event` 绕过；最终轮也只靠提示词要求 `evidenceRequest=null`。
- 修复：建立前后端共享的收敛策略：第一条有效事件即评分，最终确认统一要求至少 4 条事件、3 个可评分领域、候选宽度不超过 5 分钟且 margin 不低于 20%。Technical Packet 接受单分钟和零建议领域；删除窄候选失败后退回 `baseRange` 的路径。候选在证据覆盖后连续两轮不变时结束为 `completed + pending_validation`，仅剩系统验证阻塞时直接结束有限结果，不再追问用户。外部验证单独使用最多 15 分钟的入口宽度，只要求唯一领先和必需层完整，不再提前要求最终 margin。编排层统一排除 `family/other` 的评分与确认计数，但继续持久化并展示为背景。Narrative Agent 的共享校验器禁止对已评分事件继续追问无计算价值详情，包括错标为 `new_event` 的详情语义；最终轮任何非空 `evidenceRequest` 都会触发重试，连续失败后才使用既有无追问 fallback。
- 验证：前端聚焦测试覆盖结构化日期确认、单事件起评、单分钟候选、plateau/系统阻塞终止、家庭背景不进入评分计数、已评分事件详情错标重试，以及最终轮非空 `evidenceRequest` 重试。Python 聚焦测试覆盖长对话窄化后恢复 VedAstro 调用、4 条/3 领域统一门槛、官方分钟快照判别与 Technique Contract。
- 防复发：必须区分“开始本地评分”“进入外部验证”“允许最终确认”三个阶段；没有新问题可问不得解释为候选无效。只有评分器实际支持的领域可以推进收敛计数，模型提问必须能改变日期、事件身份或评分领域，否则由确定性校验拒绝。
- 相关记录：BUG-064、BUG-066、BUG-068
- 修复版本：待提交（本地可测）
## BUG-070 | 结构化日期确认迁移未接入生产迁移工作流
- 状态：resolved
- 首次发现：2026-07-25
- 最近更新：2026-07-25
- 影响面：生产环境生时校正 follow-up 持久化、日期候选确认与数据库约束
- 用户现象：代码已写入 `prompt`、`answerMode` 和 `proposedDate`，但生产迁移工作流不会上传或执行对应 migration；生产数据库仍可能按旧 JSON 合同拒绝新 turn。
- 触发条件：从 GitHub Actions 手动执行生产生时校正 migration 的 `check` 或 `apply` 操作。
- 根因：新增 `20260725010000_structured_conversational_date_confirmation.sql` 后，没有同步加入工作流的 `scp` 上传列表和远端顺序执行列表。
- 修复：将该 migration 同时加入上传与执行列表，继续复用现有 checksum、迁移账本和单事务执行保护。
- 验证：静态回归断言 migration 文件名在生产工作流中恰好出现两次，分别覆盖上传和执行路径。
- 防复发：新增需要生产执行的 migration 时，必须同时更新受审生产迁移清单并由测试覆盖上传和执行两处引用。
- 相关记录：BUG-068、BUG-069
- 修复版本：待提交（本地可测）