Le ticket de A à Z

L’agent peut créer des tickets enfants pour répartir une mission en tâches indépendantes. Chaque enfant a sa carte, sa description, son agent et son résultat. Le parent peut continuer son propre travail, suivre les enfants et leur transmettre des instructions ; il reprend la synthèse lorsque leurs résultats arrivent.

La description de l’enfant doit être autonome : objectif, périmètre, contraintes et critères de réussite. Le découpage est limité à trois niveaux et cinq enfants non terminés par parent. Un enfant terminé ne clôture pas le parent : celui-ci vérifie les résultats et termine sa propre mission.

Un ticket de suivi conserve un travail distinct découvert en cours de route. Une dépendance exprime un prérequis : elle peut pointer vers un ticket déjà existant sans en faire un enfant. Par exemple, la documentation peut attendre la livraison d’une fonctionnalité, tandis que deux enfants frontend et API travaillent en parallèle. Une action réservée à une personne peut être représentée par un ticket Actions utilisateur lorsque ce plugin est actif.

Le libellé numéroté identifie le ticket. Le titre résume le résultat attendu et la description en donne le contexte. La priorité est low, medium, high ou critical. Les tags facilitent le classement et les projets concernés indiquent les dépôts à consulter.

Les huit types sont feature, bug, refactor, doc, test, ia, session et user-action. Ce dernier représente une action humaine et apparaît lorsque le module Actions utilisateur est actif.

Les six statuts exacts sont todo, in_progress, working, pending, done et failed. in_progress couvre la prise en charge, working une exécution active et pending une attente explicite.

Double-cliquez sur une carte de Mission Control. Le détail s'ouvre comme un onglet du deck : gardez-le à côté de l'éditeur, du terminal ou d'un autre ticket sans perdre le contexte.

La description est l'instruction principale lue par l'agent. Donnez le contexte et le problème observé, formulez des critères d'acceptation vérifiables, puis nommez le périmètre exclu. Ajoutez les chemins ou commandes utiles sans imposer une solution quand seul le résultat compte.

Une bonne description permet de savoir ce qui doit changer, comment vérifier la réussite et ce qui doit rester intact.

Un ticket vérifiable décrit le problème actuel, le résultat attendu, le périmètre, les exclusions et des critères observables accompagnés de commandes. Voici un exemple fictif et anonymisé, sans donnée client ni syntaxe de spécification imposée.

Dans un dépôt Git de démonstration avec Node.js 22 ou plus récent, vérifiez que les deux chemins ci-dessous sont libres. Créez un ticket dans Mission Control, reportez le titre, le type et la priorité dans leurs champs, puis copiez le reste dans la description. Pour votre projet réel, adaptez les chemins, les prérequis et les commandes avant de lancer l’agent.

Titre : Normaliser les espaces d’un libellé
Type : feature
Priorité : low
Projet : le dépôt de démonstration ouvert dans Singularity
Dépendances : aucune

Problème actuel
Ce dépôt Git de démonstration ne possède pas de fonction de normalisation.
Un libellé saisi avec des espaces superflus serait conservé tel quel.

Résultat attendu
Créer une fonction normalizeLabel(text) exportée depuis
src/normalize-label.mjs : retirer les blancs au début et à la fin,
puis remplacer chaque suite de blancs (espaces, tabulations, retours
à la ligne) par un seul espace. Conserver la casse et les accents.

Périmètre
Créer src/normalize-label.mjs et test/normalize-label.test.mjs.
Utiliser Node.js 22 ou plus récent, node:test et node:assert/strict.
Les entrées sont uniquement des chaînes. Aucune dépendance à installer.

Exclusions
Pas d’interface, de base de données, d’appel réseau, de changement
des fichiers existants, de gestion des autres types ou de publication.

Critères d’acceptation
1. "  Bonjour   équipe  " devient "Bonjour équipe".
2. "" et une chaîne composée de blancs deviennent "".
3. Des tabulations et retours à la ligne entre deux mots deviennent
   un espace ; "Équipe A" reste "Équipe A".
4. Les tests automatisés couvrent chacun de ces cas et réussissent.
5. Le diff final ne contient que les deux fichiers du périmètre.

Vérification depuis la racine du dépôt
node --version
node --check src/normalize-label.mjs
node --test test/normalize-label.test.mjs
git diff --check

Compte rendu attendu
Donner les commandes exécutées, leurs résultats et les fichiers créés.
Si une commande échoue, conserver son erreur et expliquer la limite.
Relire les deux fichiers dans l’onglet Revue et vérifier le périmètre
avant l’intégration ; une commande réussie ne valide pas tout le diff.

Les critères 1 à 4 se vérifient avec les tests ; le critère 5 se vérifie dans le diff de l’onglet Revue. Les commandes ci-dessus sont à exécuter par l’agent après création des fichiers ; cet exemple ne prétend pas rapporter une exécution réelle.

Déposez un fichier ou une image dans le formulaire de création, ou utilisez le bouton d'ajout. Images, PDF et textes se prévisualisent dans le détail. À l'exécution, Singularity expose leur liste à l'agent ; il peut les lire par la passerelle de session ou avec le chemin local fourni.

Utilisez des exemples minimaux et anonymisés : aucune capture ne doit révéler de secret ni le contenu d'un ticket réel.

Le champ Bloqué par relie le ticket à ses prérequis. Il ne se lance que lorsqu'ils sont terminés et, s'ils ont produit un worktree, intégrés.

Un ticket complexe peut être découpé en enfants. Le parent conserve leurs liens et peut continuer à travailler. Lorsqu’il attend ses enfants, il passe en pending puis reprend pour synthétiser leurs résultats.

Une échéance indique la date cible sans lancer le travail. La planification programme une exécution récurrente quotidienne ou hebdomadaire à l'heure choisie. Vous pouvez démarrer la première occurrence immédiatement, puis suspendre, reprendre ou supprimer la programmation.

Le fil conserve les tentatives, messages et réponses de l'agent. Écrivez pour préciser la demande pendant une exécution. Si l'agent pose une question bloquante, le ticket passe en pending : votre réponse revient à la même session avec son contexte.

Sur un ticket done ou failed, un nouveau message ou la relance démarre une nouvelle tentative sans effacer l'historique.

Le compte rendu final explique ce qui a été livré, les vérifications effectuées et les limites éventuelles. Il reste dans le détail et alimente la revue lorsqu'elle est activée.

La résolution courte est une phrase sans Markdown de moins de 120 caractères, affichée en gras sur la carte terminée pour rendre la colonne Done lisible d'un coup d'œil.