service/cases 的「工单升级」整节(:89–100)与 :34 是 PR #894 未清扫的同族副本:High+Customer 分支、改派给经理、跟进任务归原客服、通知客服+经理+支持团队 #914

发现自 #904 / PR #913 的实施过程(清扫 service/index 同族说法时,顺链核对了 sla / cases 两页的现行文本)。

#887 / PR #894 在 content/docs/service/cases.mdx 上认领并写实的是《工作流自动化》一节的 :82 / :83 与管理员提示 :178 —— 那三处现在是对的。但同一页的另外两处仍是原样未动的旧说法,而且比已改的那三处更完整地复述了全部虚构:一个不存在的触发分支、一次不存在的改派、一条归属错误的任务、一封发给三方的邮件。不在 #887 的切割里,故单独立单。

基线 origin/main = 7df29789(含 PR #894 / #906 / #907 / #910),平台 17.0.0-rc.3。三语同行号,共 7 行 ×3 语言 = 21 行。

逐条

:34 —— Critical 通知支持经理 + High/Customer 自动升级

When a case is set to Critical, the support manager is notified by email. When set to High for a customer account, the case is auto-escalated.

两句都不成立,且与同页 :82(PR #894 已写实)直接打架::82 说收件人是 {caseRecord.owner_id} 一人、support_manager@example.com 不存在,:34 在它上方 48 行说支持经理会收到邮件。High/Customer 分支同理 —— src/flows/case-escalation.flow.ts 的 start 条件全文只有 record.priority == "critical",全仓 24 个 flow 无一处读取账户类型(#886 已按同一实测把 sla 页写实)。

:89–:100 —— 升级触发条件与五步清单

89: The Case Escalation flow runs automatically when:
91: - Priority is Critical, OR
92: - Priority is High AND the account is a Customer (not a prospect)
94: It performs:
96: 1. Reassign the case to the agent's manager.
97: 2. Flag as escalated, stamp the escalated date.
98: 3. Set status to Escalated.
99: 4. Create a follow-up task on the original agent due tomorrow.
100: 5. Notify the agent, the manager, and the support team via email.

这正是 #876 / PR #885 在 sla 页逐条写实过的那份五步清单,原封不动地留在 cases 页上:

• :92 的 High+Customer 分支不存在(同 :34);
• :96 的改派不存在 —— update_record 节点只写 is_escalated / escalation_reason / escalated_date / status,注释开头即 No owner reassignment,通知正文自己写着 It remains assigned to you.;
• :99 的跟进任务归属错 —— flow 里根本没有任务节点,任务由 src/objects/case.hook.ts 的 case_status_side_effects 钩子开出,owner_id 取的是账户负责人(account.owner_id),且仅限有关联账户的工单;
• :100 的三方邮件不存在 —— recipients 只有 {caseRecord.owner_id} 一项,grep -rn "support-team@\|support_manager@" src/ 零命中。

:97 / :98(打标记 + 改状态)经核对是对的,与 sla 页 :70 / :71 一致,不要顺手改。

为什么要紧

:34 与 :82、:89–:100 与 :82/:83 在同一页里互相矛盾:PR #894 把《工作流自动化》一节修好之后,读者在这一页上同时读到「发给工单负责人一人」和「通知客服、经理和支持团队」,而后者带着一份看起来更权威的编号清单。

边界

• 与 service/index 的「工作流程 / 系统为你做了什么」两处清单是 #876/#885/#894 已清掉那批说法的未清扫副本：升级会重新分配给资深客服、High+Customer 分支、通知支持经理 / 升级团队、红色横幅 #904 / PR docs(service): 把 service/index 的升级与通知五条说法按 flow / hook 写实(#904) #913 不重叠:那单只动 content/docs/service/index{,.zh-Hans,.zh-Hant}.mdx 的 :30/:36/:37/:38/:40。
• 与 service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 / service/cases 三语的「工作流自动化」清单同样写着虚构的 support_manager@example.com 与「向升级团队发邮件」，实际收件人是工单负责人一人 #887 不重叠:两者的行清单里都没有本单这 7 行。
• SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 / Case intake: round-robin assignment + triage view so web-to-case never lands ownerless #596 不预判:升级是否应该改派、High 是否应该自动升级是产品问题,本单只写实当前行为。
• 三语同步;口径直接沿用 PR docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885(sla 页 :53/:57/:61/:62/:78/:80)、PR docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894(cases 页 :82/:83)、PR docs(service): 把 service/index 的升级与通知五条说法按 flow / hook 写实(#904) #913(index 页)已落地的写法逐句抄平——点名说清不做什么 + 真实归属,不静默删名。
• :89 的中文页内链带着英文锚点 #case-escalation,在中文标题的页面上落不到任何位置(docs(guides): email-and-calendar 按实测改写——Log a Call 的三写路径、活动指标所在仪表盘、连接器段落标注未落地 (#738) #755 / docs(guides): 按实际落地能力重述 integrations 页，并校正指南索引描述行 (#756) #762 惯例、content/docs 还剩 17 处悬空锚点（全仓实测），三类新成因：emoji 标题、标题后来加了后缀、zh 页沿用英文锚点 #866 记录的成因之一);若重写这一行,顺手去掉锚点。

Refs #876 #886 #887 #904