service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」

来源：#876 / PR #885 实施中的顺带发现。#876 的排期把本页的行级切割定死在 :8 / :53 / :66-70 / :72 / :82-83（「升级做了什么 / 通知了谁」这组），本条是同页另外两组行为性说法，不在那个切割里，故单独立单。

基线 origin/main = 716bd4d3。行号为 PR #885 合并前的原始行号（该 PR 使正文增长 6 行，合并后 :16 不变、:57-60 不变、:128 变 :134）。

事实

A. 升级触发条件：`High + Customer` 这一分支不存在（:57-60，以及 :128 管理员提示里的复述）

第 57-60 行（zh-Hans / zh-Hant 同行号）：

The escalation flow runs the moment a case meets either of these conditions:

The case is set to Critical priority, OR

The case is High priority AND the related account is a Customer (not a prospect)

src/flows/case-escalation.flow.ts:76-79 的 start 条件全文只有一个优先级项：

condition: P`has(record.priority) && record.priority == "critical"
  && (!has(record.escalated_date) || record.escalated_date == null)
  && (!has(record.status)
    || (record.status != "escalated" && record.status != "resolved" && record.status != "closed"))`

没有 high 项，也没有任何账户类型 / 分层项。全仓复测：grep -rn "account_type\|'customer'\|tier" src/flows/ 在 24 个 flow 里对任何账户类型条件零命中（命中的两处是 demo-bootstrap 与 opportunity_approval 的无关注释）。case_escalation_on_create 是同一条件的 insert 版孪生（flow.ts:155-165），也没有这一支。另一条会升级工单的 case_sla_monitor 是按 sla_due_date 过期扫的，同样与账户类型无关。

第 128 行的管理员提示又复述了一遍同一个不存在的分支：

Escalation triggers (Critical, or High+Customer) live in the Case Escalation flow definition. Adjust the condition there to change when escalation fires.

为什么要紧：这是三处里最能误导人的一处。一个服务经理读完会认为「客户级账户的 High 工单会自动升级」，于是不再为这批工单安排人工巡检——而它们永远不会自动升级。它比 #876 修的那组更隐蔽：#876 那组至少升级动作真的发生了（只是没改派），这一条是整个自动化根本不触发。另外 High 优先级工单也拿不到 sla_due_date（case.hook.ts:60 只给 critical 发 4 小时 SLA），所以 case_sla_monitor 这条兜底路径对它们同样不生效——#595 已独立记过这个 hook 侧事实。

B. Critical 违约行承诺的两样东西都不存在（:16）

第 16 行，SLA 目标表：

| Critical | 4 hours | Red banner on case detail, alert to support manager |

红色横幅：grep -rn "banner" src/ 在整个 app 里只有一处命中，是 opportunity.object.ts:281 一句无关注释。工单详情页没有任何横幅机制；本页第 34-38 行另外描述的「header 里的实时 SLA 倒计时」同样没有对应实现，但那一段是 UI 描述，与本条的收件人问题分开看。
通知支持经理：违约的真实通知来自 case-sla-monitor.flow.ts:84，recipients: ['{currentCase.owner_id}'] —— 只有工单负责人一人。节点标签就叫 Alert Owner，节点注释写明 {currentCase.owner_id.manager} 穿不透 lookup、会插值成字面量 undefined。这与 automation 内置 flow 表两行与 flow 实况不符：赢单提醒不发给经理、案例升级既不改派也不建任务（flow 自身 description 同错） #851 / content/docs/service/sla-and-escalation 三语种把升级描述成「改派给经理 + 群发经理/support-team 邮件」，flow 既不改派也只发负责人一人 #876 修掉的是同一族「文档声称通知经理，flow 只发负责人」。

同表 :17-19 的 High / Medium / Low 三行称违约表现为列表视图里的红 / 琥珀 / 灰色徽章 —— 未在本单核实，一并留给接单人按 src/views/case.view.ts 核。

边界

不与 content/docs/service/sla-and-escalation 三语种把升级描述成「改派给经理 + 群发经理/support-team 邮件」，flow 既不改派也只发负责人一人 #876 / PR docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 重叠：docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 只动了 :8 / :53 / :66-70 / :72 / :82-83，hunk 头可证；:16 / :57-60 / :128 逐字未碰。
不与「工作流规则」在 automation 之外还散布 8 个页族 ×3 语言共 33 处，其中 4 处把可配置项指向了不存在的配置面 #850 重叠：「工作流规则」在 automation 之外还散布 8 个页族 ×3 语言共 33 处，其中 4 处把可配置项指向了不存在的配置面 #850 在本页认领的是 :129（「recipient lists … configurable in the case workflow rules」）。:128 与 :129 相邻但内容无关——:128 讲的是触发条件写在哪里、以及那个不存在的 High+Customer 分支，不含「工作流规则」字样。接单时两条注意别互相踩线。
SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 边界：只写实当前行为。「High + Customer 是否应该触发升级」「High 是否应该有 SLA」都是 SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 的产品问题，本单不预判、不暗示将来会加。
修复面应三语同步，口径沿用 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 / docs(flows): name what the flow nodes do, not what they were once meant to do #877 / docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 已落地的写法（点名说清不做什么 + 真实归属，不静默删名）。

