卡片上那句是 LLM 压出来的摘要,而摘要天然会丢东西 —— 客服看到「未留结果」
「未接通」这种结论时,第一反应就是"到底原文写了什么"。没有入口他只能信摘要,
或者去问别人。抽屉里是逐条原文(日期/类型/内容/结果),正是那个反问的答案。

⚠️ 抽屉 kind='return-visits' 一直都在(drawer.tsx),2026-07-29 那次只是
把回调摘掉了 —— 改动就一行,⛔ 别当"功能没做"重写一遍。

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

产品 2026-08-04:「第二句是他跟我们以前的关系亲密度是什么样的,就是联系他
多不多,然后有没有过不好的体验」。原来第②句只写"最近一次联系是什么事",
"多不多"和"不好的体验"整个缺失。

「不好的体验」只有一种形态(全量查证):
- `type` 只有 常规回访/咨询回访/术后回访 —— 没有投诉类
- `result` 自由文本 3 万行 6765 种取值,长尾里 投诉/不满/纠纷/态度/退费 **一条都没有**
- 真负面只有**「挂断」**:688 次 / 595 位患者(占有回访记录患者的 11.5%)
⚠️ 第一遍扫的时候「无不适」被"不适"接住,假阳性 5816 条 —— 负面词表必须排除否定式

三个刻意的设计:
① 总次数**单独聚合**:回访历史只给最近 3 条,让模型拿那 3 条数总量必然低估
   (实测 1131 位患者被联系过 10 次以上,全会被说成"联系过 3 次");
② 挂断为 0 时**整段不出现**。⛔ 不是输出「被挂断 0 次」——一旦出现那个 0,
   模型必然翻译成"沟通一直顺畅"。**没有记录 ≠ 关系好**,那是拿没证据当反面用
   (与 noTag 铁律同一件事);
③ schema 与 prompt **必须同时改** —— 只改一边 = 定义了但没喂,静默失效。
   单独一条测试锁两边。

promptVersion → 2026-08-07-closeness(不升的话老患者读到的还是旧简报,
而本地怎么测都是新的 —— 那种"改完看不到效果"最难查)。

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

产品 2026-08-04 评审原话:「我不可能挨个去看他分的对不对,你在这儿应该给的是
**结论性的东西**…如果你不能告诉他哪不对、哪里需要主管判断,那就默认他必须
一条一条看过去才能确认。」

卡片顶部新增 opsNote,只答三个问题:
- 这活多大:本批每人拿到 1~4 条;分完手上共 57~62 条 ——
  按每人每天 15 通算,最满的那位要 5 天打完
- 谁的批次全是自己的老客户(dedicated === count)→ 点名,主管可以直接过

顺带修掉一个真问题:卡片原来只写「分完每人 57~62 条」——那是**在手总量**,
而那一批实际每人只给 1~4 条。拟分 16 条的单子上写着 57~62,很容易读成
"这批好大一坨"。现在增量与总量分开说,并把这句从 basisNote 里挪走
(它答的是"凭什么这么分",不是"这活多大";两处都说就是复述)。

⚠️ DAILY_CALLS_PER_AGENT=15 是评审口头经验值不是实测,所以文案写成
「按每天 15 通算」而不是「需要 5 天」,让主管看得见这个前提;
⛔ 常量注释钉死不许接进落人算法 —— 那等于把删掉的"容量"从后门放回来。
⚠️ 结论钉在卡片上不进助手那段话:助手的话会被后续对话冲走,而重排换卡片时
它也不会重说 —— 与 refillNote 同一条理由。

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

- 🔴 姓名搜索/phoneVerified/画像标签全部静默失效:温度重构时把
  `where.patient = {...}` 的挂载整段删掉了,tsc 绿、单测绿、界面无报错,
  只是筛选条件从此不生效。改回合并式挂载(顺带修掉 sourceUnit 被覆盖的隐患),
  补了会在缺这行时变红的回归测试
- 画像圈人性别男女都返回 0
- jest 吃满 CPU:transform 里的 isolatedModules 被挪进 tsconfig 后**更慢**
  (18.1s/165s vs 6.9s/43s),因为 pac-service 的 tsconfig 把它设成了 false。
  按弃用警告改反而变慢 —— 以实测为准。配 maxWorkers 50%
- 新增 tsconfig.typecheck.json(单测不覆盖类型,提交前得单独跑)

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

秒挂原来算在「保持」里,而它明明是没接通的一种。改 group 之后
tone 和提示文案没跟着改 —— 边框还是 slate、提示还写着「等下次跟进」,
而实际已经压 30 天。教训:一个字段辐射到多处渲染时,每一处都要跟着查。

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

- 回访摘要改读 result/followContent,⛔ 不再念「任务已完成」这类状态字段 ——
  主管要的是事实不是流程
- 「—」这类空占位不再成行:列不出来的就不展示
- daysText:Math.round(74/30)=2 而 Math.round(75/30)=3,相差一天的两次回访
  被渲染成 2 个月 vs 3 个月。改成按天分档 + 30.44,再修 floor(365/30.44)=11
  让整年读成 11 个月
