docs: write the three business-hours claims outside the SLA page to source (#928)

[yinlianghui]

Fixes #928

PR #924 wrote the two business-hours promises on service/sla-and-escalation to source. The same promise was still being made in three other files — and the setup page, which links to that very page, had ended up contradicting it outright.

Premise re-confirmed on fresh origin/main (4855d50)

The issue's evidence chain was re-run rather than reused:

check	result
grep -rniE "business.?hour" src/	3 hits, all product-description strings in seed data (catalog.seed.ts:138, sales.seed.ts:585 / :629)
workingHours / businessCalendar / business_hours / slaCalendar / holiday in src/	zero
"Business Hours" in node_modules/@objectstack/console/dist/	zero — the screen does not exist at platform level either
business hours in @objectstack/spec	only a time-field filter-window test fixture, unrelated to any configuration surface
only SLA deadline computed anywhere	due.setHours(due.getHours() + 4), src/objects/case.hook.ts:60-63, critical only

So: premise valid, all three claims fictional.

What changed

1. administration/setup section 2 — the expensive one. It was not a sentence but a configuration checklist: three checkboxes under a bold Setup → Business Hours heading (working days, working hours, the year's holidays), closing with "business hours drive SLA calculations" and a link to the SLA page. There is no such screen, none of the three settings exist, and after #924 the linked page states that in as many words — two pages disagreeing about one feature. The section keeps its number (so 3–14 do not shift) and its name, so a reader who was sent looking for that screen finds out what happened to it, and now says there is nothing to configure, that deadlines therefore run on calendar hours, and where the one real deadline comes from. The old example, "resolve within 8 business hours", is High's service commitment — nothing stamps sla_due_date for High — so it is named as a promise the team keeps rather than a clock the app runs.

2. reference/faq — "My SLA clock isn't running". Two of the three preconditions were fictional (business hours configured; the priority has an SLA defined) and so was the closing line about a default SLA. This is the one that costs a reader real time: an admin whose High case was not being timed went hunting for a configuration problem when the actual reason is that the hook stamps sla_due_date for critical alone. The answer now opens by saying nothing counts down at all, and the checklist is the real one — open status, a due date present at all, that due date already past with an hourly sweep since. The first bullet (open status) was correct and is unchanged: it matches case_sla_monitor's status: { $nin: ['resolved', 'closed'] }. The re-entrancy bullet #899 added above it is untouched.

3. reference/glossary — rewritten, not deleted. Deleting the entry would leave a reader who looked the term up with no answer, and the repo's own precedent for a term that is not a concept here is the Workflow rule entry (kept, explained). It now gives the industry meaning, states that HotCRM has none of it, and points at the wall-clock four hours.

Three locales each. The zh section heading moves from 工作时间 / 工作時間 to 营业时间 / 營業時間 to match the SLA page it is being reconciled with; the case noun in the rewritten FAQ answer follows the repo-wide 工单 / 工單 rather than the 案例 that was local to that block.

Whether the app should grow a business-hours calendar, per-priority SLA definitions or a default SLA is #595's product question and is not pre-judged here — this records today's behaviour only.

Verification

All six gates run serially under the shared verification lock, on the branch as pushed:

gate	result
pnpm validate	exit 0 (5 pre-existing author-time warnings, unchanged)
pnpm typecheck	exit 0
pnpm lint	exit 0 — 13 warnings, 14 suggestions, all pre-existing
pnpm hygiene	exit 0 — "no raw control bytes in first-party files", scan surface covers content and .changeset
pnpm build	exit 0 — dist/objectstack.json 1921.4 KB
pnpm test -- --maxWorkers=2	exit 0 — 70 files, 1602 passed, 1 skipped

Honest note on what that proves: no automated guard reads these three files. grep -rniE "business.?hour|faq\.mdx|glossary|setup\.mdx" test/ scripts/ returns nothing, and the docs guards that do exist (docs-drift, automation-docs-coverage, sharing-coverage, status-state-machines) pin other pages. The suite was therefore predicted green before it was run and stayed green; it confirms the change broke nothing, not that the new prose is true. What backs the prose is the source evidence in the table above, cited inline in the docs so the next reader can re-check it.

src/ is untouched — git diff --stat is nine .mdx files plus the changeset.

---

Generated by Claude Code

[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 10:10am