Créer des tickets Jira

Les tickets se lisent en dehors du contexte qui les a produits, ils doivent donc être autonomes.

Les tickets en direct sont difficiles à annuler, donc create_issue et link_issues ont par défaut un dry run qui retourne le payload exact sans l'envoyer. Prévisualisez avant chaque écriture en direct. Une écriture en direct nécessite un dryRun: false explicite.

Rien n'est créé sans approbation sauf si on te le dit explicitement. Voir l'étape 3.

Étape 1 : Lire l'écran de création du projet cible

Bitwarden classe les tickets dans plusieurs projets qui n'ont pas la même structure. PM et SM exposent un champ Acceptance criteria ; QA, VULN et PLT ne l'ont pas. VULN n'a pas de type Story. Le seul type créable de PLT est Platform Initiative. Ne présume jamais d'un id de champ, d'un champ obligatoire, ou de l'existence d'un type d'issue.

Appelle get_create_fields avec la clé du projet, puis à nouveau avec le type d'issue prévu. Il retourne les types créables du projet, puis chaque champ de l'écran de création de ce type avec son id, s'il est obligatoire, et ses valeurs autorisées.

• Le type n'est pas dans la liste : choisis parmi ce que propose le projet, ou demande à l'utilisateur lequel il veut.
• L'outil rapporte qu'il ne peut pas lire l'écran de création (un 404) : cela signifie que la clé du projet n'existe pas, ou que l'utilisateur n'a pas les permissions de création là-bas — l'outil ne peut pas distinguer. Revérifie la clé du projet pour une faute de frappe avant de conclure à la seconde raison ; si elle est correcte, dis à l'utilisateur qu'il lui manque probablement les permissions de création et arrête. Ne devinez pas un projet différent.

Critère d'achèvement : pour le projet cible et le type d'issue, une liste des champs obligatoires et les ids de tout champ optionnel que ce travail doit remplir.

Étape 2 : Rédiger le ticket

Traduis le travail en champs. Ne colle pas ce que le document source disait.

• Titre. Verbe impératif, résultat et domaine : Add CSV export to the item list (web). Respecte le style des tickets frères sous le même parent, et consultes-en un si tu n'es pas sûr.
• Description. Un court paragraphe du travail réel, plus toute réserve spécifique à ce ticket. Pas de boilerplate de filiation comme Part of PM-1234, et pas de chemin vers un document source ; le lien parent le transmet déjà. Épelle les abréviations plutôt que d'utiliser des symboles.
• Acceptance criteria. Si l'étape 1 a montré que le projet a un champ de critères, transmets les critères là via fields, indexés par l'id du champ, comme une seule chaîne de Gherkin (Scenario, Given, When, Then, And) — ce champ est du texte brut, donc les sauts de ligne intégrés s'affichent bien. Si le projet n'a pas ce champ, mets les critères dans la description à la place : transmets chaque ligne Gherkin comme sa propre entrée descriptionParagraphs, puisque chaque entrée devient un paragraphe et un paragraphe n'a pas de nœud de saut de ligne en soi. Dis à l'utilisateur que c'est ce que tu as fait. N'invente pas un id de champ.
• Champs obligatoires. Fournis chacun que l'étape 1 a rapporté. Quand une valeur relève d'un jugement métier plutôt que de quelque chose de dérivable du travail, demande à l'utilisateur et propose les valeurs autorisées que l'étape 1 a retournées. Ne devinez pas, et ne choisissez pas la première option.
• Labels. Seulement ce que l'utilisateur a demandé.

Critère d'achèvement : un payload rédigé par ticket qui satisfait chaque champ obligatoire que l'étape 1 a rapporté.

Étape 3 : Prévisualiser, approuver, créer

Pour chaque ticket, dans l'ordre donné :

1. Fais un dry run.
2. Vérifie la sortie brute de l'outil par rapport à l'étape 1 : chaque champ obligatoire présent, critères dans le champ que l'étape 1 a identifié (ou dans la description si le projet n'en a pas), parent correct, le titre a du sens pour quelqu'un qui n'a pas lu la source.
3. Montre à l'utilisateur une prévisualisation en langage clair : titre, texte de description complet, critères d'acceptation complets, parent, labels.
4. Obtiens l'approbation sur cette prévisualisation. Puis crée-le avec dryRun: false et enregistre la clé retournée.

L'approbation avant chaque création est la norme. Ignore-la seulement si on te dit explicitement de créer sans approbation.

Si une création échoue en nommant un champ, relis l'étape 1 pour ce projet au lieu de deviner la correction.

Critère d'achèvement : chaque ticket demandé prévisualisé, approuvé et créé, avec chaque clé retournée enregistrée.

Étape 4 : Câbler les liens de dépendance

Les liaisons sont réversibles, donc cette étape peut s'exécuter par lot une fois les tickets créés.

• Une dépendance dure, où un élément doit atterrir avant qu'un autre puisse commencer, est Blocks. Une dépendance souple ou seulement d'ordre est Relates.
• Pour Blocks, transmets blockerKey pour l'élément qui doit atterrir en premier et blockedKey pour l'élément qui attend. L'outil les mappe sur les côtés inward et outward de Jira en interne, donc la direction ne peut pas être inversée en se trompant dans l'ordre des arguments.
• link_issues relit le lien lui-même et rapporte s'il l'a vérifié. S'il rapporte qu'il n'a pas pu le vérifier, dis-le à l'utilisateur et pointe-le vers le panneau Linked Issues de Jira directement — la sortie de get_issue n'a pas de section links, donc il ne peut pas confirmer cela pour toi.

Critère d'achèvement : chaque relation dont le ticket cible existe est créée et vérifiée. Les relations pointant vers un travail qui n'existe pas encore sont rapportées à l'utilisateur, non supprimées.