Version: 0.9.9.dev.260408

后端：
1. 粗排后分流与顺序守卫落地，支持“无明确微调偏好时粗排后直接收口”，并新增 allow_reorder / needs_refine_after_rough_build 语义，打通 chat→rough_build→execute/order_guard→deliver 路由。
2. execute 工具执行链路修复：清理乱码坏块与重复分支；新增 min_context_switch 未授权拦截；补齐 suggested 顺序基线初始化与顺序守卫联动。
3. 新增复合写工具 min_context_switch（减少上下文切换）并接入注册、参数解析、写工具白名单、提示词与文档；仅在用户明确允许打乱顺序时可用。
4. 工具口径升级：find_first_free 支持 day/day_start/day_end 范围参数并统一文案；移除 find_free 兼容别名；读写工具输出统一到“第N天(星期X)”格式。
5. prompt 同步升级：chat/execute/execute_context 增加粗排后是否继续微调、顺序授权、min_context_switch 使用边界与返回示例约束。
6. handoff 文档重命名并重写下班交接重点：下一步聚焦“工具收敛能力研究 + 运行态必要参数重置（不丢运行态）”。
7. 同步更新调试日志文件。
前端：无
仓库：无

backend/newAgent/prompt/execute.go

@@ -15,16 +15,21 @@ const executeSystemPromptWithPlan = `
 1. 只围绕当前步骤推进，先读后写，逐步完成当前步骤。
 2. 可调用读工具补充事实，再决定下一步。
 3. 需要写操作时输出 action=confirm 并附带 tool_call，等待用户确认。
+4. 若用户给出了“二次微调方向”（如负载均衡、某天减负、某类任务后移），优先围绕该方向推进，并在 goal_check 说明满足情况。
+5. 只有在用户明确允许打乱顺序时，才可使用 min_context_switch 做重排。
 
 你不要做什么：
 1. 不要跳到其他 plan 步骤，不要越级执行。
 2. 不要伪造工具结果。
 3. 如果上下文明确“粗排已完成/rough_build_done”，不要把任务当成未排入，不要重新逐个手动 place。
-4. 不要连续重复同类查询而没有推进；连续两轮同类读查询后，必须转入执行、ask_user，或明确阻塞原因。
-5. list_tasks 的 status 只允许单值：all / existing / suggested / pending。禁止使用 "existing,suggested" 这类拼接值。
-6. 若工具结果与已知事实明显冲突（如无写操作却从“有任务”变成“0任务”），先自我纠错并重查一次，不要直接 ask_user。
-7. 不要连续两轮调用“同一读工具 + 等价 arguments”；若上一轮已成功返回，下一轮必须换工具或进入 confirm。
-8. list_tasks.category 只接受任务类名称，不接受 task_class_ids（如 "1,2,3"）。
+4. 如果上下文明确“当前未收到明确微调偏好/本轮先收口”，不要继续微调，直接输出 action=done。
+5. 不要连续重复同类查询而没有推进；连续两轮同类读查询后，必须转入执行、ask_user，或明确阻塞原因。
+6. list_tasks 的 status 只允许单值：all / existing / suggested / pending。禁止使用 "existing,suggested" 这类拼接值。
+7. 若工具结果与已知事实明显冲突（如无写操作却从“有任务”变成“0任务”），先自我纠错并重查一次，不要直接 ask_user。
+8. 不要连续两轮调用“同一读工具 + 等价 arguments”；若上一轮已成功返回，下一轮必须换工具或进入 confirm。
+9. list_tasks.category 只接受任务类名称，不接受 task_class_ids（如 "1,2,3"）。
+10. 不要忽略用户最新补充的微调方向；若与旧目标冲突，以最新用户要求为准。
+11. 若当前顺序策略是“默认保持顺序”，禁止调用 min_context_switch。
 
 执行规则：
 1. 只输出严格 JSON，不要输出 markdown，不要在 JSON 外补充文本。
@@ -41,12 +46,15 @@ const executeSystemPromptReAct = `
 阶段事实（强约束）：
 1. 若上下文给出“粗排已完成/rough_build_done”，表示目标任务类已经进入 suggested/existing，不是待排入状态。
 2. 当前阶段目标是“微调”，不是“重新粗排”。
+3. 若上下文明确“当前未收到明确微调偏好/本轮先收口”，应直接结束而不是继续优化循环。
+4. 若用户提出了二次微调方向，本轮优先目标就是满足该方向。
 
 你可以做什么：
-1. 你可以基于科学排程原则（负载均衡、学习连贯性、冲突最小化）对 suggested 做微调。
+1. 你可以基于用户给定的二次微调方向，对 suggested 做定向微调。
 2. existing 属于已安排事实层，可用于冲突判断和参考，不作为 move/batch_move 的目标。
 3. 你可以先调用读工具补充必要事实（例如 get_overview/list_tasks/find_first_free/get_task_info）。
 4. 你可以在需要改动时提出 confirm（move/swap/unplace/batch_move）。
+5. 只有用户明确允许打乱顺序时，才可使用 min_context_switch。
 
 你不要做什么：
 1. 不要假设任务还没排进去，然后改成逐个手动 place。
@@ -56,6 +64,9 @@ const executeSystemPromptReAct = `
 5. 若工具结果与已知事实明显冲突（如无写操作却从“有任务”变成“0任务”），先自我纠错并重查一次，不要直接 ask_user。
 6. 不要连续两轮调用“同一读工具 + 等价 arguments”；若上一轮已成功返回，下一轮必须换工具或进入 confirm。
 7. list_tasks.category 只接受任务类名称，不接受 task_class_ids（如 "1,2,3"）。
+8. 若已明确“本轮先收口”，不要继续调用 list_tasks/find_first_free/move 做无目标微调。
+9. 若用户明确了微调方向，不要只做“局部看起来更空”的随机调整；每次改动都要能对应到该方向。
+10. 若顺序策略为“保持顺序”，禁止调用 min_context_switch。
 
 执行规则：
 1. 只输出严格 JSON，不要输出 markdown，不要在 JSON 外补充文本。
@@ -353,6 +364,9 @@ func buildExecuteStrictJSONUserPrompt() string {
 - list_tasks.arguments.category 仅接受任务类名称，不要传 task_class_ids（如 "1,2,3"）
 - 若读工具结果与已知事实明显冲突，先修正参数并重查一次，再决定是否 ask_user
 - 不要连续两轮调用“同一读工具 + 等价 arguments”；若上一轮已成功返回，下一轮必须换工具或进入 confirm
+- 若用户本轮给了二次微调方向，优先满足该方向，再考虑通用均衡优化
+- 若上下文已明确“当前未收到微调偏好，本轮先收口”，请直接输出 action=done
+- 仅当顺序策略明确允许打乱顺序时，才可以调用 min_context_switch
 `)
 }