chrislacey89/execute

Que fait execute ?

Exécutez une unité de travail complète : planifiez-la, construisez-la, vérifiez les résultats réels, validez-la.

Position d'invocation

C'est une compétence principale du pipeline utilisée après que /prd-to-issues a produit une tranche concrète, ou lorsque l'utilisateur a déjà une tâche d'implémentation clairement cadrée.

Utilisez /execute lorsque le travail est prêt à être construit, vérifié et validé.

Utilisez HITL /execute lorsque la tranche nécessite encore des décisions actives de jugement, de supervision ou d'acceptation de la part de l'utilisateur pendant l'implémentation. Utilisez AFK /execute uniquement lorsque la tranche suivante est déjà durable sur GitHub, non bloquée, et lisible à partir de son issue, de la carte des limites et de tout artefact de recherche lié (fichier d'archive ou issue de spike) ou du contexte docs/solutions/.

Lisible par un lecteur qui n'en détient rien — c'est ce qu'est une itération AFK. La vérification d'exhaustivité du contexte de /prd-to-issues §4 est la porte derrière cette condition : elle exige que chaque tranche AFK comporte un bloc ### Context, ou des déclarations vides explicites, avant que l'issue ne soit déposée. Une tranche marquée AFK sans un tel bloc n'a jamais été vérifiée par rapport à cette condition, seulement supposée y répondre. Traitez cela comme une raison d'exécuter la tranche en HITL, ou de la renvoyer via /prd-to-issues, plutôt que comme une formalité à passer.

Consultez Étape 0 : Prérequis ci-dessous pour les portes obligatoires de détection automatique de Ralph et des marqueurs TDD.

Ne l'utilisez pas pour remplacer /shape, /research ou /write-a-prd lorsque le problème ou la forme est encore non résolu. Ne l'utilisez pas comme substitut de /pre-merge une fois l'implémentation terminée et prête pour la révision.

Workflow

0. Prérequis

Porte d'isolement de branche. Avant tout travail d'implémentation, assurez-vous de travailler sur une branche propre créée pour cette tâche spécifique — pas une branche de fonctionnalité résiduelle de travaux antérieurs.

