fix: speed up rectification start

2026-07-25 22:11:13 +08:00
parent 3e56389aeb
commit 031c275324
5 changed files with 192 additions and 74 deletions
@@ -1353,3 +1353,18 @@
 - 防复发：数据库 JSON 合同的日期格式只维护一组精度分支；新增生产迁移时必须执行真实 PostgreSQL 函数调用，而不是只做 SQL 文本断言。
 - 相关记录：BUG-067、BUG-070
 - 修复版本：本次修复提交（生产已向前迁移）
+
+## BUG-072 | 生时校正首轮在零事件时执行全范围扫描并阻塞输入
+
+- 状态：resolved
+- 首次发现：2026-07-25
+- 最近更新：2026-07-25
+- 影响面：首页生时校正入口、`start` 编排、首次会话持久化与咨询问题 handoff
+- 用户现象：从首页进入生时校正后长时间停留在加载状态；未知时间或宽时段资料最明显，首问出现后输入框也可能继续等待会话同步。
+- 触发条件：新建生时校正 case，尤其声明时间为全天未知或宽时段；首页没有待转交咨询问题时也会读取 durable handoff。
+- 根因：`start` 在尚无人生事件时仍构建 Technical Packet，按声明范围逐分钟重排，随后再调用叙事模型生成固定性质的首问；前端收到首轮后又串行等待 `persistSession()`，并且直接首页入口无条件读取 durable handoff。
+- 修复：`start` 只按已声明时间范围创建确定性首轮和待验证候选，不做分钟扫描或模型生成；第一条有效事件回答后才进入原技术计算与叙事链。首页先展示首轮并开放输入，再后台同步会话；只有存在本地或显式待转交问题时才读取 durable handoff。
+- 验证：Orchestrator、入口、客户端、路由、持久化与同会话写入队列聚焦测试 144/144 通过；目标 ESLint 与 `git diff --check` 通过。覆盖首轮不扫描/不生成叙事、先展示后按序后台持久化，以及无 handoff 时跳过 durable 读取。
+- 防复发：零证据首轮不得执行分钟级技术计算或模型调用；非关键会话同步不得阻塞已持久化 case 的首轮交互；可选 handoff 读取必须由实际 handoff 状态触发。
+- 相关记录：BUG-055、BUG-065、BUG-067
+- 修复版本：待提交（本地可测）