Version: 0.9.62.dev.260502

后端：
1. 主动调度补齐 `unfinished_feedback` 定位闭环——用户补充信息先在滚动窗口内定位到可校验的日程块，定位失败则继续 ask_user，不再硬猜 target_id 或直接跑 graph。
2. 聊天占管重跑链路加并发保护——`waiting_user_reply -> rerunning` 改为 DB CAS 抢占，重复补充只返回可见等待提示，避免并发生成多份 preview。
3. rerun 结果回写继续收口——新 preview_id 同步回 trigger 审计指针，session 只在拿到新 preview 时更新当前预览，ready_preview 后清空追问状态并释放回普通聊天。
4. 主动调度事件校验放宽 unfinished_feedback 的空 target 场景，允许先触发、后定位，再进入 graph + preview 主链路。

docs/backend/主动调度缺口分阶段实施计划.md

@@ -4,6 +4,8 @@
 
 目标只有一个：把主动调度剩下的缺口按阶段补完，并且每个阶段都能明确验收、明确自动化边界、明确是否已经完成。后续我会在这里持续把 `[ ]` 改成 `[x]`。
 
+补充约定：本文档是阶段进度看板，不再重复写设计细节；已经落地的阶段必须及时改成 `[x]`，并保留简短验证记录。实现方案和边界口径以《第二阶段主动调度 MVP 实现方案.md》为准。
+
 ---
 
 ## 0. 当前仓库基线
@@ -25,9 +27,19 @@
 - [x] `CreatePreview` 已切到 graph + 受限 selector，不再是固定 top1 / `Candidates[0]`。
 - [x] `active_schedule_sessions` 已正式进入代码，并接好缓存链路。
 - [x] 聊天入口已按 session 状态拦截，`waiting_user_reply / rerunning` 会接管补信息链路。
-- [ ] `unfinished_feedback` 的“定位 -> ask_user -> 重跑 graph”闭环还没完全做实。
-- [ ] 聊天页里的主动调度 preview 卡片 / 微调弹窗还没有最小适配。
-- [ ] 剩余极限验收项还没完全脚本化。
+- [x] `unfinished_feedback` 的“定位 -> ask_user -> 重跑 graph”后端闭环已经接上，前端最小适配也已落地。
+- [x] 聊天页里的主动调度 preview 卡片 / 微调弹窗已完成最小适配。
+- [ ] 剩余极限验收项已做过实测验证，但还在继续脚本化沉淀。
+
+### 近期实测记录（2026-05-02）
+
+这轮重新核验后，主动调度最小闭环已经再次跑通，可作为后续阶段 5 负向边界验收的基线。
+
+1. 测试账号为 `test0424 / 123456`，任务为“做马原大作业”，`mock_now` 固定到 `2026-04-30T01:14:21+08:00` 的周四窗口。
+2. 这次链路跑出了 `trigger_id=ast_1bb62e3e-f2cf-48a9-8f29-1461b99bff6b`、`preview_id=asp_e79db789-ba16-4108-a843-cd33c03aa3f6`、`conversation_id=ce525dc0-101a-50ca-8993-7fc466328de2`、`notification_records.id=22`。
+3. DB 对账显示 `active_schedule_triggers.status=preview_generated`、`active_schedule_previews.status=ready`、`active_schedule_sessions.status=ready_preview`，而 `schedule_events` 对该 preview 的正式写入计数为 0，说明这次只到预览态，没有执行正式 apply。
+4. 浏览器里周四列同时存在已有课程和待确认任务块；周六窗口只剩一个孤立任务块属于正常现象，不是后端漏课程。
+5. 这批结果说明：当前收口已经不在“主链路能不能跑通”，而是在“阶段 5 的过期、重复、篡改、冲突、幂等、通知和 outbox 负向边界能不能全部挡住”。
 
 ### 代码锚点
 
@@ -71,8 +83,8 @@
 | 阶段 0 | [x] | 补 `estimated_sections` 写入入口 | 创建任务时能稳定写入 1~4 节，主动调度只消费落库值 | 可以，API + DB + `go test` |
 | 阶段 1 | [x] | 补主动调度 Eino graph 和 LLM 解释 / 补全兜底 | 产生候选、有限裁决、输出解释、保留 fallback | 可以，后端单测 + API 验证 |
 | 阶段 2 | [x] | 补 `active_schedule_sessions`、聊天拦截和缓存链路 | `waiting_user_reply / rerunning` 拦截生效，`ready_preview` 释放 | 可以，API + DB + 路由验证 |
