100 lines
6.0 KiB
Markdown
100 lines
6.0 KiB
Markdown
# AI Ticket Platform Implementation Roadmap
|
|
|
|
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:writing-plans to expand each stage into a detailed implementation plan before writing code. Use superpowers:subagent-driven-development or superpowers:executing-plans when executing a detailed stage plan.
|
|
|
|
**Goal:** Break the AI-native technical support ticket platform into independently deliverable implementation stages.
|
|
|
|
**Architecture:** Build a modular monolith first. Keep Django apps, React feature modules, workers, model gateway, Agent runtime, and MCP integration separated by clear interfaces so heavily loaded areas can be split later.
|
|
|
|
**Tech Stack:** Django, Django Ninja, PostgreSQL, pgvector, Redis, Celery, MinIO, React, Vite, Tailwind CSS, shadcn/ui, Radix UI, TanStack Table, OpenAI-compatible model adapter.
|
|
|
|
---
|
|
|
|
## Source Spec
|
|
|
|
- `docs/superpowers/specs/2026-06-30-ai-ticket-platform-design.md`
|
|
|
|
## Planning Rule
|
|
|
|
The product contains multiple independent subsystems. Do not implement the entire spec from one plan. Use this roadmap to create one detailed plan per stage. Each detailed plan must produce working, testable software.
|
|
|
|
## Stage Breakdown
|
|
|
|
| Stage | Name | Purpose | Depends On | Detailed Plan |
|
|
|---|---|---|---|---|
|
|
| 0 | Foundation and design system | Create the repo skeleton, local runtime, auth/RBAC baseline, audit baseline, frontend theme and component standards. | None | `docs/superpowers/plans/2026-06-30-stage-0-foundation-design-system.md` |
|
|
| 1 | Ticket workflow and reusable solutions | Implement ticket lifecycle, comments, attachments, events, export, solution library, and solution links. | Stage 0 | Create after Stage 0 passes. |
|
|
| 1.5 | shadcn enterprise UI foundation | Formalize shadcn/ui initialization, add a project-owned App component layer, redesign current ticket and solution pages, and enforce Chinese frontend text. | Stage 1 | `docs/superpowers/specs/2026-07-01-stage-1-5-shadcn-ui-foundation-design.md` |
|
|
| 2 | Knowledge base and vector retrieval | Implement knowledge bases, documents, parsing jobs, chunks, embeddings, and retrieval. | Stage 0, partial Stage 1 | Create after Stage 1 model contracts stabilize. |
|
|
| 3 | Model gateway and Agent/Skill runtime | Implement provider configs, model configs, model testing, Skill configs, built-in Agents, runs, steps, AI artifacts. | Stage 0, Stage 1, Stage 2 retrieval interfaces | Create after Stage 2 retrieval contracts exist. |
|
|
| 4 | MCP tools and trust boundary | Implement MCP server registration, tool sync, risk levels, Agent tool binding, tool calls, confirmation, audit. | Stage 3 | Create after Agent runtime exists. |
|
|
| 5 | Historical ticket migration and polish | Import historical tickets, standardize fields, vectorize, generate solution drafts, add dashboards and UI polish. | Stage 1, Stage 2, Stage 3 | Create after core flows work. |
|
|
|
|
## Stage 0 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| Backend | Django project, settings split, Django Ninja API root, health endpoint, accounts app, audit app, system app. |
|
|
| Frontend | Vite React project, Tailwind, shadcn/Radix base, theme tokens, layout shell, component preview page. |
|
|
| Runtime | Docker Compose with backend, frontend, PostgreSQL, Redis, MinIO, Celery worker, Celery beat. |
|
|
| Governance | Login baseline, users/groups/roles baseline, menu definitions, permission seed command, audit model. |
|
|
| Quality | pytest, ruff, mypy baseline, frontend lint/typecheck/build, pre-commit optional. |
|
|
| Documentation | `.env.example`, local startup guide, design system notes. |
|
|
|
|
## Stage 1 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| Ticket core | `ticket`, `ticket_category`, `ticket_comment`, `ticket_attachment`, `ticket_event`, `ticket_collaborator`. |
|
|
| Ticket APIs | Create/list/detail/update/status transition/comment/upload/export. |
|
|
| Ticket UI | List page, create page, detail page, status timeline, comments, attachments. |
|
|
| Solutions | `solution`, `ticket_resolution`, `ticket_solution_link`, solution list/detail/linking. |
|
|
| Audit | Ticket operations written to audit/event tables. |
|
|
|
|
## Stage 2 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| Knowledge | `knowledge_base`, `knowledge_document`, `knowledge_item`, `knowledge_chunk`. |
|
|
| Jobs | Document parsing, chunking, embedding enqueue/retry/status. |
|
|
| Retrieval | Keyword search plus vector search interface. |
|
|
| UI | Knowledge base, document status, knowledge item editor, search page. |
|
|
|
|
## Stage 3 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| Model gateway | `model_provider`, `model_config`, encrypted secrets, OpenAI-compatible client adapter. |
|
|
| Model testing | Single model test and multi-model comparison UI. |
|
|
| Skills | `skill_definition`, prompt template rendering, input/output schema validation. |
|
|
| Agents | `agent_definition`, `agent_run`, `agent_step`, `ticket_ai_artifact`. |
|
|
| Built-ins | Ticket creation Agent, support analysis Agent, knowledge distillation Agent. |
|
|
|
|
## Stage 4 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| MCP config | `tool_server`, `tool_definition`, `tool_call`. |
|
|
| Sync | Tool discovery/sync from configured MCP server. |
|
|
| Risk control | low/medium/high risk, human confirmation for high risk. |
|
|
| Agent integration | Authorized tool calls appear in `agent_step` and `tool_call`. |
|
|
|
|
## Stage 5 Deliverables
|
|
|
|
| Area | Deliverable |
|
|
|---|---|
|
|
| Migration | Import script and staging model for historical tickets. |
|
|
| AI cleanup | Summaries, categories, error codes, solution draft generation. |
|
|
| Retrieval | Historical tickets available for similar-ticket search. |
|
|
| Dashboards | Ticket trends, high-frequency problems, solution usage, Agent usage. |
|
|
|
|
## Cross-Stage Invariants
|
|
|
|
- Business writes generated by AI require user confirmation by default.
|
|
- Secrets are encrypted at rest.
|
|
- Raw model/tool payloads stored in logs must support masking.
|
|
- No business page may define one-off colors, status badges, or table styling.
|
|
- Every backend stage includes API tests.
|
|
- Every frontend stage includes typecheck and build verification.
|
|
- Commit after each coherent task.
|