service/cases 的《自动发生的事》:70/:71 是同族第三处未清扫的 SLA 说法——「SLA 截止日期按优先级计算」只对 critical 成立、「违约标记按解决时间超目标翻转」是另一套机制,字段名也不存在 #925

发现自 #914 / #915 的实施过程(清扫 cases / index 两页升级与通知说法时,顺链读了 cases 页的 SLA 相关行)。

#886 / PR #885、#903 / PR #918 已经把 content/docs/service/sla-and-escalation.mdx 的 SLA 计算与跟踪两节按 hook / flow 写实。content/docs/service/cases.mdx 上同一族的三处说法不在那两单的行清单里,原样未动,而且它们出现在读者更早读到的《自动发生的事》清单中。

基线 origin/main = 6014b2cf(PR #913 / #916 / #918 / #919 之后),平台 17.0.0-rc.3。行号为 main 上的行号;PR #922(#914 / #915)只动 :34 与 :89 以后,故这三处行号不受它影响,唯 :111 在 #922 合并后变为 :114。

逐条

:70 —— SLA 截止日期「工单创建时根据优先级计算」

70: - SLA due date — calculated when the case is created, based on priority.

zh-Hans :70:- SLA 截止日期——工单创建时根据优先级计算。

只对 Critical 成立。src/objects/case.hook.ts:60 的 case_sla_defaults:

if (priority === 'critical' && !input.sla_due_date && !ctx.previous?.sla_due_date) {
  const due = new Date();
  due.setHours(due.getHours() + 4);
  input.sla_due_date = due.toISOString();
}

High / Medium / Low 一个字节都不写,字段就停在空值,除非有人手工填。兄弟页 sla-and-escalation.mdx:12 已按这条写实(「Only Critical cases get an SLA due date automatically……At High, Medium and Low it writes nothing」),cases 页仍在承诺四个优先级都有。而且该 hook 绑的是 beforeInsert + beforeUpdate,「工单创建时」也漏掉了「编辑为 Critical 时」这条路径。

:71 —— 违约标记「解决时间超过 SLA 目标则翻转为 true」

71: - SLA breached flag — flipped to true if the resolution time exceeds the SLA target.

zh-Hans :71:- SLA 违约标记——如果解决时间超过 SLA 目标，则翻转为 true。

机制不对。真正写这个字段的是 src/flows/case-sla-monitor.flow.ts 的每小时扫描:它选的是仍未结(status 不是 resolved / closed)且 sla_due_date 已过期、is_sla_violated 还是 false 的工单,然后置真。它从不比较解决时间与目标 —— sla-and-escalation.mdx:34 已经把这一点写实(「It does not measure resolution time against the target」),并点出两个后果:没有截止日期的工单永远不是候选;晚解决但赶在下一次扫描前解决的工单永远不会被标记。cases 页写的是被替换掉的那套说法。

:59 / :111 —— 字段名 breach flag 不存在

59: | SLA & Priority | Status, priority, type, first response time, SLA due date, breach flag |
111: - SLA breach flag and Resolution time are read-only for agents ...

sla-and-escalation.mdx:34 已明确:「there is no field called SLA Breached?; the checkbox agents see is labelled SLA Violated」,字段是 is_sla_violated。cases 页三处仍叫 breach flag / 违约标记(中文两页的译名倒是对的,英文页的字段名不对)。:111 那句「对客服只读」经核对属实(Service Agent profile 对 crm_case.is_sla_violated 的 FLS 掩码,见 sla-and-escalation.mdx:36),只是字段名要跟着改。

为什么要紧

一个管理员照 :70 去排查「为什么 High 工单没有 SLA 截止日期」,会以为是 bug;一个客服照 :71 去理解违约标记,会以为关单时才判定,而实际上是每小时扫描按截止日期判定 —— 两条都会让人对着正确运行的系统找错。同一页 :27-:32 的优先级表把四个数字并列为「Typical SLA target」,读者拿到的整体印象就是四条都有时钟。

边界

• 三语同步:content/docs/service/cases{,.zh-Hans,.zh-Hant}.mdx,:59 / :70 / :71 / :111 各 4 行 × 3 语言 = 12 行。
• 与 service/cases 的「工单升级」整节(:89–100)与 :34 是 PR #894 未清扫的同族副本:High+Customer 分支、改派给经理、跟进任务归原客服、通知客服+经理+支持团队 #914 / service/index :27「*紧急*会立即提醒支持经理」是同页 :37 那条虚构收件人的第二份——#904 的行清单没有列到它,PR #913 落地后同页自相矛盾 #915(PR docs(service): cases 升级整节与 index 生命周期第 2 步按 flow / hook 写实(#914、#915) #922)不重叠:那个 PR 只动 :34 与《工单升级》整节(:89-:100),以及 index 页 :27。
• 与 service/sla-and-escalation 剩余六处失实(#903 四族之外):营业时间可配置、SLA 表现报表的四个维度、Breached SLA 视图、Service Board 看板、My Open Cases 排序、Waiting on Customer 暂停 SLA 时钟 #917 不重叠:那单是 sla-and-escalation 页剩余六处,不含 cases 页。
• 与 administration/state-machines 通篇声称状态机会「拦下」非法转换，实测五条规则全是 warning：保存照样通过；连「只显示合法下一状态」「bypass state machine 权限」都无实现 #920(:78 状态推进)、bare workflows 残留族在 #899 枚举之外还有 4 处：whats-new 把真实的 contract_renewal 流程叫成 workflow，state-machines:133 在 PR #894 扫过该文件后仍留着 #912(:80 标题)不重叠。
• SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判:High / Medium / Low 是否应该有自动 SLA 时钟是产品问题,本单只写实当前行为。
• 口径抄平 service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 / PR docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 与 service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 / PR docs(service): SLA 跟踪一节按实测行为改写(#903) #918 在 sla 页已落地的写法:点名说清哪一档没有时钟 + 写出真实机制与真实字段名,不静默删掉数字。
• :27-:32 优先级表要不要加一句限定(四个数字中只有 Critical 有时钟),连同本单一并判断即可,不必另立一单。

Refs #886 #903 #914 #917