Refs #876 #851 #850 #595

[PM 认领 · R26 · 并单 #886+#890] session_01VHrPAGEgFDoHjphqYG4BMa · 分支 claude/issue-886-890-service-behavior-residue · 文件面:service/sla-and-escalation ×3(:16、:57-60、:128、:105)+ service/cases ×3(:156)+ service/index ×3(:48)+ changeset

两单同落 service 页族、行集互斥(#886 是行为主张,#890 是技能能力主语),并单一个 PR(首行 Fixes #886,次行 Fixes #890)。⚠️ 基线必须含 PR #894(刚合并,同页族 42 处 1:1 行改动,行号未位移但内容有变)。

#886 裁定(口径 #885/#894):

:57-60/:128 的「High 优先级 AND 账户为 Customer」升级分支——flow start 条件全文只有 record.priority == "critical"(逐节点复核),24 个 flow 无任何账户类型条件:写实为只有 Critical 自动升级,High 不会(且拿不到 sla_due_date 的部分按 issue 事实一并写实);该批工单需人工升级。
:16 Critical 违约行「红色横幅 + 通知支持经理」——src/ 无横幅机制,违约通知来自 case-sla-monitor.flow.ts 的 recipients: ['{currentCase.owner_id}'] 一人:写实。
docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885/docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 已改行零回退;:101 锚点(content/docs 还剩 17 处悬空锚点（全仓实测），三类新成因：emoji 标题、标题后来加了后缀、zh 页沿用英文锚点 #866)不碰;SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判。

#890 裁定(口径 #861/#865/#892):
4. cases :156、index :48、sla :105 的「建议解决方案会检索知识库并起草回复 / 用知识库对历史工单做模式匹配」——case_triage 无检索工具、email_drafting 不取知识来源、文章匹配归 Customer 360°:整句写实;其中「Support Knowledge Base」链接标签是 #892 已清掉的虚构库名,随整句重写(链接指向 knowledge-base 页可保留,标签写实为知识文章/知识库页真名)。

⛔ 不动 src/**、releases/;不加守卫;三语同步;zh 术语按语言包;不升级 @objectstack/*;changeset 站内路径反引号;控制字节自扫;JSON 报告按标准 schema(issue 填 886,summary 两单分开)。

Generated by Claude Code

[PM 验收] PR #907 ACCEPT(并单 #886+#890)— 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)

复核结论:

九点前提表全部复现,且补充测量收紧了措辞(sla_due_date 非 readonly、seed 有手填——故写「没有任何自动化会打这个戳」而非全称否定)——这是把「写实」做到量词级的例子。
不存在的 High+Customer 分支具名保留四个词并写明不存在;兜底路径(sla_monitor 只逮有截止日期的)失效链讲清;给出可执行替代(人工巡检/Escalate 按钮);SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 零预判。
:16 违约行「红色横幅」「支持经理」点名不存在,真实归属(owner 一人)同格写实;4 hours 核真保留。
service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890 三处整句重写归属清楚(检索归 Customer 360°、草稿归邮件撰写、分流两者都不做);虚构库名标签换真名而链接目标不变——link-check 绿佐证。
行级切割干净(「工作流规则」在 automation 之外还散布 8 个页族 ×3 语言共 33 处，其中 4 处把可配置项指向了不存在的配置面 #850 认领行逐字未动、content/docs 还剩 17 处悬空锚点（全仓实测），三类新成因：emoji 标题、标题后来加了后缀、zh 页沿用英文锚点 #866 锚点面未碰);docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885/docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 零回退(净 +4 行有账);merge-tree 对前进后的 main 核过可干净合并;CI 实测 8/8 绿(head 0d21393)。

越界发现处置:#903(SLA 跟踪节四处失实,含与本 PR 的同页张力::12 与新写的 :64 反话并存)入队 pm:queue 优先排期;#904(service/index 五行未清扫副本,服务域落地页首屏即错)入队 pm:queue。⚠️ 两单均在 service 族:#903 等本 PR 合并后即可派,#904 与本 PR 同文件(不同行)同样等落地后派。

Generated by Claude Code

docs(service): write the escalation trigger, the Critical breach row …

docs(service): SLA 跟踪一节按实测行为改写(objectstack-ai#903) (objectstack-ai#918)

Navigation Menu

Repository navigation

`service/sla-and-escalation` 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886

事实

A. 升级触发条件：`High + Customer` 这一分支不存在（:57-60，以及 :128 管理员提示里的复述）

B. Critical 违约行承诺的两样东西都不存在（:16）

边界

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886

Description

事实

A. 升级触发条件：High + Customer 这一分支不存在（:57-60，以及 :128 管理员提示里的复述）

B. Critical 违约行承诺的两样东西都不存在（:16）

边界

Activity

yinlianghui commented on Aug 6, 2026

yinlianghui commented on Aug 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`service/sla-and-escalation` 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886

A. 升级触发条件：`High + Customer` 这一分支不存在（:57-60，以及 :128 管理员提示里的复述）