Isolement déjà fourni — restez en retrait (vérifiez ceci d'abord, avant les règles numérotées). Certains environnements remettent à la session un worktree+branche dédié et isolé avant que /execute ne s'exécute — les espaces de travail Conductor, GitHub Codespaces, les devcontainers et les hôtes similaires provisionnent chacun "un espace de travail = une branche, auto-forké de la base", avec des scripts de configuration déjà exécutés. Lorsque c'est le cas, le pipeline ne possède pas le provisionnement : créer un worktree ici en imbriquerait un à l'intérieur de celui de l'hôte, et la branche de l'hôte (nommée pour l'espace de travail, pas pour la tâche) n'est pas "périmée". Lisez le signal de l'environnement et cédez le worktree à celui qui le possède déjà (Norman — lisez le signifiant du monde plutôt que de porter une hypothèse dans la tête selon laquelle le pipeline provisionne toujours ; Meadows — un acteur par stock, donc le pipeline diffère plutôt que d'ajouter un gestionnaire concurrent).

Résolvez le mode de provisionnement depuis .claude/settings.json worktree.provisioning — "host" | "pipeline" | "auto", par défaut "auto" lorsque la clé est absente (reflétant le précédent research.storage) :

• host — l'isolement est détenu par l'hôte. Restez en retrait inconditionnellement.
• pipeline — le pipeline provisionne. Ignorez ce retrait et exécutez la porte numérotée ci-dessous.
• auto (par défaut) — restez en retrait si l'un ou l'autre signal se déclenche :
  • une variable d'environnement de l'hôte décrit cet arbre — le bloc ci-dessous affiche host_owned=yes. C'est le discriminateur principal le moins coûteux : le seul mécanisme de détection du pipeline est Bash, et ces variables sont visibles dans le shell de l'agent. La simple présence ne suffit pas : CONDUCTOR_WORKSPACE_PATH est hérité par tout shell démarré sous Conductor et peut nommer un espace de travail d'un dépôt différent, donc il ne compte que lorsqu'il contient le toplevel actuel. (Ne détectez pas via un répertoire .conductor dans le cwd — Conductor le conserve sous $CONDUCTOR_ROOT_PATH, pas l'espace de travail.)
  • l'arbre de travail actuel n'est pas l'arbre de travail principal du dépôt — git rev-parse --show-toplevel diffère du premier chemin dans git worktree list --porcelain.

# host-signal : une variable d'environnement de l'hôte décrit CET arbre, pas seulement ce shell ?
host_owned=no
top=$(cd "$(git rev-parse --show-toplevel)" && pwd -P)
if [ -n "${CONDUCTOR_WORKSPACE_PATH:-}" ]; then
  ws=$(cd "$CONDUCTOR_WORKSPACE_PATH" 2>/dev/null && pwd -P) || ws=
  if [ -n "$ws" ]; then
    case "$top/" in "$ws"/*) host_owned=yes ;; esac
  fi
fi
if [ -n "${CODESPACES:-}" ] || [ -n "${REMOTE_CONTAINERS:-}" ]; then host_owned=yes; fi
echo "host_owned=$host_owned"

CODESPACES et REMOTE_CONTAINERS ne portent aucun chemin à comparer et sont lus pour la présence ; ils sont limités au conteneur, donc un shell qui les voit est à l'intérieur du conteneur dont les dépôts ils décrivent. Le même bloc apparaît dans /closeout, /lfg et /init-pipeline, identique octet par octet, épinglé par scripts/test-host-signal-containment.sh dans le dépôt du pack lui-même.

Lorsque vous restez en retrait : sautez la création de worktree et EnterWorktree, et travaillez sur place sur la branche actuelle. Les règles numérotées ci-dessous sont déjà satisfaites — en particulier la règle 3 ne s'applique pas (une branche provisionnée par l'hôte n'est ni une base ni nommée pour la tâche, mais elle n'est pas périmée ; n'imbriquez pas un worktree et ne vous arrêtez pas). L'hôte a déjà ensemencé la configuration et les dépendances ignorées par git, donc la plupart des éléments de la "Liste de vérification de configuration du worktree" sont informatifs uniquement — vérifiez .env.local/deps si une commande échoue, mais ne reprovisionnez pas. L'élément de son git-hooks fait exception et s'applique toujours. Les hôtes provisionnent les fichiers suivis plus les dépendances ; les hooks git vivent dans .git/hooks, qui est par worktree et non suivi, donc un espace de travail provisionné par l'hôte n'en a typiquement aucun. Vérifiez cet élément même en cas de retrait. Passez à la porte de forme de l'issue.

Ce retrait est délibérément asymétrique avec la vérification de démontage de /closeout. L'entrée n'a besoin que de répondre "suis-je déjà isolé ?" — la détection générique (toplevel ≠ primaire) et l'indice de variable d'environnement règlent chacune cela. La question de sortie — "qui possède le démontage ?" — est plus stricte et ne peut pas se fier uniquement à l'heuristique générique, car un worktree créé par le pipeline satisfait également toplevel ≠ primaire ; /closeout se base sur le paramètre explicite ou la variable d'environnement de l'hôte uniquement.

1. Vérifiez la branche actuelle : git branch --show-current
2. Si la branche actuelle est la branche de base (par exemple, main, prod, master), créez une nouvelle branche de fonctionnalité pour cette tâche.
3. Si la branche actuelle est une branche de fonctionnalité différente (pas la branche de base et pas une branche nommée pour cette tâche), vous êtes sur une branche périmée de travaux antérieurs. Ne validez pas de nouveau travail ici. Exception : si la branche actuelle est une branche de tranche sœur nommée dans la déclaration Consumes from #N de cette tâche, vous êtes intentionnellement sur le point de bifurquer à partir d'elle pour une tranche de PR en pile — poursuivez. Exception (provisionné par l'hôte) : si la vérification de retrait ci-dessus s'est déclenchée, cette branche est la branche d'espace de travail isolé de l'hôte — elle n'est pas périmée ; travaillez sur place.

Pour créer une branche isolée, utilisez l'une de ces approches (par ordre de préférence) :

• Worktrunk (si wt est disponible) : wt switch --create <nom-de-branche> — crée un nouveau worktree + branche à partir de la base appropriée et y bascule, offrant un isolement complet du système de fichiers. Consultez la compétence /worktrunk pour des conseils.
• Git simple : git checkout <base> && git checkout -b <nom-de-branche> — crée une nouvelle branche à partir de la base appropriée dans le répertoire de travail actuel.

La base appropriée est la branche de base du dépôt par défaut — ce que bash "$SC" base-ref --name affiche, avec SC défini sur references/sidecar.sh de cette compétence. Ne partez pas du principe que c'est main. Pour une tranche avec une dépendance Consumes from #N non fusionnée qui produit des symboles que cette tranche importe, bifurquez à partir de la branche de cette tranche sœur à la place afin que le PR empilé puisse cibler le PR de la sœur (Hammant Trunk-Based Development Ch. 13 : plusieurs PRs par histoire ; le PR de la sœur doit toujours fusionner dans la branche de base du dépôt dans les 2 jours).

Dérivez le nom de la branche de la tâche : par exemple, issue-5-landing-page, landing-page ou le slug de l'issue. Ne réutilisez pas les noms de branche de travaux antérieurs.

Entrez dans le worktree en tant que session (lorsque vous avez créé un worktree). Créer le worktree n'est pas la même chose que la session s'exécutant à l'intérieur — wt switch --create réinitialise le cwd du shell à la racine du projet après chaque commande, donc sans une étape supplémentaire, la session reste ancrée au checkout d'origine et le cwd signalé ment sur l'endroit où le travail se déroule. Après avoir créé le worktree, entrez-y avec l'outil de gestion EnterWorktree afin que le répertoire de travail de la session soit réellement le worktree :

• Appelez EnterWorktree { path: <chemin-absolu-du-worktree> }. Le chemin doit déjà apparaître dans git worktree list pour ce dépôt (ce sera le cas, car vous venez de le créer). Cela bascule définitivement la session dans le worktree.
• Gardez l'étape de création exactement comme ci-dessus — wt switch --create / git worktree add exécute les hooks pre-start du worktrunk qui ensemencent .env.local et les dépendances. EnterWorktree ne fait que basculer le cwd ; il n'exécute pas ces hooks. Créez d'abord (pour ensemencer env/deps), puis entrez.
• Cela met la connaissance dans le monde, pas dans la tête : le cwd dit la vérité sur l'endroit où les modifications et les validations aboutissent (un opérateur observateur peut le voir), et il n'y a pas de préfixe cd par commande à oublier — éliminant la classe de glissement où une commande non préfixée écrit dans le mauvais arbre.
• L'option Git simple (git checkout -b, sans worktree) crée la branche dans le checkout actuel — il n'y a pas de worktree à rejoindre, donc sautez EnterWorktree et travaillez sur place.

Repli AFK / sans tête. Si EnterWorktree est indisponible (exécutions sans tête, AFK Ralph, cron), repliez-vous sur la discipline du préfixe cwd : le cwd du shell se réinitialise à la racine du projet après chaque commande Bash, donc prefixez chaque appel Bash dans cette session avec cd <chemin-absolu-du-worktree> &&. Utilisez ceci uniquement lorsque l'outil de gestion est réellement indisponible — c'est l'ancienne solution de contournement, conservée pour les environnements sans le mécanisme natif.

Le démontage de ce worktree est détenu par /closeout à la fin du pipeline — après la fusion du PR, /closeout ré-ancré le shell au checkout de base, supprime le worktree et élimine la branche fusionnée. /execute est le côté entrée du cycle de vie du worktree ; /closeout est le côté sortie. Le nettoyage de l'étape 6 ci-dessous ne supprime que les marqueurs .tdd-* — il ne supprime délibérément pas le worktree.

Après avoir créé le worktree, configurez-le. Un nouveau worktree hérite des fichiers suivis mais pas de ceux ignorés par git (.env.local, dépendances par worktree, caches de build). Deux chemins :

Préféré — configurer une fois via les hooks worktrunk (.config/wt.toml dans le projet) :

[pre-start]
copy = "wt step copy-ignored"
install = "pnpm install"

Les hooks pre-start sont bloquants — le worktree n'est pas signalé comme prêt tant qu'ils ne sont pas terminés. Utilisez pre-start (pas post-start) pour les deux, car post-start s'exécute en arrière-plan et les commandes ultérieures qui nécessitent .env.local ou node_modules entreront en concurrence avec le hook. Consultez /worktrunk pour la recette complète. Une fois par projet.

Repli — configuration manuelle pour git worktree add simple (sans worktrunk) :

• cp <dépôt-source>/.env.local <worktree>/.env.local (et toute autre configuration ignorée par git utilisée par le projet).
• Exécutez la commande d'installation du projet (pnpm install, npm ci, pip install -r requirements.txt, etc.) depuis le worktree.

Liste de vérification de configuration du worktree (FAIRE-CONFIRMER — effectuez chaque étape, puis vérifiez avant de continuer). S'applique quelle que soit la façon dont le worktree a été créé :

• Configuration ignorée par git copiée — .env.local (et tout autre .env.*, *.local ou configuration ignorée spécifique au projet) existe dans le worktree
• Dépendances installées — la commande d'installation (pnpm install, npm ci, etc.) s'est exécutée sans erreur dans le worktree
• La session est à l'intérieur du worktree — pwd signale le chemin du worktree car vous y êtes entré via EnterWorktree { path } (pas la racine du projet). Dans le repli AFK/sans tête uniquement, cet élément signifie que le préfixe cd <chemin-absolu-du-worktree> && est appliqué à chaque appel Bash
• Portée de $CLAUDE_PROJECT_DIR correcte — si le projet référence cette variable d'environnement dans des scripts, vérifiez qu'elle correspond au chemin du worktree, pas au dépôt principal
• Les hooks git locaux sont installés et leur gestionnaire est sur PATH — ls "$(git rev-parse --git-dir)/hooks/" | grep -v '\.sample$' liste quelque chose, et le gestionnaire que le dépôt déclare (lefthook, husky, pre-commit, …) résout. Les hooks vivent dans .git/hooks, qui est par worktree et non suivi, donc un nouveau worktree n'en hérite aucun — et l'échec est silencieux dans la pire direction : chaque validation réussit, et chaque garantie que le dépôt documente au moment de la validation n'a tout simplement pas été exécutée. Si le gestionnaire est absent, installez-le (lefthook install) ou enregistrez dans les notes de révision de l'étape 6 que les portes locales étaient inactives pour cette branche, afin que personne ne lise un passage local vert comme la porte de fusion
• Marqueur de classification absent — .claude/.tdd-active, .claude/.tdd-skipped et .claude/.lfg-active n'existent pas dans le worktree (nouvelle ardoise ; l'étape 3 en crée un)
• Drapeaux de verrouillage post-révision absents — .claude/.review-stamped et .claude/.fix-findings-active n'existent pas. Les deux appartiennent à la branche précédente de révision : /pre-merge Phase 4 écrit le premier, /fix-findings écrit le second, et /closeout et /fix-findings les suppriment respectivement à la fin de cette branche. Un .review-stamped qui a fuité refuse toute écriture d'implémentation sur cette tranche avant qu'elle ne commence ; un .fix-findings-active qui a fuité maintient le verrou ouvert pour toute la tranche, ce qui est la direction silencieuse. Supprimez l'un ou l'autre que vous trouvez — vous êtes au début d'une branche qui n'a eu aucune révision, donc aucun ne peut décrire celle-ci

Porte de forme d'issue et de blocage. Si la tâche est une issue GitHub, confirmez qu'il s'agit d'une tranche prenable avant de l'implémenter : pas un PRD non décomposé, pas bloqué, et pas déjà en cours de fermeture par un PR ouvert de quelqu'un d'autre. Une lecture GraphQL répond aux trois questions, et le bloc décide — ne jugez rien à l'œil :

N=<n>
VERDICT_JQ='
def lignes: split("\n")[];
[inputs][0] | if (.errors // [] | length) > 0 then "inconnu" else
.data.repository.issue as $i
| if $i == null or $i.number != $n or (($i.title // "") == "")
     or ($i.bf ...