- Shipped
- 28 Agosti 2026, 22:20 UTC
- Author
- Kamo
- Commit
- 70f388f
Creating an organization handed the creator a button pointing at `https://internal.<the domain they typed>/`. That host does not resolve: the domain is one they own and have not pointed at us yet — doing so is a later, optional step — so the link that was meant to open the thing they had just made opened a browser error. The twelve-step wizard had this right and said so in a comment: it spent the one-time key at `/validate` on whatever host the member was already on, noting that it USED to redirect to `internal.<new-domain>` and had stopped precisely because a brand-new org has no DNS. The one-page rewrite reintroduced it, from the primary domain the create response reports. So the entry link is relative again, and the decision now lives in createdWorkspace.ts with tests that pin it — including one that simply asserts the URL never contains a scheme or `internal.`, so this cannot come back a third time by way of some other plausible-looking domain field. Two things came back with it that the rewrite had also dropped: - `?org=<themeSlug>` rides along. The arriving tab has no session yet, so without it the shell resolves the shared host, gets "the platform", and paints Kamo's logo and colours over an organization whose own branding is already provisioned and waiting. - A missing one-time key is handled rather than ignored. There is nothing to enter with, so the link goes to the organization list — where the new org is deep-linked by id — and a warning says why, instead of a button labelled "Enter workspace" quietly going somewhere else. `submitWizard` no longer reports the org's primary domain at all. It had exactly one consumer and that consumer was the bug; leaving the field there is leaving the same mistake within reach.