Démarrer un élément de travail Azure DevOps

Démarrer un élément de travail

Transforme un ticket ADO collé en : une branche fraîche (ou correctement reprise), une mémoire de contexte que les sessions ultérieures peuvent reprendre, une découverte du codebase fondée, et soit une analyse de cause racine soit une disposition de fonctionnalité. Il se termine à un point de contrôle — présente les résultats et attend. Aucun correctif ni code de fonctionnalité n'est écrit dans cette compétence ; l'utilisateur approuve d'abord la direction, car une RCA erronée qui est livrée rapidement coûte un cycle QA complet.

0. Charger la configuration locale

Lisez d'abord config.local.md dans le dossier de cette compétence — avant d'analyser le ticket. Il contient les noms que cette compétence ne code pas en dur délibérément : préfixe de branche, branche de base, le document de stratification du projet, où les investigations résident, les angles morts de l'index de code, et les mémoires passées qui méritent d'être signalées. La qualité de la découverte dépend de ces spécificités, donc ne l'ignorez pas.

S'il est manquant (nouvelle installation), déduisez ce que vous pouvez — branche de base depuis git remote show origin (branche HEAD), préfixe à partir des branches existantes de l'utilisateur (git branch --list "*/*") — dites à l'utilisateur ce que vous avez déduit et proposez de l'enregistrer sous config.local.md (voir config.example.md).

Le répertoire de mémoire est celui que votre invite système nomme pour ce projet ; le dépôt est celui dans lequel vous travaillez. Aucun des deux n'a besoin de configuration.

1. Analyser le ticket

Extrayez, à partir de ce qui a été collé. Le copier-coller de page ADO est bruité : la première ligne est le type et l'ID en MAJUSCULES (USER STORY 12345, BUG 12346), chaque étiquette de champ se trouve sur sa propre ligne avec la valeur sur la suivante (State / Dev In Progress), les balises apparaissent comme des lignes nues près du haut, et il y a des éléments d'interface à ignorer (Save, Follow, Click to add …, switch to HTML editor, sections TestRail vides). Les images et pièces jointes ne survivent pas au collage.

