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

[yinlianghui]

来源：#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 区域有两个组件，页面把它们合并成了一个，还多算了一样东西：

页面主张	实况
页眉含工单编号、主题	✅ page:header 的 title: '{case_number} · {subject}'（:47）
页眉含状态徽章、优先级徽章	❌ 不在页眉。page:header 的 subtitle 是 {crm_account}，此外只有图标、面包屑和三个动作按钮。status / priority 在下面那个 record:highlights（Key Information 条，:57-73）里，与 sla_due_date / is_sla_violated / owner_id / crm_account 并列，是普通字段不是徽章
页眉含 SLA 倒计时	❌ 不存在。全仓没有任何倒计时/剩余时间的计算或渲染

最后一条不是新发现，而是同一件事已经在兄弟页写实过了：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

[yinlianghui]

🔒 认领(/pm-dispatch R30)— session session_01VHrPAGEgFDoHjphqYG4BMa,分支 claude/issue-941-cases-header-facts。

文件面:content/docs/service/cases{,.zh-Hans,.zh-Hant}.mdx 的 :130(页眉徽章+SLA 倒计时)与 :68(首次响应标记时机)——PR #939 刚大改本页,fresh main 重定位。

裁定:

1. :130 沿 docs(service): SLA 跟踪一节按实测行为改写(#903) #918 已写实的 page:header 实况(页眉只有 case_number·subject + crm_account 副标题;status/priority/sla_due_date 在 record:highlights 的 Key Information;全仓无倒计时)抄平,消除与 sla 页的两页打架;
2. :68 沿 docs: write the three business-hours claims outside the SLA page to source (#928) #933 口径:first_response_date 唯一写入方是 logActivityAction 的 EVENT_STATUS==='held' 分支(记录已发生的通话/会议),评论与邮件都不打戳——写实标记时机,不虚构;
3. :131 的 Status path 经核属实不得删(dev 立单时已注明);PR docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 落地行零回退;
4. src/ 零改动;SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判;三语同步;zh 内链不带锚。

---

Generated by Claude Code

[yinlianghui]

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

验收要点:

1. 两行 premise 逐一回源码复核成立(:130→:142 重定位;first_response_date 写入条件精确到 EVENT_STATUS==='held' 且写前读库非空跳过——比派单更细);:143 状态路径逐字核对属实保留。
2. 沿 docs(service): SLA 跟踪一节按实测行为改写(#903) #918/docs: write the three business-hours claims outside the SLA page to source (#928) #933 口径抄平,两页打架消除;diff 仅 3 文件 9 增 6 删,docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 落地行零回退。
3. 反向验证按预告方向实测(stash 回错误文案同绿),守卫盲区如实报。

越界发现处置:#945(cases 详情布局同列表另三条失实:客户面板/AI 参考栏无组件承载、Related 页签实际只有一个 Open Tasks 关联列表)已复核成立,标 pm:queue,R31 候选——⚠️ 与本 PR 同页,派发须在 #946 合并后重定位;与 #612 的区别 dev 已写明,不互相等待。

---

Generated by Claude Code