umairmsm/wp-kickoff

Étape 1 : Lancement

Objectif : une page de vérité sur l'entreprise, et un projet vide avec tous les fichiers attendus par la méthode. Rien n'est encore conçu ni construit.

Étapes

1. Existe-t-il déjà un site en ligne ? Si oui, traitez-le comme une entreprise en activité, pas comme un domaine en attente. Commencez par faire l'inventaire (references/discovery-brief.md, « Site existant ») :
   • chaque URL (à partir de ses sitemaps), formulaire, étape de paiement, article de blog et coordonnées ;
   • ses données Search Console, si le propriétaire peut les partager ;
   • ce qui génère de l'argent aujourd'hui. La reconstruction doit tout garder opérationnel. Crawlez poliment : lisez d'abord les conditions d'utilisation (robots.txt n'est pas une autorisation) et laissez 2 secondes ou plus entre chaque requête.
2. Briefing de découverte. Posez les questions dans references/discovery-brief.md et écrivez les réponses dans docs/BRIEF.md. Marquez chaque fait avec sa source (propriétaire, document, crawl). Si vous ne connaissez pas un fait, écrivez PENDING-<qui>. Ne devinez jamais.
3. Stack. Partez de la valeur par défaut dans references/stack.md. Modifiez une couche uniquement pour une raison que vous pouvez énoncer, et enregistrez-la dans DECISIONS.md.
4. Créez le projet avec le générateur du kit (deux dossiers au-dessus de cette compétence) :

   bash <kit>/bin/wp-site-new --name "Acme Tours" --slug acme-tours --prefix acme \
        --domain example.com --dir ~/sites/acme-tours --git
   

   • slug : minuscules et traits d'union. Il nomme le projet DDEV, les dossiers et les domaines de texte.
   • prefix : 2 à 12 lettres minuscules ou chiffres. Chaque fonction, option, type de publication, clé meta, hook et nonce commence par <prefix>_.
5. Remplissez AGENTS.md :
   • ce qu'est le site ;
   • qui approuve le design et le texte client ;
   • les décisions verrouillées ;
   • les règles strictes propres à cette entreprise, comme les allégations réglementées, les licences à afficher ou les mots que le propriétaire ne veut jamais.
6. Dépôt privé distant, mis en place dès le premier jour. Le propriétaire crée un dépôt privé et pousse. Une fois le site local existant (étape 3), exécutez scripts/backup.sh et conservez une copie sur une autre machine.
7. Inventaire des identifiants (docs/reference/CREDENTIALS_INVENTORY.md) :
   • listez chaque compte (registraire, DNS, hébergeur, SMTP, analytics, Search Console, paiements, CDN) ;
   • indiquez où chaque secret est stocké ;
   • noms uniquement, jamais de valeurs.
8. Cochez la porte de validation du lancement dans SITE_STATUS.md avec les preuves : la date d'approbation du brief, le SHA du premier commit, le nom du dépôt distant.

Porte de validation

• docs/BRIEF.md approuvé par le propriétaire (date)
• Décisions verrouillées et règles métier strictes dans AGENTS.md
• Projet créé et commité ; dépôt privé distant existant
• Inventaire des identifiants commencé (noms uniquement)
• Remplacement d'un site en ligne : inventaire des URL et fonctionnalités sauvegardé dans docs/data/legacy/ (ou « n/a »)

Pièges que nous avons rencontrés

• Traiter le « basculement » comme un simple changement DNS alors que l'ancien site recevait des réservations payantes ce jour-là.
• Les nombres d'avis d'un ancien site (« 1 118 avis ») se sont révélés inventés. Ne les reprenez pas.
• Proxifier le domaine via Cloudflare alors que l'ancien hébergeur limitait le débit par IP. L'hébergeur ne voyait que les IP de Cloudflare, donc les vrais visiteurs obtenaient des erreurs 429. Vérifiez les limites de l'origine avant d'activer le proxy.
• Faire confiance aux notes d'un autre agent qui disaient « résolu ». Le correctif n'était ni poussé, ni testé, ni déployé. Vérifiez la réalité.
• Quelqu'un a collé une clé API dans un chat d'agent. Faites tourner toute clé qu'un agent a vue.