Frontend applications
Administrator, operator, and ticket-agent applications, their runtimes, boundaries, and current delivery status.
Application portfolio
| App | Actor | Stack | Current delivery |
|---|---|---|---|
apps/backoffice | Administrator | TanStack Start, SSR, React Query | 8 shipped capabilities |
apps/supervision | Operator | Vite SPA, React Query, SSE | Platform shell |
apps/counter | Ticket agent | Vite SPA, future Tauri shell | Platform shell |
The applications share one codebase but not one user experience. Each surface serves one actor and mirrors backend module boundaries.
Back-office
The administrator surface ships carrier, line/itinerary, vehicle, permit, permit-import, RFID, permit-expiry, display-point, and display-profile workspaces.
It uses a server-managed OIDC session, authenticated server functions, and capability-gated routes and controls.
Supervision
The operator surface is designed for realtime bay maps, allocation, coach flow, alerts, access-code handling, and SIV supervision. Those workflows remain backlog; the current application provides the technical shell and feature boundaries.
Counter
The counter surface will cover sales, cash sessions, refunds, after-sales work, and vehicle-stay collection. Web code must remain browser-capable when wrapped by Tauri.
The shell owns only storage, printing, kiosk, and startup plumbing. Business logic never moves into Rust or imports Tauri APIs directly.
Shared conventions
- UI text comes from
@smartgare/i18n; French is primary. - Features mirror backend modules and vocabulary.
- API types are generated from OpenAPI, never handwritten.
- Shared primitives come from
@smartgare/ui. - Feature tests are colocated and HTTP goes through MSW.
- Station-specific names and values come from deployment configuration.