chore: wire Carplace into dev and production stacks
Build & Deploy / Build & Push Docker Image (push) Successful in 2m55s
Test / Type Check (all packages) (push) Successful in 54s
Build & Deploy / Deploy to VPS (push) Successful in 4s
Test / API Unit Tests (push) Failing after 48s
Test / Homepage Unit Tests (push) Successful in 43s
Test / Storefront Unit Tests (push) Failing after 40s
Test / Admin Unit Tests (push) Successful in 40s
Test / Dashboard Unit Tests (push) Failing after 42s
Test / API Integration Tests (push) Successful in 1m0s

This commit is contained in:
root
2026-07-02 18:15:42 -04:00
parent ad5f5ebab7
commit 7ff2dbb139
214 changed files with 5258 additions and 5906 deletions
+8 -8
View File
@@ -29,7 +29,7 @@ The app covers:
It is distinct from:
- the storefront app, which is public and cross-company
- the Carplace app, which is public and cross-company
- the company site app, which is public and company-branded
- the admin app, which is platform-internal rather than tenant-scoped
@@ -65,7 +65,7 @@ This lets the dashboard run:
- directly in dev on port `3001`
- behind a reverse proxy
- embedded under a shared storefront/admin hostname while still loading its own chunks correctly
- embedded under a shared Carplace/admin hostname while still loading its own chunks correctly
## Top-Level Structure
@@ -92,7 +92,7 @@ apps/dashboard/
api.ts cookie-aware API fetch wrapper
preferences.ts language/theme persistence scoped per employee
dashboardPaths.ts normalizes basePath-aware routes
urls.ts resolves storefront/admin app links
urls.ts resolves Carplace/admin app links
src/middleware.ts auth gate and redirect logic
```
@@ -142,7 +142,7 @@ Important behavior:
- public dashboard routes are limited to sign-in and forgot-password flows
- all other `/dashboard/*` routes require the `employee_session` cookie
- unauthenticated users are redirected either to the storefront root or to `/dashboard/sign-in`, depending on host context
- unauthenticated users are redirected either to the Carplace root or to `/dashboard/sign-in`, depending on host context
- duplicate `/dashboard/dashboard` paths are normalized back to `/dashboard`
This means route protection is enforced before React renders the protected pages.
@@ -284,7 +284,7 @@ The onboarding flow then completes the initial tenant setup in three steps:
1. basic company info via `PATCH /companies/me`
2. brand/public profile via `PATCH /companies/me/brand`
3. payment and storefront settings via `PATCH /companies/me/brand`
3. payment and Carplace settings via `PATCH /companies/me/brand`
This makes onboarding a dashboard-owned continuation of the API signup flow.
@@ -391,7 +391,7 @@ Route:
Backed by:
- `GET /reservations?source=MARKETPLACE&status=DRAFT`
- `GET /reservations?source=CARPLACE&status=DRAFT`
- `POST /reservations/:id/confirm`
- `POST /reservations/:id/cancel`
@@ -604,7 +604,7 @@ This is the broad configuration surface for the tenant.
It includes:
- public brand and storefront profile
- public brand and Carplace profile
- payment account identifiers
- custom domain setup
- rental policies
@@ -645,7 +645,7 @@ Examples in the code:
It also coordinates with sibling apps:
- `storefrontUrl` links staff back to the public storefront domain
- `CarplaceUrl` links staff back to the public Carplace domain
- `adminUrl` supports cookie-based handoff into the admin interface
- host-aware URL rewriting allows the same app to function under external domains, internal Docker hostnames, and proxied environments