Spaces:
Running
Running
| # HELPDESK.AI - As-Built Architecture | |
| ## 1. System Overview | |
| HELPDESK.AI is a multi-tenant SaaS ticketing platform driven by an AI processing pipeline to automate triage. | |
| ## 2. Component Architecture | |
| ### 2.1 Frontend (React + Vite) | |
| - **Framework:** React 19 mapped through Vite. | |
| - **State Management:** Zustand (`useAuthStore`, `useTicketStore`) with `zustand/middleware/persist` bound to `localStorage` (hardened against QuotaExceeded errors). | |
| - **Styling:** TailwindCSS + Vanilla CSS for animations and layout. | |
| - **Routing:** React Router DOM (v6+), facilitating public routes (`/`), protected user routes (`/dashboard`), and admin flows (`/master-admin`). | |
| ### 2.2 Backend (FastAPI + Python) | |
| - **Framework:** FastAPI providing high-concurrency async endpoints. | |
| - **Core Endpoints:** | |
| - `POST /ai/analyze_ticket`: Synchronous pipeline handling Text Classification (DistilBERT), NER, and Semantic Duplicate detection. | |
| - `POST /ai/log_correction`: Feedback loop endpoint for adversarial retraining. | |
| - **Deployment:** Containerized and hosted on Hugging Face Spaces. | |
| ### 2.3 AI Inference Pipeline (Hugging Face / PyTorch) | |
| - **Categorization & Routing:** Fine-tuned `DistilBERT`. | |
| - **Duplicate Detection:** `sentence-transformers/all-MiniLM-L6-v2` for cosine similarity on cached ticket embeddings. | |
| - **Performance:** End-to-end inference executes in <400ms under standard load. | |
| ### 2.4 Database & Auth Layer (Supabase / PostgreSQL) | |
| - **Auth:** Supabase Auth (Email/Password & Magic Links). User state synchronized instantly via metadata and asynchronously via `profiles` table. | |
| - **Database:** PostgreSQL. | |
| - Table: `profiles` (User RBAC and metadata) | |
| - Table: `tickets` (Core ticket data with JSONB for AI metadata) | |
| - **Row Level Security (RLS):** Strict RLS policies ensure Company Admins only see their tenant's data, and users only see their own tickets. | |
| ## 3. Storage and Scaling Strategy | |
| - **Client-Side:** Critical UI state cached in `localStorage` via Zustand persist. Direct `localStorage` access wrapped in `try-catch` blocks for adversarial resilience. | |
| - **API Rate Limiting:** Expected at the API Gateway level (or via Hugging Face limits). | |
| ## 4. Production Hardening (BMAD Phase 1 & 2) | |
| As part of the BMAD End-Game: | |
| - **SEO & Metadata:** Implemented OpenGraph, Twitter Cards, and canonical meta boundaries in `index.html`. | |
| - **Browser Storage Hardening:** Error boundaries established defensively against JSON Parse failures and Quota Limit Exceeded exceptions on clients. | |
| - **Retrospective Log:** Documented in project artifacts repository. | |