docs(service): 把 service/index 的升级与通知五条说法按 flow / hook 写实(#904)

.changeset/service-index-escalation-residue.md

@@ -0,0 +1,45 @@
+---
+'hotcrm': patch
+---
+
+按 flow / hook 源码写实 `content/docs/service/index.mdx` 上残留的五条升级与通知说法,三语同步(#904)。
+
+服务域的落地页是大多数读者最先读到的一页。`service/sla-and-escalation`(#876 / #886)与
+`service/cases`(#850 / #887)的同族说法已经逐条写实之后,本页的「一个典型工单的生命周期」
+与「系统为你做的事」两处清单仍在原样承诺重新分配、一个不存在的分支、两个不存在的收件人
+和一个不存在的横幅 —— 读者拿到的是自相矛盾的两套描述,而更显眼的那一套是错的。五条按
+兄弟页已落地的口径写实,`content/docs/service/index.zh-Hans.mdx` /
+`content/docs/service/index.zh-Hant.mdx` 同步:
+
+- **升级不会把工单重新分配给资深客服。** 生命周期第 5 步写的是「如果卡住了(或紧急,或来自
+  客户),升级流程会将其重新分配给资深客服」。`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.`。现在写实为:升级把工单标记为 *Escalated* 并提醒
+  它的负责人,不做交接;交到资深客服手里仍是一个需要有人手动完成的步骤。
+- **没有 `High + Customer` 这条分支。** 同一步里的「或来自客户」,以及「自动升级——将紧急工单
+  或高优先级客户工单升级给资深客服」,说的是同一个不存在的东西:start 条件全文只有
+  `record.priority == "critical"`,全仓 24 个 flow 没有任何一处读取账户类型。现在写实为:
+  只有 Critical 会自动升级,High 工单永远不会(无论账户是什么),升级它靠的是工单记录上的
+  **Escalate Case** 按钮。
+- **「紧急时通知」发给工单负责人,不发给支持经理。** 该行说的其实就是工单升级流程的 `notify`
+  节点,`recipients` 只有 `{caseRecord.owner_id}` 一项,`support_manager@example.com` 在
+  `src/` 下零命中。现在写实为站内消息 + 邮件发给**工单负责人**,并点名说清这个收件人不存在。
+- **「升级时通知」不发任何邮件。** `escalation_team@example.com` 全仓零命中,状态转为
+  escalated 触发的是 `src/objects/case.hook.ts` 的 `case_status_side_effects` 钩子开出的那条
+  **次日到期、优先级为紧急、归账户负责人**的跟进任务。现在写实为这条真实归属。
+- **SLA 违约没有红色横幅。** `grep -rn "banner" src/` 在整个 app 里只有
+  `src/objects/opportunity.object.ts` 的一句无关注释 —— 没有任何横幅机制。违约的真实表现是
+  `is_sla_violated` 被置真、工单被升级,外加 `src/flows/case-sla-monitor.flow.ts` 的 `notify`
+  节点发给 `{currentCase.owner_id}` 一人的站内消息 + 邮件。
+
+沿用 #876 / #886 已确立的写法:读者来找的那几个词 —— 资深客服、支持经理、升级团队、红色横幅
+—— 都点名说清**不做**,并写出真正的归属,而不是静默删掉、留下一个「页面大概是忘了写」的印象。
+本页只陈述当前行为,不预判升级*是否应该*改派、High *是否应该*自动升级(#595 / #596 的产品问题)。
+同段中经核对属实的三条(工单分流技能定优先级、关闭时标记解决时间、未写解决方案不能关单)
+保持不动。顺带把生命周期第 5 步的中文页内链去掉了英文锚点 `#case-escalation` —— 两个中文页的
+标题是中文,该锚点在这两页上落不到任何位置(#755 / #762 惯例)。
+
+纯文档改动,3 个文件。未触碰 `src/**`,没有任何 flow、hook、条件、收件人或字段发生变化 ——
+是页面向已经在跑的行为对齐。Fixes #904.

content/docs/service/index.mdx

@@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─
 2. **Priority is assigned** — Low, Medium, High or Critical. *Critical* alerts the support manager immediately.
 3. **SLA target is calculated** — every case gets a deadline based on priority.
 4. **Agent works the case**, moving status as they go.
-5. **If it's stuck** (or critical, or a customer's), the [escalation process](/docs/service/sla-and-escalation#case-escalation) reassigns it to a senior agent.
+5. **If it's Critical** (or its SLA due date passes), the [escalation process](/docs/service/sla-and-escalation#case-escalation) flags the case as *Escalated* and alerts its owner. It does **not** reassign it — there is no hand-off to senior staff or to a manager — and no escalation condition reads the account, so a *Customer*'s case gets no branch of its own.
 6. **Resolution is recorded**, the resolution time is auto-stamped, and the case is closed.
 
 ## What the system does for you
 
 - **Auto-prioritise** with the Case Triage skill (the Service Copilot reads the case and recommends a priority).
-- **Auto-escalate** critical cases or high-priority customer cases to a senior agent.
-- **Notify on critical** — emails the support manager whenever a case is set to Critical.
-- **Notify on escalation** — emails the escalation team whenever a case is escalated.
+- **Auto-escalate** Critical cases — the flow flags them *Escalated* and alerts the owner; it never touches `owner_id`, so nothing is handed to a senior agent. A High case is never escalated automatically, whatever the account is: raising one is the manual **Escalate Case** button.
+- **Notify on critical** — inbox message + email to the **case owner** whenever a case is set to Critical. That is the Case Escalation flow's notify node, whose recipient list is `{caseRecord.owner_id}` alone; there is no `support_manager@example.com` recipient anywhere in this app.
+- **Notify on escalation** — no email goes to an escalation team: `escalation_team@example.com` exists nowhere in this app. What the *Escalated* status fires is the `case_status_side_effects` hook, which opens an **Urgent follow-up task due tomorrow for the account owner**.
 - **Stamp resolution time** automatically when a case is closed.
-- **Flag SLA breaches** with a red banner once the SLA target passes.
+- **Flag SLA breaches** once the SLA target passes — the case is marked **SLA Violated**, escalated, and its owner alerted by inbox + email. No red banner: this app has no banner mechanism.
 - **Block bad closes** — you can't mark a case Closed without a resolution written.
 
 ## Service AI skills

content/docs/service/index.zh-Hans.mdx

@@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─
 2. **分配优先级**——低、中、高或紧急。*紧急*会立即提醒支持经理。
 3. **计算 SLA 目标**——每个工单都会根据优先级获得一个截止时间。
 4. **客服处理工单**，随进度推进状态。
-5. **如果卡住了**（或紧急，或来自客户），[升级流程](/zh-Hans/docs/service/sla-and-escalation#case-escalation)会将其重新分配给资深客服。
+5. **如果是 Critical**（或 SLA 截止日期已过），[升级流程](/zh-Hans/docs/service/sla-and-escalation)会把工单标记为 *Escalated* 并提醒它的负责人。它**不会**重新分配工单——不存在向资深员工或经理的交接——也没有任何升级条件会读取账户，所以 *Customer* 的工单没有属于自己的分支。
 6. **记录解决方案**，自动标记解决时间，并关闭工单。
 
 ## 系统为你做的事
 
 - **自动确定优先级**——通过工单分流技能（Service Copilot 阅读工单并推荐优先级）。
-- **自动升级**——将紧急工单或高优先级客户工单升级给资深客服。
-- **紧急时通知**——每当工单被设为紧急时，向支持经理发送邮件。
-- **升级时通知**——每当工单被升级时，向升级团队发送邮件。
+- **自动升级**——只针对 Critical 工单：流程把它们标记为 *Escalated* 并提醒负责人，从不改写 `owner_id`，因此没有任何工单被交到资深客服手里。High 工单永远不会被自动升级，无论账户是什么：要升级它，靠的是手动的 **Escalate Case** 按钮。
+- **紧急时通知**——每当工单被设为 Critical 时，站内消息 + 邮件只发给**工单负责人**。这就是工单升级流程的 notify 节点，其收件人列表只有 `{caseRecord.owner_id}` 一项；本应用中不存在 `support_manager@example.com` 这个收件人。
+- **升级时通知**——不会给任何升级团队发邮件：`escalation_team@example.com` 在本应用中根本不存在。状态转为 *Escalated* 真正触发的，是 `case_status_side_effects` 钩子开出的那条**次日到期、优先级为紧急、归账户负责人的跟进任务**。
 - **标记解决时间**——工单关闭时自动标记。
-- **标记 SLA 违约**——一旦 SLA 目标时间过去，显示红色横幅。
+- **标记 SLA 违约**——一旦 SLA 目标时间过去，工单会被标记为 **SLA 已违约**并升级，其负责人收到站内消息 + 邮件提醒。没有红色横幅：本应用没有任何横幅机制。
 - **阻止错误关闭**——未填写解决方案就不能将工单标记为已关闭。
 
 ## Service Copilot

content/docs/service/index.zh-Hant.mdx

@@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─
 2. **分配優先順序**——低、中、高或緊急。*緊急*會立即提醒支援經理。
 3. **計算 SLA 目標**——每個工單都會根據優先順序獲得一個截止時間。
 4. **客服處理工單**，隨進度推進狀態。
-5. **如果卡住了**（或緊急，或來自客戶），[升級流程](/zh-Hant/docs/service/sla-and-escalation#case-escalation)會將其重新分配給資深客服。
+5. **如果是 Critical**（或 SLA 截止日期已過），[升級流程](/zh-Hant/docs/service/sla-and-escalation)會把工單標記為 *Escalated* 並提醒它的負責人。它**不會**重新指派工單——不存在向資深員工或經理的交接——也沒有任何升級條件會讀取帳戶，所以 *Customer* 的工單沒有屬於自己的分支。
 6. **記錄解決方案**，自動標記解決時間，並關閉工單。
 
 ## 系統為你做的事
 
 - **自動確定優先順序**——透過工單分流技能（Service Copilot 閱讀工單並推薦優先順序）。
-- **自動升級**——將緊急工單或高優先順序客戶工單升級給資深客服。
-- **緊急時通知**——每當工單被設為緊急時，向支援經理發送郵件。
-- **升級時通知**——每當工單被升級時，向升級團隊發送郵件。
+- **自動升級**——只針對 Critical 工單：流程把它們標記為 *Escalated* 並提醒負責人，從不改寫 `owner_id`，因此沒有任何工單被交到資深客服手裡。High 工單永遠不會被自動升級，無論帳戶是什麼：要升級它，靠的是手動的 **Escalate Case** 按鈕。
+- **緊急時通知**——每當工單被設為 Critical 時，站內訊息 + 郵件只發給**工單負責人**。這就是工單升級流程的 notify 節點，其收件人列表只有 `{caseRecord.owner_id}` 一項；本應用中不存在 `support_manager@example.com` 這個收件人。
+- **升級時通知**——不會給任何升級團隊發郵件：`escalation_team@example.com` 在本應用中根本不存在。狀態轉為 *Escalated* 真正觸發的，是 `case_status_side_effects` 鉤子開出的那條**次日到期、優先順序為緊急、歸帳戶負責人的跟進任務**。
 - **標記解決時間**——工單關閉時自動標記。
-- **標記 SLA 違約**——一旦 SLA 目標時間過去，顯示紅色橫幅。
+- **標記 SLA 違約**——一旦 SLA 目標時間過去，工單會被標記為 **SLA 已違約**並升級，其負責人收到站內訊息 + 郵件提醒。沒有紅色橫幅：本應用沒有任何橫幅機制。
 - **阻止錯誤關閉**——未填寫解決方案就不能將工單標記為已關閉。
 
 ## Service Copilot