「首次响应 SLA」被三处文档写成可度量的目标：setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936

发现自 #928 / PR #933 的实施过程（写实 administration/setup §2 营业时间节时，读到同页 :102-:110 的 SLA 矩阵）。

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

事实：有戳，没有目标

• crm_case.first_response_date（src/objects/case.object.ts:185）有写入方：src/actions/global.actions.ts:368-:398 的 logActivityAction 在工单第一条 sys_activity 落地时打戳（Follow-up to #514: remaining behaviour fixes, conventions, and the action-sandbox test gap #575 B2，test/case-first-response.test.ts 钉住）。这一半是真的。
• 但没有任何"首次响应目标"：grep -rn "first_response_date" src/flows/ src/objects/*.hook.ts src/reports/ src/datasets/ 零命中 —— 没有任何地方把这个戳与一个按优先级的目标做比较，没有违约标记，没有对应的扫描。case_sla_monitor 只读 sla_due_date。
• 语义层里也没有度量：src/datasets/case.dataset.ts 的 case_metrics 只有三个 measure —— case_count / avg_resolution / avg_sla_violated，没有首次响应时间，也没有任何"达标 %"。
• 报表同样没有：src/reports/case.report.ts:18-:28 的 sla_performance 是 rows: ['priority'] + values: ['case_count', 'avg_sla_violated', 'avg_resolution']。

三处

1. content/docs/administration/setup.mdx:102-:110（§11 Case SLAs）

「Confirm the default SLA matrix」的四行表带一整列 First response（Critical 1 小时 / High 2 小时 / Medium 4 小时 / Low 1 个工作日），并把「SLA matrix」链回 service/sla-and-escalation。而那一页（#924 写实后）根本没有「first response」这三个字 —— grep -c -i "first response" content/docs/service/sla-and-escalation.mdx = 0。点进去的读者找不到这一列的任何落点。

2. content/docs/analytics/reports.mdx:40

| **SLA Performance** | % first-response on time, % resolved on time, by priority |

真实的 sla_performance 两个都不是：它出的是违约率（avg_sla_violated）与平均解决时长，没有任何「准时 %」。

3. content/docs/analytics/cubes.mdx:84 / :86

Service Cube 的 measure 列表含 First-response time (minutes) 与 SLA met % (first response and resolution)，case_metrics 两者都没有。

三语同址（.zh-Hans / .zh-Hant 行号一致）。

为什么要紧

管理员照 §11「确认默认 SLA 矩阵」逐行确认之后，会相信首次响应超时会被系统计量；服务经理照 analytics 两页会去找一个「首次响应达标 %」的报表列。两者都不存在，也没有任何东西会在超时时报警 —— 一个 New 工单坐多久都不会有信号。这与 #928 修掉的那一族是同一种伤害：读者把不存在的度量当成已有的防线。

边界 / 给 triage 的提示

• 与 「营业时间」在 sla 页之外还有三处：administration/setup 整整一节教人配置一个不存在的 Setup → Business Hours 屏，reference/faq 把它写成 SLA 计时的前置条件，glossary 收了词条 #928 / PR docs: write the three business-hours claims outside the SLA page to source (#928) #933 不重叠：那单只动 setup §2 营业时间节、faq :92-:95、glossary :34；§11 未动，本单是它。
• 未并入的同族一处：content/docs/service/cases.mdx:166（「New cases should not sit for more than the first-response SLA」）属同族，但该页正被 bare workflows 残留族在 #899 枚举之外还有 4 处：whats-new 把真实的 contract_renewal 流程叫成 workflow，state-machines:133 在 PR #894 扫过该文件后仍留着 #912 族的 dev 在改，未并入本单，请判定归属。同页 :167（「it stops the SLA clock in some configurations」）是 docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 已在 sla 页杀掉的同一条说法的残留。
• 本单不主张的部分：analytics/cubes / analytics/reports 两页的其余条目（CSAT、agent/team、product、account tier 等维度）看上去同样与 case_metrics 的五维三度量对不上。本单只主张首次响应这一条线索；若另有 analytics 文档漂移的单，建议把第 2 / 3 处并进去，避免重复。
• 口径建议沿 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(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 / docs: write the three business-hours claims outside the SLA page to source (#928) #933：点名说清不存在 + 给出真实归属（戳是 logActivityAction 写的，但没有目标、没有度量、没有告警），不静默删名。至于是否应该有首次响应 SLA，是 SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 的产品问题，本单不预判。

Refs #928 #924 #917 #595