HaiLin/ai-ticket-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: sync ticket workflow stage progress

Browse Source
This commit is contained in:
hailin
2026-07-03 16:53:23 +08:00
parent 3449f02579
commit 9d2cdc1ec9
3 changed files with 16 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -6,7 +6,7 @@ The product centers on support tickets and business knowledge, with configurable
## Current Status ## 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: Key docs:

6
docs/frontend/design-system.md
View File

@@ -67,8 +67,10 @@ Business pages should use:
## Current Core Screens ## 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 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 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 require a handling note through `TicketTransitionDialog`. - 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`. - System governance quick-create forms use `AppSection`, `FieldGroup`, and `AppField`.
Preview page: Preview page:

11
docs/superpowers/plans/2026-07-01-stage-1-7-ticket-experience-visual-redesign.md
View File

@@ -37,6 +37,17 @@ Frontend:
- Create: `frontend/src/features/tickets/TicketTransitionDialog.tsx` - Create: `frontend/src/features/tickets/TicketTransitionDialog.tsx`
- Create: `frontend/src/features/tickets/TicketMetaPanel.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 ## Task 1: Backend Ticket List Support
**Files:** **Files:**