docs(service): 把工单页眉与首次响应打戳两行写实到源码 (#941)

[yinlianghui]

Fixes #941

content/docs/service/cases{,.zh-Hans,.zh-Hant}.mdx 两行族 × 三语，逐条回源码核过。基线 origin/main = 11f62429（PR #939 落地后的 fresh main），issue 正文给的是 #939 之前的行号，已重定位：:130 → :142，:68 仍是 :68。

一、页眉（:142，原 :130）—— 消除与 sla 页的两页打架

原文把三个组件里的两个揉成了一条，还多算了一样不存在的东西：

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

src/pages/case_detail.page.ts 的实况：

页面主张	实况
工单编号、主题	属实 —— page:header 的 title: '{case_number} · {subject}'（:47）
状态徽章、优先级徽章	不在页眉。subtitle 是 {crm_account}（:50），另有 icon、breadcrumb 与三个动作按钮，此外没有别的属性。status / priority 在下面的 record:highlights（Key Information，:57-73），与 sla_due_date / is_sla_violated / owner_id / crm_account 并列，是普通字段不是徽章
SLA 倒计时	不存在。用 countdown / time remaining / time left 一族关键词（grep -rniE）扫 src/，零命中

改法沿 #918 已在 service/sla-and-escalation.mdx:38 落地的口径：点名说清不存在 + 给出真实归属，不静默删名。一条拆成两条 —— Header 照抄 page:header 的四样属性并明说没有徽章、没有倒计时；新增 Key Information 一条，把 status / priority 的真实归属写出来。两页从此说同一件事。

二、首次响应打戳时机（:68）

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

first_response_date 的唯一写入方是 src/actions/global.actions.ts 的 logActivityAction（:385-403），条件是 OBJECT_NAME === 'crm_case' && recordId && EVENT_STATUS === 'held'，且写前先把库里的值读回来（非空则跳过）。held 的活动只有 LOG_CALL_SPEC 与 LOG_MEETING_SPEC 两种（:487-511），SCHEDULE_MEETING_SPEC 是 planned。评论走动态流、邮件走 sys_email，两条路径都不碰这个字段 —— grep -rn first_response_date src/ 除定义、视图列与四份翻译外，只有 global.actions.ts 一处写入。

test/case-first-response.test.ts 把这套语义按行为钉死了（两个 twins 都打戳、只预约不打戳、第二次不覆盖第一次、读库不读投影记录），新文案与它逐条对齐。

三、不动的部分

• :143 状态路径经核属实，原样保留 —— record:path（:76-92）确有六个 stage，与页面列的 New → In Progress → Waiting on Customer → Escalated → Resolved → Closed 逐字一致（waiting_customer 的 value 与 label 对得上）。
• PR docs(service): write the cases and state-machine pages' remaining claims to source (#912, #920, #925, #926) #939 的落地行零回退 —— diff 只有 3 个文件、9 增 6 删，:34 / :59 / :70 / :71 / :78 / :80 / :89-105 / :111 / :114-121 / :166 / :167 / :171-173 族一字未动。
• src/ 零改动，@objectstack/* 版本未动，content/docs/releases/ 未碰。
• 与本轮并行的 service 两页共 11 处把 service_dashboard 叫作「Service Dashboard / 服务仪表盘」，但这个名字在应用里不存在：dashboard 的 label 是 Customer Service，导航项的 label 是 Service Overview #937 无同行冲突：service 两页共 11 处把 service_dashboard 叫作「Service Dashboard / 服务仪表盘」，但这个名字在应用里不存在：dashboard 的 label 是 Customer Service，导航项的 label 是 Service Overview #937 的「Service Dashboard」词面在 :130 一带的视图小节里，本 PR 只动 :68 与 :142。

验证

六道门在 flock -w 7200 /tmp/os-heavy-verify.lock 内串行，全部退出码 0：

门	结果
pnpm validate	✓ Validation passed (1162ms)，5 条既有 author-time warning 与基线一致
pnpm typecheck	无输出，exit 0
pnpm lint	13 warning(s), 14 suggestion(s)，均为既有项
pnpm hygiene	✓ no raw control bytes in first-party files —— 该脚本的控制字节扫描面覆盖 content 与 .changeset 共 429 个文件
pnpm build	✓ Build complete，dist/objectstack.json (1921.4 KB)
pnpm test -- --maxWorkers=2	Test Files 70 passed (70) / Tests 1602 passed | 1 skipped (1603)

推送前另做控制字节自扫：grep -naP 扫四个改动文件的控制字节区间（\x00-\x08 / \x0b / \x0c / \x0e-\x1f），零命中。未起 dev server。

反向验证 —— 预判方向：GREEN，且实测 GREEN（守卫盲区）

先定方向再跑：把两行错误文案 git stash 回去、再跑整套测试，预判是全绿，因为守卫面根本读不到这两行。实测 Test Files 70 passed (70) / Tests 1602 passed，与预判一致。

这是如实报告的盲区，不是「验证通过」：test/docs-drift.test.ts 只按流程/仪表盘磁贴/agent 名/译文 callout 数量做断言，docs-object-coverage 只查每个对象有没有页面，没有任何一条规则读详情布局这份清单的散文。译文 callout 数量那条本 PR 也不会踩到 —— 三语各加一条 bullet，callout 数不变。这类「页面写了一个源码里不存在的组件」的漂移，本仓当前没有任何自动门能拦，只能靠人逐条回源码核。

顺带发现（未在本 PR 修）

同一份「打开一个工单时，你会看到」清单里，紧挨着的另外三条同样对不上源码，已按 Prime Directive #10 立单 #945（未指派）：:145 客户面板、:148 Related 页签内容（实际只有一个 Open Tasks 关联列表）、:150 AI 参考栏 —— 页面只有 page:header / record:highlights / record:path / page:tabs 四个组件，没有侧栏 region。与 #612（全站 Copilot 用语定调）相邻但不同：那是叫什么名字，这是组件压根不存在。

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 6, 2026 12:51pm