> For the complete documentation index, see [llms.txt](https://docs.giize.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.giize.com/ticket-dashboard-en/getting-started/architecture-overview.md).

# Architecture Overview

## Current architecture

Ticket Dashboard is a local-runtime application with four main layers:

```
React UI
  -> thin Vite adapter
     -> server route/domain modules
        -> remote APIs or Node/Playwright workers
```

* UI: `frontend/src/`
* adapter: `frontend/vite.config.js`
* API routes: `server/routes/*.mjs`
* domain/session/job logic: `server/*.mjs`
* shared workflow logic: `shared/*.mjs`
* browser/CLI workers: `scripts/*.mjs`
* runtime state: `data/`

## C1/C2 server extraction

The large middleware implementation has already been extracted. `frontend/vite.config.js` is now a small adapter and builds an exact `METHOD /path` route table from:

* `server/routes/system.mjs`
* `server/routes/sdp.mjs`
* `server/routes/ticket-tools.mjs`
* `server/routes/orders.mjs`

Config, logs, sessions, job lifecycle, SDP, Ticket Tools, and IT Portal behavior now live in focused modules under `server/`. C2 also moved Ticket Tools detail/status work in-process where a separate CLI worker was unnecessary.

## C3 frontend split

`OrderReportPage.jsx` is now an orchestration page rather than a 4,000-line monolith. Asset, create-order, new-employee, login, detail, helper, and shared UI concerns live under `frontend/src/pages/order-report/`.

## Data flow

1. A React page calls a local `/api/*`, `/data/*`, or `/config/*` URL.
2. Vite dispatches API calls to the extracted route registry.
3. The route calls an in-process domain function or starts a worker when browser automation is required.
4. Long-running jobs expose progress/state files or status endpoints.
5. The UI reloads the response or revalidates cached JSON using ETags.

## Active browser routes

* `/overview`
* `/servicedesk`
* `/servicedesk/openvpn`
* `/servicedesk/tickettools`
* `/myportal`
* `/myportal/tools`
* `/settings`

`frontend/src/App.jsx` remains the source of truth for this list.

## Integration surfaces

* ServiceDesk Plus REST and authenticated web flows
* IT Portal / CMDB APIs
* TS/Jira-like web flows
* ACL internal web flow

## Rule of thumb

* For a UI change, inspect the page and its local API/data contract.
* For an API change, start in `server/routes/`, then follow into the domain module or worker.
* For an integration contract, consult `document/` notes and verify current code before relying on an older snapshot.