refactor: rename issue reporting module to tickets

docs/TICKETS_DOMAIN_BOUNDARY.md

@@ -0,0 +1,78 @@
+# Tickets Domain Boundary
+
+## Purpose
+
+Queue-oriented operational work: public or internal reports, service requests,
+incidents, problems, triage, routing, assignment, service-level tracking, and
+auditable resolution.
+
+## Owns
+
+- ticket identity, type, category, priority, state, and queue
+- public and internal intake profiles
+- reporter/requester and affected-object references
+- triage, routing, assignment, escalation, and service-level facts
+- discussion and resolution evidence references
+- stable links to tasks, projects, assets, facilities, and cases
+
+## Does Not Own
+
+- formal administrative case identity, parties, evidence, decisions, and retention
+- project plans, milestones, and portfolios
+- asset lifecycle management
+- workflow definitions and task execution
+
+## Integration Candidates
+
+- cases
+- projects
+- wiki
+- assets
+- facilities
+- forms_runtime
+- portal
+- files
+- workflow
+- tasks
+- mail
+- notifications
+- search
+
+## Ticket Versus Case
+
+A ticket is the operational record of work entering and moving through a queue.
+It can be reported with incomplete information, assigned and reassigned,
+discussed, resolved, reopened, or linked to another work object. Its lifecycle
+answers: what needs attention, who owns the next action, and was it resolved?
+
+A case is the authoritative procedural record for an administrative matter. It
+has formal parties, evidence, decisions, procedural deadlines, access rules,
+retention obligations, and a durable case history. Its lifecycle answers: what
+matter is being administered, under which procedure, and what formal outcome
+was reached?
+
+Escalation does not convert or duplicate records. It creates an auditable
+relation containing the ticket reference, case reference, relation type,
+actor, timestamp, and optional handoff note. The ticket remains the intake and
+service history; the case becomes authoritative for the formal procedure.
+
+The former Issue Reporting and Helpdesk concepts become ticket type, intake,
+queue, and policy profiles. They do not need separate persistence models.
+
+## Seed State
+
+The current repository state is intentionally small:
+
+- module manifest and entry point
+- tenant-level permission definitions
+- manager and viewer role templates
+- documentation topic describing the module boundary
+- Gitea issue workflow templates
+- manifest contract test
+
+No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.
+
+## First Implementation Slice
+
+Define ticket identity, intake profiles, queues, triage, assignment,
+resolution, and stable escalation links to cases.