service/cases 详情字段两族失实：:147 Details 页签「所有元数据字段」（实为 16/28）与 :55 「详情屏幕分为 6 个分区」表（真实界面各只有 3 个分区） #958

来源：#945 / PR #956 实施过程的顺带发现。为核 :148（Related 页签）读完了 src/pages/case_detail.page.ts 与 src/views/case.view.ts，命中同一页另外两处失实。明确不在 #945 范围内（#945 的行集是 :145 / :148 / :150），故单独记录。

行号为 origin/main = b7791caf 上的行号（PR #939 / #946 / #947 均已落地），三语同址。

一、:147 Details 页签「所有元数据字段」

  - **Details** — full case description and resolution, all metadata fields.

zh 同款：cases.zh-Hans.mdx:147「Details——完整的工单描述和解决方案、所有元数据字段。」

Details 页签是一个 record:details（src/pages/case_detail.page.ts:112-154），三个分区共 16 个字段：

crm_case 自己声明的字段是 28 个（src/objects/case.object.ts）。落在这个页签之外的至少有：first_response_date、created_date、closed_date、is_closed、parent_case、customer_rating、customer_feedback、customer_signature、internal_notes、priority_rank、display_title。

其中 first_response_date 尤其刺眼：同一页 :72 刚用一整段讲清它由 logActivityAction 怎么打戳（PR #946 落地），读者顺着「所有元数据字段」去 Details 页签上找这个字段，找不到。

二、:55 「详情屏幕分为 6 个分区」表

The detail screen is organised into 6 sections:

| **Case Information** | Case number, subject, description, account, contact |
| **Origin & Routing** | Origin, owner, parent case |
| **SLA & Priority** | Status, priority, type, first response time, SLA due date, SLA Violated |
| **Resolution** | Closed date, resolution, customer signature |
| **Escalation** *(collapsed by default)* | Escalation flag, escalated date, escalation reason |
| **System** *(collapsed by default)* | Audit trail, timestamps |

这六个分区名在任何一个真实界面上都不成立：

• 详情页的 record:details 只有三个分区：Case Information / Status & SLA / Description（见上表）。
• 表单（src/views/case.view.ts:167-205）是 type: 'tabbed'，也是三个分区：Case / SLA / Resolution。
• Origin & Routing、Escalation、System 三个名字在 src/ 里根本不存在，grep 零命中；「审计跟踪、时间戳」不是任何一个分区的字段列表。
• 字段归属也串了位：description 在详情页属于 Description 分区而不是 Case Information；parent_case 只出现在表单的 SLA 分区里，详情页上根本没有。

注意 PR #939 动过这张表的一个单元格（把「违约标记」改成 SLA Violated），但没有复核分区名与数量本身，所以这一族至今未被处理。

为什么要紧

与 #941 / #945 同一模式：读者按这份清单去工单上按图索骥。:55 的表告诉他有六个分区、其中两个默认折叠，:147 告诉他 Details 页签上有全部字段 —— 两处都会让他在界面上白找一轮，然后合理地怀疑是自己权限或版本问题。此外「详情屏幕」与「表单」是两个不同界面，这张表把两者混成了一个，也值得在改写时分开写清。

口径建议沿 #903 / #924 / #933 / #941 / #945：点名说清不存在 + 给出真实归属（真实的分区名与字段清单，详情页与表单分开），不静默删名。三语同步。

重复检查

本轮 search_issues 对有命中的查询一律返回 API rate limit already exceeded（零命中的查询正常返回），因此只能用零命中作反证："all metadata fields"、"所有元数据字段"、"detail screen is organised"、"Origin & Routing"、"6 sections" cases 五个查询在 open issue 里均为 0 命中，故判定无重复单。若与他人同小时立单重复，烦请 PM race-close。

Refs #945 #941