Sous-domaines publics : checklist operateur

Le code est pret (src/config/domains.ts, src/lib/subdomain-routing.ts, src/proxy.ts). Rien ne change pour un utilisateur tant qu'un sous-domaine n'est pas liste dans NEXT_PUBLIC_LIVE_SUBDOMAINS. L'etat des lieux et le pourquoi : public-domains-audit.md.

Les sept

Chaque sous-domaine ne repond QUE pour sa surface : mcp.boostecom.app/admin est un 404, pas le panel sur un autre hote.

docs. est l'exception inverse (decision D15 du nettoyage du 2026-09-25) : une page de doc indexee veut UNE adresse, donc ce sous-domaine redirige en 308 vers la meme page sur www au lieu de la servir une seconde fois. docsUrl() (src/config/domains.ts) n'emet donc jamais docs., meme allume. Lister docs dans NEXT_PUBLIC_LIVE_SUBDOMAINS ne change plus rien ; il faut seulement le CNAME et le domaine Vercel pour que la redirection reponde.

boostecom.fr n'est pas un domaine de la plateforme : c'est l'agence emailing du fondateur, et il ne redirige PAS vers .app (decision du proprietaire du 2026-09-25, qui corrige la reco D15 de l'audit). Rien ici ne doit le configurer.

Ce que tu fais (une fois, dans cet ordre)

1. DNS, chez le registrar de boostecom.app : un CNAME par sous-domaine vers cname.vercel-dns.com.

2. Vercel, projet BoostEcom, Settings > Domains : ajouter les sept domaines au meme projet. Attendre le certificat (colonne Valid).

3. Verifier chaque hote avant de l'allumer :

   • curl -I https://status.boostecom.app rend 200 ;
   • curl -I https://mcp.boostecom.app/<un storeId> rend 401 avec un en-tete WWW-Authenticate qui pointe sur https://mcp.boostecom.app/.well-known/oauth-protected-resource/<id> ;
   • curl https://mcp.boostecom.app/.well-known/oauth-protected-resource/<id> rend resource: https://mcp.boostecom.app/<id> et authorization_servers: ["https://www.boostecom.app"].

4. Allumer : dans Vercel, variable NEXT_PUBLIC_LIVE_SUBDOMAINS = mcp,api,cdn,hooks,status,docs,preview (ou seulement ceux verifies), puis redeployer : la variable est inlinee au build.

5. Webhooks (seulement pour hooks) : ressaisir l'URL chez chaque fournisseur. Les anciennes continuent de marcher, donc sans urgence.

   Fournisseur	Nouvelle URL
   Stripe	https://hooks.boostecom.app/stripe
   Resend	https://hooks.boostecom.app/resend
   GitHub	https://hooks.boostecom.app/github
   Meta / WhatsApp	https://hooks.boostecom.app/whatsapp
   Shopify	rien a faire : l'adresse est enregistree par le code a la prochaine connexion de boutique

   Verifier le nom exact de chaque route dans src/app/api/webhooks/ avant de ressaisir.

Ce qui est volontairement fixe

• L'emetteur OAuth reste www. Le consentement /oauth/authorize a besoin de la session NextAuth, un cookie host-only que mcp. ne recoit jamais. Le document de ressource sur mcp. nomme donc www comme serveur d'autorisation.
• preview. est « meme site » que www. C'est sans risque ici pour trois raisons, a garder vraies : le cookie de session n'a pas d'attribut Domain (src/modules/auth/server.ts), une ecriture venant de preview. porte une origine que checkStateChangingOrigin refuse, et une lecture reste derriere CORS. Ajouter un Domain=.boostecom.app au cookie de session casserait les trois d'un coup.
• Les URLs Blob en base ne sont pas migrees. cdnUrl() traduit a l'affichage ; un rendu renvoye au serveur (Reuse, Variation) est ramene a son URL Blob par canonicalReferenceUrl() avant le controle de propriete.
• Les formes en chemin ne sont jamais retirees. Un jeton OAuth est lie a l'URL appelee, une URL de webhook est saisie dans une console.

Pas fait, et pourquoi

partner., affiliate., blog., community. : ce sont des pages marketing. En sous-domaine, Google les traite comme un site a part et l'autorite SEO se divise. Si une adresse courte est utile a imprimer, une redirection (partners.boostecom.app → /network/partners) suffit, sans y heberger la page. og. : lu par des crawlers seulement.