**① 只报最忙一位,分不出两种相反的局面**(产品定): · 只有他一个人超 → 该给他少分点 / 改派几个 · 全队都超 → 该减少这批 / 延长时效 同一句话、相反的处置 —— 而本节点唯一的选项是「整批时效改成 N 天」, 碰上第一种局面它本身就是错的(为一个人的负载去延长整批时效)。 ⇒ why 里补「另有 N 位也超过 X 天;每位分完之后要打几天,确认单上逐位都写着」。⚠ ️ 只加一个数 + 一句引路,⛔ 不在引导里铺开每个人:确认单每行已经有「约 N 天」, 分布本来就在眼皮底下(引导节点的职责是点出要他定的事,不是展示数据)。⚠ ️ 只有一个人超时那半句**不出现** ——⛔ 不制造无谓噪音。📌 加在**工具产出的数据**里(`daily_overload` 的 why),⛔ 没动提示词 —— 模型从返回值里直接读,不需要被提醒(工具返回值 > 提示词)。 **② 团队面板那段注释与 SQL 打架**:注释把「超期」和「在手」并列写成"与窗口无关", 而 SQL 里是 `assignment_expires_at >= since` —— **SQL 是对的**: 一年前过期的单报上来对主管没意义,他此刻能处置的只有近期这批。 ⇒ 改注释、⛔ 别照注释去掉 SQL 的窗口,并把理由写在旁边。 新增 2 条测试(多人超时 → 报数并引到确认单;只有一人超 → 那半句不出现),1298 全绿。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| dto | Loading commit data... | |
| engine | Loading commit data... | |
| recall-debug | Loading commit data... | |
| agent-roster.service.ts | Loading commit data... | |
| assignment-expiry.scheduler.ts | Loading commit data... | |
| assignment-facts.ts | Loading commit data... | |
| assignment-proposal.service.ts | Loading commit data... | |
| assignment-signals.ts | Loading commit data... | |
| assignment.controller.ts | Loading commit data... | |
| claim-guard.ts | Loading commit data... | |
| cohort-attributes.service.ts | Loading commit data... | |
| cohort-filter.ts | Loading commit data... | |
| dispatch-guard.ts | Loading commit data... | |
| execution-callback.service.ts | Loading commit data... | |
| execution.service.ts | Loading commit data... | |
| plan-assignment.service.ts | Loading commit data... | |
| plan-event.recorder.ts | Loading commit data... | |
| plan.controller.ts | Loading commit data... | |
| plan.module.ts | Loading commit data... | |
| plan.service.ts | Loading commit data... | |
| reason-temperature.sql.ts | Loading commit data... | |
| recall-suppression.ts | Loading commit data... | |
| recycle-scheduler.service.ts | Loading commit data... |