- 🔴 标签泄漏三次同一形状(cold_3y → 本批 → 备注):**输入里出现的任何标签
  都可能被原样抄进输出**。逐一堵掉

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

- 「待分配」单列一组(amber + 顶部粗边),可拖可删可收拢、默认展开,
  带医生列与已分配一致;⛔ 不处理就是不分,文案必须说清
- 顶栏「共 N 人 · 拟分 X(Y 位客服) · 待分配 Z 人」—— 先给总数再拆,
  光写「拟分 21 · 待分配 39」读不出 21 含不含 39
- 患者/客服姓名点击复制(draggable=false + stopPropagation,否则吃掉整行拖拽)
- 重排后卡片自己交代换了什么 —— 重排走 HTTP 只换卡片,助手不会重新说一遍,
  不交代就是"上面写着 34 人要您定、卡片显示 0 待分配"两份打架的口径
- 🔴 同批指令后一条读不到前一条:「李汝明给李闻,剩下的都给高瑞珍」——
  第二条读的还是旧 state,李汝明被连同其余 31 人一起铺给了高瑞珍,
  而两条都回报"已执行"。改成 moveDraft/dropDraft 草稿,最后一次性提交
- findPatients 要搜到「待分配」、findAgent 要搜到「本批未分到」——
  卡片上看得见的人,指令就必须能指到
- 拖给「未分到」的客服后组标题不再退化成 #678 · 在手 0
- 铺平算水位时排除本次要改派的这批(否则算了两遍)

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

同一个形状一天栽了三次:**工具契约少一格,模型必然填错且静默**,
返回值都是合法的(一个数字、一个 0、一次成功的操作),只有肉眼比对才发现。
追提示词修不好 —— 得补格子。

- 温度枚举只有 hot/warm/cold(缺 cold_2y/cold_3y)→ 主管点「2–3 年」67 人,
  助手报 324。改成从 TEMPERATURE_ORDER 派生 + 中文对照表 + ⛔ 不许把码说出口
- clinicId 必填且无兜底 → 模型编了 CL001,SQL 正确、返回 0,
  助手转头去解释"这批人为什么是空的"。改成可选 + resolveClinicId 兜底,
  范围外**抛错**并列出真实 id,⛔ 绝不当成"这个诊所没人"返回 0
- 确认单指令 8 条并列字面量 → **三个正交的轴**:
  select(patients/agent/pending/batch) × action × to(owner/balance)
  由来:主管说「把待分配的患者各自分给各自的专属客服」,而
  「待分配 × 改派 × 各自的专属」这一格是空的 —— 只有铺平可用,
  18 个人被散给了 17 位别人。而那恰恰是助手唯一不许自作主张干的事。
  正交化不消灭"枚举漏值",但缺的组合变成**表格里的空格**(看得见),
  测试里是一张 test.each 的「说话 → 拼法」对照表,加一行比加一条指令便宜

另:助手第 0 条「说人话」—— 禁说取值码/字段名/工具名/「温度」。

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

三趟落人改成两趟 + 待分配:专属客服排满的人不再被自动改派给别人,
单列一组交主管决策。把患者从他的专属客服手里挪走是关系层面的决定。

「重新排一版」当天推翻两版才定稿,病史都写进注释了:
- v1 预先下发「顶替名单」→ 名单只能从取数窗口挑,池子 19 位无主、
  窗口里只落进 6 位,界面只敢说"顶 3 位"
- v2 把整个窗口丢给落人 + stopAt 跳过 → 水位按 chosen.length 算被窗口撑大
  (⌈(1001+50)/17⌉=62 → ⌈(1001+165)/17⌉=69),34 个"专属排满"的人原地进了
  同一位客服手里(她 59→68,别人 58)。底线没破,但负载塌了、口径全错
- v3(定稿)只换"挑谁":池子里无主的全换进来,其余按优先级用有专属的补满 N,
  然后走完全一样的三趟。有专属的那部分**按客服轮着取** —— 直取前 N 名会把
  名额全给专属大户(111/165 属同一人),另两位客服的余量白白空着。
  实测 拟分 16·待分配 34 → 拟分 31·待分配 19

顺带:确认后可补挂/改/撤福利(此前只改 state 亮角标,DB 一个字没变)。

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

bull-board.module.ts 原注释称「本路由由 NestJS 路由系统接管;需要走全局
JwtAuthGuard」—— 不成立。@bull-board/nestjs 用 ExpressAdapter 自己挂独立
Express handler,不经过 Nest 的路由与守卫。

2026-08-05 从公网实测旧生产(网关把 /admin/queues 转到了 3101):
  GET /admin/queues              → 200,面板 HTML
  GET /admin/queues/api/queues   → 200,队列数据
返回体带 "readOnlyMode":false / "allowRetries":true —— 未鉴权即可翻 job
payload(含 patientId / hostId / tenantId)并重试、清理任务。

加守卫要下沉到 Express 中间件层;而这个面板平时没人用(前端无任何入口链接,
只在 docs/monitoring 里作为排障手段提过),故取成本最低的解法:默认不挂载,
排障时 PAC_BULL_BOARD=1 临时开。

关掉的只是**面板**:队列本身、定时任务、job 消费全部照常,它只是查看器。