• ID (numéro) et Type d'élément de travail — Bug vs. User Story / Feature / PBI / Task. Si le type n'est pas indiqué, déduisez-le (étapes de reproduction + attendu/réel ⇒ bug ; "En tant que … je veux" ou critères d'acceptation ⇒ feature) et dites ce que vous avez déduit.
• Titre, État, Zone/Itération si présent
• Bug : étapes de reproduction, attendu vs. réel, numéro de build, plateforme/périphérique/OS, liens profonds, noms de journaux joints, captures d'écran mentionnées
• Feature : description, critères d'acceptation, conceptions liées, noms de feature flags / expériences
• Discussion/commentaires : tentatives précédentes, notes QA et leurs dates, numéros de PR

S'il n'y a pas d'ID, demandez-le avant de créer quoi que ce soit — l'ID pilote le nom de la branche et de la mémoire. Notez tout ce qui est référencé mais non visible (captures d'écran, journaux) afin de pouvoir le demander au point de contrôle plutôt que de deviner son contenu.

2. Branche

Exécutez git dans le dépôt dans lequel vous travaillez (si la session est dans un worktree ou un autre clone, utilisez-le — ne faites jamais cd loin de lui) :

git status --porcelain

Si l'arbre est sale, arrêtez-vous. Listez les fichiers et la branche courante, et demandez comment procéder (transférer, mettre de côté, ou valider sur l'ancienne branche). Les fichiers non validés d'un élément fuient dans les validations du suivant ; l'utilisateur décide, pas vous.

Quand c'est propre :

git fetch origin
git branch --list "<prefix>/<id>*"; git branch -r --list "origin/<prefix>/<id>*"

Si aucune branche n'existe pour l'ID, créez <prefix>/<id> à partir de origin/<base> et enregistrez le SHA court (git rev-parse --short HEAD).

Si <prefix>/<id> ou <prefix>/<id>-N existe déjà (local ou distant), regardez le plus récent avant de décider — le même ID peut arriver à trois moments très différents :

git log --oneline origin/<base>..<prefix>/<id>[-N]   # validations non fusionnées ?
git log --oneline origin/<base> --grep=<id>           # "Merged PR NNNN: ... <id>" = c'est arrivé

ADO fusionne par squash, donc une branche fusionnée montre encore ses validations comme "en avance" sur la base — la ligne Merged PR sur la branche de base est ce qui vous dit qu'elle est arrivée. Lisez-la conjointement avec l'État du ticket et la date du commentaire QA le plus récent par rapport à la dernière validation de la branche.

Branche existante la plus récente	État typique du ticket	Que faire
Pas de validations au-delà de origin/<base> (souvent la branche sur laquelle vous êtes — l'utilisateur l'a créée avant de coller)	Nouveau / Dev In Progress	Réutilisez-la. Vérifiez-la, git merge --ff-only origin/<base>.
Fusionnée (un Merged PR pour cet ID sur la base) et QA a échoué depuis	Actif / rouvert, commentaire d'échec QA plus récent que la fusion	Créez le suffixe suivant (-1, -2, …) à partir de origin/<base> ; la tentative précédente devient un matériau de découverte de premier ordre.
Validations non fusionnées (poussées ou non), ou une PR toujours ouverte	Revue PR / Prêt pour le test / En cours	En vol — ne créez pas de branche. Rapportez ce qu'elle contient (validations, si elle est poussée, à quel point elle est derrière la base), faites-en le sujet de la découverte, et demandez s'il faut reprendre ou lancer une nouvelle tentative.

Si les signaux se contredisent (par ex. l'état dit Nouveau mais il y a une branche non fusionnée), traitez-la comme en vol et demandez — créer une branche en double est l'erreur coûteuse. Si git fetch échoue (VPN / auth), dites-le et utilisez l'origin/<base> locale, en notant que la base peut être obsolète.

Ne poussez pas et ne validez pas — l'utilisateur ne l'a pas demandé.

3. Mémoire de contexte (écrivez-la maintenant, mettez-la à jour plus tard)

Écrivez la mémoire avant la découverte, avec le statut ⏳, afin que l'élément soit reprenable même si la session meurt en cours d'investigation. Utilisez references/memory-template.md.

• Bug → bug-<id>-context.md, feature/story/task → feature-<id>-context.md
• Si une existe déjà pour cet ID, mettez-la à jour au lieu d'en créer une seconde — et corrigez tout ce que l'état git contredit maintenant.
• Ajoutez un pointeur d'une ligne vers MEMORY.md. Sans lui, les sessions ultérieures ne trouveront jamais la mémoire.

4. Découverte du codebase

L'objectif est de trouver les chemins de code réels que le ticket touche et l'historique qui les entoure — suffisamment pour que la RCA/disposition cite fichier:ligne, pas des suppositions.

• Utilisez l'index de code s'il y en a un (CodeGraph, LSP) : commencez par une requête de contexte sur les noms du ticket (page, contrôle, service, DTO), puis un appel d'exploration sur ce qu'il remonte ; appelants/impact sur le symbole suspect. Vérifiez la configuration pour les angles morts de l'index (types de fichiers qu'il n'analyse pas) et utilisez grep pour ceux-ci à la place.
• Routes et noms d'interface : les routes de page, les noms de composants, les classes CSS et les schémas de lien profond du ticket sont de bons termes pour grep.
• Travail antérieur : git log --oneline --all --grep=<id>, git log --oneline -20 -- <fichiers suspects>, le dossier docs/investigations du projet (configuration), et le répertoire de mémoire pour les comptes rendus sur la même zone. Un correctif antérieur pour le même symptôme qui a échoué à la QA est la chose la plus précieuse que vous puissiez trouver.
• Comparez les cas qui passent et ceux qui échouent. Lorsque QA liste des cas qui passent et un qui échoue, trouvez ce qui diffère réellement entre eux dans le code — la page hôte, le chemin de données, le timing — avant de vous arrêter sur un mécanisme.
• Chaque hôte/plateforme : si l'interface est partagée entre les hôtes (shell mobile, web), vérifiez si le ticket est spécifique à une plateforme et si le code l'est.
• Ne construisez pas pendant la découverte. Lire le code suffit ici ; les constructions sont lentes et appartiennent à l'implémentation.

Pour des analyses larges sur de nombreux dossiers, un sous-agent Explore convient ; pour une zone connue, faites-le directement.

5a. Bug → analyse de cause racine

Utilisez la compétence superpowers:systematic-debugging pour la méthode si elle est disponible. La barre est mesurée, pas devinée : nommez le mécanisme et le fichier:ligne exact, et expliquez pourquoi il produit précisément le symptôme rapporté et pas un autre (pourquoi le cas qui échoue échoue et ceux qui passent passent).

• Tracez le chemin de l'action utilisateur dans les étapes de reproduction à l'état défaillant. Citez les lignes pertinentes.
• Reproduisez si possible sans appareil : tests de composants pour l'état/markup, une réplique statique de navigateur sans tête pour les problèmes de mise en page/défilement/CSS (la configuration peut pointer vers une mémoire décrivant un harnais existant). Si vous ne pouvez pas reproduire, dites-le clairement, indiquez votre confiance et quelles preuves le confirmeraient (par ex. une ligne de log spécifique ou une capture d'écran de QA).
• Séparez la cause racine des facteurs contributifs et des problèmes adjacents qui appartiennent à d'autres tickets.
• Proposez une direction de correction (ou 2–3 options avec une recommandation) et le test de régression qui la verrouillerait — mais ne les écrivez pas encore.
• Élément en vol (étape 2) : la RCA devient une revue du correctif déjà sur la branche — répond-il au plus récent échec QA, et quels risques résiduels le feraient échouer sur l'appareil ? Recommandez de le reprendre et dites quel résultat QA justifierait une nouvelle tentative.

5b. Feature → disposition et élaboration

Utilisez la compétence superpowers:brainstorming pour la conversation de conception si elle est disponible.

Jugez d'abord si les critères d'acceptation sont suffisants. Ils sont suffisants lorsque :

• chaque CA peut être transformé en une assertion de test concrète et mappé à un fichier à modifier, et
• les états d'interface (chargement, vide, erreur, désactivé), le comportement par plateforme, les événements d'analyse et le feature flagging sont soit spécifiés, soit clairement non applicables.

S'ils sont suffisants, ne posez pas de questions pour le simple fait de poser des questions — disposez la fonctionnalité. S'ils ne le sont pas, l'élaboration est nécessaire : demandez uniquement sur les lacunes, regroupées dans un seul AskUserQuestion (jusqu'à 4 questions, options concrètes, un défaut recommandé en premier). Des CA vagues qui sont devinés produisent des reprises.