-| 阶段 3 | [ ] | 补 `unfinished_feedback`、`ask_user` 闭环和前端最小适配 | 用户在聊天页补信息后能重跑 graph 并刷新 preview | 后端可自动，前端需浏览器验证 |
-| 阶段 4 | [ ] | 收口飞书通知与会话链接 | `action_url` 指向 `/assistant/{conversation_id}`，通知 payload 从简 | 可以，webhook POST + DB 验证 |
+| 阶段 3 | [x] | 完成 `unfinished_feedback`、`ask_user` 闭环和前端最小适配 | 用户在聊天页补信息后能重跑 graph 并刷新 preview | 后端可自动，前端需浏览器验证 |
+| 阶段 4 | [x] | 收口飞书通知与会话链接 | `action_url` 指向 `/assistant/{conversation_id}`，通知 payload 从简 | 可以，webhook POST + DB 验证 |
 | 阶段 5 | [ ] | 跑完第五阶段剩余验收和失败注入脚本 | 冲突、过期、重复确认、重试、dead/skipped 全覆盖 | 可以，基本全自动 |
 
 ---
@@ -268,9 +280,9 @@
 
 **当前状态**
 
-`unfinished_feedback` 目前还偏向“已有目标就能做”，但“定位不稳怎么办、用户回一句怎么办、如何重跑 graph”还没有完全闭环。
+`unfinished_feedback` 的后端定位闭环、聊天页最小适配和并发兜底都已经收口，阶段 3 已完成。
 
-**要做什么**
+**已落地内容**
 
 1. 定位逻辑按这个顺序走：
    - LLM 上下文推断
@@ -287,6 +299,30 @@
    - 只是把 timeline 新类型和主动调度 confirm API 接起来
 7. 后端负责把主动调度 preview DTO 转成前端容易复用的结构，前端不背脏活。
 
+**补充链路图**
+
+```mermaid
+flowchart TD
+    A[用户在聊天页发送消息\nPOST /api/v1/agent/chat] --> B{查询 active_schedule_sessions}
+
+    B -->|未占管| N[进入普通 newAgent]
+    B -->|waiting_user_reply / rerunning| C[拦截到主动调度分支]
+
+    C --> D[写入用户消息到 timeline]
+    D --> E[LLM JSON 定位节点\n只负责补齐缺失事实]
+    E --> F{能否定位 schedule_event?}
+
+    F -->|否| G[生成 ask_user\nsession=waiting_user_reply]
+    F -->|是| H[重跑 active scheduler graph]
+
+    H --> I[BuildContext -> Observe -> GenerateCandidates -> SelectAndExplain]
+    I --> J[CreatePreview]
+    J --> K[session=ready_preview]
+    K --> N
+```
+
+这个定位节点只做一件事：把用户补充的话术转成后端可校验的 JSON 事实，不负责写正式日程，不负责生成新排程策略，也不负责替代后端候选裁决。
+
 **验收点**
 
 1. 用户补完当前主动调度缺失事实后，能刷新 preview 并解除锁定；解锁后再说“我周末不想学习”这类偏好话术时，直接走现有 newAgent memory / execute 链路。
@@ -300,69 +336,40 @@
 - 前端卡片展示和按钮分支，建议用浏览器实际打开一次做可视确认。
 - 如果只是检查 DOM / 路由 / 请求是否发对，能自动；如果要看卡片样式是否真的对齐，还是需要浏览器看一眼。
 
+**验证记录**
+
+1. `go build ./cmd/all` 已通过。
+2. `go test ./...` 已通过。
+3. 并发补充场景已验证：同一会话两条补充同时到来时，只会有一条抢到 rerun，另一条返回占管提示，不会重复生成 preview。
+
 ---
 
 ### 阶段 4：收口飞书通知与会话链接
 
 **当前状态**
 
-用户级 webhook 配置、通知投递、测试接口已经有基础，但主入口还需要统一收口到聊天会话链接，不能再把旧的 `/schedule-adjust/{preview_id}` 当新目标。
+已完成。用户级 webhook 配置、通知投递、测试接口和会话链接已经统一到 `/assistant/{conversation_id}`，不再把旧的 `/schedule-adjust/{preview_id}` 当作新入口。
 
-**要做什么**
+**已落地内容**
 
-1. 通知前先绑定或预创建 `conversation_id`。
-2. `action_url` 统一走：
+1. 通知前由后端预创建或绑定 `conversation_id`，保证飞书点击后直接进入同一会话。
+2. `action_url` 已统一为 `/assistant/{conversation_id}`；通知 payload 保持从简，只保留会话跳转和排障所需字段。
+3. 用户级飞书 webhook 的保存 / 查询 / 删除 / 测试接口已接通，真实投递与测试共用同一套 provider 校验和 JSON 拼装。
+4. `notification_records` 已覆盖 `sent / failed / dead / skipped` 和 retry 相关状态。
+5. 用户未配置或禁用 webhook 时，通知记录会落 `skipped`，不阻塞主链路。
 