同步订正三处文档里「需登录 admin」「豁免前缀」的旧描述。

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

docker-compose.prod.yml 里写死 DOCS_API_URL: https://pac.jarvismedical.asia,
而这份 compose 是**测试服与生产共用**的 —— 于是生产 docs 页上点 Scalar 的"发送请求",
实际打到测试服去。当前生产就是这个状态(不影响文档阅读,但"试一试"跑错环境)。

改为复用 NEXT_PUBLIC_API_BASE_URL:它就是同一个东西(API 的对外地址),
各环境 apps/pac-web/.env 里本来就有 —— 零额外配置,且不会再随环境漂移:
    DOCS_API_URL: ${DOCS_API_URL:-${NEXT_PUBLIC_API_BASE_URL:-http://localhost:3101}}
要单独指定时才设 DOCS_API_URL 覆盖;都没有则退回本地。

⚠️ 它是 **build-time** 参数(server 在 next build 期烘进 SSG 页),
改了必须重新构建 pac-docs 镜像,不是改 env 重启就行。

测试锁住:值必须是变量插值、且不得出现任何具体域名。

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

README 原文「期间 service 秒级重启」会让人以为一两秒,实测三次都在 15.97~16.86s。
force-recreate 不是滚动更新,就是停旧起新,中间必然有真空期。

补三点容易误解的:
  · build 阶段不影响服务(老容器一直跑)→ 部署总耗时长短与停机无关
  · 影响面:API 报错、刷新即恢复;登录态不掉(JWT 在浏览器);无数据风险
  · 要真零停机得网关层蓝绿,不在本脚本范围

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

rootless podman 下 `up -d --force-recreate` 要删**运行中**的容器,而 rootless 杀不掉
它的网络进程,直接失败:
    rootless netns: kill network process: permission denied
失败还留下 <hash>_<proj>-<svc>-1 半成品容器,不清则重建报名字冲突。

改为:主路径不变(直接 force-recreate),**仅在它失败时**回退 ——
清残留 → stop → 重建。docker 侧一行路径都没变,podman 侧多走一次回退。

【停机实测,顺带纠正我自己两次错判】2026-08-04 三组对照(0.5s 间隔探 /health):
    docker + 直接 force-recreate   ~16s
    docker + 先 stop 再 recreate   15.97s
    podman + 先 stop 再 recreate    5.44s
即 **部署本来就有约 16 秒停机,一直如此** —— force-recreate 不是滚动更新,
它就是停旧起新。

⚠️ 第一轮曾测出 docker「0 停机(535 样本全 200)」,那是**测量错误**:
探测有 300s 上限,而那次是全量构建、耗时更长,容器重建发生在探测结束之后
(实测 probe 比 deploy 早结束 29s),535 个样本全采自"还在 build、老容器好好跑着"的阶段。
我据此先判「本改动引入退化」、后判「修正后恢复零停机」,两次都错。
教训:探测窗口必须覆盖被测阶段,否则"全绿"只是没看见。

本改动保留的理由因此不是"避免退化",而是**改动面最小**:docker 走原路径,
只有 rootless 才多一步。

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

2026-08-04 新生产机(Ubuntu 26.04,运维刻意配的 rootless podman:非 root 账号 +
netavark/pasta,攻击面更小)实测:
  rootless netns: kill network process: permission denied
  Error: ... up -d --force-recreate pac-service: exit status 1
失败还留下 <hash>_pac-pac-service-1 半成品容器,要手工清。

根因:force-recreate 要删**运行中**的容器,rootless 杀不掉其网络进程。
手动 stop → rm 实测正常,说明不是普遍权限问题,只是删运行中容器这条路走不通。

改为先 stop 再 up --force-recreate:
  · rootless podman 下通过(网络进程正常退出后再删)
  · docker 上语义等价甚至更彻底(stop 后必然重建,不依赖 compose 判定)
  · 仍保留 --force-recreate,不退回裸 up -d —— 那正是本脚本要绕开的 compose diff 缺陷

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

【podman 差异】docker 默认就是 json-file(写不写行为一样),但 **podman rootless 默认
journald**。2026-08-04 新服务器(Ubuntu 26.04 + podman 5.7 兼容层)实测:
  · `docker logs <c>`  → 只回一行兼容层提示
  · `podman logs <c>`  → 0 行
  · 日志进用户 journal,普通用户不在 systemd-journal 组 → 读不到
等于线上出问题**完全看不到日志**。今天排查那四个增量 bug 全靠 docker logs,这在新环境行不通。
显式声明后两种运行时行为一致。

【顺带治一个既有隐患】此前没有任何 rotate —— 当前生产 /var/lib/docker/containers 已 1.4 GB,
只增不减。50m × 5 = 单容器上限 250MB:够排查近期问题,又不会把盘吃满
(2026-08-01 测试服正是被写满后 Postgres 写不了 pg_wal 崩溃重启)。

用 YAML anchor 统一 7 个服务,避免逐个漂移。对 docker 侧唯一的行为变化是**加了 rotate**,
驱动本身就是原默认值。

顺带纠正一个误判:pac-asr 早已是 `profiles: ["asr"]` 默认不启(当前生产也没跑它),
「迁移时 ASR 不部署」不需要改 deploy 脚本 —— 之前判断错了,已用测试钉住该事实。

测试 828 项(+4)。

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

服务器迁移窗口里新旧实例并存,新实例要能起来接流量、验证配置,但绝不能同时对 DW 做
增量摄入 + persona/plan 重算:
  - 各连各库:两边各拉各的,待迁移的数据快照持续偏移,dump 出来就是旧的
  - 同连一库:互抢 sync_logs 的 partial UNIQUE(host_id) WHERE status='running' 锁,
    还会把对方**正在跑**的锁当"僵尸"回收(判据只看 startedAt 早于本进程启动)

【为什么必须是代码开关,env 关不掉】
  - jvs-dw 的 manifest 写死 auto_sync: true,scheduler 启动即自动发现并注册
  - cron 也写在 manifest(incremental_cron),优先级高于全局 PAC_INCREMENTAL_CRON
  - PAC_INCREMENTAL_HOSTS= 留空只会 fallback 到自动发现
  - 改 manifest 能关,但 deploy-prod.sh 会 git pull 覆盖掉

覆盖范围**只关写、不关读**:
  ✅ sync-incremental(摄入+persona+plan)—— 闸判定放在 reapStaleRunningLocks **之前**,
     禁用态完全不碰 sync_logs
  ✅ stale-scan(enqueue persona 重算)
  ❌ dw-lag-monitor / daily-health-report —— 只发告警和报表,备用实例照常跑反而多一双眼睛
  这条边界用测试钉住,防后来人"顺手统一"掉 → 迁移期静默失去监控。

只认严格的 '1','true'/'yes' 都不算 —— 半开状态比全开更难查。

⚠️ 迁移完成、旧实例下线后务必移除该 env 并重启,否则新生产静默不摄入(只表现为数据越来越旧)。

测试 824 项(+6)。

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

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

原来两个入口共用一个 RAIL_FILTERS_VISIBLE,只要电话这个就得拆开:
  PHONE_FILTER_VISIBLE = true   ← 放回
  TAG_FILTER_VISIBLE   = false  ← 仍隐藏

外层条件跟着两个开关一起判 —— 只判其中一个的话,以后放开另一个时
整排还是不显示,而且不会报错。

服务端谓词一直都在(plan.service.ts 的 patientWhere.phoneVerified),
这次只是把入口露出来;realPhoneOnly 初值仍是"不筛",不会出现看不见的筛选。
`!hasPatientArchive` 守卫保留:宿主自带患者档案时号码整个不展示,
筛「真」没有意义(同 PatientRow 的 hidePhone 判据)。

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

CI 的 openapi-drift 闸只在 MR 和默认分支跑,合 test 时不会拦;
但合 main 时会 fail。在这里补掉,别把债留到下一刀。

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

主管侧批次分配从地基到闭环:三趟落人(专属封顶 → 无主补空 → 有主改派)、
确认单可局部修正、批次归因走 plan_event_logs 账本、通话成效四桶、撤销/退回
分离。企微话术(深度档单块可复制)+ 复制埋点。含路由遮蔽修复 ——
script-feedback / script-copy 此前被 script:regenerate 整个吞掉。

自动合并无冲突;删除的 plans-list-app / task-drawer 等来自 3cbb3899 的重构。

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

「我分过的批次,哪批出问题了?」换成两条能落到工具上的:
  · 总览我在跑的所有分配批次,出个表格  → list_assignment_batches
  · 最近一批分配出份报表:…            → get_assignment_detail

指标措辞用服务端原词:「未动过」不写「曝光」、「已处理」不写「完成」。
后者服务端每次返回都在喊「这是处理率不是成功率」,例句写「完成」会把
模型往"谈成了"上带 —— 同文件里那条「别写转化率」的注释防的是同一件事。
点名的七个指标每个都有真实返回值(planned/untouched/progress.done/
outcomes.success/expired/releaseReasons/byOutcome),不是许愿。

顺带:/assistant 整页的兜底建议此前写死一份客服版,主管在那儿看不到任何
分配入口 —— 而整页恰恰是他做批次活最可能待的地方(表格宽、能铺开)。
按同一个 PLAN_DISPATCH 闸拆成 EXAMPLES_LEADER / EXAMPLES_STAFF。

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

═ 埋点 ═
plan_event_logs 新增事件 script_copy,reason 列存渠道(wecom / phone,都登记进
PlanEventReason —— 那一列的注释写死了"不要在调用处随手写字符串")。

为什么值得记:企微稿的正常用法就是复制出去发给患者,复制那一下之后客服就离开
PAC 了 —— 这是我们能观测到的**最接近"真的用了"**的信号。生成完没人复制 =
生成了但没人用,那是产品问题不是模型问题,而这件事此前完全看不见。

口径(回归里锁着,这两条改错不会有任何编译错误):
· byHuman=false —— 复制 ≠ 联系了患者(复制完可能没发)。算进 HUMAN_TOUCH_EVENTS
  的话「处理过的患者」会静默膨胀成"复制一下也算",与 view 同一类错误。
· holdsPatient=false —— 可能发生在未认领的单上,不参与归属区间。
端点不加认领闸(同 :id/view):主管浏览时也能复制,加闸统计直接偏。

═ 顺带修掉两个真 bug ═
1) 🔴 路由遮蔽 —— **已有的话术 👍👎 反馈按钮从来没生效过**。
   Express 把 ':id/script:regenerate' 里的 :regenerate 当路径参数,模式实际是
   「字面量 script + 参数」,于是 /script-feedback 和 /script-copy 全部命中它
   (参数 = '-feedback' / '-copy')。点一次反馈 = 真的重新生成一次话术:
   花 AI 钱 + 覆盖已有稿,而前端拿到 200、界面一切正常,**不报任何错**。
   治标:字面量路由挪到冒号路由之前(Express 按声明顺序匹配)。
   治本是把 :verb 改成 /verb,会动前端与文档契约,没在这一刀做。
   新增 route-shadowing.spec 用文本扫描锁住顺序 —— 这个 bug 恰恰不会在类型
   或运行时暴露,只能这么防。已验证:把 script-copy 挪回去,测试立刻红。

2) 复制按钮在 http / 宿主 iframe 下**点了毫无反应**。
   navigator.clipboard.writeText 在非 https 或 iframe 里直接 NotAllowedError,
   而原写法把 setCopied 放在它后面 → 不报错、不变文案,客服会以为按钮坏了。
   加 execCommand 回落路径。
   ⭐ 埋点挪到最前面,与剪贴板成败**解耦** —— 记的是"点了复制"这个意图。
   剪贴板被拒时客服往往改成手动选中复制(真的用了),埋点不该跟着一起丢。

