帮我审查以下清单，查看是否有改进的价值
sky-ai 多任务改进清单
P0 — 必须修复（影响正确性）
1. lookup-driven plan 的订单ID传递链路不可靠
Step 1 执行后，extractOrderOutputs 依赖 LLM 返回精确 JSON，但 LLM 大概率返回自然语言。Step 2/3 因拿不到订单ID而静默失败，用户收到"未找到对应订单"却不知原因。
修复方向：Step 1 的 instruction 必须强制要求 LLM 只返回 JSON；Step 2/3 执行前检测 order_id 是否存在，不存在则终止并返回明确错误，而不是继续执行。
2. buildLookupDrivenCancelPlan 硬编码 requestedCount != 2
用户说"取消最近3个未送达订单"会静默 fall through 到单意图路径，行为完全错误且无任何提示。
修复方向：将条件改为 requestedCount < 2 || requestedCount > MAX_STEPS，支持2到3单的范围；超出范围时返回明确的澄清提示而不是静默降级。
P1 — 应该修复（影响可靠性）
3. 多步任务执行超时风险
applyStreamTimeout 统一设置30秒，但3步任务每步都有 LLM 调用加工具调用，总耗时可能超过30秒，导致整个 plan 被 timeout 打断。
修复方向：executePlan 和 continueAfterConfirmation 路径单独设置更长的超时（如90秒），或者改为每步单独计时。
4. buildMultiIntentPlan 忽略 possible_intents 的顺序语义
Prompt 要求模型按执行顺序填写 possible_intents，但代码先把主 intent 插入 LinkedHashSet，导致模型给出的执行顺序被覆盖，"先查后消"等场景会变成"先消后查"。
修复方向：当 possible_intents 存在且长度 >= 2 时，直接以它作为步骤顺序的权威来源，忽略主 intent 的插入顺序。
5. 多步任务缺少整体超时预算和步骤失败的终止策略
当前任何一步失败（LLM 返回错误、工具调用异常），continueExecution 会把错误 answer 存入 stepOutputs 然后继续执行下一步，导致后续步骤基于错误数据运行。
修复方向：每步执行后检查 answer 是否包含 FAIL: 前缀或为空，失败则立即终止 plan 并向用户说明在第几步失败、原因是什么。
P2 — 建议改进（影响体验和可维护性）
6. Prompt 中的 possible_intents 顺序语义未在代码注释中体现
RuleBasedTaskPlanner 和 ChatClientCustomerIntentRecognitionClient 之间存在隐性契约（possible_intents 代表执行顺序），但两处都没有注释说明，后续维护者很容易破坏这个约定。
修复方向：在 IntentRecognitionResult 的 possibleIntents 字段上加 Javadoc，明确说明其顺序语义。
7. extractOrderOutputs 的 JSON 解析过于乐观
该方法用 readJson 从 LLM 的自然语言回答中提取 JSON，但没有区分"LLM 确实没有返回 JSON"和"LLM 返回了但格式错误"这两种失败，都静默返回空 Map。
修复方向：增加 debug 日志记录原始 answer，方便排查；对 lookup 类型的 Step 1，解析失败时记录 warn 而非静默。
8. WebSocket handler 中 session 属性的并发安全
session.getAttributes() 在 handleQuestion 和 handleConfirmation 中直接读写，没有同步保护。虽然 WebSocket 通常是单连接单线程，但 Spring 的实现不保证，高并发场景下存在竞态。
修复方向：对 session attributes 的读写加 synchronized(session) 块，与 send 方法保持一致。
P3 — 长期优化（架构层面）
9. 任务编排目前是纯规则驱动，扩展成本高
每新增一种多步场景都要修改 RuleBasedTaskPlanner，逻辑会越来越复杂。
长期方向：考虑引入 LLM-based planner 作为补充，规则 planner 处理高频确定性场景，LLM planner 处理模糊复合场景。
10. SafeToolCallAdvisor 的去重粒度是 per-step 而非 per-plan
多步任务中每步重置 LoopState，理论上同一个工具调用可以在不同步骤中重复执行。目前逻辑上没问题，但如果未来步骤之间共享上下文，可能引入重复副作用。
长期方向：在 plan 执行层维护一个跨步骤的已执行操作记录，防止意外重复写操作。