feat(sla): SLA policies, inboxes, business hours & routing rules

[melihsunbul]

What

SLA policies, inboxes, business hours and routing rules — the assignment-and-response-time layer on top of ticketing.

Concepts

• Inbox — a queue that groups tickets (for example by product or team) so work can be triaged and owned.
• Business hours — the working calendar an SLA clock runs against, so targets are not breached overnight or at weekends.
• SLA policy — response/resolution targets measured against business hours, with breach tracking surfaced on the ticket.
• Routing rule — an ordered, condition→action rule that directs an incoming ticket to an inbox/team/assignee. Rules are evaluated read-only over ticket attributes.

How it works

• Domains — domains/sla/ (policy definitions, clock calculation against business hours, breach tracking) and domains/inboxes/.
• API — /api/v1/sla-policies, /inboxes, /routing-rules, /business-hours (CRUD plus coverage tests); the internal /api/v1/internal/sla-tick advances SLA clocks.
• Server functions — functions/routing.
• UI — /admin/settings/sla, /admin/settings/inboxes, /admin/settings/routing-rules (conditions and actions builders), /admin/settings/business-hours, and an SLA clock chip on the ticket view.
• Client — use-routing-queries and a business-hours query factory.

How to use

• Set business hours: Settings → Business hours (/admin/settings/business-hours).
• Create inboxes: Settings → Inboxes (/admin/settings/inboxes).
• Define SLAs: Settings → SLA (/admin/settings/sla) — set response/resolution targets; the ticket view shows a live clock and breach state.
• Automate routing: Settings → Routing rules (/admin/settings/routing-rules) — build condition→action rules; order determines precedence.

Safety

• Routing rules and SLA policies are admin-managed and audit-logged; rule evaluation is read-only over ticket attributes.

Verification

• bun run typecheck, bun run lint; sla.services.test.ts, sla-policies coverage, business-hours, routing conditions/actions builders (included).

Depends on 04-ticketing-crm-core.

---

📚 This is a stacked series — please review & merge in order

These 10 PRs are split by concern and ordered by dependency. Each is opened against main, so until the PRs before it have merged, a PR's diff is cumulative (it also contains the earlier batches). As the earlier PRs merge and we rebase the next branch onto main, each diff reduces to just its own batch. Merging all 10 in order reproduces our integrated branch exactly (verified: the cumulative tip of the series is byte-identical to it).

Order (by branch):

1. 01-data-model-foundation — data model, TypeIDs, migrations
2. 02-rbac-authz-teams — RBAC, teams, organisation & auth surfaces
3. 03-events-audit-webhooks — event dispatch, audit log, webhooks, notifications
4. 04-ticketing-crm-core — ticketing / CRM core
5. 05-sla-inboxes-routing — SLA policies, inboxes, business hours, routing
6. 06-github-sync-and-ticket-email — GitHub ticket sync, ticket email, integration platform
7. 07-widget-profiles — scoped widget profiles + ticket submission
8. 08-api-openapi-mcp — OpenAPI surface, MCP tools, conversation actions, API keys
9. 09-content-visibility — changelog/help-centre visibility, segments, portal tabs
10. 10-test-coverage — broad unit/integration test suite + supporting infra

Part of the roadmap: #283

[CLAassistant]

All committers have signed the CLA.