Problem
seamless init uses application.domain verbatim as AUTH_SERVER_URL after normalization (src/commands/init.ts:180). Per the portal API, mvp and business instances are actually served at domain/<infraId>, so any app whose auth URL is not exactly domain gets a scaffold pointed at a URL that does not respond.
Scope
- Consume a server-computed
instanceUrl field from GET /applications once the portal API exposes it (tracked in seamless-portal-api), falling back to the current behavior only when the field is absent.
seamless check (managed mode) probes <instanceUrl>/health/status and has the same composition assumption; fix both.
Why
The managed scaffold path silently produces a broken local setup for the affected plans, and the failure shows up far from the cause (SDK errors in the user's app, not in the CLI).
Problem
seamless initusesapplication.domainverbatim asAUTH_SERVER_URLafter normalization (src/commands/init.ts:180). Per the portal API, mvp and business instances are actually served atdomain/<infraId>, so any app whose auth URL is not exactlydomaingets a scaffold pointed at a URL that does not respond.Scope
instanceUrlfield fromGET /applicationsonce the portal API exposes it (tracked in seamless-portal-api), falling back to the current behavior only when the field is absent.seamless check(managed mode) probes<instanceUrl>/health/statusand has the same composition assumption; fix both.Why
The managed scaffold path silently produces a broken local setup for the affected plans, and the failure shows up far from the cause (SDK errors in the user's app, not in the CLI).