实测:点复制 → script_copy | wecom | 操作人 832 | 带批次号 t 落库。
1024 tests,两个 tsc + next build 干净。

基于 docs/design/plan-assignment-doctrine.md 重写成产品视角,放进 docs app
新建的「设计 › 产品设计」分组。

与原教条文档的关系:那份是工程内部的决策留痕(含表名、字段、弯路记录、
踩坑复盘),给开发看;这份只讲**为什么这么设计**和**流程长什么样**,
去掉全部实现细节与代码路径 —— 讲给产品和业务听。

结构按设计思路重排(不按 T 编号顺序):
  问题 → 全流程 → 这是什么 → 谁做什么 → 怎么选人 → 怎么落到人头上
  → 确认单 → 闭环

5 张图代替长段落:
  ① 五步生产线(带反哺回环)  ② 三方职责与唯一写动作
  ③ 初选两轴矩阵            ④ 落人三趟(专属封顶 → 无主补空 → 有主改派)
  ⑤ 一条单子的状态机(含退回/到期/撤销三条回池路径)

保留了对业务最有说服力的两处真实数据:70% 挂在同一客服名下、
封顶前后 248/34/31/14/14 → 每人 20。

实测:docs 已渲染,5 张图全部成 SVG(4 flowchart + 1 stateDiagram),
无残留代码块;导航挂在「设计 › 产品设计 › 召回分配」。
⚠️ 新增 content 目录会让 Fumadocs 索引发僵(整树打不开),
   清 .next/.source 重建才恢复 —— 老坑,已按记录处理。

