「营业时间」在 sla 页之外还有三处：administration/setup 整整一节教人配置一个不存在的 Setup → Business Hours 屏，reference/faq 把它写成 SLA 计时的前置条件，glossary 收了词条 #928

发现自 #917 / PR #924 的实施过程（写实 sla 页 :27 / :142 两处营业时间承诺时，grep -rniE "business.hours" content/docs/ 找到同族其余落点）。

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

事实：全仓没有任何营业时间的实现

• grep -rniE "business.?hour" src/ 只有三处命中，全是产品目录与报价行的描述文案（src/data/catalog.seed.ts:138、src/data/sales.seed.ts:585 / :629）。
• workingHours / businessCalendar / business_hours / slaCalendar 在 src/ 里零命中——没有工作日日历，没有节假日清单，没有任何可供截止时间对照的配置。
• 唯一会算 SLA 时间的地方是 src/objects/case.hook.ts:60-63 的 due.setHours(due.getHours() + 4)——纯挂钟小时，夜间/周末/节假日照算。
• 也没有"每个优先级的 SLA 定义"这种配置：那 4 小时只对 critical 生效，写死在同一处钩子里（service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 / PR docs(service): SLA 跟踪一节按实测行为改写(#903) #918 已把 sla 页这一点写实）。

PR #924 已把 service/sla-and-escalation 三语页的 :27（引用块）与 :142（管理员提示）写实。同族说法在另外三个文件里仍是原样，不在 #917 的切割里，故单独立单。

三处

1. content/docs/administration/setup.mdx:20-:28 —— 整整一节

### 2. Business hours

**Setup → Business Hours**:

- [ ] Working days (e.g., Mon–Fri)
- [ ] Working hours (e.g., 9 AM – 6 PM)
- [ ] Holidays for the year

Business hours drive [SLA calculations](/docs/service/sla-and-escalation) — e.g., "resolve within 8 business hours" uses these.

这是本族里最贵的一处：不是一句话，而是一份带勾选框的配置清单，指名一个 Setup → Business Hours 屏幕，让管理员逐项去填工作日、工作时段和当年节假日。三样东西都不存在，那个屏幕也不存在。:28 还把它作为 SLA 计算的驱动来源反向链回 sla 页——而 sla 页在 PR #924 之后已经明写没有这个设置，两页现在直接打架。举例里的 "resolve within 8 business hours" 对应的是 High 的 8 小时，那是团队的服务承诺，背后连 sla_due_date 都不会被写（#903 已写实）。

2. content/docs/reference/faq.mdx:92 —— 写成 SLA 计时的前置条件

- The case is in an **open status** (not Resolved / Closed).
- **Business hours** are configured.
- The case's **priority** has an SLA defined.

Cases without a priority get the *default* SLA; if none is set, no clock runs.

:92 与 :93 都不成立，:95 也不成立：不存在"配置营业时间"这一步，不存在"给某个优先级定义 SLA"这个配置面，也不存在"默认 SLA"——钩子只认 critical，其余优先级什么都不写。而 :91（开放状态）是对的，跟 case_sla_monitor 的 status: { $nin: ['resolved', 'closed'] } 一致，不要顺手改掉。

3. content/docs/reference/glossary.mdx:34 —— 词条

**Business hours** — Working days and hours used in SLA calculations.

词典条目定义了一个本应用没有的概念，且断言它被用于 SLA 计算。

三语同址（.zh-Hans / .zh-Hant 均已翻译，行号一致）。

为什么要紧

setup.mdx 是管理员上手时逐项照做的清单，读者会花时间去 Setup 里找一个不存在的屏幕，找不到之后合理地怀疑是自己权限不够或版本不对。faq.mdx:92 更糟一点：它把"营业时间已配置"列成 SLA 时钟运行的前置条件，于是一个发现 High 工单没有计时的管理员，会去排查一个不存在的配置项，而真正的原因是钩子只给 critical 打戳。

边界

• 与 service/sla-and-escalation 剩余六处失实(#903 四族之外):营业时间可配置、SLA 表现报表的四个维度、Breached SLA 视图、Service Board 看板、My Open Cases 排序、Waiting on Customer 暂停 SLA 时钟 #917 / PR docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924 不重叠：那单只动 service/sla-and-escalation 三语页的 :27 / :142，本单是 administration/setup、reference/faq、reference/glossary 三个文件。
• 与 service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 / service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 / service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890 不重叠。
• SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判：营业时间日历是否应该存在是 SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595（SLA policy matrix）的产品问题。本单只要求把当前行为写实——要么点名说清不做什么，要么把这一节整体撤掉并说明去向。
• 口径沿 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: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894 / docs(service): write the sla page's views, report dimensions and business-hours claims to source (#917) #924：点名说清不存在 + 给出真实归属（src/objects/case.hook.ts 的挂钟 4 小时），不静默删名。setup.mdx 这一节是带勾选框的操作清单，写实时需要决定是改写成"本应用不提供"还是整节移除并调整后续小节编号（### 3. Email setup 起）——建议前者，与本仓既有口径一致。

Refs #917 #903 #595