steve-swanson/execute-work

Execute Work

Exécuter le travail convenu de manière autonome sur une branche significative issue de develop. Déléguez l'implémentation à des sous-agents dans des worktrees séparés, puis effectuez un fast-forward sur leurs branches terminées dans cette branche coordinatrice, nettoyez, et ouvrez une pull request prête pour la relecture à partir de la branche coordinatrice complétée vers develop.

L'invocation autorise les branches de tâches locales, les worktrees, les commits, le rebase de vos propres branches de tâches non publiées, les fusions fast-forward dans la branche coordinatrice, la suppression des worktrees et branches de tâches propres et entièrement intégrés, le push de la branche coordinatrice complétée, et la création de sa PR vers develop. Poursuivez sans autre confirmation pour ces actions. Suivez le périmètre et les instructions du référentiel de l'utilisateur, y compris une dérogation explicite locale uniquement ou sans PR. La fusion de la PR et le déploiement sont en dehors de l'autorisation de cette compétence. Maintenez toutes les interdictions existantes en vigueur.

1. Préparer la branche coordinatrice

Lisez le plan convenu, le fichier AGENTS.md applicable, et les directives nécessaires du projet. Si le travail est déjà défini, exécutez sans autre phase de conception ou d'approbation. Posez une seule question ciblée uniquement en cas d'exigence manquante substantielle.

Inspectez l'état, les références, et les worktrees existants. Préservez les modifications et les changements de branche sans rapport ; ne les réinitialisez pas, ne les stash pas, ne les réutilisez pas. Récupérez develop depuis son remote configuré lorsqu'il est disponible et utilisez ce pointeur récupéré. Si la récupération est indisponible, divulguez la limitation et utilisez une référence locale existante develop ; si aucune n'existe, demandez la branche de base. Ne substituez jamais silencieusement une autre branche.

Avant de créer une branche ou un worktree, capturez git worktree list --porcelain, les noms des branches locales et les éventuels attachements de worktrees gérés. Conservez un inventaire propre à l'exécution dans la liste de contrôle des tâches : branche, chemin absolu, propriétaire/agent, type et identité de gestion, commit final, et statut de nettoyage. Incluez chaque tâche, assistant, relecteur, tentative et descendant agent checkout créé pour cette exécution, même s'il est abandonné ou ne contient aucune modification. Le coordinateur est responsable du nettoyage de l'intégralité de cet inventaire. Préservez les branches/worktrees préexistants et sans rapport ; un préfixe de nom correspondant n'est pas une preuve de propriété.

Créez un worktree et une branche coordinatrice dédiés. Nommez-la avec le style Conventional Branch, <type>/<short-description>, en minuscules avec des traits d'union, par exemple feat/store-invitation-recovery. Choisissez le type qui correspond au travail : feat (nouveau comportement), fix (correction de bogue), refactor, perf, docs, test, chore (outillage ou maintenance), ou ci. Si l'utilisateur ou le référentiel nomme une convention différente (par exemple dans AGENTS.md), suivez-la à la place. N'incluez pas integration dans son nom. Enregistrez le commit de base coordinateur. Sur une invocation reprise, réutilisez la branche/worktree coordinateur et l'inventaire de cette exécution, en inspectant leur état plutôt que de recommencer.

2. Diviser et déléguer

Divisez par livrable et propriété de fichier. Exécutez les tâches indépendantes simultanément dans la capacité d'agent disponible ; séquencez les dépendances et les modifications se chevauchant. Créez chaque branche/worktree de tâche à partir du pointeur actuel de la branche coordinatrice. Après l'intégration d'une dépendance, démarrez les tâches dépendantes à partir du pointeur mis à jour.

Générez des sous-agents réels avec les exigences de la tâche, les sections pertinentes du plan, le chemin absolu du worktree, la branche, les fichiers possédés, les contrats de dépendance, les critères d'acceptation, et les vérifications requises. Chaque agent travaille uniquement dans son checkout assigné, commit ses modifications, et rapporte son commit, ses vérifications, les préoccupations restantes, et les éventuelles branches/worktrees supplémentaires qu'il a créés. Enregistrez-les immédiatement dans l'inventaire propre à l'exécution. Le coordinateur seul intègre et supprime les worktrees. Les sous-agents ne doivent pas invoquer récursivement cette compétence d'orchestration ni pousser leurs branches. Utilisez des répertoires de travail explicites ou git -C ; les agents peuvent partager un répertoire par défaut. Si la délégation n'est pas disponible, signalez cette limitation au lieu de substituer silencieusement une exécution solo.

3. Examiner les tâches terminées

Inspectez le diff réel et les commits de chaque tâche par rapport à ses critères d'acceptation. Traitez les échecs avec l'agent propriétaire. Exigez un checkout de tâche propre, des commits terminés, et des vérifications pertinentes réussies avant l'intégration ; signalez avec précision les bloqueurs préexistants ou environnementaux. Ne fusionnez pas le travail simplement parce qu'un agent signale sa terminaison.

