service/index :27「*紧急*会立即提醒支持经理」是同页 :37 那条虚构收件人的第二份——#904 的行清单没有列到它,PR #913 落地后同页自相矛盾 #915

发现自 #904 / PR #913 的实施过程。

#904 逐行核对了 content/docs/service/index.mdx 的两处清单,认领的是 :30(生命周期第 5 步)与 :36/:37/:38/:40(《系统为你做了什么》四条),并明确点出 :35/:39/:41 经核对属实。但生命周期清单里的 :27 没有被枚举到,而它承载的正是 :37 那条虚构收件人:

27: 2. Priority is assigned — Low, Medium, High or Critical. Critical alerts the support manager immediately.

zh-Hans :27:2. 分配优先级——低、中、高或紧急。紧急会立即提醒支持经理。
zh-Hant :27:2. 分配優先順序——低、中、高或緊急。緊急會立即提醒支援經理。

事实

Critical 触发的通知就是 src/flows/case-escalation.flow.ts 的 notify 节点,recipients 只有 {caseRecord.owner_id} 一项,channels: ['inbox','email'];grep -rn "support_manager@" src/ 全仓零命中。这与 #886/#887/#904 认定的是同一条虚构 —— PR #885 已在 sla 页 :92 写实、PR #894 已在 cases 页 :82 写实、PR #913 刚在本页 :37 写实。

为什么现在要紧

PR #913 落地后,本页 :37 写「站内消息 + 邮件只发给工单负责人……本应用中不存在 support_manager@example.com 这个收件人」,而它上方 10 行的 :27 仍写「紧急会立即提醒支持经理」。矛盾是同页、同屏可见的,且 :27 位于读者先读到的编号清单里。PR #913 严格按 #904 的行清单执行,没有顺手扩围,故留此单。

顺带

:27 也是本页把 Critical 译成「紧急」的唯一一处;PR #913 按兄弟页(sla / cases)已落地的口径在改写行里用了拉丁写法 Critical / High。若重写 :27,一并对齐即可,不必另立一单。

边界

• 三语同步,content/docs/service/index{,.zh-Hans,.zh-Hant}.mdx 各 1 行,共 3 行。
• 不要顺手改同清单的 :26/:28/:29/:31(未核对)与 service/index 的「工作流程 / 系统为你做了什么」两处清单是 #876/#885/#894 已清掉那批说法的未清扫副本：升级会重新分配给资深客服、High+Customer 分支、通知支持经理 / 升级团队、红色横幅 #904/docs(service): 把 service/index 的升级与通知五条说法按 flow / hook 写实(#904) #913 已处理的 :30/:36–:41。
• 口径抄平 PR docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 / docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 / docs(service): 把 service/index 的升级与通知五条说法按 flow / hook 写实(#904) #913:点名说清不发给支持经理 + 写出真实收件人,不静默删名。

Refs #886 #887 #904