Livraison en Prod

Que fait Livraison en Prod ?

Lorsque l'utilisateur dit « ship it » ou une expression similaire après avoir terminé le travail, suivez ces étapes sans être invité deux fois.

Le flux dépend de la branche sur laquelle vous vous trouvez. Détectez l'environnement une fois, puis réutilisez-le dans les étapes suivantes.

Détecter l'environnement

Exécutez ces vérifications une fois au début, en parallèle :

1. Gestionnaire de paquets : recherchez un fichier de verrouillage à la racine du dépôt.
   • pnpm-lock.yaml -> pnpm
   • yarn.lock -> yarn
   • bun.lockb ou bun.lock -> bun
   • package-lock.json -> npm
   • Si package.json a un champ packageManager, utilisez-le à la place.
   • Si rien trouvé, par défaut npm.
2. Branche par défaut : git symbolic-ref refs/remotes/origin/HEAD (ou git config init.defaultBranch en second recours). Si les deux échouent, par défaut main.
3. Outil PR : gh --version. Si gh est installé et authentifié, utilisez-le pour la création et la fusion de PR. Sinon, affichez l'URL de la PR pour que l'utilisateur la crée manuellement.
4. Shell : détectez le shell actuel. Sous Windows (PowerShell), les heredocs ne fonctionnent pas, donc utilisez plusieurs flags -m pour git commit. Sous bash/zsh/fish et autres shells Unix, utilisez un heredoc.

Stockez ces informations sous <pkg>, <branche-par-defaut>, <gh-disponible> et <shell> pour la suite du flux.

Étapes

1. Nettoyage (optionnel)

Deux compétences nettoient le superflu généré par l'IA avant de commiter. Exécutez les deux si disponibles :

• deslop : supprime le code superflu de l'IA du diff (commentaires inutiles, vérifications défensives sur des chemins de confiance, casts any, imbrication profonde). À exécuter sur le diff actuel par rapport à la branche par défaut.
• unslop : supprime les marqueurs de texte de l'IA de la prose (chaînes UI, commentaires, messages de commit, descriptions de PR). À exécuter sur tout texte que vous avez écrit durant cette session.

Corrigez tout ce que chaque compétence signale avant de continuer.

Si l'une des compétences n'est pas installée, ne l'ignorez pas en silence. Demandez à l'utilisateur s'il souhaite installer celle(s) manquante(s), en proposant ces choix. Mentionnez que les deux compétences proviennent du dépôt officiel de plugins de Cursor AI (https://github.com/cursor/plugins), donc d'une source fiable :

• Globalement (pour une utilisation future dans tous les projets) : npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• Localement (ce projet uniquement) : npx skills add https://github.com/cursor/plugins --skill deslop unslop
• Ignorer pour cette exécution : continuez sans la ou les compétences manquantes. Ne bloquez pas le flux sur une dépendance optionnelle manquante.

Utilisez l'outil ask_user_question pour présenter le choix. Si l'utilisateur choisit global ou local, exécutez la commande d'installation, puis vérifiez à nouveau que les compétences sont maintenant disponibles avant de les invoquer. Si l'installation échoue ou que l'utilisateur choisit ignorer, continuez le flux avec ce qui est disponible.

2. Vérifier le travail

Exécutez ces commandes dans l'ordre, en corrigeant tout problème avant de continuer. Remplacez <pkg> par le gestionnaire de paquets détecté. npm nécessite toujours run (ex. npm run format) ; pnpm/yarn/bun permettent l'invocation directe (ex. pnpm format) :

1. <pkg> run format (ou <pkg> format pour pnpm/yarn/bun) : auto-formatage
2. <pkg> run lint (ou <pkg> lint pour pnpm/yarn/bun) : corrigez les erreurs de lint dans les fichiers que vous avez touchés (ignorez les problèmes préexistants dans les autres fichiers)
3. <pkg> run typecheck (ou <pkg> typecheck pour pnpm/yarn/bun) : doit réussir avec un code de sortie 0
4. <pkg> run build (ou <pkg> build pour pnpm/yarn/bun) : doit réussir avec un code de sortie 0