4. Intégrer en série avec des fusions fast-forward

Arrêtez les écritures sur une branche de tâche terminée avant de la rebaser. Pour chaque tâche, inspectez l'ascendance par rapport au pointeur actuel de la branche coordinatrice. Les branches frères parallèles divergent après la première fusion : rebasez chaque branche de tâche restante non publiée sur la branche coordinatrice mise à jour avant de fusionner. Résolvez les conflits par rapport aux exigences convenues, en préservant le comportement déjà intégré ; réexécutez les vérifications affectées après le rebase ou la résolution de conflits.

Exemple utilisant des chemins absolus et des noms de branches enregistrés :

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# Exécutez les vérifications requises dans task_path, puis vérifiez l'ascendance.
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

Inspectez le résultat de chaque commande avant de continuer. Si le fast-forward échoue, réinspectez l'ascendance et rebasez à nouveau si nécessaire. Ne substituez pas un commit de merge, un squash, un cherry-pick, un push forcé ou une réinitialisation de la branche coordinatrice. Si une résolution sécurisée nécessite une décision produit, conservez les deux branches et demandez. Après chaque intégration de tâche réussie et ses vérifications requises, effectuez le nettoyage requis ci-dessous pour cette tâche immédiatement. Examinez le travail combiné à partir du checkout coordinateur ; les checkouts de tâches fusionnées ne sont pas nécessaires pour la relecture de la PR. Appliquez le même nettoyage aux assistants abandonnés ou remplacés appartenant à l'exécution une fois leur travail pris en compte.

5. Vérifier, nettoyer et ouvrir la PR

Exécutez les vérifications combinées pertinentes sur la branche coordinatrice finale et reconciliez le résultat avec l'ensemble du plan. Corrigez les régressions d'intégration avant la fin.

Nettoyage requis : exécuter et vérifier

Le nettoyage fait partie du livrable, pas une suggestion pour l'utilisateur à effectuer plus tard. L'invocation autorise déjà la suppression des worktrees et branches de tâches/assistants propres et entièrement intégrés de cette exécution ; ne demandez pas à nouveau ces suppressions.

1. Arrêtez l'agent propriétaire et tout processus en arrière-plan écrivant dans le checkout. Enregistrez le commit final de la branche après le rebase, vérifiez qu'il est un ancêtre du pointeur coordinateur actuel, et inspectez les fichiers suivis, non suivis et ignorés. Pour un assistant sans commits, vérifiez que son pointeur est déjà contenu également. Traitez le travail inachevé avec le propriétaire : intégrez les modifications requises et préservez les artefacts locaux précieux dans un emplacement conservé avant de continuer. Les caches ou journaux générés par l'exécution jetables peuvent être supprimés par chemin exact ; ils ne sont pas une raison de laisser un checkout par ailleurs fini indéfiniment.

2. Pour un worktree Git simple, exécutez ces opérations en utilisant les chemins et noms exacts enregistrés, en vérifiant chaque résultat avant de continuer :

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   La suppression d'un worktree ne supprime pas sa branche. Les deux opérations sont requises. Supprimez également les branches appartenant à l'exécution qui n'ont plus de worktree. N'utilisez jamais la suppression forcée, git branch -D, la suppression large de répertoire, ou ignorez les modifications inconnues. Diagnostiquez les commandes en échec et corrigez les problèmes de nettoyage ordinaires dans le périmètre plutôt que de les sauter silencieusement.

3. Pour un worktree géré par application, utilisez son API de gestion au lieu de supprimer le répertoire directement. Dans Codex, utilisez list_artifacts pour résoudre l'identité exacte du worktree possédé, puis archive_worktree ; inspectez le résultat et re-lister pour confirmer qu'il n'est plus actif. Supprimez ensuite sa branche locale appartenant à l'exécution avec git branch -d lorsqu'elle reste. Un snapshot d'archive ou un attachement d'application ne substitue pas la vérification à la fois de l'enregistrement Git et de la suppression de branche.

4. Marquez une entrée d'inventaire comme nettoyée uniquement après avoir vérifié que son chemin exact est absent, qu'elle n'est plus enregistrée par git worktree list --porcelain, que sa branche est absente des références locales, et que tout attachement géré n'est plus actif. Inspectez les autres checkouts si Git indique que la branche est toujours checkoutée. Ne considérez pas une demande de suppression réussie ou un rapport d'agent comme une preuve.

5. Immédiatement avant la réponse finale, après la création de la PR ou tout travail de relecture tardif, répétez les inventaires des branches/worktrees Git et des attachements gérés. Comparez-les avec la base de référence et l'inventaire propre à l'exécution ; rendez compte des nouvelles entrées omises des rapports d'agent sans supprimer le travail simultané sans rapport. La branche/worktree coordinateur doit être le seul branche/worktree restant appartenant à l'exécution. Préservez-la pour la PR et les tests, ainsi que les checkouts préexistants ou sans rapport. Cette vérification finale est requise même si la création de la PR est bloquée ou sautée, et en cas d'échec/interruption avant de céder le contrôle lorsque cela est sûr.