1) 不再另造生成按钮
   企微视图里的「生成/重新生成」删掉,统一走顶栏那一个入口(与电话稿同一个)。
   两个"生成"按钮=两条路径两套状态,必然不一致。
   切到企微时隐藏档位下拉(只有深度档,摆一个单选下拉是误导);模型下拉保留。

2) 交互与电话深度档一致(过程可见)
   加 GET :id/wecom-script:stream(SSE),事件形状与 script:stream 对齐 →
   前端 ScriptDeepProcess 时间线 / 停止 / AIStamp 整套复用,不另画一套。
   企微一轮跑 60s 上下,没有过程可见就是一个转圈白屏。
   ⚠️ 只推步骤不推正文增量:企微是一整块,逐字推只是闪。

3) ⛔ 禁止输出任何时间占位符
   电话稿留【时间段1】是对的(客服边打边填);企微这条消息是整段复制直发的 ——
   占位会原样发到患者微信里,或者客服得先手动编辑一遍,"可直接发送"当场不成立。
   改成不含具体时间的邀约(「您方便的时候回我一下,我帮您安排」)。
   四处一起改才拦得住:format.md / verify system / verify user prompt / repair 铁律,
   外加策略侧硬扫兜底(只靠 prompt 拦不住,实测模型照着电话档习惯写出来了)。
   forbiddenWordsBlock 加 timePlaceholders 参数 —— 不然它那句「占位照旧保留」
   会和企微 format.md 的「一个都不许出现」拼进同一份 system 打架。

踩的坑:
· 企微 done 事件不带 costYuan → 外层 toast 直接 .toFixed() 整页崩(实测)。
  两条流的 done 形状不一样,别假设一致。
· 步骤时间线渲染了两遍(外层已有一份,我在视图里又画了一份)。

