service/index 的「工作流程 / 系统为你做了什么」两处清单是 #876/#885/#894 已清掉那批说法的未清扫副本：升级会重新分配给资深客服、High+Customer 分支、通知支持经理 / 升级团队、红色横幅 #904

发现自 #886 / #890 的实施过程。#890 在本页认领的是 :48（「建议一个解决方案」的技能主语），改完后同页上方 15 行内还留着五条同族说法——它们是 #876 / PR #885（sla 页）与 #850 / #887 / PR #894（cases 页）已经逐条写实过的那批主张，在 service/index 上的未清扫副本。不在 #890 的切割里，故单独立单。

基线 origin/main = 90686a4f（含 PR #885 / #894 / #895）。content/docs/service/index.mdx，zh-Hans / zh-Hant 同行号，共 5 处 ×3 语言 = 15 行。

逐条

:30 —— 升级会把工单重新分配给资深客服（外加 High+Customer 分支）

> 5. If it's stuck (or critical, or a customer's), the escalation process reassigns it to a senior agent.

两个错。重新分配：src/flows/case-escalation.flow.ts 的 update_record 节点只写 is_escalated / escalation_reason / escalated_date / status，从不碰 owner_id；节点注释开头就是 No owner reassignment，因为 {caseRecord.owner_id.manager} 穿不透 lookup、会插值成字面量 undefined。通知正文自己写着 It remains assigned to you. —— PR #885 已在 sla 页把同一说法（三处）写实。"or a customer's"：start 条件全文只有 record.priority == "critical"，24 个 flow 无任何账户类型条件 —— 与 #886 认定的 High+Customer 分支是同一个不存在的东西。

:36 —— 自动升级「紧急工单或高优先级客户工单」给资深客服

> - Auto-escalate critical cases or high-priority customer cases to a senior agent.

同上两个错的浓缩版。#886 已按实测把 sla 页写成「只有 Critical 会自动升级；High 工单永远不会，无论账户是不是 Customer；升级不改 owner」，本行是它的原样副本。

:37 —— 「紧急时通知」会给支持经理发邮件

> - Notify on critical — emails the support manager whenever a case is set to Critical.

recipients 只有 {caseRecord.owner_id} 一项；grep -rn "support_manager@" src/ 零命中。PR #885 已在 sla 页的《其他工单自动化》表把这一行写实（「站内消息 + 邮件发给工单负责人……本应用中不存在 support_manager@example.com 这个收件人」），本行是漏网的第二份。

:38 —— 「升级时通知」会给升级团队发邮件

> - Notify on escalation — emails the escalation team whenever a case is escalated.

escalation_team@example.com 全仓零命中，且状态转为 escalated 根本不发消息 —— 它触发的是 case_status_side_effects 钩子创建的、给账户负责人的紧急跟进任务。同样由 PR #885 在 sla 页写实过。

:40 —— SLA 违约会显示红色横幅

> - Flag SLA breaches with a red banner once the SLA target passes.

grep -rn "banner" src/ 在整个 app 里只有 src/objects/opportunity.object.ts:281 一句无关注释 —— 没有任何横幅机制。#886 已按这条把 sla 页 :16 的 Critical 违约行写实。违约的真实表现是 is_sla_violated 被置真、工单被升级，外加 src/flows/case-sla-monitor.flow.ts:84 发给 {currentCase.owner_id} 一人的站内消息 + 邮件。

同段的另两条经核对是对的，不要顺手改：:39「关闭时自动标记解决时间」（case.hook.ts 确实算 resolution_time_hours）、:41「未写解决方案不能关单」（对象上有对应校验）。:35「用工单分流技能自动确定优先级」也成立。

为什么要紧

这是同一批说法里覆盖面最广的一页——service/index 是服务域的落地页，大多数读者先读到它。sla 与 cases 两页已经写实之后，本页仍在原样承诺重新分配、两个不存在的收件人和一个不存在的横幅，读者拿到的是自相矛盾的两套描述，而更显眼的那一套是错的。

边界

• 与 service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890 不重叠：service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890 认领 :48，本单是 :30、:36、:37、:38、:40。
• 与 service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 不重叠：service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 全部落在 service/sla-and-escalation。
• 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 / docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 在 sla / cases 两页已落地的写法（点名说清不做什么 + 真实归属，不静默删名），逐句可对照抄。

Refs #876 #850 #886 #887 #890