门诊经理提的:单子分下去之后主管什么都做不了。原来只有一条绕道 ——
让客服退回池子再重新分一批,而那条路有五处漏水:退回原因被污染、回池后
不保证拿得回来、掉批次(旧批 planned 静默缩水)、福利断了、超期被洗掉。

现在:主管跟助手说一句 → 助手出一版**调整单** → 他过目微调 → 手动确认。
行为跟确认单一致,但是**独立的一条路,不碰确认单**(产品定:不要污染)。

── 数据层(最小)──────────────────────────────────────────
· plan_event_logs 加 operation_id(可空 + 索引),把同一次调整的 N 条串起来。
  ⛔ 没借用 assignment_id:那一列没有外键、塞得进,但批次报表全在它上面出数,
    两个 id 空间混一列迟早串台。
· 三个新事件 transfer / expiry_changed / rearrange_remove,都 byHuman:false。
  🔴 移出**绝不能复用 release**:批次的退回原因分布只按 assignment_id 过滤、
    不看是谁干的,复用会同时污染那张分布、并给原客服记一笔他没做过的退回。

── 落库规则 ──────────────────────────────────────────────
· assignment_id 一律不动(原批归属完整保留,分母不塌)
· 逐条落,落不上的如实回报 —— ⛔ 不照抄 create() 的「数量对不上整体拒绝」:
  主管调了二十条因为客服刚打完一条就全作废,一次就废掉这个功能
· 幂等:同一个 operationId 重复提交一个字都不写

── 批次表认得这件事 ──────────────────────────────────────
主管回收的单原来在批次表上凭空消失(既不在没动、也不在退回)。
新增「回收」一列,「退回」改叫「客服退回」,两者在列表 / 详情 / 按客服拆
三处都分开;进度那句也补上第三种来路。

── 助手 ──────────────────────────────────────────────────
三个新工具(propose_rearrange / edit_rearrange_sheet / show_rearrange),
与确认单那三件完全隔离。两条纪律写进描述:
· 出完就停,等他说怎么调 —— 把患者从一位客服手里挪走是关系层面的决定
· 他说出了要动哪些才动手;只说不满意什么的时候,那三个数是他要定的

ASSISTANT_PROMPT_VERSION → assistant@2026-08-20-f

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>