83212d7c23
ci / typecheck (map[dir:apps/booking name:booking]) (push) Successful in 19s
ci / typecheck (map[dir:apps/operator name:operator]) (push) Successful in 21s
ci / typecheck (map[dir:apps/website name:website]) (push) Successful in 18s
ci / build (map[dir:apps/booking name:booking]) (push) Successful in 9s
ci / typecheck (map[dir:apps/portal name:portal]) (push) Successful in 27s
ci / typecheck (map[dir:services/platform-api name:platform-api]) (push) Successful in 21s
ci / test (push) Successful in 29s
ci / build (map[dir:apps/portal name:portal]) (push) Successful in 5s
ci / build (map[dir:services/platform-api name:platform-api]) (push) Successful in 5s
ci / build (map[dir:apps/operator name:operator]) (push) Successful in 29s
ci / deploy (push) Successful in 40s
The operator could list and inspect tenants but had no create flow — tenant creation only existed as the partner-portal wizard, which always attaches a partnerId. Platform-api's POST /tenants (platform-admin only, no partner field) was already built for this; add the missing UI: a New tenant modal on the tenants page (slug, name, plan/cycle/currency/seats, optional primary mail domain + first-admin invite) and the server proxy route. Operator-created tenants are direct customers; attach a partner later if needed.