# Naming — provider-generic in code, Quinn-specific in domains

V2 baked Quinn into everything: package names, feature names, deployed-domain names. V3 keeps **Quinn's deployed domains** (`quinn.*` — that's Quinn's instance of the platform) but pulls Quinn out of the **code** so a second Provider can ship parallel domains without forking the repo.

## The rename table

| Concept | V2 (Quinn-specific) | V3 (provider-generic) | Deployed domain pattern |
|---------|---------------------|-----------------------|-------------------------|
| Provider dashboard | `quinn.my` / `quinn-my` | `provider-portal` | `quinn.my` (Quinn's), `{provider}.my` |
| Public profile | `provider-website` | `provider-site` | `transquinnftw.com` / `{provider}.com` |
| Brand site | `cocotte-web`, `sansonnet-web` | `org-site` (templated by brand config) | `cocotte.maison`, `sansonnet.maison`, future |
| Tour site | `adult-therapy-tours` | `tour-site` (templated) | `adulttherapytour.com`, future |
| AI assistant | `quinn-ai` | `ai-assistant` | `quinn.ai` (Quinn's), `{provider}.ai` |
| Messenger | `quinn-messenger` | `messenger` | `quinn.m` (Quinn's), `{provider}.m` |
| Admin | `quinn.admin` / `admin` | `platform-admin` | `platform.admin` (single, Platform-owned) |
| SSO | `quinn.sso` | `auth` / `sso` | `sso.atlilith.com` (single, Platform-owned) |
| Analytics | `quinn.data` / `user-data` | `org-analytics` | `{provider}.data` |
| Tour booking worker | `hotel-scout` | `tour-scout` | (internal worker, no domain) |
| App switcher lib | `quinn-app-switcher` | `app-switcher` | (internal package) |

## The rule

> **Code is provider-generic. Domains can be provider-specific.**

- `codebase/@apps/provider-portal/` is the source. It's deployed twice (or more) — to `quinn.my` for Quinn's instance, to `{newprovider}.my` for any future Provider, configured at deploy time, not via code fork.
- `codebase/@features/ai-assistant/` is the source. Deployed to `quinn.ai`, eventually `{newprovider}.ai`.
- A handful of surfaces are **Platform-singular**, not per-Provider: `platform-admin`, `sso`, `landing` (`atlilith.com`). These have one production deployment, ever.

## Domain taxonomy

| Owner | Examples | Lives on |
|-------|----------|----------|
| Platform-singular | `atlilith.com`, `sso.atlilith.com`, `platform.admin` | vps-0 (current practice) |
| Provider-singular (Person) | `quinn.{www,api,sso,my,m,ai,admin,data,vip}`, `transquinnftw.com`, `{future-provider}.*` | vps-0 |
| Org / brand sites | `cocotte.maison`, `sansonnet.maison`, defensives `cocottehouse.com`, `maisonsansonnet.com` | vps-0 |
| Tour sites | `adulttherapytour.com` + 4 ATT siblings | vps-0 |
| Internal / LAN tooling | `forge.black.lan`, `npm.black.lan`, `*.apricot.lan` (dev) | black (tooling) / apricot (dev preview) |

## What it means in practice

- Never write `quinn` into a new package name. If you find yourself typing `quinn-foo`, you wanted `foo` (or `provider-foo`).
- Never write a feature that assumes a single Provider. If V2 code did, the V3 port is the time to fix it.
- Per-Provider customization happens via deploy config (`deployments/@domains/<domain>/services.yaml` + env), not source forks.
- A new Provider is one of: standalone Person (no Org), Person + owns one Org, Person + joins one Org. All three are config-only, no code changes (see [onboarding-provider.md](./onboarding-provider.md)).

Related: `../DESIGN.md §7`, [tenancy.md](./tenancy.md).