Fiche vérifiée le 31 octobre 2026 · Canal production · Meteor Factory
Pourquoi utiliser User Actions ?
Pour les équipes qui confient des tickets aux agents, User Actions transforme une intervention humaine en consignes traçables.
Créez une action manuelle, consultez son état et ajoutez une dépendance au ticket de l’agent lorsque cette intervention est indispensable.
Les captures montrent les résultats réellement exécutés des outils du plugin dans un banc MCP local, avec stockage de tickets en mémoire. La résolution humaine est simulée par une fixture ; ni la persistance du Board, ni le transport MCP Electron, ni la reprise réelle d’un agent ne sont exercés. Aucun service cloud n’est appelé.
Prérequis et activation
Installez User Actions depuis le Marketplace de Singularity 2.x, puis activez son interrupteur global. Accordez les permissions obligatoires tickets.read, tickets.write et mcp.expose. Ouvrez un espace de travail de démonstration et un ticket agent. Le plugin est gratuit et désactivé par défaut ; aucun compte externe ni secret n’est nécessaire pour cet exemple.
Premier résultat : valider un texte
- Créez un fichier local demo.txt contenant Bonjour Atlas.
- Demandez à l’agent du ticket de lancer user_action_create avec les arguments ci-dessous (JSON MCP, pas une commande shell).
- Vérifiez la réponse : pendingApproval vaut true et blocking vaut true. Le nouveau ticket est de type user-action ; le ticket appelant conserve ses dépendances et ajoute cet identifiant dans dependsOn.
- Dans le Board, ouvrez l’action utilisateur, lisez les étapes et vérifiez le fichier. Après exécution, marquez l’action terminée. Relancez user_action_list avec includeInstructions: true pour vérifier status: done.
{
"title": "Valider le libellé de démonstration",
"instructions": "1. Ouvrir le fichier local demo.txt.\n2. Vérifier le texte Bonjour Atlas.\n3. Marquer cette action terminée dans le Board.",
"blocking": true
}
Résultat attendu : l’action attend une personne, jamais une exécution automatique par un agent. La fin de l’action satisfait cette dépendance ; les autres dépendances et l’ordonnanceur de Singularity déterminent la reprise du ticket appelant.
Création réelle : approbation humaine et dépendance du ticket appelant.
{"includeInstructions": true}
Résolution simulée : user_action_list retourne l’action terminée.
Variante : demande sans blocage
Utilisez les mêmes arguments avec blocking: false (ou omettez ce champ). L’action est créée avec pendingApproval: true, mais le ticket appelant ne reçoit aucune dépendance supplémentaire. Appelez user_action_list avant de créer une nouvelle action pour éviter les doublons.
Erreur reproductible
{"title":"", "instructions":"Check demo.txt"}
Le titre vide est rejeté avant toute création avec title is required and must be a non-empty string. Corrigez le titre puis réessayez.
Configuration
title: texte obligatoire, 1 à 200 caractères après suppression des espaces en bordure.instructions: texte obligatoire non vide.priority:low,medium(par défaut),high,critical.blocking:false(par défaut).includeInstructions:false(par défaut).
Limites et dépannage
Les captures montrent les résultats réellement exécutés des outils du plugin dans un banc MCP local, avec stockage de tickets en mémoire. La résolution humaine est simulée par une fixture ; ni la persistance du Board, ni le transport MCP Electron, ni la reprise réelle d’un agent ne sont exercés. Aucun service cloud n’est appelé.
Si blocking revient à false malgré la demande, le contexte ne contient pas de ticket appelant ou celui-ci est introuvable. Inspectez le ticket créé avant de réessayer. Une erreur de mise à jour peut survenir après sa création : ne créez pas de doublon. Si les outils sont absents, vérifiez activation et permissions puis démarrez une nouvelle exécution agent. Désactiver le plugin retire les outils ; cela ne résout pas les actions existantes.
Reproduire les captures
User Actions 1.0.7 · docs/demo.json · Node.js ≥22.5 · pnpm 11.15.1 · Chromium headless.
Depuis la racine du dépôt Particles, utilisez les commandes suivantes. Le chemin SINGULARITY_SOURCE doit désigner un checkout local de Singularity avec ses dépendances installées et son renderer construit (pnpm install --frozen-lockfile, puis pnpm build dans ce checkout). Le test lit son CSS dans out/renderer/assets ; SINGULARITY_CSS_ROOT permet un autre répertoire de build.
pnpm install --frozen-lockfile
pnpm build:tooling
pnpm exec playwright install chromium
SINGULARITY_SOURCE=/path/to/Singularity \
node test/user-actions-documentation.playwright.mjs
Continuer avec Singularity
Ce plugin s’utilise dans un espace de travail Singularity. Consultez les permissions et les conditions de licence dans le Marketplace avant de l’activer.