实测:切企微 → 顶栏「重新生成」→ 步骤逐个亮 → 正文出,收尾是
「您看最近工作日哪天方便,回我一下帮您安排复查时间」,无任何【时间段】占位。
1020 tests(1 条并发计时测试在全量负载下抖动,单独跑通过,与本次改动无关),
两个 tsc + next build 干净。

═ 沿用了什么、没沿用什么 ═
共用(直接 import,⛔ 不复制):ScriptContext / buildRichFactBlock 患者事实块 /
  安全护栏 forbiddenWordsBlock / 福利硬约束 / 自报家门占位 / 医生姓脱敏 /
  人群 skills / composeSystem 装配 —— 与"用电话还是企微说"无关。
  复制的代价是护栏两处,改了一处另一处悄悄留旧版,而漏了哪条要等客服已经发给患者才发现。
自己写(draft-wecom-script/):
  · schema:电话 sections[](伴飞逐段高亮要它)→ 企微单块 markdown
  · format.md:口语/分段/口头二选一 → 书面/断行/可复制即发
  · verify 多一条⑤「可直接发送」(无小标题、无占位残留、无给客服看的话、
    无"您现在方便吗"这类需对方当场回话的电话句式)
  · plan 步语义改成"排要点顺序"而非"拆几段"

═ 几个关键取舍 ═
· composeSystem 加 formatPath 覆盖参数,⛔ 不往 ScriptTier 里塞 'wecom' ——
  tier 是质量档、渠道是另一维度,混进一个枚举后"深度档企微"就表达不出来了。
  formatPath 一并进 composeHash(否则两个渠道 promptVersion 撞车,eval 数据混在一起)。
· plan_scripts 加 channel + 改 @@unique([planId,channel]),⛔ 不另立表:
  状态机/source/agentInvocationId/聚合查询全一样,两张表必然漂。
· 企微**无模板兜底**,失败就是 failed。电话失败可以给模板(客服拿着电话必须有东西念,
  平淡但不出事);企微是原样发给患者的,套话复制发出去比没有更糟,而且发出去收不回。

═ 前端 ═
· 话术面板 3 视图切换(伴飞/卡片/原文)隐藏,那个位置改成渠道 tab 电话/企微;
  电话固定「原文」渲染(视图代码整套保留,开关可恢复)
· 企微视图单块 + 复制按钮;whitespace-pre-wrap 原样呈现,⛔ 不过 markdown 渲染器 ——
  客服复制的必须是他看到的那些字
· 执行结果的「触达方式」选择器隐藏(⚠️ 期间 channel 全落 'phone',触达方式分布不可用)

═ 踩的三个坑 ═
1. __dirname 拿不到 format.md(ENOENT):SWC dev 产物在 dist/src/,tsc prod 在 dist/,
   同一个 __dirname 指向不同层级。照抄 resolveScriptRoot 的 cwd 策略。
2. serializeScript 会把正文拆成 sections 并丢原文 → 企微稿 content 长度 0。
   企微单独序列化,不复用那个。
3. ai.module 的 exports 没加(正则打在了 providers 上,那里有同样的三行序列)→
   Nest 启动时 UnknownDependenciesException。

实测:真库生成一份企微稿(单块、空行断段、无小标题、收尾是"您回我一下方便的时间就行"
而不是电话的口头二选一),界面 tab 切换 + 复制按钮 + 【回访客服】按登录人回填全部正常。
1020 tests,两个 tsc + next build 干净。

1) 左栏「真」号码筛选 + 「筛选标签」隐藏
   开关 RAIL_FILTERS_VISIBLE=false,置 true 即恢复;PersonaTagFilter 与服务端
   phoneVerified 谓词都留着,不是删除。
   ⚠️ 藏的只是入口:realPhoneOnly / tags 初值都是"不筛",所以请求里不会残留条件。
   ⛔ 别改它们的初值,否则会出现"看不见的筛选"——列表少人而主管找不到原因。

2) 详情页号码角标:只在已核实时打「真」,未核实**不打标**
   原来给未核实号打「假」,而那是绝大多数 —— 整页每个患者都挂着「假」,既是噪音,
   又在客服正要拨号的那一秒告诉他"这号是假的",平白制造犹豫。
   「未核实」≠「假」:只是外部对照表里没有,号码本身可能完全正常。

3) 列表电话明文(PlanPatientBrief 加 phone)
   脱敏号 138****2417 客服拨不出去,等于每次都要点进详情再拨。
   ⚠️ 不是新开暴露面:详情页早就明文下发同一个号(plan-aggregate.phone),
     两处同权限同 tenant scope。
   ⚠️ phoneMasked 保留:配了原始档案(VIEW_PATIENT)的宿主整行隐藏手机号,
     两个字段都不显示 —— 别因为加了明文就把脱敏删了。

1020 tests,两个 tsc + next build 干净。按你说的没进浏览器调试。

前一刀(跳转前必答)让 plan_executions 有数了,这一刀把它接进批次报表。

1) plan_executions 加 assignment_id
   理由与 plan_event_logs 那次一字不差:followup_plans.assignment_id 会被下一次
   分配覆盖,时间窗是启发式不是键。
   ⚠️ 落这一列的判据是 assignment_expires_at != null(「非空 ⟺ 有一次在办的分配」),
   ⛔ 不是 plan.assignment_id 非空 —— 后者在退回后仍留着(那是退回率的分母),
   此时客服自己捞回来打的电话会被算进一个早就结束的批次。

