Évaluation de la Pertinence d'un Ticket Jira

Déterminer si un ticket Jira s'applique toujours à la base de code actuelle. Récupérer le ticket, localiser le chemin de code spécifique qu'il décrit, comparer le comportement actuel par rapport à la description du ticket, et retourner un verdict avec des preuves.

Flux de travail

Étape 1 : Récupérer le Ticket et Son Contexte

Utiliser get_issue avec expand: ["renderedFields", "names"]. Extraire :

Le problème ou la tâche spécifique : Lire au-delà du résumé. La description, les critères d'acceptation et les étapes de reproduction sont plus précis. Pour les bugs : quel est le comportement réellement cassé et quel est le résultat attendu ? Pour les tâches : quel changement de code spécifique est requis ?
Identifiants techniques : Noms de méthodes, noms de classes, chemins de fichiers, routes d'API, chaînes d'interface utilisateur qui apparaissent dans la source, clés de configuration, noms de feature flags — tout ce qui est nommé dans le ticket et qui peut être recherché dans le code. Noter ces éléments explicitement avant de continuer.
Date d'ouverture : Utilisée pour délimiter les recherches git log.
Preuves de portée du repo : Recueillir ce que le ticket dit sur l'endroit où le code réside, et noter la force de cette preuve. Ne pas se décider sur un repo ici — l'étape 2 décide.
- Forte : un nom de repo littéral, une URL github.com/bitwarden/<repo>, ou une PR/commit liée.
- Plus faible : champ équipe, labels de composant, mots-clés de langage ou de plateforme, chemins de fichiers dans la description.

Noter aussi ces signaux de vieillissement des champs du ticket avant de continuer :

Âge : Combien de mois depuis l'ouverture du ticket ?
Priorité et assigné : Est-ce une priorité Basse/Très basse ? Non assigné ?
Epic parent : Le ticket a-t-il une epic parent ? Si oui, la récupérer (get_issue) et vérifier si tous les autres tickets enfants sont résolus. Une seule tâche survivante dans une epic autrement complétée est un fort signal que le travail aurait pu être intentionnellement reporté ou oublié — pas qu'il soit toujours nécessaire.

Après avoir récupéré le ticket, toujours faire les deux choses suivantes :

Récupérer les commentaires du ticket (get_issue_comments) : Les commentaires contiennent souvent des décisions qui n'ont jamais été réintégrées dans la description — findings de cause racine, « on a décidé de ne pas corriger cela », appels de priorité, ou pointeurs vers où le correctif a atterri. Les lire avant de construire les cibles de recherche.

Récupérer les tickets liés (get_issue_remote_links et le champ issuelinks) : Chercher spécifiquement les relations de blocage — les tickets que ce ticket bloque ou qui le bloquent. Un ticket bloqué par du travail non résolu peut ne pas être actionnable encore ; un bloqueur qui a depuis été résolu peut signifier que ce ticket est maintenant prêt. Récupérer (get_issue) tous les tickets directement liés pour vérifier leur statut actuel et extraire un contexte technique supplémentaire. Ne pas traverser plus d'un niveau en profondeur.

Étape 2 : Établir la Portée du Repo

Déterminer quels repositories sont en scope et confirmer qu'ils sont lisibles avant de chercher quoi que ce soit. Ne pas passer à l'étape 3 jusqu'à ce que les trois vérifications ci-dessous réussissent.

Bitwarden a de nombreux repositories — clients, server, sdk-internal, sdk-sm, android, ios, mcp-server, et autres. Traiter l'ensemble candidat comme ouvert ; ne jamais supposer qu'un ticket doit appartenir à l'un des repos que tu as vus avant.

1. Déterminer les repos.

Si le ticket porte une forte preuve (un nom de repo littéral, une URL github.com/bitwarden/<repo>, ou une PR/commit liée), l'utiliser et continuer.

Sinon, inférer le(s) repo(s) le(s) plus probable(s) à partir des signaux plus faibles et présenter cette inférence pour confirmation avec AskUserQuestion. Énoncer ce qui a été inféré et le signal sur lequel il repose, offrir les alternatives plausibles qui ont été considérées, et permettre les sélections multiples — les tickets s'étendent légitimement sur plusieurs repos. Ne jamais chercher dans un repo que l'utilisateur n'a pas confirmé.

2. Résoudre chaque repo vers un chemin.

Utiliser le répertoire de travail actuel s'il s'agit de ce repo ; sinon chercher un répertoire frère du même nom ; sinon demander le chemin. Confirmer que chaque chemin résolu est un vrai checkout :

git -C <path> rev-parse --show-toplevel

3. Vérifier que le repo est cloné, et s'arrêter s'il ne l'est pas.

Si un repo en scope n'a pas de checkout sur disque, demander s'il faut le cloner. Avec l'approbation, le cloner et continuer.

Si l'utilisateur refuse de cloner, s'arrêter immédiatement. Ne retourner aucun verdict. Indiquer quel repo était indisponible et que l'évaluation n'a pas pu être complétée. Cette halte s'applique même lorsque d'autres repos en scope sont présents — ne pas évaluer la moitié disponible et ne pas réduire à un verdict plus faible. Chercher un repo qui n'est pas sur disque ne retourne aucune correspondance, ce qui est indistinguishable du code ayant été supprimé ; continuer produirait un « No longer relevant » confiant sur un ticket qui est toujours actif.

Cette halte est distincte du verdict Cannot determine à l'étape 5. « Cannot determine » signifie que le ticket était trop vague à tracer. Cela signifie que la preuve n'était jamais accessible.

Étape 3 : Construire les Cibles de Recherche

