| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| admin | ||
| ai | ||
| assistant | ||
| auth | ||
| clinical-gap | ||
| clinical-signals | ||
| facts | ||
| mcp | ||
| patient | ||
| persona | ||
| plan | ||
| plan-aggregate | ||
| realtime-coach | ||
| sync | ||
| weixin-aibot |
上一刀把 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 干净。
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| admin | Loading commit data... | |
| ai | Loading commit data... | |
| assistant | Loading commit data... | |
| auth | Loading commit data... | |
| clinical-gap | Loading commit data... | |
| clinical-signals | Loading commit data... | |
| facts | Loading commit data... | |
| mcp | Loading commit data... | |
| patient | Loading commit data... | |
| persona | Loading commit data... | |
| plan | Loading commit data... | |
| plan-aggregate | Loading commit data... | |
| realtime-coach | Loading commit data... | |
| sync | Loading commit data... | |
| weixin-aibot | Loading commit data... |