Si le nettoyage ne peut pas se terminer en toute sécurité, continuez à nettoyer les autres entrées éligibles et signalez nettoyage bloqué, avec chaque branche/chemin conservé, l'opération exacte en échec ou le travail précieux/non fusionné, et la plus petite action nécessaire pour le résoudre. Ne signalez pas le workflow global comme terminé tant que des branches/worktrees temporaires appartenant à l'exécution restent. Continuez à travailler sur le nettoyage de routine plutôt que de vous arrêter à une fusion réussie, des tests passants ou la création d'une PR.

Push et ouverture de la PR

Conservez la branche/worktree coordinateur avec tout le travail commité prêt pour la relecture. Après l'intégration et la validation requise réussies, inspectez le diff final et pushez uniquement la branche coordinatrice vers le remote du référentiel prévu. Créez une PR prête pour la relecture avec develop comme base et la branche coordinatrice comme tête ; utilisez un brouillon uniquement lorsque l'utilisateur le demande explicitement. Vérifiez la présence d'une PR ouverte existante pour cette tête/base avant d'en créer une, y compris après un résultat de création incertain, et réutilisez-la ou mettez-la à jour plutôt que de créer un doublon.

Suivez les modèles de PR du référentiel, les conventions de titre et les exigences de lien vers le ticket. Décrivez le comportement final, les vérifications et leurs résultats, et les étapes concrètes de test manuel. Ces étapes doivent décrire l'exercice du produit et/ou l'inspection de l'état persistant, et non une autre liste de commandes de test du référentiel. Préférez Git local pour le push et un connecteur de référentiel disponible pour la création de la PR ; utilisez une CLI authentifiée lorsque cela est approprié. Vérifiez la base réelle de la PR, la tête et le commit publié par rapport à la branche coordinatrice complétée. Attachez chaque PR créée au chat actuel lorsque l'outil d'attachement d'artefacts est disponible. Laissez la PR ouverte pour la relecture.

Si le push ou la création de la PR est bloqué, préservez la branche/worktree coordinateur complété et signalez le bloqueur exact et l'action restante. Ne prétendez pas qu'une PR existe sans URL confirmée ou ne forcez pas le push pour contourner un rejet.

Rapport de fin

La réponse finale doit commencer par le nom exact de la branche coordinatrice et le chemin absolu du worktree. Incluez un lien Markdown vers la PR confirmée, ou indiquez pourquoi la création de la PR est bloquée ou explicitement sautée, puis incluez :

• Ce qui fonctionne maintenant : le comportement terminé et tout périmètre restant.
• Vérifications déjà exécutées : commandes exactes et résultats réels, en identifiant les vérifications sautées ou bloquées.
• Comment tester : une courte procédure de validation numérotée, exécutable par l'utilisateur, à partir du worktree coordinateur. Ceci est séparé des vérifications automatisées et ne doit pas être satisfait en répétant pnpm test, lint, build, ou des commandes similaires. Incluez, selon le cas :
  • configuration : environnement/URL de l'application, login et rôle, services, données de seed ou fixture, IDs d'enregistrements, et le répertoire de travail ;
  • le flux produit principal : écran ou endpoint exact, entrées réalistes et actions UI, le comportement à déclencher, et le résultat visible attendu ;
  • les flux de bord ou de régression pertinents : données invalides, vides, dupliquées, restreintes, ou précédemment terminées lorsque ces cas sont importants ;
  • la vérification de l'état persistant pour les modifications qui écrivent ou transitionnent les données : fournissez une inspection DB/API en lecture seule avec la table ou la ressource, les filtres ou identifiants, les champs/statuts à vérifier, et le résultat attendu. Reliez l'action de l'utilisateur à l'enregistrement stocké plutôt que de dire simplement « vérifiez la DB. » Par exemple, un changement de prospection devrait dire de créer un scan de territoire pour une zone nommée et un rayon, trouver un lieu spécifique, confirmer son attribut requis, terminer l'action de révision/contact, et vérifier l'état de la révision ou du contact résultant dans l'application et les enregistrements pertinents. Utilisez le même niveau de spécificité pour les autres workflows produit. Conservez les commandes automatisées sous Vérifications déjà exécutées. Marquez chaque étape manuelle comme effectuée ou suggérée ; si l'application ou la base de données était indisponible, indiquez le bloqueur exact et la plus petite configuration nécessaire pour l'exécuter. L'inspection de la base de données est en lecture seule sauf si le travail approuvé autorise explicitement la mutation des données de test.
• Nettoyage et bloqueurs : nombres vérifiés de worktrees temporaires supprimés ou archivés et de branches locales supprimées ; la vérification finale de la branche/worktree restant appartenant à l'exécution (normalement uniquement le coordinateur). Listez chaque branche/chemin temporaire bloqué et sa raison exacte ; incluez toute étape de push ou de PR incomplète.

Gardez les mises à jour de progrès concises et terminez par une action concrète suivante réalisable en moins de deux minutes.