Version: 0.9.61.dev.260501

后端：
1. 主动调度 graph + session bridge 收口——把 dry-run / select / preview / confirm / rerun 串成受限 graph，新增 active_schedule_sessions 缓存与聊天拦截，ready_preview 后释放回自由聊天
2. 会话与通知链路对齐——notification 统一绑定 conversation_id，action_url 指向 /assistant/{conversation_id}，会话不存在改回 404 语义，避免 wrong param type 误导排障
3. estimated_sections 写入与主动调度消费链路补齐——任务创建、quick task 与随口记入口都透传估计节数，主动调度只消费落库值

前端：
4. AssistantPanel 最小适配主动调度预览与失败态——复用主动调度卡片/微调弹窗，补历史加载失败可见提示与跨账号会话拦截

文档：
5. 更新主动调度缺口分阶段实施计划和实现方案，标记阶段 0-2 收口并同步接力状态

docs/backend/第二阶段主动调度MVP功能预期.md

@@ -10,12 +10,12 @@
 课程 / 任务事实变化
   -> 后台观测滚动 24 小时内的任务与日程风险
   -> 生成结构化诊断和候选方案
-  -> 让 LLM 在候选方案中做选择与表达
+  -> 让 LLM 做解释、追问和有限选择
   -> 写入预览 / 触达用户
   -> 用户回系统确认后再进入正式应用
 ```
 
-这里的关键是：**系统主动观测，后端给候选，LLM 做选择题，用户掌握最终确认权**。
+这里的关键是：**系统主动观测，后端给候选并粗排，LLM 做解释 / 追问 / 有限选择，用户掌握最终确认权**。
 
 ---
 
@@ -78,7 +78,7 @@
 
 1. 后端先做结构化观测。
 2. 后端输出问题、指标、裁决和候选操作。
-3. LLM 不做开放式全窗搜索，而是在候选项里选择。
+3. LLM 不做开放式全窗搜索，也不承担主排序；它只在后端候选里做有限选择与表达。
 4. 候选必须是后端验证过合法性和收益的。
 5. 如果没有值得继续处理的问题，后端明确返回 close / ask_user，而不是继续诱导 LLM 硬调。
 
@@ -86,13 +86,13 @@
 
 也就是说，新能力更像一个主动调度观测能力，而不是一个自由排程工具。具体工程工具名后续再确认，本阶段只固定职责边界。
 
-### 3.2 让 LLM 做选择题
+### 3.2 让 LLM 做解释、追问和有限选择
 
 LLM 的职责：
 
-1. 在后端候选方案中选择更符合上下文的一项。
-2. 把结构化诊断转换成用户能理解的解释。
-3. 在候选不足、信息不足、风险过高时选择 ask_user / close。
+1. 把结构化诊断转换成用户能理解的解释。
+2. 在后端候选非常接近时，做有限选择。
+3. 在信息不足时，把后端 `missing_info` 转成自然追问。
 4. 根据主动注入的上下文理解用户偏好，但不调用单独的 `user_preference.get` 工具。
 
 后端的职责：
@@ -540,7 +540,7 @@ assumed_completed
 4. 动态任务计划时间过去后默认按已完成推进，不主动追问。
 5. 当前动态任务失败且影响后继时，能按“局部重排 -> 延后结束 -> 压缩融合”顺序生成候选。
 6. 能输出结构化 metrics / issues / decision / candidates。
-7. 候选项必须是选择题，不让 LLM 自由生成正式写库参数。
+7. 候选项必须来自后端，不让 LLM 自由生成正式写库参数；LLM 只做解释、追问和有限选择。
 8. 不直接写正式 schedule，只写预览或触达用户。
 9. 能发布 `notification.feishu.requested` 提醒用户回系统确认。
 10. 用户确认后才允许进入正式应用链路。