replica-deploy
Lit tout ce qui se trouve dans replica/. Écrit replica/deploy.md (la checklist dans preflight.md de ce dossier, remplie).
Les règles
- Rien ne peut être mis en ligne sans l'accord de l'utilisateur. Affiche les résultats de la pré-vérification et demande.
- L'utilisateur achète et se connecte. L'agent n'achète jamais de domaine, ne saisit pas de carte bancaire, ne tape pas de mot de passe et ne colle pas de clé live. L'agent écrit les enregistrements DNS exacts, les noms de variables d'environnement et les commandes ; l'utilisateur effectue les étapes liées au compte.
- Pas avant que ce soit rebrandé. Le nettoyage doit être complet. Aucune exception.
Étape 1 : pré-vérification
Exécute chaque vérification et colle les résultats dans deploy.md :
npx playwright test # replica-test
python3 .cursor/skills/replica-diff/parity.py replica/features.csv # fonctionnalités essentielles faites
python3 .cursor/skills/replica-brand/sweep.py . --config replica/brand.json # sortie 0 : propre
python3 .cursor/skills/replica-launch/listing.py replica/launch/listing.json # si publication sur les stores
npm run build # build de production réussi
(Les chemins supposent que le pack se trouve dans .cursor/skills/ à la racine du projet. Si vous avez copié les dossiers ailleurs, pointez les commandes python3 vers ces chemins.)
En plus, manuellement : aucun bug S1 ou S2 ouvert, pages de politique de confidentialité et conditions d'utilisation en ligne (listant chaque sous-traitant), bannière de cookies si vous utilisez des cookies non essentiels dans l'UE ou au Royaume-Uni, suppression de compte fonctionnelle, favicon, titres et image OG qui sont les vôtres.
Tout échec arrête le déploiement. Indique lequel et pourquoi.
Étape 2 : services de production
- Un projet de production séparé pour la base de données (jamais celui de développement), sauvegardes activées, migrations exécutées par le déploiement, pas à la main.
- Variables d'environnement définies dans l'hébergeur pour la production, correspondant à
.env.example. Clés live uniquement ici. - Stripe : passer en mode live, recréer les produits et les prix, ajouter le point d'accès webhook de production et son secret de signature, tester un achat réel et le rembourser.
- OAuth : ajouter le domaine de production aux URI de redirection et aux origines autorisées de chaque fournisseur. Les portées Google nécessitant une vérification doivent être approuvées, sinon seuls les utilisateurs de test peuvent se connecter.
- Email : le domaine d'envoi vérifié auprès du fournisseur d'email.
Étape 3 : hébergeur et domaine
Par défaut : Vercel pour Next.js (Netlify, Cloudflare Pages, Fly ou Render sinon). Connecter le dépôt pour que main soit déployé et que les pull requests aient des URL de prévisualisation.
Le domaine, après que l'utilisateur l'ait acheté chez un registraire quelconque :
| enregistrement | nom | valeur |
|---|---|---|
| A | @ | l'IP apex de l'hébergeur (Vercel : affichée dans les paramètres de domaine) |
| CNAME | www | la cible de l'hébergeur (Vercel : cname.vercel-dns.com) |
| TXT | @ ou un sous-domaine | la valeur de vérification de l'hébergeur, si demandée |
DNS email provenant du fournisseur d'email : SPF (TXT), DKIM (CNAME ou TXT), et un enregistrement DMARC commençant par v=DMARC1; p=none; rua=mailto:you@yourdomain puis renforcé à quarantine une fois les rapports propres. Sans cela, vos emails de confirmation iront dans les spams.
Choisir un hôte canonique (apex ou www) et rediriger l'autre. HTTPS est automatique sur les hébergeurs ci-dessus ; vérifiez-le.
Étape 4 : surveiller
Suivi des erreurs (Sentry ou celui de l'hébergeur), vérifications de disponibilité sur la page d'accueil et l'API du flux principal, journaux conservés, analytics (un outil respectueux de la vie privée évite la bannière de cookies), et une alerte par email ou téléphone à l'utilisateur. Ensuite, effectuez vous-même le flux principal sur le site live et demandez à l'utilisateur de le faire sur son téléphone.
Étape 5 : mobile, s'il y a une application
Expo : eas build puis eas submit vers TestFlight et les tests internes de Google Play. Natif : archiver dans Xcode, télécharger sur App Store Connect ; bundle Gradle vers Play Console. L'utilisateur possède les comptes développeurs (99 $ par an pour Apple, 25 $ une fois pour Google). D'abord en bêta, puis révision avec le listing de replica-launch.
Résultat
replica/deploy.md avec chaque vérification et son résultat, l'URL live, les enregistrements DNS configurés, et à quoi faire attention la première semaine. Le clone est désormais une application qui porte votre nom.