[Feature] Establish the canonical Ticket service and Case escalation boundary #1

New Issue

2026-07-29T15:44:36+02:00

zemion commented

2026-07-29 15:44:36 +02:00

Outcome

Provide canonical operational tickets without duplicating formal case records or helpdesk queue behavior.

Boundary

A Ticket is an operational request, incident, problem, or report with status, assignment, queue references, service targets, communication, and resolution.
A Case is an authoritative formal procedure with parties, evidence, decisions, statutory deadlines, retention, and record obligations.
Helpdesk supplies service profiles, queues, routing, escalation clocks, and channels over Tickets; it does not own a second ticket store.
Escalating a Ticket creates or links a Case through a stable external reference. Ticket and Case histories remain separately authoritative and linked rather than copied or silently transformed.

Acceptance criteria

Tenant-safe ticket CRUD, status lifecycle, assignment, participants, links, attachments, comments, and immutable history.
Optional queue/SLA capability hooks work with and without Helpdesk installed.
Optional Case escalation is idempotent and records source/target references, actor, timestamp, and outcome.
Permissions distinguish reading, reporting, triage, assignment, resolution, and administration.
Ticket search resources and change events can be announced without importing Search.
API and WebUI explain unavailable optional behavior instead of failing when Cases, Helpdesk, Projects, Wiki, Files, or Search are absent.

## Outcome Provide canonical operational tickets without duplicating formal case records or helpdesk queue behavior. ## Boundary - A **Ticket** is an operational request, incident, problem, or report with status, assignment, queue references, service targets, communication, and resolution. - A **Case** is an authoritative formal procedure with parties, evidence, decisions, statutory deadlines, retention, and record obligations. - Helpdesk supplies service profiles, queues, routing, escalation clocks, and channels over Tickets; it does not own a second ticket store. - Escalating a Ticket creates or links a Case through a stable external reference. Ticket and Case histories remain separately authoritative and linked rather than copied or silently transformed. ## Acceptance criteria - Tenant-safe ticket CRUD, status lifecycle, assignment, participants, links, attachments, comments, and immutable history. - Optional queue/SLA capability hooks work with and without Helpdesk installed. - Optional Case escalation is idempotent and records source/target references, actor, timestamp, and outcome. - Permissions distinguish reading, reporting, triage, assignment, resolution, and administration. - Ticket search resources and change events can be announced without importing Search. - API and WebUI explain unavailable optional behavior instead of failing when Cases, Helpdesk, Projects, Wiki, Files, or Search are absent.

zemion added the module/cases module/search module/tickets area/webui module/helpdesk area/api codex/ready area/governance area/db

labels 2026-07-29 15:44:36 +02:00

zemion commented

2026-08-22 10:52:56 +02:00

Implementation started for the first releasable vertical slice. Scope: tenant-safe canonical ticket persistence; distinct report/triage/assignment/resolution/admin permissions; guarded lifecycle and optimistic concurrency; participants, typed resource/attachment links, comments, and immutable history; optional queue/SLA and Case-escalation capability boundaries; Search source/change evidence without importing Search internals; actor-facing API/WebUI availability diagnostics; and manifest-driven user/admin documentation. I will release and attach verification evidence here before closing or stating exact residual work.

zemion commented

2026-08-22 12:29:27 +02:00

Implemented and released the canonical Tickets vertical slice.

Delivered:

tenant-scoped Ticket lifecycle with report, triage, assignment, resolution, reopen/cancel, replay/OCC guards, soft deletion, participants, typed links/attachments, internal/external comments, and immutable history;
distinct read/report/triage/assign/resolve/admin authorization, including service-layer rechecks;
optional Helpdesk routing profiles and deterministic fail-open manual routing when no profile/provider matches;
optional, replay-safe Ticket -> Case escalation through the Core capability contract, without sibling-module imports;
Search source/backfill/events plus DSAR coverage and documentation for the new persistence;
semantic Tickets queue/detail WebUI, shared page/action/dialog primitives, endpoint-complete UI actions, destructive-action separation, and explicit consequences when optional modules are absent;
Core v0.1.30 integration contracts and WebUI composition, plus tagged WebUI packages for Tickets, Helpdesk, and Cases.

Published evidence:

Tickets v0.1.20: c6c643778bc73d0504e9f1ef5b710ca98436ae41
Helpdesk v0.1.20: 2cfc013791b50e09eddd26b7720163d94628ddd9
Cases v0.1.20: d395b22301e71049e831ab4742a247de6ce5d9d0
Core v0.1.30: a090e5af2091b8b5ab2beb117dd8663344e56943
Workspace composition/evidence: ca68d98806beaadd8318512cc3e1b61fb43aeb8a

Verification:

tools/checks/check-focused.sh passed end-to-end;
68/68 manifest shapes and dependency boundaries passed;
Tickets/Helpdesk/Cases owner suites and interface-pattern checks passed;
strict endpoint/interface inventory and DSAR coverage passed (47 providers, 21 reviewed no-store modules);
61 WebUI module permutations, full-product bundle budgets, and 8 Playwright conformance scenarios passed;
remote branches and annotated release tags were verified at the SHAs above.

The acceptance criteria are satisfied; closing this issue.

Implemented and released the canonical Tickets vertical slice. Delivered: - tenant-scoped Ticket lifecycle with report, triage, assignment, resolution, reopen/cancel, replay/OCC guards, soft deletion, participants, typed links/attachments, internal/external comments, and immutable history; - distinct read/report/triage/assign/resolve/admin authorization, including service-layer rechecks; - optional Helpdesk routing profiles and deterministic fail-open manual routing when no profile/provider matches; - optional, replay-safe Ticket -> Case escalation through the Core capability contract, without sibling-module imports; - Search source/backfill/events plus DSAR coverage and documentation for the new persistence; - semantic Tickets queue/detail WebUI, shared page/action/dialog primitives, endpoint-complete UI actions, destructive-action separation, and explicit consequences when optional modules are absent; - Core v0.1.30 integration contracts and WebUI composition, plus tagged WebUI packages for Tickets, Helpdesk, and Cases. Published evidence: - Tickets v0.1.20: `c6c643778bc73d0504e9f1ef5b710ca98436ae41` - Helpdesk v0.1.20: `2cfc013791b50e09eddd26b7720163d94628ddd9` - Cases v0.1.20: `d395b22301e71049e831ab4742a247de6ce5d9d0` - Core v0.1.30: `a090e5af2091b8b5ab2beb117dd8663344e56943` - Workspace composition/evidence: `ca68d98806beaadd8318512cc3e1b61fb43aeb8a` Verification: - `tools/checks/check-focused.sh` passed end-to-end; - 68/68 manifest shapes and dependency boundaries passed; - Tickets/Helpdesk/Cases owner suites and interface-pattern checks passed; - strict endpoint/interface inventory and DSAR coverage passed (47 providers, 21 reviewed no-store modules); - 61 WebUI module permutations, full-product bundle budgets, and 8 Playwright conformance scenarios passed; - remote branches and annotated release tags were verified at the SHAs above. The acceptance criteria are satisfied; closing this issue.

zemion closed this issue

2026-08-22 12:29:28 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-tickets#1