Triez chaque lacune avant de demander : si la réponse changerait la conception (ce qui est affiché, d'où viennent les données, ce que l'utilisateur voit en tapant), c'est une question. S'il s'agit de quelque chose avec une convention maison évidente — une clé de feature flag, un nom d'événement d'analyse, un enregistrement DI — choisissez la valeur conventionnelle, écrivez-la dans la disposition comme Supposé : afin que l'utilisateur puisse la corriger d'un coup d'œil, et ne demandez pas. Le lot de 4 questions est la seule demande ; pas de "aussi, veuillez confirmer…" après, car ce ne sont que plus de questions sans options.

La disposition couvre :

• Fichiers à ajouter/modifier, placés selon la stratification du projet (la configuration pointe vers le document qui la définit), y compris l'enregistrement DI dans chaque hôte
• Flux de données : d'où viennent les données, quel service possède l'état, comment il atteint le composant
• Mappage CA → test, nommant le projet de test pour chacun
• Différences de plateforme, analytiques/flags, risques et questions ouvertes

6. Point de contrôle

Mettez à jour le fichier mémoire avec ce que vous avez trouvé (statut 🔄, résumé de la cause racine ou de la disposition, questions ouvertes), puis présentez à l'utilisateur :

Bug:

## Bug <id>: <titre>
Branche: <prefix>/<id> (depuis origin/<base> @ <sha>)   — ou : en vol sur <branche>, pas de nouvelle branche
Mémoire: bug-<id>-context.md

### Cause racine
<mécanisme, fichier:ligne, pourquoi correspond au symptôme> — Confiance : <haute/moyenne/faible + ce qui l'augmenterait>

### Preuves
<citations de code, résultats de reproduction, historique : PR/tentatives précédentes>

### Correction proposée
<direction ou options + recommandation ; test de régression à ajouter ; fichiers à toucher>

### Besoin de vous
<catures d'écran/journaux manquants, décisions>

Feature:

## Feature <id>: <titre>
Branche / Mémoire : ...

### Ce que les CA disent vs. ce qui manque
### Disposition proposée (fichiers, flux de données, CA → tests, chaque plateforme, Supposé : …)
### Questions  (ou "Aucune — les CA sont suffisants")

Arrêtez-vous ensuite et attendez l'approbation. Si la RCA ou la disposition couvre 5+ fichiers ou modifie l'architecture, proposez de la rédiger dans le dossier docs/investigations du projet (configuration) — proposez, ne créez pas automatiquement.