2) detail 增加 outcomes:success / failed / keep / noOutcome / byOutcome / note
   · 每个患者只取最近一次执行(DISTINCT ON) —— 打三次才约上是一个成功不是三个
   · noOutcome 单独成桶:那不是效果差,是根本没做/没记。并进 failed 会把执行问题
     读成召回问题,而两者要改的东西相反
   · 四桶穷尽 success+failed+keep+noOutcome === planned

3) ⛔ outcomes 与 releaseReasons 不能互相顶替(工具描述里也写死了)
   releaseReasons = 没打就还回去(分配问题);outcomes = 打了结果这样(召回效果问题)

写这一版时踩了一次:noOutcome 里多减了 reassigned → 被压成 0。
「现在归谁」与「做没做」是正交维度,不能放进同一个减法。已加回归锁住。

实测(真库):3 人批次打 refused + no_answer → 执行带批次号落库 →
详情读出「成功 0 · 不成功 1 · 打了没进展 1 · 一次结果都没有 1」,四桶合计 3 === planned 3,
明细「明确拒绝 1」,note 自带样本不足与「成功含约定下次回访」两条护栏。
1020 tests,两个 tsc 干净。

═ 为什么 ═
这两个按钮跳走之后客服基本不回来 —— 这正是 plan_executions 回写率只有 11%
(生产 65 个认领单只有 7 条结果)的根源。回写率低到这个程度,"成功率""退回率"
全是猜的。⇒ 把一次必答的极简输入挪到跳转之前:人还在 PAC 里、手还在键盘上,
那一刻才录得到。

═ 做了什么 ═
1) 吸附在按钮上的小浮层(Popover),各只收**一个必填**:
   · 预约 → 备注   → 落 success_appointed(结案 + 60 天抑制)
   · 跟进 → 下次时间 → 落 scheduled_next(不结案,snooze 到那天)
   多一个字段都不行 —— 这是拦在人和他真正想做的事之间的门,门越重越会被绕开。

2) scheduled_next 的 group: keep → close(「保持」→「成功」)。
   ⚠️ drivesStatus 保持 'keep' —— group 与状态机在这一项上**故意不一致**:
   算成功是统计口径,工单必须留着 snooze 到回访日。改成 completed 的话,
   客服刚答应患者"那天再联系您",这单当场出池,约好的回访再也不会发生。
   面板分组是读 meta 现算的 → 「保持」组自动只剩未接通/秒挂,历史数据一并重归类。

═ 几条纪律 ═
· **先落库、后跳转**。反过来的话写失败人已跳走,他会以为记过了。
· URL 未配置时**先拦住**,⛔ 不先把单结了再告诉他跳不过去。
· channel 记 'other',⛔ 不许默认 'phone' —— 我们不知道他怎么触达的,编一个会把
  触达方式分布做脏。
· 浮层里写明后果(「记为转化新预约并结案」)—— 不写就是让他在不知情下关掉工单。

实测(真库):跟进 → scheduled_next/other/2026-08-12 落库,plan 仍 assigned +
snoozed_until=回访日;预约 → success_appointed + 备注落库,plan → completed。
未配 URL 时确认不落库、浮层保持打开。新增 taxonomy 回归锁住 group/drivesStatus 分离。
1013 tests,两个 tsc + next build 干净。

开关 HEADER_PRIORITY_VISIBLE=false,置 true 即恢复;
代码整段保留(含 hover 的算分明细),不是删除。

⚠️ 只关头部这一处。左栏每行的优先级分数不动 ——
那是主管挑人的排序依据,隐藏了他就没法判断先跟谁。

实测:头部已无「优先级」;左栏分数 7.38/6.78/6.70 完好。tsc + build 干净。

召回池每行都写「待分配」、我的每行都写「进行中」—— 整列同一个词,
读者第二行就不再看它,却一直占着行尾最值钱的位置(退回按钮就在那儿)。

⛔ 但不能把药丸整个删掉:「我的」不带 status 过滤(where.assigneeUserId = 我),
已完成 / 已放弃的单也在这一栏里,而那两个才是真要一眼看见的。
删掉等于让客服分不出哪条已经结案。

⇒ 按「这一行是不是本视图自身的定义」判断:
  pool → 隐藏 active,mine → 隐藏 assigned,其余照常显示。

两栏处理还不一样:
  · 召回池没有退回按钮 → 默认态**整个不渲染**(留 42px 空白纯属白占,
    而右侧正是手机号/诊所名要用的地方)
  · 我的有退回按钮,药丸与它叠在同一 grid 格、格宽取较大值 →
    默认态用 invisible **占位**,否则 hover 前是 0 宽,按钮一冒出来整行位移,
    而那个叠层机制存在的全部理由就是防这个

实测:召回池 25 行 0 个药丸;我的 22 个药丸全 invisible、占位 42px,
hover 姓名位移 0(退回按钮 37px 落在占位内)。tsc + build 干净。

