From 9d2cdc1ec9f10c5da35941573e20bf970259697c Mon Sep 17 00:00:00 2001 From: hailin Date: Fri, 3 Jul 2026 16:53:23 +0800 Subject: [PATCH] docs: sync ticket workflow stage progress --- README.md | 2 +- docs/frontend/design-system.md | 6 ++++-- ...-01-stage-1-7-ticket-experience-visual-redesign.md | 11 +++++++++++ 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 88f9a4b..a410b85 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ The product centers on support tickets and business knowledge, with configurable ## Current Status -Active implementation. The project has a runnable Django + React baseline with ticket workflow, reusable solutions, enterprise governance, shadcn-based frontend foundation, and Docker Compose local startup. +Active implementation. The project has a runnable Django + React baseline with enterprise governance, shadcn-based frontend foundation, Docker Compose local startup, category-driven ticket workflows, and reusable solution adoption for fast ticket closure. Key docs: diff --git a/docs/frontend/design-system.md b/docs/frontend/design-system.md index bc4caa7..c6cbb2c 100644 --- a/docs/frontend/design-system.md +++ b/docs/frontend/design-system.md @@ -67,8 +67,10 @@ Business pages should use: ## Current Core Screens - Ticket center uses an operations-table layout: the first column combines ticket number, title, requester, and description; workflow state and priority are grouped together. -- Ticket detail uses `AppDetailLayout`, a ticket overview card, a real event timeline, and a side column for metadata, linked solutions, and AI analysis placeholder. -- Ticket status transitions require a handling note through `TicketTransitionDialog`. +- Ticket detail uses `AppDetailLayout`, a ticket overview card, a real event timeline, and a side column for handling context, linked solutions, and AI analysis placeholder. Avoid repeating overview-card fields in the side column. +- Ticket status transitions use `TicketTransitionDialog`. Resolution and closure actions can carry a solution summary; non-resolution workflow actions still require a handling note. +- Ticket workflows are category-driven: business and operation issues support short closure paths, data issues use a medium path, and technical issues keep the standard support workflow. +- Linked solutions support search, recommendation-only linking, adoption with automatic ticket closure, and prefilled resolution text during later resolve/close actions. - System governance quick-create forms use `AppSection`, `FieldGroup`, and `AppField`. Preview page: diff --git a/docs/superpowers/plans/2026-07-01-stage-1-7-ticket-experience-visual-redesign.md b/docs/superpowers/plans/2026-07-01-stage-1-7-ticket-experience-visual-redesign.md index f4f5a0b..b2b8430 100644 --- a/docs/superpowers/plans/2026-07-01-stage-1-7-ticket-experience-visual-redesign.md +++ b/docs/superpowers/plans/2026-07-01-stage-1-7-ticket-experience-visual-redesign.md @@ -37,6 +37,17 @@ Frontend: - Create: `frontend/src/features/tickets/TicketTransitionDialog.tsx` - Create: `frontend/src/features/tickets/TicketMetaPanel.tsx` +## Implementation Progress + +As of 2026-07-03, Stage 1.7 has moved beyond the first visual redesign into a stronger ticket workflow baseline: + +- Ticket categories are standardized as `业务问题`, `技术问题`, `数据问题`, and `操作问题`. +- Category-driven status policies shorten simple business/operation tickets while preserving the full technical workflow. +- Ticket creation captures business-facing context fields including problem performance, problem object, submitter, submitter organization, and environment. +- Solution adoption can close a ticket, write the resolution summary, update usage count, and record timeline events. +- Recommended linked solutions remain non-closing references, but resolve/close dialogs prefill the resolution from linked solutions. +- Ticket detail side metadata was reduced to avoid repeating the overview card. + ## Task 1: Backend Ticket List Support **Files:**