execute — exécuter un plan d'implémentation

Entrée : un plan approuvé à .ai/plans/{date}-{slug}.md. Sortie : code fonctionnel, vérifié et committé sur la branche de feature, avec la checklist Progression du plan entièrement cochée.

Votre rôle est de suivre le plan exactement — pas de l'améliorer. Les écarts sont des bloqueurs, pas des décisions discrétionnaires.

Annoncez au démarrage : « Using the execute skill — implementing the plan at {path}. »

Step 1: Charger et vérifier la cohérence

1. Lire l'intégralité du fichier plan. Confirmer : vous êtes sur la branche qu'il désigne, la spec qu'il référence existe, et ses dépendances de tâches sont cohérentes.
2. Si quelque chose manque ou est contradictoire → STOP et rapportez avant de toucher au code.

Step 2: Boucle par tâche

Pour chaque tâche non cochée, dans l'ordre des dépendances :

1. Lire la tâche et chaque fichier qu'elle liste (y compris le fichier de précédent pour les tâches UI).
2. Faire exactement les étapes. Chemins exacts, code exact, commandes exactes. Si la tâche dit « copier du précédent X », ouvrir X et reproduire sa structure et son idiome.
3. Exécuter le bloc Verify de la tâche et comparer au résultat attendu. Une vérification que vous n'avez pas exécutée compte comme échouée.
4. Committer via /check-and-commit (elle exécute les gates, stage les fichiers de la tâche spécifiquement, et écrit un commit conventionnel). Un commit par tâche.
5. Cocher la tâche dans la liste Progression du fichier plan.

Rappels qui priment sur ce que le plan oublierait :

• Après toute migration appliquée : pnpm run generate:types AVANT le typecheck.
• Typecheck uniquement par package : pnpm exec turbo run typecheck --filter=<pkg>. Ne jamais lancer un typecheck sur tout le repo.
• Ne jamais reconstruire ou réinitialiser la base de données pour faire passer une tâche — stop et rapportez.

Step 3: Bloqueurs — quand s'arrêter

Arrêtez immédiatement et rapportez (ne devinez pas, n'improvisez pas) quand :

• Une vérification échoue et une tentative de correction ciblée ne la fait pas passer.
• Le plan a une lacune : étape manquante, chemin incorrect, décision non énoncée.
• Une condition d'échappatoire dans le plan se déclenche.
• Vous êtes sur le point de toucher un fichier que la tâche liste comme hors scope.

Format de rapport : ce qui s'est passé, commande exacte + output, ce que vous avez essayé, 1–2 options si vous en avez. Après que l'humain l'ait résolu, reprenez la boucle. Si le plan lui-même est erroné, retournez à /plan et mettez d'abord le fichier plan à jour — ne poussez jamais avec un changement de design non planifié.

Signaux d'alarme — penser à l'un de ceux-ci signifie que vous improvisez ; s'arrêter plutôt :

• « le plan est assez proche, j'adapterai cette étape »
• « je lancerai toutes les vérifications ensemble à la fin »
• « ce correctif supplémentaire est manifestement nécessaire » (hors scope est un bloqueur, pas une faveur)
• « la vérification a échoué mais le code a l'air correct »

Step 4: Tâches parallèles (optionnel)

Les tâches marquées indépendantes peuvent être confiées à des subagents — une tâche par subagent, chacun recevant le texte de tâche complet verbatim plus le nom de branche. Ne jamais laisser deux subagents toucher le même fichier. Vérifier et committer chaque résultat via la même boucle par tâche ; vous (l'agent principal) exécutez les gates, pas le subagent.

Step 5: Terminer

Après la dernière tâche :

1. Passage complet des tests : pnpm test (turbo scope la mise en cache ; celui-ci est sûr repo-wide).
2. Pour tout ce qui est user-facing : vérification navigateur avec /test (démarre sur la stack crbn up en cours, se connecte, conduit les flows modifiés). Un changement UI sans vérification navigateur réussie n'est pas terminé — si la stack ne peut pas démarrer, le travail est BLOQUÉ, pas complet.
3. Passez en revue votre propre diff avec /self-review.
4. Rapportez :

## Implementation complete
**Plan:** .ai/plans/{date}-{slug}.md (all tasks checked)
**Branch / commits:** {branch}, {N} commits
**Tests:** {X added, all passing — command + result}
**Browser verification:** {flows verified via /test, or explicit N/A for non-UI}
**Deviations from plan:** {none, or list with reasons}
**Ready for:** PR

N'ouvrez une PR que si l'utilisateur l'a demandé.