Si un script est manquant (ex. pas de script format), sautez cette étape et notez-le. Ne faites pas échouer tout le flux sur un script optionnel manquant. typecheck et build sont requis s'ils existent ; si aucun des deux n'existe, continuez avec un avertissement.

Ne passez pas au commit tant que les vérifications disponibles n'ont pas réussi.

Si git status est propre après vérification (rien en staging ou non staging), signalez « rien à livrer » et arrêtez-vous. Ne tentez pas un commit vide.

3. Évaluer la branche courante

Exécutez git branch --show-current pour obtenir le nom de la branche courante. Comparez-la à <branche-par-defaut>. Ensuite, décidez :

• Si sur <branche-par-defaut> : Commitez et pushez directement. Pas de PR, pas de merge. Passez à l'étape 5.
• Si sur toute autre branche : Commitez, pushez, créez une PR vers <branche-par-defaut>, et fusionnez. Passez à l'étape 4.

4. Examiner les modifications

Exécutez git status, git diff et git log --oneline -5 en parallèle pour comprendre ce qui a changé et correspondre au style de commit.

5. Staging et commit

git add -A, puis commitez avec un message de commit conventionnel (feat/fix/refactor).

Format du message de commit :

<type>: <description courte>

<corps optionnel>

Sous bash/zsh/fish et autres shells Unix, utilisez un heredoc :

git commit -m "$(cat <<'EOF'
type: sujet

corps
EOF
)"

Sous PowerShell (Windows), les heredocs ne fonctionnent pas, donc utilisez plusieurs flags -m :

git commit -m "type: sujet" -m "corps"

6. Push

git push (ou git push -u origin <branche> si la branche n'a pas encore de suivi).

7. Si sur une branche de fonctionnalité : créer une PR et fusionner

Si <gh-disponible> :

• Écrivez le corps de la PR dans un fichier temporaire, puis créez la PR avec --body-file (fonctionne sur tous les shells, y compris PowerShell) :
  • gh pr create --base <branche-par-defaut> --head <branche-courante> --title "<titre>" --body-file <fichier-temporaire>
• Supprimez le fichier temporaire après que gh pr create a terminé. Ne le laissez pas sur le disque.
• Fusionnez sans spécifier de stratégie, afin que la configuration par défaut du dépôt de l'utilisateur s'applique :
  • gh pr merge <numéro>

Format du corps de la PR :

## Résumé
<points en bullet>

#### Plan de test
- [ ] <liste de vérification>

Si gh n'est pas disponible :

• Pushez la branche (étape 6).
• Affichez l'URL que l'utilisateur doit ouvrir pour créer la PR manuellement : <url-du-depot>/compare/<branche-par-defaut>...<branche-courante>
• Arrêtez-vous. Laissez l'utilisateur créer et fusionner la PR lui-même. N'essayez pas de fusionner sans gh.

8. Garder la branche courante active

Ne SUPPRIMEZ PAS la branche de travail après la fusion. Elle reste ouverte pour la prochaine fonctionnalité.

9. Confirmer

Rapportez l'URL de la PR (le cas échéant) et le statut de la fusion/push à l'utilisateur.

Gestion des conflits

Si la branche de fonctionnalité est en retard par rapport à <branche-par-defaut>, rebasez avant de pousser :

git fetch origin <branche-par-defaut>
git rebase origin/<branche-par-defaut>

Résolvez les éventuels conflits, puis continuez avec le push, la PR et la fusion.

Remarques

• La cible est toujours la <branche-par-defaut> détectée, pas un nom codé en dur.
• Ne supprimez jamais la branche de travail après la fusion.
• Si vous êtes sur <branche-par-defaut>, commitez et pushez simplement. Pas de PR nécessaire.
• Ne sautez jamais l'étape de vérification, même si l'utilisateur est pressé.
• L'étape deslop est optionnelle. Si une compétence est manquante, proposez de l'installer (globalement ou localement) avant de passer à l'ignorance.