中途插话分流
当前任务的纠正进入下一模型步骤，补充请求留到后续轮次。
主 Agent 运行时，用户发来的文字可能是眼前任务的纠正，也可能是新要求。插件在原生 inbox 中保留同一条消息身份，再判断应该进入哪个时机。
接入方式
这项判断如何进入任务
原生接入点
agent/inbox/insertedagent/pre-step
- 触发
- agent/inbox/inserted 捕捉运行中的直接用户消息；在 agent/pre-step 准备入模前等待分类结果。
- 送给 Jev
- 原消息文本、附件类型、有限的已记录上下文及当前 Goal 目标；不会读取附件正文。
- 如何采用
- typed correction 进入最近的 next-step；queue 留给后续轮次。已启动工具不取消，原消息在 Session 中只交付一次。
实现依据：inbox 接入与分流 ↗
真实运行 · 原排队消息
调查顺序的纠正进入当前轮
模型正在做购物车只读调查；用户以原 queue 方式发送“先查负 quantity 的错误处理，其他稍后”。
执行与核查核对正在运行的原工具是否完整执行，以及纠正是否进入当前轮的后续模型步骤。
实际观察
原工具完整执行约 40 秒；纠正进入当前轮后续步骤，没有被原 queue 模式推迟到另一个任务。证据：六项监督与纠正：公开验收摘要 ↗
验证消息时机，不代表主模型最终调查质量已提高。
真实运行 · 原立即消息
调查之后才讲示例
另一条运行中的消息以原 steer 方式要求“调查结束后，再给初学者写 quantity 示例，不改变当前调查”。
执行与核查检查它有没有打断当前轮，何时进入模型请求。
实际观察
插件把这条补充排到下一轮，原调查工具继续。证据：六项监督与纠正：公开验收摘要 ↗双向路由测试 ↗
这是第二个方向的真实路由观察；编辑、删除和停止等窗口仍主要由自动化测试覆盖。
这些结果的边界
- 消息被模型接收不等于模型采纳。
- 上下文不足或附件内容不可见时不假装已理解消息。