上一刀把 released 计数改成账本口径,但**分布和名册还读 followup_plans**,
于是自己跟自己对不上:

  followup_plans.release_reason 是当前值,而 assign 的 SQL 里有 release_reason = NULL
  → 一条退过的单被后面的批次挑走后:
      released      1  (账本)
      releaseReasons []  (列已被清空)
  主管看到"退了 1 条"却没有任何原因,会以为是客服没填。实测复现。

更糟的是 agentStats 的名册按当前 plans 建 —— 被挑走的人从所有人名下蒸发,
「各人之和 === planned」这条本仓最早锁的不变量当场破(而 planned 已是账本口径)。

修法:名册与退回都从本批账本事件建(按 assignment_id 取,不是按当前 planIds)。
  · release 事件自身 assigneeUserId 是 null → 按 planId 回查 assign 的原始承接人
  · 同一 plan 多条 assign(退回→自认领→再退回)去重后计数
  · 老批次(账本没批次号)整条回落到原路径,行为不变

实测(真库):把退过的那条重新分配一次 → 列被清空、账本仍在 →
  分布之和 1 === released 1;agentStats 各人之和 9 === planned 9。
1008 tests,tsc 干净。

主管四问引出的一组修复。

1) 归因失血(不报错的真 bug)
   followup_plans.assignment_id 会被下一次分配覆盖 —— 一条单退回/到期回池后
   被后面的批次挑走,旧批次就少一个人。批次跑得越久缩得越厉害。
   实测 c02e1b80 分过 9 条,重分后 planned 显示 0。与 supersededAt 那坑同构。
   ⇒ plan_event_logs 加 assignment_id(不建明细表:账本本来就是明细,
     缺的只是"属于哪一批"这个维度;该表自己写着"要按它筛就该立柱")。
     四个写入点全覆盖;claim 刻意不写(自认领捞的是池子,plan 上那个 id 是陈迹)。
   ⇒ planned/agents/released/expired 走账本,inHand/done 走当前状态。
   ⇒ 补 progress.reassigned 让穷尽性重新成立(不补则主管一对数就少人)。
   ⇒ 老批次回落到 followup_plans 现算;到期数无源可落,只能给 0。

2) 到期终于能统计
   到期事件一直在账本里(auto_release + assignment_expired),但任何接口都没报,
   全被 backToPool 一桶吞掉。而到期与退回主管的下一步动作相反:
   退回多=分配策略不对,到期多=派多了/时效太紧。现在分开报,note 也分开说。

3) overdue 加 snoozed 守卫
   回收器刻意跳过"约了下次回访"的单,于是它们永远超期;而 progress 已把它算作
   suppressed(已处理)。不加守卫,同一条单「已处理」和「超期」同时成立 ——
   主管看到「薛玫 超期 3」以为她压单,实际她打了电话约好了下次。

4) 批次人话名 label(服务端唯一生成)
   「8/3 23:35 · 牙周治疗 · 窗口内 · 9 人 · 2 位客服」。没有列表页时这是主管
   指认一批的唯一抓手。做这个才发现 temperature 一直没进 criteria 快照 ——
   它参与圈人却没随确认单下发,导致批次说不清"当时按哪个温度圈的"。已补。

顺带修一个潜伏编译错误:assignmentExpiresAt 加进 FollowupPlanSchema 时漏了
serializePlan(19bd658f)。当时没报错是因为 packages/types/dist 是旧的。

实测(真库):新批次 9 人 → 撤销 → 同一批人重分 → 旧批次 planned 仍是 9
(旧实现下是 0)、五桶+重分 0+0+0+9=9;退回 1 条、到期 2 条(等回收器真扫)
分别落账,详情读出「客服主动退回 1 条、到期没人动 2 条」。
1005 tests,两个 tsc + next build 干净。

走查两条:

1) loading 文案闪
   - 加最短停留 700ms(useStickyLabel)。get_current_user / get_agents 这类
     100ms 就返回,文案在屏幕上活不过两帧,主管只看到一片闪烁,反而以为卡了;
     慢工具的文案看得见,于是他以为"只有那一句"。
     用「最新覆盖待显示」而非排队 —— 排队会在活干完后继续播,5 个快工具能
     拖出 3 秒假忙碌。上限就是一个停留周期。
   - 修并行调用:原来只看最后一块,3 个工具并行时最后那块可能已 done 而前两个
     还在跑 → 退回「生成中」,前两句文案一次都不出现。改成找还在跑的那个。
   - 补齐 4 个漏掉的工具中文名(get_cohort_attributes / edit_assignment_sheet /
     revoke_assignment / render_artifact),此前兜底把英文工具名摆给主管看。

   实测(多工具一轮):5 个文案,最短 955ms,无一低于 700ms。

2) 输入框占位符 + 开场建议是客服口径
   主管打开助手是来分配和看批次的,占位符从不提这两件事 = 把一半能力藏起来。
   按 PLAN_DISPATCH 分两版(与召回池/确认单同一个闸)。
   顺带删掉「(Enter 发送,Shift+Enter 换行)」—— 输入框只有 300px,而原句 450px,
   那半句从来就没显示出来过,占着长度却看不见。

996 tests,web tsc + next build 干净。