À partir du ticket, identifier 2–5 identifiants spécifiques à rechercher dans le code. Prioriser :

Noms de méthode ou fonction mentionnés dans le ticket (ex. ValidateLegacyMigrationAsync, unlockViaBiometrics, validateCanManagePermission)
Noms de classe ou composant (ex. BaseRequestValidator, LockComponent, CollectionDialog)
Chaînes de route API (ex. "trial/send-verification-email", "verify-email-token")
Chaînes d'interface utilisateur qui apparaissent dans la source ou i18n JSON (ex. "managePermissionRequired")
Clés de configuration ou feature flag (ex. DenyLegacyUserMinimumVersion)

Si le ticket ne nomme pas d'identifiants spécifiques, les dériver du comportement décrit : quelle fonction implémenterait ceci, quel composant rendrait cette interface utilisateur, quel endpoint servirait cette requête ?

Étape 4 : Rechercher dans le Code

Exécuter les recherches dans le(s) repo(s) confirmé(s) à l'étape 2.

D'abord, s'orienter dans chaque repo : lire son CLAUDE.md et README pour trouver les racines de source, la disposition des modules et les emplacements de test. Faire cela plutôt que de se fier aux noms de répertoires mémorisés — les dispositions diffèrent par repo et changent au fil du temps.

Ensuite :

Grep pour chaque identifiant dans les répertoires sources pertinents. Ne pas s'arrêter à confirmer l'existence — lire le code environnant pour comprendre le comportement actuel. Un symbole qui existe toujours mais se comporte maintenant différemment peut signifier que le bug est déjà corrigé.
Lire l'implémentation actuelle à chaque correspondance. Le résultat grep montre où ; le contenu du fichier montre ce qu'il fait actuellement. Confirmer si le comportement que le ticket décrit est toujours présent, partiellement changé, ou disparu.
Vérifier l'historique git sur les fichiers affectés depuis l'ouverture du ticket :
```
git log --oneline --since="<filed-date>" -- <file-path>
```
Chercher les commits qui auraient pu silencieusement résoudre le problème — refactorisation, renommages, suppressions de feature flag, réécritures de composant. Si un commit semble pertinent, lire son diff sur les lignes affectées.
Tracer les chemins refactorisés : Si un symbole nommé n'existe plus, trouver ce qui l'a remplacé. Une méthode supprimée ne signifie pas que le bug est corrigé — la logique peut avoir bougé. Chercher le comportement, pas seulement le nom original.

Étape 5 : Livrer le Verdict

Comparer ce que le ticket décrit par rapport à ce que le code fait aujourd'hui. Atteindre une conclusion.

Options de verdict :

Still relevant — Le problème décrit existe inchangé dans le code actuel. Montrer le file:line spécifique qui le prouve.
Partially addressed — Une partie du problème décrit a été corrigée, mais un écart demeure. Énoncer précisément ce qui a été corrigé et ce qui reste ouvert, avec des preuves pour chacun.
No longer relevant — Le problème n'existe plus. Expliquer ce qui a changé et citer le code actuel ou le commit qui le prouve. Noter si le ticket peut être fermé en toute sécurité.
Technically relevant, but question whether still needed — L'écart existe dans le code, mais les signaux de vieillissement sont assez forts pour que le travail soit confirmé avec le reporter ou le PM avant de le prendre. Utiliser ceci quand plusieurs signaux se combinent : ticket significativement ancien (> ~9 mois), non assigné, priorité basse, et/ou seule tâche survivante dans une epic autrement complétée. Énoncer la preuve du code et les signaux de vieillissement séparément pour que le lecteur puisse peser les deux.
Cannot determine — La description du ticket est trop vague pour être tracée à un code spécifique, et git log ne fournit aucun signal. Énoncer ce qui a été cherché et pourquoi c'était inconclusive. Utiliser uniquement après avoir épuisé les cibles de recherche.

Format : Commencer par le verdict et sa justification en prose simple. Citer les références file:line comme preuve. Si toujours pertinent, énoncer ce qui spécifiquement reste à faire — ne pas simplement réitérer le ticket. Si des signaux de vieillissement sont présents même pour un verdict « Still relevant », les noter à la fin : âge du ticket, état d'achèvement de l'epic, priorité et assigné. Garder cela serré ; un paragraphe de verdict avec preuves à l'appui est suffisant.

Ce qu'il NE FAUT PAS Faire

Ne pas traverser les tickets liés plus d'un niveau — récupérer les tickets directement liés (bloque, est bloqué par, epic parent) mais ne pas suivre leurs liens plus loin
Ne pas sauter la vérification de l'epic parent pour les tickets de tâche — un appel get_issue supplémentaire change souvent la recommandation de « construire ceci » à « confirmer si c'est toujours voulu »
Ne pas lire les pages Confluence sauf si le ticket n'a pas de description et un lien Confluence est le seul contexte disponible
Ne pas retourner « cannot determine » sans d'abord vérifier à la fois les symboles nommés ET git log sur les fichiers pertinents
Ne pas traiter « le symbole existe toujours » comme « le bug est toujours présent » — lire le comportement actuel, pas seulement le nom
Ne pas réitérer la description du ticket comme le verdict — le verdict doit refléter ce que le code dit aujourd'hui

Exemples

examples/relevance_assessment_workflow.md

Quatre exemples détaillés : un bug où le chemin de code décrit a été silencieusement refactorisé, une tâche dont l'écart d'implémentation est confirmé présent, un spike rendu obsolète par un travail ultérieur, et un ticket dont le repo n'est pas cloné localement, où la compétence s'arrête sans verdict.

assessing-jira-issue-relevance