-```text
-/assistant/{conversation_id}
-```
+**验证记录**
 
-3. 本地测试和示例配置继续用 `localhost`，上线后再换正式域名。
-4. 业务 JSON 保持从简，只让飞书流程去编排消息，不把复杂卡片协议塞进 webhook。
-5. 维持当前通知状态机：
-   - `sent`
-   - `failed`
-   - `dead`
-   - `skipped`
-   - retry 相关状态
+1. `PUT /api/v1/notification/channels/feishu` 已跑通。
+2. `POST /api/v1/notification/channels/feishu/test` 已跑通，成功时会回写 `last_test_status / last_test_at`。
+3. `POST /api/v1/active-schedule/trigger` 后生成的通知请求 payload 中，`message.action_url` 已指向 `/assistant/{conversation_id}`。
+4. 真实飞书消息样式和外部页面交互仍属于最终验收，不影响后端收口结论。
 
-**建议 payload 形态**
+**建议保留的边界**
 
-```json
-{
-  "event": "smartflow.schedule_adjustment_ready",
-  "version": "1",
-  "notification_id": 123,
-  "user_id": 5,
-  "preview_id": "asp_xxx",
-  "conversation_id": "conv_xxx",
-  "trigger_id": "ast_xxx",
-  "trigger_type": "important_urgent_task",
-  "target_type": "task_pool",
-  "target_id": 81,
-  "message": {
-    "title": "SmartFlow 日程调整建议",
-    "summary": "把重要且紧急任务放入滚动 24 小时内的空闲节次。",
-    "action_text": "查看并确认调整",
-    "action_url": "http://localhost:5173/assistant/conv_xxx"
-  },
-  "trace_id": "trace_xxx",
-  "sent_at": "2026-04-30T17:34:52+08:00"
-}
-```
-
-**验收点**
-
-1. 通知里的跳转链接能直接进聊天页。
-2. 用户级 webhook 的保存、查询、删除、测试都能跑通。
-3. 未配置、临时失败、不可恢复失败的状态都能在 `notification_records` 里看见。
-4. 用户已经在聊天页时，不再强依赖飞书通知承接回复。
-
-**自动化测试**
-
-- 可以自动跑。
-- 建议路径：Webhook POST、测试接口、`notification_records` 状态断言、真实 webhook 收到后人工看一次消息。
-- 如果需要验证“飞书真的收到”，最终还是要看外部页面一次，但 HTTP 层和状态层可以自动。
+1. 这里不再恢复旧的 `/schedule-adjust/{preview_id}` 主入口。
+2. 业务 JSON 继续从简，不把复杂卡片协议塞进 webhook。
+3. 后续如果要扩展新的通知渠道，先复用 `notification_records` 状态机和 `FeishuProvider` 的抽象边界。
 
 ---
 
@@ -370,7 +377,7 @@
 
 **当前状态**
 
-主链路已经有了，但极限边界还需要系统化收口。
+主链路已经有了，而且周四窗口的最小闭环已经再次跑通；现在阶段 5 的重点只剩极限边界、失败注入和脚本化收口。这里不再重跑阶段 3 的整套 `ask_user` 主链路，只保留 1 条真实 chat 烟测确认入口未回归。
 
 **要做什么**
 
@@ -391,7 +398,12 @@
 1. 所有核心状态机都能串起来排障。
 2. 同一条 preview / notification / apply 不会被重复落库。
 3. 过期、冲突、篡改、失败注入都能拒绝。
-4. 最终能把这一轮主动调度缺口标成完成。
+4. 预览过期、重复 confirm、错误 candidate / 跨用户 preview / preview-session 不匹配都能挡住。
+5. 同一 `idempotency_key / dedupe_key` 不能重复生成有效 trigger / preview / notification。
+6. notification 的 `skipped / failed / dead / sent` 状态都能在 DB 里对上。
+7. outbox 重复消费不会重复投递或重复写通知记录。
+8. `api / worker / all` 三种启动边界相关 handler / job 注册不能缺失。
+9. 最终能把这一轮主动调度缺口标成完成。
 
 **自动化测试**
 
@@ -414,6 +426,7 @@
 8. `unfinished_feedback` 先定位，再 `ask_user`，定位成功后直接生成补做 preview，不移动原任务。
 9. 用户在聊天页说偏好时，不归主动调度接管；解锁后直接走现有 newAgent memory / execute 链路。
 10. 只有后台离线自动触达才走飞书；用户已经在会话里时，不需要再先走飞书通知。
+11. `ask_user` 闭环只新增一个 LLM JSON 定位节点，沿用正常 `chat` 入口和 session 拦截，不单独再造工具系统。
 
 ---