- Shipped
- August 25, 2026 at 12:56 AM UTC
- Author
- Kamo
- Commit
- e3daede
Creation checked the alias only within one security provider, and PUT /org/{id} checked nothing at all — it applied whatever it was given. Both were reasonable while an alias was only resolved as (security_provider_id, alias) behind a <alias>.<parentdomain> host. ?org= changed that. An organization can be named directly by its alias with no provider to scope the lookup, so a repeat makes the reference ambiguous platform-wide: OrgResolutionService refuses it rather than picking one, which leaves BOTH organizations unreachable by alias. A rename through PUT could do that silently to an org that was previously fine. Also rejects an all-digit alias on both paths. A digit reference resolves as an organization id and never falls through to the alias lookup, so such an alias could never name its own organization — better to refuse it than to create something unreachable. The existing repeats are left alone: four orgs share "acme-corp" and two share "kia-kaha", all seeded the same day. An alias is a tenant key — it names theme folders and <alias>.<domain> hosts — so renaming live ones is not something to do unilaterally. The resolver already refuses the ambiguous ones, so nothing resolves wrongly in the meantime. Verified on a clean clone: 951 tests pass. The working tree currently fails 63 unrelated tests from another session's in-flight PHI work (a PhiTenantResolver that is not wired in their tests yet).