Skip to content

service 两页共 11 处把 service_dashboard 叫作「Service Dashboard / 服务仪表盘」,但这个名字在应用里不存在:dashboard 的 label 是 Customer Service,导航项的 label 是 Service Overview #937

Closed

Description

@yinlianghui

发现自 #927 / PR #932 的实施过程(核对 nav_service_dashboard 的 label 时,顺着「Service Dashboard 这个名字到底存不存在」查到的)。

基线 origin/main = 4855d50b(平台 17.0.0-rc.3)。

事实

src/dashboards/service.dashboard.ts:20-:23:

export const ServiceDashboard: Dashboard = {
  name: 'service_dashboard',
  label: 'Customer Service',
  description: 'Case load, SLA health, and resolution performance',

src/apps/crm.app.ts:139 的导航项:

{ id: 'nav_service_dashboard', type: 'dashboard', dashboardName: 'service_dashboard', label: 'Service Overview', icon: 'gauge' },

也就是说,用户能在产品里看到的这个仪表盘只有两个名字:侧边栏上叫 Service Overview,仪表盘自己的标题叫 Customer Service。Service Dashboard 不是其中任何一个——它既不是 label,也不是 name(name 是 service_dashboard,标识符,不是展示名)。

文档里却有 11 处按展示名在用它(三语):

文件 行 原文
content/docs/service/index.mdx :53 - **Service Dashboard** — open cases by priority, SLA performance, top agents, oldest open cases.
content/docs/service/index.zh-Hans.mdx :53 - **服务仪表盘**——按优先级划分的未结工单、SLA 表现、顶尖客服、最久未结工单。
content/docs/service/index.zh-Hant.mdx :53 - **服務儀表板**——按優先順序劃分的未結工單、SLA 表現、頂尖客服、最久未結工單。
content/docs/service/sla-and-escalation.mdx :126 :128 :130 :142 plus the Service Dashboard's **SLA Violations** tile / | **Executive** | Service Dashboard | Weekly | / metric tiles on the [Service Dashboard](/docs/analytics/dashboards) / read the **SLA Violations** tile on the Service Dashboard for the count
content/docs/service/sla-and-escalation.zh-Hans.mdx :126 :128 :130 :142 同上,作「服务仪表盘」
content/docs/service/sla-and-escalation.zh-Hant.mdx :126 :128 :130 :142 同上,作「服務儀表板」

为什么要紧

与 #927 是同一类:按文档去产品里找一个名字,找不到。sla-and-escalation 的那几处尤其别扭——:126 / :142 让服务经理「每天一早去 Service Dashboard 上看 SLA Violations 磁贴」,:128 让高管「每周看 Service Dashboard」,而侧边栏上只有 Service Overview,点进去的页面标题是 Customer Service。这一页恰好是 #870 / #877 / #885 / #894 / #924 反复拿「点名说清不存在」口径修过的页面,Breached SLA / Critical Cases / Service Board 都已经被逐一写实,唯独承载它们的这个仪表盘的名字本身没被核过。

content/docs/analytics/dashboards*.mdx 上的名字另需一并核对(:130 的链接就指向那里)——本单只记录 service 两页的 11 处,analytics 页的实际写法未查。

边界

Refs #927 #932 #924

Activity

  1. yinlianghui commented on Aug 6, 2026

    @yinlianghui
    ContributorAuthor

    接单前注意:本单的命中计数会因 PR #939 变化(PR #939 收口 #912/#920/#925/#926,已 push,draft)。

    PR #939 重写了 service/cases 三语页的《标准列表视图》一节与《给服务经理的提示》,其中沿用了 service/sla-and-escalation.mdx:130 / :143(#917 / PR #924 已落地)的现有措辞 Service Dashboard / 「服务仪表盘」/「服務儀表板」,用来指 SLA Violations 与 Critical Cases 两个磁贴的所在处。也就是说:

    • service/cases 三语页上这个名字的出现处增加了(每语 1–2 处,位于新的《标准列表视图》尾段与经理提示第一条);
    • 增加的位置与本单原本枚举的 11 处同族同因,一并按本单的裁定改即可。

    之所以没在 PR #939 里顺手改成真名:本单尚未裁定要用 Customer Service(dashboard 的 label)还是 Service Overview(导航项的 label)还是别的写法,PR #939 单方面选一个会与本单的统一口径打架。所以那里保持与兄弟页当前一致的措辞,等本单一次性扫平。

    建议接单时以 grep -rn "Service Dashboard\|服务仪表盘\|服務儀表板" content/docs/ 重新取一次计数,不要直接用正文里的 11。


    Generated by Claude Code

  2. added
    documentationImprovements or additions to documentation
    pm:queueReady for the PM dispatch loop
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    and removed
    pm:queueReady for the PM dispatch loop
    on Aug 6, 2026
  3. self-assigned this
    on Aug 6, 2026
  4. yinlianghui commented on Aug 6, 2026

    @yinlianghui
    ContributorAuthor

    🔒 认领(/pm-dispatch R30)— session session_01VHrPAGEgFDoHjphqYG4BMa,分支 claude/issue-937-service-dashboard-name。

    文件面:全仓「Service Dashboard / 服务仪表盘 / 服務儀表板」命中行(立单时 11 处已因 PR #939 漂移——开工先全量 grep 重扫定面,含 #939 在 cases 页新增的出现处与 analytics/dashboards*.mdx 另核)。

    命名裁定(PM 定口径):统一以导航 label「Service Overview」为读者找路的主要指称(用户经侧边栏进入,导航名是找路名);各页首次出现处可附注真实仪表盘标题为 'Customer Service'(service.dashboard.ts:22),后续同页引用只用 Service Overview;不发明第三名,三语按既有译法对齐(导航/仪表盘标题若语言包有译名以语言包为准,无则沿各页既有处理)。

    裁定:

    1. 基线 rc.3;逐处 stale-premise 复核(dashboard label / 导航 label 两个源码锚点重验)。
    2. PR docs(service): write the index page's 《Where to find things》 list to the real navigation (#927) #932/docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 等已落地行零回退——它们沿用旧名是等本单统一,你替换时保持句子其余部分不动。
    3. src/ 零改动;三语同步;改后全量重扫「Service Dashboard」三语归零(除非某处是历史叙述语境,逐处说明)。

    Generated by Claude Code

  5. yinlianghui commented on Aug 6, 2026

    @yinlianghui
    ContributorAuthor

    ✅ 验收通过 —— PR #947 已转 ready 并挂 auto-merge(CI 8/8 全绿实核)。

    验收要点:

    1. 重扫定面 11→24 行(含 docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 新增与 2 个未发布 changeset——把幻名拦在 CHANGELOG 之外是加分项);analytics/dashboards 三语核实从未用幻名且成为译法裁决依据。
    2. 命名裁定执行精确:Service Overview 主称 + 首现处附注 Customer Service;zh 译名走语言包 zh-CN.ts:1209「服务概览」沿 docs(service): write the index page's 《Where to find things》 list to the real navigation (#927) #932 的「中文译名(Latin label)」形式;仪表盘标题保留拉丁(改译反而断链)——每个取舍都有锚点。
    3. 零回退纪律:docs(service): write the index page's 《Where to find things》 list to the real navigation (#927) #932 的否定句逐字未动;中文两页自相矛盾句(描述性「服务仪表盘」恰是下一句否定的名字)以最小改动化解。
    4. 4 类例外逐处说明(否定句/历史叙述/src 注释/真实 label 复数)——归零主张有边界而非一刀切。
    5. 反向验证结构性论证:全面还原 24 行后 4 个 content 测试 + hygiene 全绿(预测一致),并给出 DOC_PAGES 只含 analytics 三页的行号证据;能力缺口如实指向 [观察] 文档里的状态名/字段标签与语言包是否一致,无人检查——一周内同一缺陷类出现三次,全靠人眼撞见 #802/守卫单语缺口:「内置共享规则表」口径规则只读英文页,三语的另两份表无人检查 #809/守卫能力:给 content/docs 的站内链接加「锚点存在性 + 语言前缀一致性」检查(#749 / #764 / #866 各自的成因都能被它抓住) #867 而不越界补守卫。

    越界发现处置:


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentationpm:dispatchedDispatched to a dev agent by /pm-dispatch

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions