生产实遇(杭州大厦,2026-08-20):确认单 537 条,点「确认分配」只回一句
「请求字段校验失败」,主管在卡片上改什么都没用。

根因是**提案层不知道确认接口的上限**:

  基数 = 在岗人数 × 每人每天通话数 × 时限天数 = 23 × 15 × 3 = 1035
  target = min(基数, 候选总数)                = min(1035, 5996) = 1035
  落人后 items                                 = 537
  确认接口 CreateAssignmentRequestSchema        items.max(500)   ← 撞这里

⚠️ 不是边界情况:**12 个客服以上、用默认值就必然触发**(12×15×3 = 540 > 500)。

修法一:target 多取一个 min。与既有的「候选不够就压低 target」完全同构,
且同样 ⛔ 不回写基数(回写会把主管的习惯值永久钉死在 500)。
⛔ 不是把 HARD_LIMIT 调大 —— 它是技术护栏(单事务 + PG bind 变量上限),
   不是业务旋钮,schema 那条注释写得很清楚。

修法二:让报错说人话。这一条独立于上面 —— 就算永不再触发,
下一个撞上 zod 校验的人也不该只看到七个字。

  · schema: items.max 带自定义 message,含具体数字与下一步动作
  · 前端:  确认失败时拼 ApiError.details 里的字段级 message
           (服务端 all-exceptions.filter 早就把 details 带出来了,前端只取了 msg)
  ⚠️ 只拼 message,⛔ 不拼 path/code —— 「items」「too_big」对主管没有意义,
     只会让他觉得"这是 bug,不是我该处理的事"。

排查期间未做任何确认操作:plan_assignments 仍为 0 行。

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