service/cases 的「标准列表视图」七个名字里有六个不存在（:114-121），经理提示的三条（Breached SLA / Service Board / 客服排行榜）同族 #926

发现自 #917 / PR #924 的实施过程（写实 sla 页的 Breached SLA / Service Board 两个名字时，顺 grep -rniE "breached sla|service board" content/docs/ 核对了同族说法的落点）。

基线 origin/main = 6014b2cf（含 PR #913 / #918 / #919，平台 17.0.0-rc.3）。三语同行号。

事实

src/views/case.view.ts 里 crm_case shipped 的全部 7 个视图是：all_cases（All Cases）、case_workflow（Service Workflow，kanban）、sla_calendar（SLA Calendar）、case_timeline（Case Timeline）、my_open_cases（My Open Cases）、escalated_cases（Escalated Cases）、sla_at_risk（⏰ SLA at Risk）。

:114-:121 —— 《标准列表视图》一节

页面列的七个名字里，只有 My Open Cases 一个是真的：

反过来说，真实存在的 6 个视图里，这一节一个都没提到：All Cases、Service Workflow、SLA Calendar、Case Timeline、Escalated Cases、⏰ SLA at Risk。

:171 / :172 / :173 —— 《给服务经理的提示》三条

• :171 「每天关注 Breached SLA 视图——每个红色徽章都代表一次客户信任事件」：视图不存在；而且"红色徽章"同 service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 已在 sla 页写实过的实测——工单列表上唯一的颜色规则是 All Cases 的 rowColor，键在优先级上，不是违约。
• :172 「使用 Service Board 看板进行每日站会」：与 sla 页 :136 完全同句，PR docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 已在 sla 页改成 Service Workflow，本页仍是原样。
• :173 「辅导那些 Resolution Time 趋势上升的客服——客服排行榜上有相应的列」：不存在任何客服排行榜。grep -rniE "leaderboard" src/ 只命中 src/dashboards/sales.dashboard.ts:243（Rep Leaderboard，销售管道按 owner 分组）。服务侧做不出来同类物：case_metrics（src/datasets/case.dataset.ts:15-21）只有 status / priority / origin / type / created_date 五个 dimension，没有 owner/agent 维度，所以任何报表和仪表盘部件都无法按客服分组（这一点 PR docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 已在 sla 页写实）。

为什么要紧

《标准列表视图》是一整节的"按图索骥"清单，读者会照着它去视图切换器里找——七个里六个扑空，而真正能用的六个视图一个都没被介绍。:173 更进一步：它让经理相信有一张按客服排的表，而这张表在语义层根本做不出来。

边界

• 与 service/cases 的「工单升级」整节(:89–100)与 :34 是 PR #894 未清扫的同族副本:High+Customer 分支、改派给经理、跟进任务归原客服、通知客服+经理+支持团队 #914 不重叠：那单的切割是 :34 与 :89–:100（升级触发条件与五步清单），本单是 :114–:121 与 :171–:173，行集互斥。
• 与 service/cases 三语的「工作流自动化」清单同样写着虚构的 support_manager@example.com 与「向升级团队发邮件」，实际收件人是工单负责人一人 #887 / PR docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 不重叠：那单落在 :82 / :83 / :178。
• 与 service/sla-and-escalation 剩余六处失实(#903 四族之外):营业时间可配置、SLA 表现报表的四个维度、Breached SLA 视图、Service Board 看板、My Open Cases 排序、Waiting on Customer 暂停 SLA 时钟 #917 / PR docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 不重叠：那单只动 sla-and-escalation 三语页。
• 口径沿 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 / docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 / docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924：点名说清不存在 + 给出真实归属（磁贴 / 真名 / 语义层缺维度），不静默删名。若要把这一节改成真实视图清单，注意与 content/docs/sales/ 的视图清单写法保持一致。
• 不预判产品：这些视图是否应该存在（尤其 Cases Due Today / Recently Closed / By Account）是产品问题，本单只要求把当前形状写实。

Refs #917 #914 #903