主管在确认单上看「每个人要打几天」——「约 N 天」落在每位客服那一行,
超出本批时效只用**颜色**(琥珀)提示。

⚠️ 算的是**分完之后手上的总量**(在手 + 本批),⛔ 不是本批那几条:
  他手上原本压着的也要打,只算增量这个数会系统性偏小。
⚠️ 与 daily_overload 引导节点**同一个式子** ceil(总量 / 每天几通):
  那条只报最忙的一位,这一列把每个人都摆出来,⛔ 两处别算出不同的数。
⛔ 措辞不带「打不完 / 超了 / 过载」——它几乎每批都会有人超,说成故障
  主管就会开始怀疑系统而不是做决定(同引导节点那条纪律)。
  在**卡片里现算**:他拖一个人、点一个 ×,这个数当场就变;服务端那份是快照。

做这个功能撞出两个真 bug:

① **换算尺根本没跟着提案回来。** dailyCalls 此前**只是 propose 的入参**,
   算完就丢 —— 主管说过「每人每天按 20 通算」之后,卡片和 modelFacts 里
   **仍然写死常量 15**:「按每天几通算: 15」和他刚说的 20 直接打架,**而且不报错**。
   与 rosterCount 同一条理由:**乘法用到的数必须跟着积一起发**。
   现在 daily_overload 的判定与措辞、batch_size_basis 的式子、那个输入框的预填值
   全读 p.dailyCalls,⛔ 不再引常量(顺带修掉:他填了 20,下次输入框还预填 15
   = 又把他的改动抹了)。

② **「重算丢东西」的第四个** —— 按自己写的通例一测就撞上:refill 那条路不收
   dailyCalls,主管改成 30 通再点一下「补上」,天数整列悄悄退回按 15 算。
   ⚠️ 它**不影响人数**(targetCount 已显式带回),只改换算与呈现 ——
   正因为不影响人数,比前三个更难被发现。已补齐 schema / controller / 前端,
   并加进契约测试那条通例(注明这一点)。

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