feat(调整在手): 主管可以调已经分下去的单 —— 换人 / 改时限 / 收回

门诊经理提的:单子分下去之后主管什么都做不了。原来只有一条绕道 ——
让客服退回池子再重新分一批,而那条路有五处漏水:退回原因被污染、回池后
不保证拿得回来、掉批次(旧批 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>

apps/pac-service/prisma/migrations/20260820060000_add_plan_event_operation_id/migration.sql

+-- 主管重排(调整各客服在手的单)的操作记录 —— plan_event_logs.operation_id
+--
+-- 【为什么要这一列】重排**不建批次**(单子的 assignment_id 一律不动,否则原批的
+--   planned 会静默缩水 —— 见 schema.prisma 里 assignment_id 那段红字)。
+--   但"这 22 条属于同一次重排"必须记得住:审计、提交幂等、将来撤销一次重排,
+--   三条路都要按它筛。本表的规矩是「要按它筛就该立柱」。
+--
+-- 【⛔ 为什么不复用 assignment_id】那一列没有外键(裸 uuid),物理上塞得进重排 id ——
+--   但 ledgerStatsByAssignment / handledByAssignment 都在 `WHERE assignment_id IN (…)`
+--   上出数。两个 id 空间混一列,迟早串台,而且不报错。
+--
+-- 【为什么普通 CREATE INDEX 就够,不用 CONCURRENTLY】
+--   生产实测(2026-08-20)plan_event_logs 只有 2,298 行 / 1 MB —— 建索引是毫秒级,
+--   ACCESS EXCLUSIVE 锁的时间可以忽略。
+--   ⚠️ 这张表是 append-only 账本,会随分配功能铺开而增长。**将来再给它加索引时
+--     先量一遍行数**:上到百万级就必须换成 CONCURRENTLY,而 CONCURRENTLY 要求
+--     整份 migration.sql 只有一条语句(见 20260802150000 那份的说明)。
+
+-- AlterTable
+ALTER TABLE "plan_event_logs" ADD COLUMN "operation_id" UUID;
+
+-- CreateIndex
+CREATE INDEX "plan_event_logs_operation_id_idx" ON "plan_event_logs"("operation_id");

apps/pac-service/prisma/schema.prisma

@@ -1651,6 +1651,24 @@ model PlanEventLog {
    */
   assignmentId String? @map("assignment_id") @db.Uuid
 
+  /**
+   * ⭐ 这条事件属于**哪一次主管重排**(调整各客服在手的单)。
+   *
+   * ── 为什么必须立柱,而不是塞 details ──
+   * 本表的规矩是「只放**查询不按它过滤**的内容;要按它筛就该立柱」。
+   * "这次重排动了什么" / 提交幂等 / 将来撤销一次重排,三条路都要按它筛。
+   *
+   * ── 为什么⛔ 不复用 `assignment_id` ──
+   * 那一列**没有外键**(裸 uuid),物理上塞得进重排 id —— 但
+   * `ledgerStatsByAssignment` / `handledByAssignment` 都在 `WHERE assignment_id IN (…)`
+   * 上出数。两个 id 空间混一列,迟早串台,且不报错。
+   *
+   * ⚠️ 重排**不建批次**:重排事件的 `assignment_id` 仍是这条单**原来那一批**
+   *   (归属不动,批次报表的分母才不塌)。两列同时有值是正常的。
+   *   claim / view / feedback 这类非重排事件此列为 null。
+   */
+  operationId String? @map("operation_id") @db.Uuid
+
   /// 事件专属细节(不立柱的部分,如 feedback 的文字说明)。
   /// ⚠️ 只放"查询不按它过滤"的内容;要按它筛就该立柱。
   details Json?
@@ -1669,6 +1687,8 @@ model PlanEventLog {
   @@index([hostId, tenantId, event, createdAt])
   /// 批次报表主查询:某批分了几条 / 退了几条 / 到期几条(event 一起进索引,聚合不回表)
   @@index([assignmentId, event])
+  /// 一次重排动了哪些单(审计 / 幂等 / 将来撤销重排)
+  @@index([operationId])
   @@map("plan_event_logs")
 }
 

apps/pac-service/src/modules/assistant/assistant-prompts.ts

@@ -123,7 +123,7 @@ import { Permission } from '@pac/types';
  */
 // ⚠️ `-b` 是 2026-08-17 那次「纪律挂在组上」的实验，已 revert（`git show 82f357e`）——
 //   ⛔ 别复用它：库里有那一版的 `agent_invocations` 行，复用等于两份不同正文同名。
-export const ASSISTANT_PROMPT_VERSION = 'assistant@2026-08-19-a';
+export const ASSISTANT_PROMPT_VERSION = 'assistant@2026-08-20-f';
 
 /**
  * ① 装置 —— 你是谁、和使用者什么关系、你看不见什么。
@@ -318,7 +318,7 @@ const ASSIGNMENT_SCENE = `## 他现在做的这件事：把一批人分给客服
 
 ### 确认之后
 
-这批的人员和时限改不了，要改只能**撤销重分**。你对已经分下去的这批能做的只有两件：撤销、补挂福利 —— 「已撤销」只能出现在撤销工具真的返回之后。
+这批的人员和时限**不在这张单上改了** —— 单子已经在客服手上。要动它们，走**调整各客服在手的单**那条路：把他手上的摆出来，换人、改时限、移出。说成整批撤销重分，他会把已经发出去的一批全收回来，而他要的往往只是挪一两个人。在这张单上还能做的只有补挂福利；整批收回才是撤销 —— 「已撤销」只能出现在撤销工具真的返回之后。
 
 福利挂在整批上，会进这批人的话术，补挂只影响此后生成的那些。他说什么就原样写进去，⛔ 别替他加条件、期限或承诺。⛔ 「这批还没带福利」**不用你再提一遍** —— 确认之前你已经问过一次了；他回头问起，或者要补，照办就是。
 

apps/pac-service/src/modules/assistant/assistant.module.ts

@@ -15,7 +15,8 @@ import { DictationGateway } from './dictation.gateway';
  * 复用 AiModule 的 AiProviderService(provider 可切换);McpClientService 真连 PAC MCP 端点。
  */
 @Module({
-  // PlanModule:本地工具 propose_assignment 用 AssignmentProposalService 取数
+  // PlanModule:本地工具 propose_assignment 用 AssignmentProposalService 取数;
+  //            propose_rearrange 用 PlanRearrangeService + AgentRosterService(姓名→id)
   imports: [AiModule, AuthModule, PlanModule],
   // 🔬 AssistantLabController = 裸 agent 试验台，⛔ 与产品助手无代码关联（见该文件头）
   controllers: [AssistantController, AssistantLabController],

apps/pac-service/src/modules/mcp/guides.ts

@@ -24,7 +24,8 @@ export const TRACKING_GUIDE = [
   '「处理」不等于「成功」：progress 是处理率，只说「这单动过了」，不说「谈成了」。',
   '「已出池·引擎判定需求已了」是引擎按客观事实判定召回需求没了，⛔ 不是「转化成功/成交」，⛔ 不要拿这些数算转化率。',
   '报处理率必须带上「本批已跑天数」：跑了三个月的批次天然比跑了三天的好看，不带年龄直接比是耍流氓。',
-  '退回率永远给两个数：「退回 5 / 已处置 40 = 12.5%（另有 60 条未动）」——「没人动」和「动了但退回」是完全不同的信号，只报一个百分比会把前者藏起来。',
+  '退回率永远给两个数：「客服退回 5 / 已处置 40 = 12.5%（另有 60 条未动）」——「没人动」和「动了但退回」是完全不同的信号，只报一个百分比会把前者藏起来。',
+  'released（客服退回）与 recalled（主管回收）是两件事：前者是客服说这单我不接，带原因、进退回原因分布；后者是主管在调整各客服在手的单时把活收回来，没有原因。把 recalled 算进退回率，他就是在拿自己的动作当调下一批的依据。',
   '分母小于 50 时直接说「样本量不足」，⛔ 不要输出百分比、⛔ 不要画图。',
   'outcomes（通话成效）与 releaseReasons（退回原因）是两件不同的事，⛔ 绝不能混说：releaseReasons =「这单不该我做」，客服没打就还回去了，是**分配**问题；outcomes =「打了，结果这样」，客服做了事，是**召回效果**问题。说反了主管会去改错的东西。',
   'outcomes.noOutcome（一次结果都没有）必须单独报出来，⛔ 不许算进「不成功」——那不是效果差，是根本没做/没记。',

apps/pac-service/src/modules/mcp/mcp-server.factory.ts

@@ -497,7 +497,7 @@ export class McpServerFactory {
             // ⚠️ 原文第一句是「**我**分过的批次」——「我」指谁在这句里是含糊的
             //   (说话人是工具描述,读的人是模型),而下面 `mine` 恰恰就是"只看自己发起的"。
             //   一含糊就会连带 `mine` 的默认值一起被猜错。
-            '已经分下去的批次列表 + 每批汇总(分了多少 / 已处理 / 还在手 / 已退回 / 涉及几个客服)。' +
+            '已经分下去的批次列表 + 每批汇总(分了多少 / 已处理 / 还在手 / 客服退回 / 主管回收 / 涉及几个客服)。' +
             '\n他问哪批出了问题、哪批还没动静时用它。要看某批细节再用 get_assignment_detail。' +
             '\n⚠️ 返回里带 `_guide`,读数前先看它。',
           inputSchema: {

apps/pac-service/src/modules/plan/assignment-facts.ts

@@ -192,6 +192,17 @@ export function modelFacts(p: AssignmentProposal): Record<string, unknown> {
     },
     '怎么派的': {
       '已排好': p.placed,
+      /**
+       * 🔴 **点确认真正会落下去几条** —— 2026-08-20 走查加。
+       *
+       * 在此之前模型手里只有「已排好 200」和引导节点上的「300 人要您定」,
+       * 「确认会写几条」得它自己减一次。实测它没减:收尾那句写的是
+       * 「确认之后这 **500** 人的名单和 3 天时限就定死了」—— 而待分配那 300 条
+       * 主管不处理就**不落库**,确认按钮上写的也是 200。
+       * ⇒ 要它说准的数就**直接给**,⛔ 别让它做算术(同「本批人数取小的那个」那次)。
+       * ⚠️ 与卡片上确认按钮里的数**同源同值**(都是 placed),⛔ 别让两处对不上。
+       */
+      '点确认会落下去的条数': p.placed,
       '涉及客服数': agents,
       '分给自己专属客服的': dedicated,
       '给手上最空的人的': spread,

apps/pac-service/src/modules/plan/dto/plan-rearrange.dto.ts

+import { createZodDto } from 'nestjs-zod';
+import {
+  RearrangeDraftSchema,
+  RearrangeSubmitRequestSchema,
+  RearrangeSubmitResponseSchema,
+} from '@pac/types';
+
+export class RearrangeDraftDto extends createZodDto(RearrangeDraftSchema) {}
+export class RearrangeSubmitRequestDto extends createZodDto(RearrangeSubmitRequestSchema) {}
+export class RearrangeSubmitResponseDto extends createZodDto(RearrangeSubmitResponseSchema) {}

apps/pac-service/src/modules/plan/plan-assignment.service.ts

@@ -123,8 +123,10 @@ export function classifyPlanProgress(
  */
 function mergeStats(
   live: { planned: number; agents: number; released: number } | undefined,
-  ledger: { planned: number; agents: number; released: number; expired: number; revoked: number } | undefined,
-): { planned: number; agents: number; released: number; expired: number } {
+  ledger:
+    | { planned: number; agents: number; released: number; recalled: number; expired: number; revoked: number }
+    | undefined,
+): { planned: number; agents: number; released: number; recalled: number; expired: number } {
   const l = live ?? { planned: 0, agents: 0, released: 0 };
   const legacy = !ledger || ledger.planned === 0;
   return {
@@ -132,6 +134,13 @@ function mergeStats(
     agents: legacy ? l.agents : ledger.agents,
     released: legacy ? l.released : ledger.released,
     /**
+     * ⚠️ 主管回收**只有账本口径**,老批次(账本没记批次号)一律 0 ——
+     *   ⛔ 别去 followup_plans 上现算:那边只看得到"现在不在人手上",
+     *   分不出是客服退回、到期、还是主管收回的,猜一个数比缺一个数更糟。
+     * ⚠️ 老批次天然为 0 也是对的:调整这条路 2026-08-20 才有,更早的批次不可能有回收。
+     */
+    recalled: ledger?.recalled ?? 0,
+    /**
      * ⚠️ 超期**不跟着 legacy 回落**（2026-08-19）：它现在只有一个来源 ——
      *   **此刻仍挂在人手上且已过时限**（现算），而那一支对新老批次一样成立。
      *   ⛔ 别让它跟着 `legacy` 归零：老批次照样可能有单还压在人手上。
@@ -526,7 +535,17 @@ export class PlanAssignmentService {
    *   但显示一个偏小的数,总好过显示 0 让主管以为这批没分成。
    */
   private async ledgerStatsByAssignment(ids: string[]): Promise<
-    Map<string, { planned: number; agents: number; released: number; expired: number; revoked: number }>
+    Map<
+      string,
+      {
+        planned: number;
+        agents: number;
+        released: number;
+        recalled: number;
+        expired: number;
+        revoked: number;
+      }
+    >
   > {
     if (ids.length === 0) return new Map();
     /**
@@ -540,12 +559,26 @@ export class PlanAssignmentService {
      *   注释里的反引号会把模板提前截断,而报错指向的是几行之后的地方(踩过)。
      */
     const rows = await this.prisma.$queryRaw<
-      Array<{ assignment_id: string; planned: bigint; agents: bigint; released: bigint; revoked: bigint }>
+      Array<{
+        assignment_id: string;
+        planned: bigint;
+        agents: bigint;
+        released: bigint;
+        recalled: bigint;
+        revoked: bigint;
+      }>
     >(Prisma.sql`
       SELECT assignment_id,
              count(DISTINCT patient_id)        FILTER (WHERE event = 'assign')        AS planned,
-             count(DISTINCT assignee_user_id)  FILTER (WHERE event = 'assign')        AS agents,
+             -- ⚠️ 并上 transfer:主管重排把一条换给别人之后,**接手人也经手了这一批**。
+             --   只数 assign 的话,批次上写着「涉及 3 人」而实际有 4 个人碰过这些单,
+             --   而且不会有任何报错(重排不改 assignment_id,那些单仍算这一批)。
+             -- ⛔ planned 不并 —— 它按 patient 去重,同一患者被转手不该多算一条。
+             count(DISTINCT assignee_user_id)  FILTER (WHERE event IN ('assign','transfer')) AS agents,
              count(DISTINCT plan_id)           FILTER (WHERE event = 'release')       AS released,
+             -- 主管在调整单里收回池子的 —— ⛔ 与 released 分开:那是客服不接,这是主管收活。
+             --   混在一起会把主管自己的调度算进退回原因分布,而他正是靠那张分布决定下一批。
+             count(DISTINCT plan_id)           FILTER (WHERE event = 'rearrange_remove') AS recalled,
              count(DISTINCT plan_id)           FILTER (WHERE event = 'auto_release'
                                                         AND reason = ${PlanEventReason.REVOKED})            AS revoked
       FROM plan_event_logs
@@ -574,6 +607,7 @@ export class PlanAssignmentService {
         r.assignment_id,
         {
           planned: Number(r.planned), agents: Number(r.agents), released: Number(r.released),
+          recalled: Number(r.recalled),
           // ⚠️ 只认「此刻挂在人手上且过了时限」这一支(理由见上面那段) ——
           //   ⛔ 别再并上账本里的 auto_release:那些单已经回池、没有客服挂着,不是谁的超期。
           expired: nowMap.get(r.assignment_id) ?? 0,
@@ -1185,7 +1219,9 @@ export class PlanAssignmentService {
      */
     const batchEvents = await this.prisma.planEventLog.findMany({
       where: { assignmentId: id, tenantId: scope.tenantId },
-      select: { planId: true, assigneeUserId: true, event: true, reason: true },
+      // ⚠️ `details` 要选出来:主管回收记的是「从谁手上收的」(details.from),
+      //   而事件本身的 assigneeUserId 是 null(收回之后无人归属)。
+      select: { planId: true, assigneeUserId: true, event: true, reason: true, details: true },
       orderBy: { createdAt: 'desc' },
     });
     const assignEvents = batchEvents.length
@@ -1229,7 +1265,7 @@ export class PlanAssignmentService {
     const touch = (key: string): AssignmentAgentStat => {
       let a = byAgent.get(key);
       if (!a) {
-        a = { userId: key, name: null, planned: 0, inHand: 0, released: 0, overdue: 0, done: 0 };
+        a = { userId: key, name: null, planned: 0, inHand: 0, released: 0, recalled: 0, overdue: 0, done: 0 };
         byAgent.set(key, a);
       }
       return a;
@@ -1252,6 +1288,19 @@ export class PlanAssignmentService {
         touch(originalOwner.get(e.planId) ?? RELEASED_BUCKET).released++;
         if (e.reason) reasonCount.set(e.reason, (reasonCount.get(e.reason) ?? 0) + 1);
       }
+      /**
+       * 主管回收 —— 归到**被收的那个人**头上(`details.from`),⛔ 不是原始承接人:
+       * 一条单可能先被转手、再被收回,那时候"从谁手上收的"跟"当初分给谁"不是一个人。
+       * ⚠️ ⛔ 不进 `reasonCount`:退回原因分布只回答「客服为什么不接这单」,
+       *   把主管自己的调度混进去,他就是在拿自己的动作当决策依据。
+       */
+      const seenRecall = new Set<string>();
+      for (const e of batchEvents) {
+        if (e.event !== PlanEventType.REARRANGE_REMOVE || seenRecall.has(e.planId)) continue;
+        seenRecall.add(e.planId);
+        const from = (e.details as { from?: string } | null)?.from;
+        touch(from ?? originalOwner.get(e.planId) ?? RELEASED_BUCKET).recalled++;
+      }
     }
 
     for (const p of plans) {
@@ -1354,8 +1403,16 @@ export class PlanAssignmentService {
         (bucket.suppressed ? `,${bucket.suppressed} 条客服写了回访结果(约下次/拒绝/放弃)` : '') +
         `;还在客服手上未处理 ${bucket.inHandPending} 条,落回池子 ${bucket.backToPool} 条` +
         // 退回与到期必须分开说 —— 主管的下一步动作相反(改分配策略 vs 派多了/时限太紧)
-        (counts.released || counts.expired
-          ? `(其中客服主动退回 ${counts.released} 条、到期没人动 ${counts.expired} 条)`
+        /**
+         * ⚠️ 「落回池子」这一桶里现在有**三种来路**,只报两种主管会自己去凑第三种:
+         *   客服主动退回 / 到期没人动 / **主管在调整单里收回**。
+         *   少报第三种时他看到的是「落回池子 12 条(其中退回 3、到期 0)」——
+         *   剩下 9 条没有出处,而那 9 条正是他自己收回来的。
+         */
+        (counts.released || counts.expired || counts.recalled
+          ? `(其中客服主动退回 ${counts.released} 条、到期没人动 ${counts.expired} 条` +
+            (counts.recalled ? `、你自己在调整时收回 ${counts.recalled} 条` : '') +
+            `)`
           : '') +
         `。` +
         (reassigned ? `另有 ${reassigned} 人已被后面的批次挑走,他们之后的表现算在那一批上。` : '') +
@@ -1470,6 +1527,7 @@ export class PlanAssignmentService {
       //   ⛔ 别改回 `plans.length` —— 那是"现在还归本批的人",会随重分失血(见 mergeStats)。
       planned: counts.planned,
       released: counts.released,
+      recalled: counts.recalled,
       expired: counts.expired,
       agents: counts.agents,
       progress,

apps/pac-service/src/modules/plan/plan-event.recorder.ts

@@ -58,6 +58,7 @@ export function recordPlanEventsBulk(
       heldSeconds: input.heldSeconds ?? null,
       reason: input.reason ?? null,
       assignmentId: input.assignmentId ?? null,
+      operationId: input.operationId ?? null,
       details: input.details ?? undefined,
     })),
   });
@@ -89,6 +90,14 @@ export interface PlanEventInput {
    *   可能是上一批留下的陈迹(退回/到期都刻意不清它),顶上去等于给旧批次凭空加人。
    */
   assignmentId?: string | null;
+  /**
+   * 这条事件属于**哪一次主管重排**(见 schema 里 `operation_id` 的说明)。
+   *
+   * ⚠️ 只有重排三件事该传:transfer / expiry_changed / rearrange_remove。
+   * ⚠️ 与 `assignmentId` **不互斥**:重排不改归属批次,所以重排事件两列都有值 ——
+   *   assignmentId 是这条单**原来那一批**,operationId 是这次重排。
+   */
+  operationId?: string | null;
   /** 事件专属细节(不按它查询的内容,如反馈文字) */
   details?: Prisma.InputJsonObject | null;
 }
@@ -106,6 +115,7 @@ export function recordPlanEvent(tx: PlanEventLogWriter, input: PlanEventInput):
       heldSeconds: input.heldSeconds ?? null,
       reason: input.reason ?? null,
       assignmentId: input.assignmentId ?? null,
+      operationId: input.operationId ?? null,
       // undefined 才让 Prisma 落 NULL;传 null 会被当成 JSON null 值
       details: input.details ?? undefined,
     },

apps/pac-service/src/modules/plan/plan.module.ts

@@ -2,6 +2,8 @@ import { Module } from '@nestjs/common';
 import { PlanController } from './plan.controller';
 import { PlanService } from './plan.service';
 import { AssignmentController } from './assignment.controller';
+import { RearrangeController } from './rearrange.controller';
+import { PlanRearrangeService } from './plan-rearrange.service';
 import { PlanAssignmentService } from './plan-assignment.service';
 import { AgentRosterService } from './agent-roster.service';
 import { AssignmentProposalService } from './assignment-proposal.service';
@@ -50,10 +52,14 @@ import { RecallDebugService } from './recall-debug/recall-debug.service';
   //   `GET /plans/:id`(id='assignments'),然后去查一个不存在的 plan,
   //   报的还是 Prisma 的 uuid 解析错(90000),完全看不出是路由撞了。
   //   实测踩过一次。同类先例见 plan.controller:80 的 `doctors` 那条注释。
-  controllers: [AssignmentController, PlanController, RecallDebugController],
+  // ⚠️ 顺序有意义:RearrangeController / AssignmentController 必须排在 PlanController
+  //   **之前** —— 后者挂在 `plans` 上且有裸 `@Get(':id')`,Nest 按注册顺序匹配,
+  //   排在它后面的话 `/plans/rearrange` 会被当成 planId='rearrange'(实测踩过)。
+  controllers: [RearrangeController, AssignmentController, PlanController, RecallDebugController],
   providers: [
     PlanService,
     PlanAssignmentService,
+    PlanRearrangeService,
     AgentRosterService,
     AssignmentProposalService,
     CohortAttributesService,
@@ -67,6 +73,6 @@ import { RecallDebugService } from './recall-debug/recall-debug.service';
     PlanLabelService,
   ],
   // MCP 的主管工具直接用这两个 service(条件注册,见 mcp-server.factory)
-  exports: [PlanService, PlanLabelService, PlanAssignmentService, AgentRosterService, AssignmentProposalService, CohortAttributesService, ExecutionService, ExecutionCallbackService, PlanEngineService, ChainComposerService],
+  exports: [PlanService, PlanLabelService, PlanAssignmentService, PlanRearrangeService, AgentRosterService, AssignmentProposalService, CohortAttributesService, ExecutionService, ExecutionCallbackService, PlanEngineService, ChainComposerService],
 })
 export class PlanModule {}

apps/pac-service/src/modules/plan/rearrange-facts.ts

+import type { RearrangeDraft, RearrangeSubmitResponse } from '@pac/types';
+
+/**
+ * rearrange-facts —— 把一版调整单投影成**给模型的结构化事实**。
+ *
+ * ⚠️ 纪律与 `assignment-facts` 完全一致,⛔ 别在这儿放宽:
+ *   ⛔ **一个字的指令都不许有**（「请照抄」「不要说成…」之类）。事实归事实,规范归提示词。
+ *   ⛔ 不含 planId / 患者姓名 —— 那些走侧信道给界面,模型手里不该有。
+ *      (客服姓名可以给:模型要用它组织「谁手上多少」这句话,确认单那边同样给。)
+ *   ⚠️ 键名用中文:模型照着键名说就是对的。
+ *
+ * ⛔ 这里**不给成品句子**。唯一的例外是 `没落上的` 那一句 —— 它来自服务端的
+ *   `summarizeSkipped`,口径必须与界面完全一致(两边各拼一份必然对不上)。
+ */
+
+/** 出一版调整单之后回给模型的事实 */
+export function rearrangeFacts(d: RearrangeDraft): Record<string, unknown> {
+  const perAgent = d.agents
+    .filter((a) => a.inHand > 0)
+    .sort((x, y) => y.inHand - x.inHand)
+    .map((a) => ({
+      客服: a.name ?? '未知客服',
+      在手: a.inHand,
+      已超期: a.overdue,
+      // 「这些大概要打几天」—— 与确认单同一把换算尺(每人每天几通)
+      约几天的量: Math.ceil(a.inHand / d.dailyCalls),
+    }));
+
+  return {
+    调整单已呈现: true,
+    这一版是: {
+      范围:
+        d.scope === 'all'
+          ? '这家诊所全部客服此刻在手的单'
+          : `点名的 ${d.scopedAgentUserIds.length} 位客服此刻在手的单`,
+      // ⚠️ 事实,不是指令:告诉它这一版**没被动过**,免得它顺口说成"我已经排好了"
+      内容: '原样 —— 谁手上什么样就摆成什么样,没有做过任何调整',
+      在手合计: d.total,
+      其中已超期: d.overdueTotal,
+      涉及客服: perAgent.length,
+      换算尺: `每人每天 ${d.dailyCalls} 通`,
+    },
+    每位客服: perAgent,
+    // 只在真的截断时出现 —— ⛔ 静默截断等于让主管以为"这就是全部"
+    ...(d.truncated > 0
+      ? {
+          没装下的: {
+            条数: d.truncated,
+            原因: '单次调整最多装 500 条,超出的这一版没有列进来',
+          },
+        }
+      : {}),
+    他可以让你做的事: ['把某几位患者换给别的客服', '改某几条的时限', '把某几条移出(收回池子)'],
+    这一步不写数据: true,
+    要生效得他在调整单上点确认: true,
+  };
+}
+
+/** 界面把调整提交完之后,回报给模型的事实(界面自己发进对话,这里是备用投影) */
+export function rearrangeResultFacts(r: RearrangeSubmitResponse): Record<string, unknown> {
+  return {
+    调整已生效: !r.duplicate,
+    重复提交: r.duplicate,
+    改派: r.moved,
+    改时限: r.expiryChanged,
+    移出: r.removed,
+    没落上的条数: r.skipped.length,
+    // ⚠️ 成品句子,口径与界面同源(服务端 summarizeSkipped)——⛔ 别让模型自己归并原因
+    没落上的: r.note,
+  };
+}

apps/pac-service/src/modules/plan/rearrange.controller.ts

+import { Body, Controller, Get, Post, Query } from '@nestjs/common';
+import { ApiBearerAuth, ApiOperation, ApiTags } from '@nestjs/swagger';
+import { ZodResponse } from 'nestjs-zod';
+import { Permission } from '@pac/types';
+import { RequirePermission } from '../../common/decorators/permissions.decorator';
+import { TenantScope } from '../../common/decorators/tenant-scope.decorator';
+import type { TenantScopeContext } from '../../common/decorators/tenant-scope.decorator';
+import { resolveClinicId } from '../../common/decorators/resolve-clinic-id';
+import { CurrentUser } from '../../common/decorators/current-user.decorator';
+import type { AuthenticatedUser } from '../../common/decorators/current-user.decorator';
+import { PlanRearrangeService } from './plan-rearrange.service';
+import { RearrangeDraftDto, RearrangeSubmitRequestDto, RearrangeSubmitResponseDto } from './dto/plan-rearrange.dto';
+
+/**
+ * 主管调整端点 —— 调整各客服此刻在手的单。
+ *
+ * ⚠️ **本控制器必须注册在 `PlanController` 之前**(见 plan.module 的 controllers 数组)。
+ *   `PlanController` 挂在 `plans` 上且有一个裸 `@Get(':id')`,Nest 按注册顺序匹配 ——
+ *   排在它后面的话 `GET /plans/rearrange` 这类单段路径会被当成 planId='rearrange',
+ *   报出来是 Prisma 的 uuid 解析错,看不出是路由问题(AssignmentController 实测踩过)。
+ *
+ * ⛔ 刻意**不复用** `plans/assignments` 前缀:调整不建批次、不属于任何一次分配,
+ *   挂进去会让"这是分配的一部分"这个错觉在路由上就成立。
+ */
+@ApiTags('plan-rearrange')
+@ApiBearerAuth('accessToken')
+@Controller('plans/rearrange')
+export class RearrangeController {
+  constructor(private readonly rearrange: PlanRearrangeService) {}
+
+  @Get('draft')
+  @RequirePermission(Permission.PLAN_DISPATCH)
+  @ZodResponse({ status: 200, type: RearrangeDraftDto })
+  @ApiOperation({
+    summary: '取一版可编辑的在手快照 —— 不传 agents = 全景(全队),传了 = 只调这几位',
+    description:
+      '⛔ 不写任何数据。`operationId` 由服务端铸造,提交时原样回传做幂等键。' +
+      '人员集合走客服名册(与分配、团队状态同源)—— 名册外的人手上的单本期不管。',
+  })
+  async draft(
+    @TenantScope() scope: TenantScopeContext,
+    @Query('clinicId') clinicId?: string,
+    /// 逗号分隔的客服 userId;不传 = 全队
+    @Query('agents') agents?: string,
+  ) {
+    return this.rearrange.draft(
+      scope,
+      // 🔴 越权闸:这条路会吐**患者姓名**,收了 clinicId 就必须过闸(纪律见 assignment.controller)
+      resolveClinicId(scope, clinicId),
+      agents
+        ? agents
+            .split(',')
+            .map((s) => s.trim())
+            .filter(Boolean)
+        : undefined,
+    );
+  }
+
+  @Post()
+  @RequirePermission(Permission.PLAN_DISPATCH)
+  @ZodResponse({ status: 200, type: RearrangeSubmitResponseDto })
+  @ApiOperation({
+    summary: '确认调整 —— 主管在调整单上点确认时调用(这条路唯一的写动作)',
+    description:
+      '幂等:同一个 operationId 重复提交返回 duplicate:true,一个字都不写。' +
+      '**逐条落**,落不上的(客服刚打完 / 已退回 / 被重算取代)逐条在 skipped 里说明;' +
+      '⛔ 不是"数量对不上整体拒绝"。',
+  })
+  async submit(
+    @TenantScope() scope: TenantScopeContext,
+    @CurrentUser() user: AuthenticatedUser,
+    @Body() dto: RearrangeSubmitRequestDto,
+  ) {
+    return this.rearrange.submit(scope, { userId: user.sub, permissions: user.permissions }, dto);
+  }
+}

apps/pac-service/tests/mcp-clinic-scope.spec.ts

@@ -457,11 +457,27 @@ describe('确认后没配福利 → 提醒补挂,但不许编效果', () => {
    *   锁整句等于把"这条规矩必须写成一句话"也锁了进去。
    * ⇒ 锁的是**这一步在、且三条不变量都在**。
    */
-  test('提示词里要说清"确认后仍可补挂、但人员时限改不了"', () => {
+  test('提示词里要说清"确认后仍可补挂、人员时限走调整那条路"', () => {
     expect(PROMPTS).toMatch(/### 确认之后/);
     expect(PROMPTS).toMatch(/补挂/);
-    expect(PROMPTS).toMatch(/人员和时限改不了/);
-    expect(PROMPTS).toMatch(/撤销重分/);
+    /**
+     * 🔴 **2026-08-20:人员和时限不再是"改不了"。**
+     *
+     * 这条断言原来钉的是「人员和时限改不了」+「撤销重分」—— 那是「调整各客服在手的单」
+     * 上线之前的事实。走查里模型照着这两句对主管说了「确认之后这 500 人的名单和 3 天时限
+     * 就定死了,要改只能整批撤销重分」,而那时候调整那条路已经能走了。
+     * ⇒ 断言跟着事实走,⛔ 不是把测试删掉了事:它守的是"确认之后到底能做什么"这件事
+     *   在提示词里必须写清楚,这个意图没变。
+     */
+    expect(PROMPTS).toMatch(/不在这张单上改了/);
+    expect(PROMPTS).toMatch(/调整各客服在手的单/);
+    /**
+     * ⚠️ 旧说法必须**被写清后果**,⛔ 不能只是删掉、也⛔ 不是写一句禁令。
+     *   删掉之后模型仍可能凭上一版的印象说出来(它见过太多"撤销重分"的语料);
+     *   而光禁止扶不住它 —— 得说清照那句做会发生什么(他把整批收回来,
+     *   可他要的往往只是挪一两个人)。所以这里查的是那句**后果**在不在。
+     */
+    expect(PROMPTS).toMatch(/说成整批撤销重分，他会把已经发出去的一批全收回来/);
   });
 });
 
@@ -677,10 +693,20 @@ describe('待分配的人 —— 对话指令要能指到', () => {
   });
 
   test('⭐ 姓名可点击复制,且⛔ 不能吃掉整行的拖拽', () => {
-    expect(SHEET).toMatch(/function CopyableName/);
-    expect(SHEET).toMatch(/draggable=\{false\}/); // 不加会被当成拖文本
-    expect(SHEET).toMatch(/e\.stopPropagation\(\)/);
-    // 两处行都要用上:客服组里的 + 待分配里的
+    /**
+     * 🔴 2026-08-20 `CopyableName` / `DaySelect` 挪进了 `sheet-primitives.tsx` ——
+     *   重排单要跟确认单**手感一致**(产品:「不用二次学习成本」),而这两个原件身上
+     *   那点来之不易的行为(懒挂 Radix、复制反馈、`draggable={false}`)抄成两份必然漂。
+     * ⇒ 行为断言跟着挪到那个文件上;确认单这边仍然要断言**用上了**它。
+     */
+    const PRIM = readFileSync(
+      join(__dirname, '../../pac-web/src/components/assistant/sheet-primitives.tsx'),
+      'utf8',
+    );
+    expect(PRIM).toMatch(/export function CopyableName/);
+    expect(PRIM).toMatch(/draggable=\{false\}/); // 不加会被当成拖文本
+    expect(PRIM).toMatch(/e\.stopPropagation\(\)/);
+    expect(SHEET).toMatch(/import \{ CopyableName, DaySelect \} from '\.\/sheet-primitives'/);
     // 三处都要用上:客服组标题 + 客服组里的患者 + 待分配里的患者
     expect((SHEET.match(/<CopyableName /g) ?? []).length).toBeGreaterThanOrEqual(3);
   });

apps/pac-service/tests/plan-event-log.spec.ts

@@ -162,6 +162,34 @@ describe('PlanEventType / PLAN_EVENT_META — 扩展性约束', () => {
     expect(PLAN_EVENT_META.release.holdsPatient).toBe(false);
     expect(PLAN_EVENT_META.auto_release.holdsPatient).toBe(false);
   });
+
+  // ── 主管重排(调整各客服在手的单)—— 2026-08-20 ──────────────────
+  test('⭐⭐ 重排三件事都不算「客服处理过」—— 是主管在调度,不是有人跟进了患者', () => {
+    for (const t of [
+      PlanEventType.TRANSFER,
+      PlanEventType.EXPIRY_CHANGED,
+      PlanEventType.REARRANGE_REMOVE,
+    ]) {
+      expect(PLAN_EVENT_META[t].byHuman).toBe(false);
+      expect(HUMAN_TOUCH_EVENTS).not.toContain(t);
+    }
+  });
+
+  test('⭐ 改派/改时限之后单子还在人手上,移出之后不在', () => {
+    expect(PLAN_EVENT_META.transfer.holdsPatient).toBe(true);
+    expect(PLAN_EVENT_META.expiry_changed.holdsPatient).toBe(true);
+    expect(PLAN_EVENT_META.rearrange_remove.holdsPatient).toBe(false);
+  });
+
+  test('⭐⭐ 重排移出**不是** release —— 复用会污染批次的退回原因分布', () => {
+    // 批次详情按 `event === 'release'` 聚合退回原因,且**只按 assignment_id 过滤、
+    // 不看是谁干的**(plan-assignment.service 的 detail())。重排移出若挂 release:
+    //   ① 会进那一批的退回原因分布(污染主管调下一批的输入);
+    //   ② 会给**原客服**记一笔「退回」—— 他没退,是主管收走的。
+    // 两个错都不抛异常,所以在这里钉死。
+    expect(PlanEventType.REARRANGE_REMOVE).not.toBe(PlanEventType.RELEASE);
+    expect(PLAN_EVENT_META.rearrange_remove.labelZh).not.toBe(PLAN_EVENT_META.release.labelZh);
+  });
 });
 
 describe('computeHeldSeconds — 必须在清空 assignedAt 前算', () => {

apps/pac-web/src/components/assistant/assignment-confirm-sheet.tsx

@@ -3,7 +3,6 @@
 import { useCallback, useEffect, useMemo, useRef, useState } from 'react';
 import { Check, ChevronDown, ChevronRight, GripVertical, Loader2, Undo2, Users, X } from 'lucide-react';
 import {
-  ASSIGNMENT_EXPIRES_DAYS_PRESETS,
   potentialTreatmentItemName,
   AssignStrategy,
   REVOKE_WINDOW_MINUTES,
@@ -27,13 +26,6 @@ import { ConfirmSheetSignals } from './confirm-sheet-signals';
 import { BenefitPopover } from './benefit-popover';
 import { Card, CardContent } from '@/components/ui/card';
 import {
-  Select,
-  SelectContent,
-  SelectItem,
-  SelectTrigger,
-  SelectValue,
-} from '@/components/ui/select';
-import {
   AlertDialog,
   AlertDialogAction,
   AlertDialogCancel,
@@ -43,6 +35,7 @@ import {
   AlertDialogHeader,
   AlertDialogTitle,
 } from '@/components/ui/alert-dialog';
+import { CopyableName, DaySelect } from './sheet-primitives';
 import { cn, formatGender } from '@/lib/utils';
 
 /**
@@ -97,40 +90,6 @@ const OP_ZH: Record<SheetEditOp['action'], string> = {
 };
 
 /**
- * 患者姓名 —— **点一下复制**(2026-08-06 产品加)。
- *
- * ⚠️ 主管审这批人时常要把名字贴到别处(问医生、查宿主档案、发消息),
- *   在一个 480px 的列表里手动选中一个中文名很难选准。
- * ⚠️ `stopPropagation` 是必须的:这一行同时是**折叠开关的兄弟**且整行可拖,
- *   不拦住会连带触发别的行为。
- * ⚠️ `draggable={false}`:不加的话按住名字拖会被浏览器当成拖文本,把整行的拖拽吃掉。
- * ⛔ 复制的是**姓名本身**,不含病历号/性别年龄 —— 那些是给眼睛看的上下文,
- *   粘出去多带一串反而要手动删。
- */
-function CopyableName({ name }: { name: string }) {
-  const [copied, setCopied] = useState(false);
-  return (
-    <button
-      type="button"
-      draggable={false}
-      title="点击复制姓名"
-      onClick={(e) => {
-        e.stopPropagation();
-        void navigator.clipboard?.writeText(name);
-        setCopied(true);
-        setTimeout(() => setCopied(false), 1200);
-      }}
-      className={cn(
-        'rounded px-0.5 transition-colors',
-        copied ? 'bg-emerald-50 text-emerald-700' : 'hover:bg-brand-50 hover:text-brand-700',
-      )}
-    >
-      {copied ? '已复制' : name}
-    </button>
-  );
-}
-
-/**
  * 服务端成品句子里的 `**加粗**` —— 只认这一个标记,⛔ 不引 Markdown 渲染器。
  *
  * ⚠️ 这些句子是**服务端拼好的**(basisNote / refillNote),里面混着患者和客服姓名。
@@ -161,80 +120,6 @@ function carryOverrides(fromSheet: Record<string, AgentOverride>): Record<string
   return out;
 }
 
-/**
- * 时限选择 —— 1~7 天。用 shadcn `Select`(Radix),不用原生 `<select>`:
- * 原生下拉在深色/窄屏下样式不可控,而这个控件现在**每一条召回计划都有一个**,
- * 出现几百次,样式必须跟卡片其余部分一致。
- * ⚠️ 值域来自 `ASSIGNMENT_EXPIRES_DAYS_PRESETS`(共享常量),⛔ 别在这里内联 [1..7]。
- */
-/**
- * 时限下拉 —— **点了才挂真正的 Radix Select**。
- *
- * 🔴 由来(2026-08-05 实测):原来每一行直接渲染一个 `<Select>`。展开一个 36 条的客服组
- *   = 一次性挂 36 个 Radix Select,每个都带 portal / 焦点管理 / 键盘导航,
- *   展开那一下明显卡顿。而这些下拉**绝大多数根本不会被点** —— 主管一批 200 人,
- *   真正逐条改时限的是个位数。
- *
- * ✅ 平时只是一个 `<button>`(样式与 SelectTrigger 一致),点击才换成真 Select 并自动展开。
- * ⚠️ `defaultOpen` 是关键:换过去之后要立刻弹开,否则用户得点两下。
- * ⚠️ 收起后**不还原成按钮** —— 还原会让"刚改完又想再改"变成再等一次挂载,
- *   而且已经挂上的那一个不再是成本问题(卡的是 36 个同时挂)。
- */
-function DaySelect({
-  value,
-  disabled,
-  onChange,
-  compact,
-}: {
-  value: number;
-  disabled?: boolean;
-  onChange: (days: number) => void;
-  /** 条目行用紧凑版(只显示数字,省掉"天"字省宽度) */
-  compact?: boolean;
-}) {
-  const [live, setLive] = useState(false);
-  const cls = cn('h-6 gap-1 px-1.5 text-[11px]', compact ? 'w-[54px]' : 'w-[76px]');
-
-  if (!live) {
-    return (
-      <button
-        type="button"
-        disabled={disabled}
-        onClick={() => setLive(true)}
-        // 样式与 SelectTrigger 对齐 —— 换过去时不许有跳动
-        className={cn(
-          cls,
-          'inline-flex items-center justify-between rounded-md border border-input bg-transparent',
-          'shadow-xs transition-colors hover:bg-accent/50 disabled:cursor-not-allowed disabled:opacity-50',
-        )}
-      >
-        <span>{compact ? value : `${value} 天`}</span>
-        <ChevronDown className="h-3 w-3 opacity-50" />
-      </button>
-    );
-  }
-
-  return (
-    <Select
-      value={String(value)}
-      disabled={disabled}
-      defaultOpen
-      onValueChange={(v) => onChange(Number(v))}
-    >
-      <SelectTrigger className={cls}>
-        <SelectValue />
-      </SelectTrigger>
-      {/* z 层级已在 ui/select.tsx 统一抬到 70(助手窗是 z-60,见那里的层级约定) */}
-      <SelectContent>
-        {ASSIGNMENT_EXPIRES_DAYS_PRESETS.map((d) => (
-          <SelectItem key={d} value={String(d)} className="text-[12px]">
-            {d} 天
-          </SelectItem>
-        ))}
-      </SelectContent>
-    </Select>
-  );
-}
 
 export function AssignmentConfirmSheet({
   requestId,
@@ -806,7 +691,9 @@ export function AssignmentConfirmSheet({
 
     const notes: string[] = [];
     // ⭐ 已确认 = 卡片进入只读态。此时唯一还能改的是**福利**(它是前向的,只影响之后生成的话术),
-    //   而且必须走接口真写库;人员 / 时限那些动的是已经发到客服手上的单,只能走撤销重分。
+    //   而且必须走接口真写库;人员 / 时限那些动的是已经发到客服手上的单 ——
+    //   ⚠️ 2026-08-20 起它们**不是没辙了**:走「调整各客服在手的单」那条路(独立的一张单)。
+    //   ⛔ 别再把话说成「只能撤销重分」,那句从这天起就是错的。
     if (assignmentId) {
       for (const { ops } of fresh) {
         for (const op of ops) {
@@ -828,8 +715,9 @@ export function AssignmentConfirmSheet({
             continue;
           }
           notes.push(
-            `这批**已经确认分配**了,「${OP_ZH[op.action] ?? op.action}」改不了 —— ` +
-              `单子已经在客服手上。要调整请撤销这批重新分(限 30 分钟),或让客服自己退回`,
+            `这批**已经确认分配**了,「${OP_ZH[op.action] ?? op.action}」在这张单上改不了 —— ` +
+              `单子已经在客服手上 —— 让我把在手的摆出来调(换人、改时限、移出),` +
+              `或者撤销整批重新分`,
           );
         }
       }

apps/pac-web/src/components/assistant/chat-blocks.test.ts

 import { describe, expect, it } from 'vitest';
-import type { AssignmentProposal } from '@pac/types';
+import type { AssignmentProposal, RearrangeDraft } from '@pac/types';
 import {
+  applyIncomingRearrange,
   applyIncomingSheet,
+  findActiveRearrange,
   findActiveSheet,
   intentToPrompt,
   intentToSheetOps,
@@ -291,7 +293,7 @@ describe('stripToolEcho · 抄出来的工具记录', () => {
 /**
  * 🔴 位置标记不进历史 —— 2026-08-13 实测的回归。
  *
- * 主管点「只选…」重排，第二轮只跑了 1 步：`propose_assignment` 调了，
+ * 主管点「只选…」调整，第二轮只跑了 1 步：`propose_assignment` 调了，
  * `show_sheet` / `show_guidance` 一个都没调 —— 卡片掉到末尾、按钮全堆在卡上。
  * 原因之一是上一轮的记录还在上下文里，「已插入选项按钮」被读成"已经摆过了"。
  * ⚠️ 这条锁的是**别让位置标记回传**；⛔ 真做了事的工具必须留（否则模型会重复调）。
@@ -377,3 +379,133 @@ describe('历史回传 · 结构化（唯一路径）', () => {
   });
 });
 
+
+// ═════════════════════════════════════════════════════════
+// 调整单 —— 与确认单**各走各的**,这一组专门锁住"别互相作废"
+// ═════════════════════════════════════════════════════════
+
+const rdraft = (n: number) => ({ total: n } as unknown as RearrangeDraft);
+
+function rmsg(id: string, ...sheets: Array<[string, DraftState]>): ChatMessage {
+  return {
+    id,
+    role: 'assistant',
+    blocks: sheets.map(([operationId, state]): Block => ({
+      kind: 'rearrange_sheet',
+      operationId,
+      sheet: rdraft(1),
+      state,
+    })),
+  };
+}
+
+function rstates(ms: ChatMessage[]): Array<[string, DraftState]> {
+  return ms.flatMap((m) =>
+    m.blocks
+      .filter((b): b is Extract<Block, { kind: 'rearrange_sheet' }> => b.kind === 'rearrange_sheet')
+      .map((b) => [b.operationId, b.state] as [string, DraftState]),
+  );
+}
+
+describe('applyIncomingRearrange', () => {
+  it('第一版挂到宿主消息下,状态 active', () => {
+    const out = applyIncomingRearrange([rmsg('m1')], {
+      operationId: 'o1',
+      sheet: rdraft(10),
+      hostMessageId: 'm1',
+    });
+    expect(rstates(out)).toEqual([['o1', 'active']]);
+  });
+
+  it('🔴 新的一版到达时,把**上一轮消息里**的 active 作废(跨消息扫描)', () => {
+    const out = applyIncomingRearrange([rmsg('m1', ['o1', 'active']), rmsg('m2')], {
+      operationId: 'o2',
+      sheet: rdraft(2),
+      hostMessageId: 'm2',
+    });
+    expect(rstates(out)).toEqual([
+      ['o1', 'superseded'],
+      ['o2', 'active'],
+    ]);
+  });
+
+  it('同 id 重推 = 换内容并清空 edits(旧指令对新名单没有意义)', () => {
+    const prev: ChatMessage[] = [
+      {
+        id: 'm1',
+        role: 'assistant',
+        blocks: [
+          {
+            kind: 'rearrange_sheet',
+            operationId: 'o1',
+            sheet: rdraft(1),
+            state: 'active',
+            edits: [{ seq: 1, ops: [] }],
+          },
+        ],
+      },
+    ];
+    const out = applyIncomingRearrange(prev, {
+      operationId: 'o1',
+      sheet: rdraft(9),
+      hostMessageId: 'm1',
+    });
+    const b = out[0]!.blocks[0] as Extract<Block, { kind: 'rearrange_sheet' }>;
+    expect(b.sheet).toEqual(rdraft(9));
+    expect(b.edits).toEqual([]);
+  });
+
+  it('⭐⭐ ⛔ 不许作废确认单 —— 主管可以一边挂着待确认的分配单、一边调在手的', () => {
+    const prev = [msg('m1', ['r1', 'active']), rmsg('m2', ['o1', 'active'])];
+    const out = applyIncomingRearrange(prev, {
+      operationId: 'o2',
+      sheet: rdraft(3),
+      hostMessageId: 'm2',
+    });
+    // 确认单原封不动
+    expect(states(out)).toEqual([['r1', 'active']]);
+    // 只有调整单那一张被作废
+    expect(rstates(out)).toEqual([
+      ['o1', 'superseded'],
+      ['o2', 'active'],
+    ]);
+  });
+
+  it('⭐⭐ 反过来也一样:新确认单⛔ 不许作废调整单', () => {
+    const prev = [rmsg('m1', ['o1', 'active']), msg('m2', ['r1', 'active'])];
+    const out = applyIncomingSheet(prev, {
+      requestId: 'r2',
+      sheet: sheet(3),
+      hostMessageId: 'm2',
+    });
+    expect(rstates(out)).toEqual([['o1', 'active']]);
+    expect(states(out)).toEqual([
+      ['r1', 'superseded'],
+      ['r2', 'active'],
+    ]);
+  });
+});
+
+describe('findActiveRearrange', () => {
+  it('拿最后那张 active', () => {
+    const at = findActiveRearrange([
+      rmsg('m1', ['o1', 'superseded']),
+      rmsg('m2', ['o2', 'active']),
+    ]);
+    expect(at).toEqual({ messageIndex: 1, blockIndex: 0 });
+  });
+
+  it('⭐⭐ ⛔ 不回落到 confirmed —— 调整一确认就生效了,再改等于让他以为改了而库里没动', () => {
+    expect(findActiveRearrange([rmsg('m1', ['o1', 'confirmed'])])).toBeNull();
+  });
+
+  it('⛔ 不选 superseded / cancelled', () => {
+    expect(
+      findActiveRearrange([rmsg('m1', ['o1', 'superseded'], ['o2', 'cancelled'])]),
+    ).toBeNull();
+  });
+
+  it('⛔ 不会错拿确认单', () => {
+    expect(findActiveRearrange([msg('m1', ['r1', 'active'])])).toBeNull();
+  });
+});

apps/pac-web/src/components/assistant/chat-blocks.ts

-import type { AssignmentProposal, SheetEditOp } from '@pac/types';
+import type {
+  AssignmentProposal,
+  RearrangeDraft,
+  RearrangeEditOp,
+  SheetEditOp,
+} from '@pac/types';
 
 /**
  * chat-blocks —— 助手消息流的**数据模型 + 纯函数操作**。
@@ -50,7 +55,7 @@ export interface Artifact {
  *   **作废那一版整条不再显示**（见 isDiscardedDraft）。它一个字都没落库，
  *   人数、分给谁全是废数，却在对话里占着大半屏 —— 往回翻读到的是一份不存在的方案。
  *   「他要能看见自己出过几版」由**主管自己那两句话**保住：
- *   「出一份分配方案」→「每人每天按 20 通算，重新排一版」，一眼看得出重排过。
+ *   「出一份分配方案」→「每人每天按 20 通算，重新排一版」，一眼看得出调整过。
  * ⚠️ `confirmed` / `cancelled` 是**终态**，⛔ 不许被后续的作废扫描回退。
  */
 export type DraftState = 'active' | 'superseded' | 'confirmed' | 'cancelled';
@@ -85,7 +90,7 @@ export type Block =
    * ⭐ 模型写完「389 人卡在待分配…」那一条，紧接着调一次工具 → 这个块就插在
    *   消息流的**此刻这个位置**，按钮正好落在它的解释下面。
    *   ⚠️ 和 artifact 同一个模式：工具调用即"在流里插一个界面块"。
-   * ⚠️ 只存 `signalKey`，⛔ 不存整个 signal —— 确认单可能被重排替换（refill），
+   * ⚠️ 只存 `signalKey`，⛔ 不存整个 signal —— 确认单可能被调整替换（refill），
    *   届时按 key 从**当前**那张单上取，取不到就不渲染（那条已经不存在了）。
    * 🔴 漏调不丢东西：没被插进正文的 action 节点仍旧显示在确认单卡片上（卡片按
    *   已插入的 key 去重）。⇒ 这个块优化的是**位置**，⛔ 不是可见性。
@@ -124,6 +129,31 @@ export type Block =
        * ⚠️ 用队列而不是"最新一条":主管连着说两句时,两批指令都要生效。
        */
       edits?: { seq: number; ops: SheetEditOp[] }[];
+    }
+  /**
+   * 调整单卡片**摆在这** —— 位置由模型决定(`show_rearrange` 工具)。
+   *
+   * ⚠️ 与 `sheet_anchor` 是**两个标记**,⛔ 别合并:同一条消息里两张单都可能存在
+   *   (他先分了一批、又要调在手的),合并之后两张卡会抢同一个位置。
+   */
+  | { kind: 'rearrange_anchor' }
+  /**
+   * 调整单 —— 调整各客服**在手**的单。原生 React 组件(要能点确认,理由同确认单)。
+   *
+   * ⛔ **与 `assignment_sheet` 完全隔离**(产品 2026-08-20 定):
+   *   两者形状像但语义不通 —— 调整不建批次、没有福利、没有"本批多大"、没有"待分配"。
+   *   共用一个块必然要给一半字段配空值,而那一半迟早有人在某个分支上忘了判。
+   *
+   * ⚠️ `sheet` 由**服务端经侧信道推来**,不是模型生成的 —— 它含几百个 planId。
+   */
+  | {
+      kind: 'rearrange_sheet';
+      /** 服务端铸的幂等键,提交时原样回传 */
+      operationId: string;
+      sheet: RearrangeDraft;
+      state: DraftState;
+      /** 助手下发的语义编辑指令队列(`edit_rearrange_sheet` 走侧信道推来) */
+      edits?: { seq: number; ops: RearrangeEditOp[] }[];
     };
 
 export interface ChatMessage {
@@ -185,7 +215,7 @@ export function upsertArtifact(
  * 新草稿到达 —— upsert 它，并把**此前所有 `active` 的当场作废**。
  *
  * 🔴 必须**跨消息**扫：上一版几乎总在**上一轮**的消息里
- *   （主管看着它才说「重排一版」的）。只扫当前消息永远扫不到，而且不会报错。
+ *   （主管看着它才说「调整一版」的）。只扫当前消息永远扫不到，而且不会报错。
  * ⚠️ 只作废 `active`：`confirmed` / `cancelled` 是终态，⛔ 不许回退。
  * ⚠️ 同一 `requestId` 重推时清空 `edits` —— 旧的编辑指令对新名单没有意义。
  *
@@ -318,7 +348,7 @@ export function intentToPrompt(
     }
     /**
      * 「按别的条件选」—— ⛔ 不改任何东西，只是把「先看看还有哪些口子」做成一个按钮。
-     * ⚠️ 措辞里要写明**别急着重排**：不然模型会顺手出一版新确认单，
+     * ⚠️ 措辞里要写明**别急着调整**：不然模型会顺手出一版新确认单，
      *   而主管这一下问的是"有哪些选择"，不是"照某个条件重来"。
      */
     case 'cohort.attrs_ask':
@@ -388,7 +418,7 @@ export function stripToolEcho(text: string): string {
  * ⚠️ 判据是「**只剩**作废的」，⛔ 不是「有作废的」：同一轮里模型可能出过两版
  *   （`applyIncomingSheet` 把旧的**就地**扫成作废、新的追加到同一条消息）。
  *   那时这条消息里还有活着的那版，整条藏掉会把有效的一起抹了。
- * ⚠️ 只认 `superseded`（重排顶掉的、一条都没落库）。
+ * ⚠️ 只认 `superseded`（调整顶掉的、一条都没落库）。
  *   ⛔ `cancelled`（已确认后又撤销）与 `confirmed` 都是真发生过的事，不能藏也不能清。
  */
 export function isDiscardedDraft(m: ChatMessage): boolean {
@@ -501,3 +531,63 @@ export function toApiMessages(m: ChatMessage): ApiMessage[] {
   return out;
 }
 
+
+
+// ─────────────────────────────────────────────────────────
+// 调整单 —— 与上面确认单那两个函数同构,⛔ 刻意不合并
+//   合并要么加一个 kind 参数、要么加泛型,两种写法都会让"哪张单该被作废"
+//   这件事变成运行时判断 —— 而这正是 2026-08-12「作废了错的那张」栽过的地方。
+// ─────────────────────────────────────────────────────────
+
+/**
+ * 新调整单到达 —— upsert 它,并把此前所有 `active` 的调整单当场作废。
+ *
+ * ⚠️ 只扫 `rearrange_sheet`:确认单是另一条路,⛔ 不许被这里作废
+ *   (主管完全可能一边挂着一张待确认的分配单、一边让助手调在手的)。
+ */
+export function applyIncomingRearrange(
+  messages: ChatMessage[],
+  input: { operationId: string; sheet: RearrangeDraft; hostMessageId: string },
+): ChatMessage[] {
+  const { operationId, sheet, hostMessageId } = input;
+  let placed = false;
+  const swept = messages.map((m) => ({
+    ...m,
+    blocks: m.blocks.map((b): Block => {
+      if (b.kind !== 'rearrange_sheet') return b;
+      if (b.operationId === operationId) {
+        placed = true;
+        // 同 id 重推清空 edits —— 旧指令对新名单没有意义
+        return { ...b, sheet, state: 'active', edits: [] };
+      }
+      return b.state === 'active' ? { ...b, state: 'superseded' } : b;
+    }),
+  }));
+  if (placed) return swept;
+  return swept.map((m) =>
+    m.id === hostMessageId
+      ? {
+          ...m,
+          blocks: [...m.blocks, { kind: 'rearrange_sheet', operationId, sheet, state: 'active' }],
+        }
+      : m,
+  );
+}
+
+/**
+ * 找**他现在说的那张**调整单 —— 助手的修改指令打到这张上。
+ *
+ * ⚠️ 与确认单不同:这里**只认 `active`**。调整一旦确认就落库了,⛔ 没有"确认后还能改"
+ *   这回事(确认单那边有,因为福利是前向的、可以补挂;调整没有福利)。
+ *   打到 `confirmed` 上等于让主管以为改了、而库里一动没动。
+ */
+export function findActiveRearrange(
+  messages: ChatMessage[],
+): { messageIndex: number; blockIndex: number } | null {
+  for (let mi = messages.length - 1; mi >= 0; mi--) {
+    const blocks = messages[mi]?.blocks ?? [];
+    const bi = blocks.findIndex((b) => b.kind === 'rearrange_sheet' && b.state === 'active');
+    if (bi >= 0) return { messageIndex: mi, blockIndex: bi };
+  }
+  return null;
+}

apps/pac-web/src/components/assistant/sheet-primitives.tsx

+'use client';
+
+import { useState } from 'react';
+import { ChevronDown } from 'lucide-react';
+import { ASSIGNMENT_EXPIRES_DAYS_PRESETS } from '@pac/types';
+import {
+  Select,
+  SelectContent,
+  SelectItem,
+  SelectTrigger,
+  SelectValue,
+} from '@/components/ui/select';
+import { cn } from '@/lib/utils';
+
+/**
+ * 两张单子共用的**呈现原件** —— 确认单(分配)与重排单各自独立,但主管的手只学一遍。
+ *
+ * ═══ 为什么这两个可以共用,而组件本身不行 ═══════════════════════════
+ * 这里的两个都是**没有业务语义**的交互原件:一个是"点名字复制",一个是"改天数"。
+ * 它们身上那点来之不易的行为(懒挂 Radix、复制反馈)一旦抄成两份必然漂 ——
+ * 而漂了的表现是**两张单子手感不一样**,正是"用户不用二次学习"要防的那件事。
+ * ⚠️ 有业务语义的东西(福利、待分配、批次时限、落人算法)⛔ 仍然各归各的,
+ *   ⛔ 别拿这个文件当"把两张单子缝起来"的入口(产品 2026-08-20:重排单与确认单独立)。
+ */
+
+/**
+ * 患者姓名 —— **点一下复制**(2026-08-06 产品加)。
+ *
+ * ⚠️ 主管审这批人时常要把名字贴到别处(问医生、查宿主档案、发消息),
+ *   在一个 480px 的列表里手动选中一个中文名很难选准。
+ * ⚠️ `stopPropagation` 是必须的:这一行同时是**折叠开关的兄弟**且整行可拖,
+ *   不拦住会连带触发别的行为。
+ * ⚠️ `draggable={false}`:不加的话按住名字拖会被浏览器当成拖文本,把整行的拖拽吃掉。
+ * ⛔ 复制的是**姓名本身**,不含病历号/性别年龄 —— 那些是给眼睛看的上下文,
+ *   粘出去多带一串反而要手动删。
+ */
+export function CopyableName({ name }: { name: string }) {
+  const [copied, setCopied] = useState(false);
+  return (
+    <button
+      type="button"
+      draggable={false}
+      title="点击复制姓名"
+      onClick={(e) => {
+        e.stopPropagation();
+        void navigator.clipboard?.writeText(name);
+        setCopied(true);
+        setTimeout(() => setCopied(false), 1200);
+      }}
+      className={cn(
+        'rounded px-0.5 transition-colors',
+        copied ? 'bg-emerald-50 text-emerald-700' : 'hover:bg-brand-50 hover:text-brand-700',
+      )}
+    >
+      {copied ? '已复制' : name}
+    </button>
+  );
+}
+
+/**
+ * 时限选择 —— 1~7 天。用 shadcn `Select`(Radix),不用原生 `<select>`:
+ * 原生下拉在深色/窄屏下样式不可控,而这个控件现在**每一条召回计划都有一个**,
+ * 出现几百次,样式必须跟卡片其余部分一致。
+ * ⚠️ 值域来自 `ASSIGNMENT_EXPIRES_DAYS_PRESETS`(共享常量),⛔ 别在这里内联 [1..7]。
+ */
+/**
+ * 时限下拉 —— **点了才挂真正的 Radix Select**。
+ *
+ * 🔴 由来(2026-08-05 实测):原来每一行直接渲染一个 `<Select>`。展开一个 36 条的客服组
+ *   = 一次性挂 36 个 Radix Select,每个都带 portal / 焦点管理 / 键盘导航,
+ *   展开那一下明显卡顿。而这些下拉**绝大多数根本不会被点** —— 主管一批 200 人,
+ *   真正逐条改时限的是个位数。
+ *
+ * ✅ 平时只是一个 `<button>`(样式与 SelectTrigger 一致),点击才换成真 Select 并自动展开。
+ * ⚠️ `defaultOpen` 是关键:换过去之后要立刻弹开,否则用户得点两下。
+ * ⚠️ 收起后**不还原成按钮** —— 还原会让"刚改完又想再改"变成再等一次挂载,
+ *   而且已经挂上的那一个不再是成本问题(卡的是 36 个同时挂)。
+ */
+export function DaySelect({
+  value,
+  disabled,
+  onChange,
+  compact,
+}: {
+  value: number;
+  disabled?: boolean;
+  onChange: (days: number) => void;
+  /**
+   * 条目行用紧凑版 —— **只是窄一点**,⛔ 不省单位。
+   *
+   * 🔴 2026-08-20 产品走查:原来紧凑版只显示一个光秃秃的数字(「1」),
+   *   而它旁边一行里还有「剩 1 天」「约 2 天」这些数 —— 一个不带单位的 1 摆在中间
+   *   读不出是什么。省下的那点宽度换来一次"这是什么"的停顿,不划算。
+   */
+  compact?: boolean;
+}) {
+  const [live, setLive] = useState(false);
+  // ⚠️ 紧凑版从 54 放到 66:要装下「1 天」+ 箭头,54 会把「天」挤掉
+  const cls = cn('h-6 gap-1 px-1.5 text-[11px]', compact ? 'w-[66px]' : 'w-[76px]');
+
+  if (!live) {
+    return (
+      <button
+        type="button"
+        disabled={disabled}
+        onClick={() => setLive(true)}
+        // 样式与 SelectTrigger 对齐 —— 换过去时不许有跳动
+        className={cn(
+          cls,
+          'inline-flex items-center justify-between rounded-md border border-input bg-transparent',
+          'shadow-xs transition-colors hover:bg-accent/50 disabled:cursor-not-allowed disabled:opacity-50',
+        )}
+      >
+        <span>{value} 天</span>
+        <ChevronDown className="h-3 w-3 opacity-50" />
+      </button>
+    );
+  }
+
+  return (
+    <Select
+      value={String(value)}
+      disabled={disabled}
+      defaultOpen
+      onValueChange={(v) => onChange(Number(v))}
+    >
+      <SelectTrigger className={cls}>
+        <SelectValue />
+      </SelectTrigger>
+      {/* z 层级已在 ui/select.tsx 统一抬到 70(助手窗是 z-60,见那里的层级约定) */}
+      <SelectContent>
+        {ASSIGNMENT_EXPIRES_DAYS_PRESETS.map((d) => (
+          <SelectItem key={d} value={String(d)} className="text-[12px]">
+            {d} 天
+          </SelectItem>
+        ))}
+      </SelectContent>
+    </Select>
+  );
+}

apps/pac-web/src/components/assistant/step-trace.tsx

@@ -56,11 +56,20 @@ const TOOL_META: Record<string, { label: string; running: string }> = {
   render_artifact: { label: '出图表', running: '正在画图' },
   // 取一篇做法(pull 式加载,见服务端 assistant-playbooks):不查库不改数据
   open_playbook: { label: '取做法', running: '正在取这类活的做法' },
+  // ── 调整各客服在手的单(2026-08-20)——与上面确认单那三件一一对应 ──
+  // ⚠️ 说的是**动作**,⛔ 不是工具名:漏配的话兜底文案会把 `propose_rearrange`
+  //   这串英文直接摆给主管看(2026-08-20 走查抓到的就是这个)。
+  propose_rearrange: { label: '出调整单', running: '正在把各客服手上的单摆出来' },
+  edit_rearrange_sheet: { label: '改调整单', running: '正在按你说的改调整单' },
   // ── 纯位置标记，不查库不写库（见 assistant.service 的 place_*）──
   show_sheet: { label: '摆确认单卡片', running: '正在摆确认单' },
+  show_rearrange: { label: '摆调整单卡片', running: '正在摆调整单' },
   show_guidance: { label: '摆选项按钮', running: '正在摆选项按钮' },
 };
 
+/** 给测试用 —— ⚠️ 只读导出,⛔ 别在运行时拿它当映射表(那是 `toolMeta` 的活) */
+export const TOOL_META_KEYS = Object.keys(TOOL_META);
+
 export function toolMeta(tool: string) {
   return TOOL_META[tool] ?? { label: tool, running: `正在调用 ${tool}` };
 }

apps/pac-web/src/components/assistant/use-assistant-chat.ts

 'use client';
 
 import { useCallback, useRef, useState } from 'react';
-import type { AssignmentProposal, SheetEditOp, Signal } from '@pac/types';
+import type {
+  AssignmentProposal,
+  RearrangeDraft,
+  RearrangeEditOp,
+  SheetEditOp,
+  Signal,
+} from '@pac/types';
 import { env } from '@/lib/env';
 import { emitPetEvent } from '@/lib/pet-events';
 import { useAuthStore } from '@/stores/auth-store';
@@ -13,7 +19,9 @@ import { assignmentsApi } from '@/components/plans/assignments-api';
 // ⭐ 数据模型 + 纯函数操作已抽到 chat-blocks（草稿状态机是最该有回归的一段逻辑，
 //   内联在 hook 里只能端到端点一遍才能验）。这里 re-export 保持下游 import 不变。
 import {
+  applyIncomingRearrange,
   applyIncomingSheet,
+  findActiveRearrange,
   findActiveSheet,
   findToolIdx,
   intentToPrompt,
@@ -77,7 +85,7 @@ export function useAssistantChat() {
    * 正在执行的引导节点 intent —— 按钮据此转圈并整排禁用。
    *
    * 🔴 必须在**这一层**（2026-08-13）：会花时间的两类动作都已经不在卡片里了 ——
-   *   `pending.refill` 走 HTTP 重排（几秒），`basis.set` / `cohort.*` 走
+   *   `pending.refill` 走 HTTP 调整（几秒），`basis.set` / `cohort.*` 走
    *   `send()` 让模型重出一版（几十秒）。⛔ 局部改单（to_owner / spread / remove /
    *   expiry.set）是同步的，⛔ 不要给它们转圈：闪一下反而像出错了。
    */
@@ -130,7 +138,7 @@ export function useAssistantChat() {
   /**
    * 消息流的**同步镜像** —— 给那些"要先读当前状态、再发请求"的回调用。
    * ⛔ 别把这类读取塞进 `setMessages` 的 updater：StrictMode 会把 updater 跑两次，
-   *   写在里面的副作用（如重排接口）就会**发两遍**。
+   *   写在里面的副作用（如调整接口）就会**发两遍**。
    */
   const messagesRef = useRef<ChatMessage[]>([]);
   messagesRef.current = messages;
@@ -206,7 +214,7 @@ export function useAssistantChat() {
       /**
        * 文本 / 思考的增量追加 —— **追加到最后一个同类块**，被别的东西打断就新起一段。
        *
-       * ⚠️ 这就是"时序"的全部实现：块的先后 = 事件到达的先后，⛔ 前端不重排。
+       * ⚠️ 这就是"时序"的全部实现：块的先后 = 事件到达的先后，⛔ 前端不调整。
        *   所以「思考 → 调工具 → 写字 → 再调」在消息里长什么样，就是它真实发生的顺序。
        */
       const appendStream = (kind: 'text' | 'reasoning', t: string) =>
@@ -273,6 +281,44 @@ export function useAssistantChat() {
                 : [...blocks, { kind: 'sheet_anchor' as const }],
             );
             break;
+          // ── 调整单(调整各客服在手的单)——— 与确认单三件事同构、⛔ 各走各的 ──
+          case 'rearrange_sheet':
+            setMessages((prev) =>
+              applyIncomingRearrange(prev, {
+                operationId: String(evt.operationId ?? ''),
+                sheet: evt.sheet as RearrangeDraft,
+                hostMessageId: assistantId,
+              }),
+            );
+            break;
+          case 'rearrange_sheet_edit':
+            // ⚠️ 与确认单同一条纪律:跨消息找**唯一那张 active**。
+            //   ⛔ 但这里不回落到 confirmed —— 调整一确认就落库了,没有"确认后还能改"。
+            setMessages((prev) => {
+              const at = findActiveRearrange(prev);
+              if (!at) return prev;
+              const { messageIndex: mi, blockIndex: bi } = at;
+              const b = prev[mi]!.blocks[bi] as Extract<Block, { kind: 'rearrange_sheet' }>;
+              const next: Block = {
+                ...b,
+                edits: [
+                  ...(b.edits ?? []),
+                  { seq: (b.edits?.length ?? 0) + 1, ops: (evt.ops ?? []) as RearrangeEditOp[] },
+                ],
+              };
+              return prev.map((m, k) =>
+                k === mi ? { ...m, blocks: m.blocks.map((x, j) => (j === bi ? next : x)) } : m,
+              );
+            });
+            break;
+          case 'rearrange_sheet_anchor':
+            // ⚠️ 与 sheet_anchor 是**两个标记**:同一条消息里两张单都可能存在
+            patch((blocks) =>
+              blocks.some((b) => b.kind === 'rearrange_anchor')
+                ? blocks
+                : [...blocks, { kind: 'rearrange_anchor' as const }],
+            );
+            break;
           case 'assignment_guidance': {
             /**
              * ⭐ 模型说「这条的按钮插在这」—— `patch` 追加到**当前正在写的**这条消息末尾,
@@ -608,7 +654,7 @@ export function useAssistantChat() {
        *
        * ⚠️ 2026-08-12 从确认单组件搬到这里：待分配的按钮已经不在卡片上了
        *   （它跟着模型的文案走），卡片再留一份实现就是**没人走的死代码**。
-       * ⚠️ 条件必须**原样带回** —— 少带一个（口径、治疗项、时间档），重排就换了人群，
+       * ⚠️ 条件必须**原样带回** —— 少带一个（口径、治疗项、时间档），调整就换了人群，
        *   而且不报错。
        */
       if (intent === 'pending.refill') {
@@ -639,7 +685,7 @@ export function useAssistantChat() {
             ...(s.narrowedBy?.minSpendYuan ? { minSpendYuan: s.narrowedBy.minSpendYuan } : {}),
             /**
              * 🔴 **他在这一版上设的按客服精调也要带回**（2026-08-15 补）。
-             *   服务端的基线读的是**上一次已确认批次**，所以不带 = 重排一下
+             *   服务端的基线读的是**上一次已确认批次**，所以不带 = 调整一下
              *   「李莉这批只给 5 条」就没了，李莉照常吃满，⛔ 而且不报错。
              * ⚠️ 发**当前这一版**的（`s.agentOverrides` 已经是基线与本轮合并后的结果），
              *   ⛔ 别只发"本轮新加的"：那样上一次沿用下来的会被当成撤销。

apps/pac-web/src/components/plans/rearrange-api.ts

+import type { RearrangeDraft, RearrangeSubmitRequest, RearrangeSubmitResponse } from '@pac/types';
+import { api } from '@/lib/api-client';
+
+/**
+ * 重排(调整各客服在手的单)。
+ *
+ * ⛔ 刻意**不并进** `assignmentsApi`:重排不建批次、不属于任何一次分配,
+ *   路径也不在 `plans/assignments` 之下。并进去会让"这是分配的一部分"这个错觉
+ *   在代码组织上就成立。
+ */
+export const rearrangeApi = {
+  /** 取一版可编辑的在手快照 —— 不传 agents = 全队 */
+  draft: (clinicId: string, agents?: string[]) =>
+    api.get<RearrangeDraft>(
+      `/pac/v1/plans/rearrange/draft?clinicId=${encodeURIComponent(clinicId)}` +
+        (agents?.length ? `&agents=${encodeURIComponent(agents.join(','))}` : ''),
+    ),
+  /** 确认重排 —— 这条路唯一的写动作 */
+  submit: (body: RearrangeSubmitRequest) =>
+    api.post<RearrangeSubmitResponse>('/pac/v1/plans/rearrange', body),
+};

apps/pac-web/src/components/supervisor/batch-tracking.tsx

@@ -12,6 +12,15 @@ import { cn } from '@/lib/utils';
 const PAGE = 20;
 
 /**
+ * 数字列的列名 —— **单一真源**。
+ *
+ * 🔴 分组表头那一行的 `colSpan` 从它推(`NUM_COLS.length + 1`,+1 是最左边的「批次」列)。
+ *   ⛔ 别在那儿手写数字:2026-08-20 加「回收」那一列时就是这么栽的 ——
+ *   分组行少跨一格,最后一列在「还在跑的」「8 月」这两行上留出一块白,且不报任何错。
+ */
+const NUM_COLS = ['条数', '已处置', '没动', '客服退回', '回收', '超期', '约上'] as const;
+
+/**
  * 「没动」标琥珀的阈值(占本批/本人分到量的比例)。
  * ⚠️ **列表和抽屉共用这一个常量** —— 各写各的必然漂，而漂了主管只会以为某一处算错了。
  */
@@ -234,7 +243,16 @@ export function BatchTracking({ clinicId }: { clinicId: string | null }) {
             <thead>
               <tr className="sticky top-0 z-10 bg-slate-50 shadow-[inset_0_-1px_0_#E2E8F0]">
                 <th className="px-3.5 py-1.5 text-left text-[11px] font-medium text-slate-500">批次</th>
-                {['条数', '已处置', '没动', '退回', '超期', '约上'].map((h) => (
+                {/*
+                  ⚠️ 列名从 `NUM_COLS` 来 —— 分组表头那一行的 colSpan 也从它推。
+                  🔴 「退回」写成「**客服退回**」,并单列「**回收**」(2026-08-20 产品定)。
+                  在此之前主管在调整单里收回的单子**在这张表上凭空消失**:既不在没动、
+                  也不在退回,他一对数就发现少了几条,而少的那几条查不出去哪了。
+                  ⚠️ 两件事必须分开:「客服退回」是客服说我不接这单(带原因,进原因分布),
+                    「回收」是主管自己把活收回来 —— 混在一起,他就是在拿自己的动作
+                    当调下一批的依据。
+                */}
+                {NUM_COLS.map((h) => (
                   <th
                     key={h}
                     className="whitespace-nowrap px-2.5 py-1.5 text-right text-[11px] font-medium text-slate-500"
@@ -344,7 +362,13 @@ function BatchGroup({
   return (
     <>
       <tr>
-        <td colSpan={7} className={cn('border-t px-3.5 py-1.5', t.rail, t.head)}>
+        {/*
+          🔴 **colSpan 必须从列表推**(2026-08-20 走查栽过):加了「回收」那一列之后,
+            这里还写着手抄的 7,分组表头那一行少跨一格 —— 最后一列(约上)在
+            「还在跑的」「8 月」这两行上留出一块白,而且不报任何错。
+          ⚠️ `+1` 是最左边那一列「批次」,它不在 NUM_COLS 里。
+        */}
+        <td colSpan={NUM_COLS.length + 1} className={cn('border-t px-3.5 py-1.5', t.rail, t.head)}>
           <span className={cn('text-[11px] font-semibold', t.headKey)}>{group.key}</span>
           <span className="ml-1.5 text-[10.5px] text-slate-400">{group.note}</span>
         </td>
@@ -383,6 +407,8 @@ function BatchGroup({
               {b.inHand}
             </td>
             <td className={cn('nums px-2.5 py-2 text-right', t.released)}>{b.released}</td>
+            {/* ⚠️ 回收是**中性**的(主管自己的调度),⛔ 别给退回那支红 —— 红会读成"出问题了" */}
+            <td className={cn('nums px-2.5 py-2 text-right', t.idle)}>{b.recalled}</td>
             <td className={cn('nums px-2.5 py-2 text-right', t.expired)}>{b.expired}</td>
             <td className={cn('nums px-2.5 py-2 text-right', t.booked)}>{b.booked}</td>
           </tr>
@@ -427,7 +453,7 @@ function BatchDrawer({ id, onClose }: { id: string; onClose: () => void }) {
     <>
       {/*
         🔴 **z-20 不能省**（2026-08-07 实测）：表格的 `thead` 是 `sticky z-10`，
-          抽屉不给层级的话，那一排列头（已处置 / 没动 / 退回 / 到期回池 / 约上）
+          抽屉不给层级的话，那一排列头（已处置 / 没动 / 客服退回 / 回收 / 超期 / 约上）
           会**浮在抽屉标题上面**，跟抽屉自己那行汇总叠在一起 —— 看着像表头样式坏了，
           实际是层级问题。⛔ 别去改 thead 的 sticky（那是列表滚动要用的）。
         ⚠️ `top-[3.25rem]` 对齐面板自己的标题行高度：抽屉盖住表格但**不盖标题**，
@@ -445,8 +471,8 @@ function BatchDrawer({ id, onClose }: { id: string; onClose: () => void }) {
             </div>
             {d && (
               <div className="nums mt-0.5 text-[11px] text-slate-600">
-                已处置 {d.handled} · 没动 {d.inHand} · 退回 {d.released} · 超期 {d.expired} ·
-                约上 {d.booked}
+                已处置 {d.handled} · 没动 {d.inHand} · 客服退回 {d.released}
+                {d.recalled > 0 && <> · 回收 {d.recalled}</>} · 超期 {d.expired} · 约上 {d.booked}
               </div>
             )}
           </div>
@@ -475,7 +501,7 @@ function BatchDrawer({ id, onClose }: { id: string; onClose: () => void }) {
               <table className="w-full border-collapse text-[12px] text-slate-700">
                 <thead>
                   <tr>
-                    {['客服', '分到', '已处置', '没动', '退回'].map((h, i) => (
+                    {['客服', '分到', '已处置', '没动', '客服退回', '回收'].map((h, i) => (
                       <th
                         key={h}
                         className={cn(
@@ -508,15 +534,18 @@ function BatchDrawer({ id, onClose }: { id: string; onClose: () => void }) {
                         {a.inHand}
                       </td>
                       <td className="nums py-1.5 text-right text-rose-600">{a.released}</td>
+                      {/* 从**他手上**收回去的(⛔ 不是当初分给他的那个人) */}
+                      <td className="nums py-1.5 text-right text-slate-500">{a.recalled}</td>
                     </tr>
                   ))}
                 </tbody>
               </table>
 
-              <div className="mt-4 text-[11.5px] font-semibold text-slate-700">退回原因分布</div>
+              {/* ⚠️ 只统计**客服退回**的原因 —— 主管回收没有原因,也⛔ 不该进这张分布 */}
+              <div className="mt-4 text-[11.5px] font-semibold text-slate-700">客服退回原因分布</div>
               {/* 🔴 退回率两个分母都给 —— 只给百分比会把"没动"藏起来 */}
               <div className="nums mt-0.5 text-[10.5px] text-slate-400">
-                退回 {d.released} / 已处置 {d.handled}
+                客服退回 {d.released} / 已处置 {d.handled}
                 {d.handled > 0 ? ` = ${((d.released / d.handled) * 100).toFixed(1)}%` : ''}，另有{' '}
                 {d.inHand} 条没动
               </div>

packages/types/src/enums/index.ts

@@ -1089,6 +1089,37 @@ export const PlanEventType = {
    *   ⛔ 别把它算进"客服处理过这个患者",那个口径会静默膨胀成"复制一下也算"。
    */
   SCRIPT_COPY: 'script_copy',
+
+  // ── 主管调整各客服**在手**的单 —— 2026-08-20 ────────────────────
+  /**
+   * 调整 · 改派:把一条**已经在客服手上**的单换给另一位客服。
+   *
+   * ⚠️ 与 `assign` 分开而不是复用,是为了 `byHuman: false` ——
+   *   转手不是「客服处理过这个患者」。挂 `assign` 会让 HUMAN_TOUCH_EVENTS
+   *   把"被转了一手"算成"有人跟进过",而那是 filter 派生的,改错不报任何错。
+   *
+   * 列怎么用:`assignee_user_id` = 接手人 / `actor_user_id` = 主管(操作人) /
+   *   `details.from` = 原客服 / `assignment_id` = **原批**(⛔ 调整不改归属批次) /
+   *   `operation_id` = 本次调整。
+   */
+  TRANSFER: 'transfer',
+  /**
+   * 调整 · 改时限:`details` 记改动前后(`{ from, to }`,ISO 时刻)。
+   * ⚠️ 归属没变 → `holdsPatient: true`。
+   */
+  EXPIRY_CHANGED: 'expiry_changed',
+  /**
+   * 调整 · 移出:主管把一条在手单收回池子。
+   *
+   * 🔴 ⛔ **绝不能复用 `release`**(2026-08-20 定,踩之前先写下来):
+   *   批次详情的退回原因分布是 `for (e of batchEvents) if (e.event === 'release')`
+   *   —— **只按 assignment_id 过滤,不看是谁干的**(见 plan-assignment.service
+   *   的 detail())。调整的移出若挂 release,会同时:
+   *     ① 进那一批的**退回原因分布** —— 污染主管调下一批的输入;
+   *     ② 给**原客服**记一笔「退回」—— 他没退,是主管收走的。
+   *   两个错都不抛任何异常。
+   */
+  REARRANGE_REMOVE: 'rearrange_remove',
 } as const;
 export type PlanEventType = (typeof PlanEventType)[keyof typeof PlanEventType];
 
@@ -1125,6 +1156,12 @@ export const PLAN_EVENT_META: Record<
   // ⚠️ holdsPatient: false —— 复制可能发生在未认领的单上(主管浏览时也能复制),
   //    跟归属无关,不参与归属区间计算。
   script_copy:  { labelZh: '复制话术',   group: 'usage',     byHuman: false, holdsPatient: false },
+  // ── 主管调整 —— 三个都 byHuman: false:调整是**主管**在调度,不是客服处理了患者。
+  //    给 true 会让「已处置」把"被主管挪了一下"算成"有人跟进过"。
+  transfer:         { labelZh: '调整改派',   group: 'ownership', byHuman: false, holdsPatient: true },
+  expiry_changed:   { labelZh: '调整改时限', group: 'ownership', byHuman: false, holdsPatient: true },
+  // ⚠️ holdsPatient: false —— 移出之后单子回池,没有客服挂着(与 release 同)。
+  rearrange_remove: { labelZh: '调整移出',   group: 'ownership', byHuman: false, holdsPatient: false },
 };
 
 /// 「该患者被客服处理过」的事件集合 —— 统计口径收口在这里,避免各处各写一套。

packages/types/src/schemas/index.ts

@@ -6,6 +6,7 @@ export * from './fact';
 export * from './persona';
 export * from './plan';
 export * from './plan-assignment';
+export * from './plan-rearrange';
 export * from './agent';
 export * from './sync';
 export * from './admin';

packages/types/src/schemas/plan-assignment.ts

@@ -263,7 +263,17 @@ export const AssignmentBriefSchema = z.object({
    *   SQL 里 `release_reason = NULL`),数它等于"被退过又被重分的人从没退过"。
    * ⚠️ **不含到期**:到期是"客服压根没动",与"看了判断不该我做"是两回事,见 expired。
    */
-  released: z.number().int().describe('客服主动退回(不含到期)'),
+  released: z.number().int().describe('客服主动退回(不含到期、不含主管回收)'),
+  /**
+   * 主管在**调整各客服在手的单**里把它收回池子的条数(账本 `rearrange_remove`)。
+   *
+   * ⭐ 与 `released` 分开的理由跟当初分开事件是同一条:那是**客服**说「我不接这单」,
+   *   这是**主管**把活收回来。混在一起,退回原因分布会被主管自己的调度污染,
+   *   而主管正是靠那张分布决定下一批怎么发。
+   * ⚠️ 它跟 `inHand` 互斥(收回之后单子不在人手上了),但**不从 `planned` 里减** ——
+   *   当时确实分了这个人,分母不能缩水。
+   */
+  recalled: z.number().int().describe('主管调整时收回池子的条数'),
   /**
    * 到期自动回池的条数(账本 auto_release + reason=assignment_expired)。
    *
@@ -325,6 +335,14 @@ export const AssignmentAgentStatSchema = z.object({
   inHand: z.number().int(),
   released: z.number().int(),
   /**
+   * 主管从**他手上**收回去的条数(调整单里的移出)。
+   *
+   * ⚠️ 归的是「从谁手上收的」,⛔ 不是「当初分给谁」—— 一条单可能先被转手再被收回,
+   *   那时候两者不是一个人。
+   * ⚠️ 它⛔ 不进退回率:退回率回答的是「他为什么不接」,而这一列是主管自己的动作。
+   */
+  recalled: z.number().int(),
+  /**
    * 仍在手、已过时限、**且没有约定回访**。
    *
    * 🔴 「且没有约定回访」这半句不能少。到期回收器刻意跳过 `snoozedUntil` 在未来的单
@@ -445,6 +463,8 @@ export const AssignmentDetailResponseSchema = AssignmentBriefSchema.extend({
    * 而"没动过"的数量本身就是信号(主管据此判断是分多了还是客服没跟)。
    * 只给一个百分比会让主管把"没人动"误读成"做得不错"。
    */
+  /// 主管在调整单里收回池子的条数(口径同列表行的 `recalled`)
+  recalled: z.number().int(),
   untouched: z.number().int().describe('分下去后客服从未打开过详情页的条数'),
   /**
    * 处理进度 —— **判据是池子状态,不是回写**(产品裁决 2026-08-02)。