service/cases 详情布局 :130 说页眉有「SLA 倒计时」和状态/优先级徽章，与 #903 已在 sla 页写实的「没有倒计时、页眉只有编号+主题+账户」直接打架；:68 的首次响应触发条件也不对 #941

来源：#925 / #926 / PR #939 实施过程的顺带发现（改同页 :59 / :70 / :71 / :111 / :114-121 / :166-173 时，回 case_detail.page.ts 与 global.actions.ts 核对同页其余的 SLA / 自动化说法）。基线 origin/main = 4855d50b，行号为 fresh main 上 PR #939 之前的行号，三语同址。

一、:130 页眉 —— 与兄弟页当面矛盾

- **Header** — case number, subject, status badge, priority badge, SLA countdown.

zh 同款：cases.zh-Hans.mdx:130「页眉——工单编号、主题、状态徽章、优先级徽章、SLA 倒计时。」

src/pages/case_detail.page.ts 的 header 区域有两个组件，页面把它们合并成了一个，还多算了一样东西：

最后一条不是新发现，而是同一件事已经在兄弟页写实过了：service/sla-and-escalation.mdx:38（#903 / PR #918 落地）写着

There is no live SLA countdown. Nothing in this app computes time remaining or time over — no threshold colouring, no warning zone, and no ⏱ / ⚠️ / 🚨 treatment anywhere on the case. The page header carries the case number, subject and account and nothing else; SLA Due Date and SLA Violated are rendered as two ordinary fields in the Key Information strip below it.

于是 service 目录下两页现在对同一个页眉给出相反的描述，且更靠前被读到的是错的那页。这与 #928 里 setup 页与 sla 页打架是同一模式。

（同段 :131 的「Status path」经核属实，不要顺手删：case_detail.page.ts:76-92 确有 type: 'record:path'，六个 stage 与页面列的 New → In Progress → Waiting on Customer → Escalated → Resolved → Closed 逐字一致。）

二、:68 首次响应时间的触发条件

- **First response time** — stamped the first time an agent comments or replies.

zh 同款：:68「首次响应时间——客服第一次评论或回复时标记。」

first_response_date 的唯一写入方是 src/actions/global.actions.ts:386-401（logActivityAction），条件是：

if (OBJECT_NAME === 'crm_case' && recordId && EVENT_STATUS === 'held') { ... }

即记录一次已发生（held）的通话或会议时才写，且只写第一次（先读库里的值，非空则跳过）。这一处的设计理由写在紧邻的注释里，是刻意的：状态变更不算响应（客服可以把工单转到 in progress 然后自己查一小时，客户什么都没听到），仅仅预约了会议也不算。

所以「评论或回复」两个动作都不会打这个戳：评论走的是 feeds，邮件走 sys_email，两条路径都不碰 first_response_date。注释里还明写了一条约定 —— "any future customer-facing path on a case MUST stamp this too, or the metric silently under-reports" —— 恰恰说明现在只有这一条路径。

读者据 :68 会以为回一封邮件就把首次响应时间定住了，实际那个字段还是空的。

为什么要紧

:130 是详情页布局的「按图索骥」描述，读者打开工单去找一个倒计时，找不到之后合理地怀疑是自己权限或版本问题 —— 而正确答案（本应用根本不算剩余时间）就写在隔壁页上。:68 让人以为一个指标已经被自动填好，实际它只在很窄的一条路径上被填。

边界

• 与 service/cases 的《自动发生的事》:70/:71 是同族第三处未清扫的 SLA 说法——「SLA 截止日期按优先级计算」只对 critical 成立、「违约标记按解决时间超目标翻转」是另一套机制,字段名也不存在 #925 不重叠：那单的行集是 :59 / :70 / :71 / :111，本条是 :68 与 :130。
• 与 service/cases 的「标准列表视图」七个名字里有六个不存在（:114-121），经理提示的三条（Breached SLA / Service Board / 客服排行榜）同族 #926 不重叠：那单是 :114-121 与 :171-173。
• 与 PR docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 不重叠：它按 bare workflows 残留族在 #899 枚举之外还有 4 处：whats-new 把真实的 contract_renewal 流程叫成 workflow，state-machines:133 在 PR #894 扫过该文件后仍留着 #912/administration/state-machines 通篇声称状态机会「拦下」非法转换，实测五条规则全是 warning：保存照样通过；连「只显示合法下一状态」「bypass state machine 权限」都无实现 #920/service/cases 的《自动发生的事》:70/:71 是同族第三处未清扫的 SLA 说法——「SLA 截止日期按优先级计算」只对 critical 成立、「违约标记按解决时间超目标翻转」是另一套机制,字段名也不存在 #925/service/cases 的「标准列表视图」七个名字里有六个不存在（:114-121），经理提示的三条（Breached SLA / Service Board / 客服排行榜）同族 #926 四单的枚举面收口，外加 PM 在 「营业时间」在 sla 页之外还有三处：administration/setup 整整一节教人配置一个不存在的 Setup → Business Hours 屏，reference/faq 把它写成 SLA 计时的前置条件，glossary 收了词条 #928 验收时判归的 :166 / :167；:68 与 :130 两行未触碰，原样留给本条。
• 与 「首次响应 SLA」被三处文档写成可度量的目标：setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936 相邻但不同：「首次响应 SLA」被三处文档写成可度量的目标：setup 清单 §11 的 SLA 矩阵整列、analytics/reports 的 SLA Performance 行、analytics/cubes 的 Service Cube 措施 —— 全仓没有任何首次响应目标、达标度量或超时信号 #936 是「首次响应 SLA 被写成可度量的目标」（setup / reports / cubes 三处），本条 :68 是同一字段的写入触发条件，不是目标度量。两条可以一起改，也可以分开。
• 口径沿 service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 / 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：点名说清不存在 + 给出真实归属（record:highlights 的 Key Information 条 / logActivityAction 的 held 分支），不静默删名。⛔ :131 的 Status path 是真的，不要删。

Refs #903 #925 #926 #936 #939