La palette est le panneau de l'éditeur visuel depuis lequel vous glissez — ou cliquez — pour ajouter des étapes à un draft. Elle contient 138 types de nodes répartis en 17 catégories. Cette page est l'index : une ligne honnête par node, pour trouver le bon sans avoir à le poser d'abord. Les entrées et sorties exactes ne sont volontairement pas ici — les signatures au niveau des pins appartiennent à la référence agent.
Les primitives proposent, les verbes engagent : les nodes cerveau n'écrivent jamais par eux-mêmes, les nodes de service qui changent l'état sont gardés par un gate sur chaque chemin, et le delta de dépôt du run ne fusionne que lorsque vous acceptez le run.
Quatre conventions couvrent presque tout, énoncées une seule fois :
Chaque node vit sur la spine Exec. Les fils d'exécution ordonnent les étapes ; les fils de données portent les valeurs. Voir Anatomie d'un workflow.
Presque chaque node émet un result JSON. 125 des 138 se terminent par une sortie result unique que les nodes en aval consomment.
Quelques-uns vous tendent en plus une poignée typée — un id de run, un id d'incident, un id de lease, ou un workspace — que vous câblez directement dans les nodes qui en ont besoin.
Les familles viennent par trois pour le fan-out. Beaucoup de familles de services livrent un node prepare (ou load), un node par item fait pour vivre dans un corps de fan-out, et un node reduce qui replie les items ensemble (analyze, aggregate, finalize, score ou submit-report). Les lignes marquées (par item) ci-dessous sont la pièce du milieu.
Une chose que vous ne trouverez pas dans ce catalogue : les blocs de contrôle de flux. La section Structural (« Structurels ») de la palette porte les tuiles — Trigger (« Déclencheur »), Approval Gate (« Porte d'approbation »), Branch / Switch (« Branche / Switch »), For Each (« Pour chaque »), Map / Fan-out (« Map / Distribution »), Wait (timer) (« Attente (minuteur) »), Wait (event) (« Attente (événement) »), Workflow Reference (« Référence de workflow ») et le cadre Comment (« Commentaire ») — et Finally, qui n'a pas de tuile et se rédige dans le payload du graphe. Tous ont leur propre page.
Six des 138 sont génératifs — ils appellent un modèle. Quatre sont des call-sites câblés avec un rôle fixe :
Missions:Decomposition transforme l'objectif d'une mission en une proposition de découpage en tâches.
Coder:Default dispatche une tâche de coder et attend l'artifact résultant.
Coder:AsyncDefault dispatche du travail de coder et route la suite sur des outcome arms (« bras d'issue ») — onSuccess, onFailure ou onRefusal. C'est l'un des deux nodes multi-arm de la palette — l'autre est service:mission:integrate, dans Git ; voir Les outcome arms.
ReviewEngine:Default revoit un artifact et produit des constats.
Deux sont génériques :
llm exécute un tour de modèle borné sur son entrée. Il n'a pas d'outils, par construction.
agent exécute une boucle d'agent multi-tours avec un toolset explicite et un budget obligatoire. Plusieurs flows intégrés sys- l'utilisent désormais — l'un en dépêche dix. Pour vos propres graphes, llm ou un coder reste le premier réflexe le plus simple, sauf si vous savez pourquoi il vous le faut.
La discipline est la même pour les six : les primitives proposent, les verbes engagent. Un node cerveau n'écrit jamais nulle part par lui-même. Sa sortie n'atteint le monde qu'à travers des nodes de service explicites en aval — et sur chacun de ces chemins, un gate se dresse avant l'écriture.
Les 132 autres nodes sont des adaptateurs, en trois genres :
Lectures — 20 nodes. Elles récupèrent de l'état et ne changent rien : les détails d'une mission, un fichier d'une branche, l'avancement d'onboarding d'un projet. Posables partout sans risque.
Actions workspace — 2 nodes.workspace:write_file et workspace:create écrivent, oui — mais uniquement dans un workspace sandboxé. Ils ne touchent jamais votre dépôt.
Opérations de service — 110 nodes. Une opération de plateforme chacune : créer un incident, classifier un case de support, lancer un check de conformité, pousser une branche. Celles qui changent l'état de la plateforme sont exactement ce que la règle de dominance des gates garde.
Le genre se lit généralement dans l'id : read: lit, service: opère, et les verbes fichiers vivent sous workspace:.
Seize catégories ici, classées selon la fréquence à laquelle un testeur en a besoin — la dix-septième, Legacy, clôt la page. Dépliez un bloc pour voir ses nodes.
Missions — planifier, décomposer et scorer le travail de mission · 12 types de nodes
Node
Ce qu'il fait
Missions:Decomposition
Transforme l'objectif d'une mission en une proposition de découpage en tâches (génératif).
read:mission_get
Lit les détails et l'état d'une mission.
read:mission:stale
Liste les missions encore ouvertes sans activité récente.
read:task-deps:resolve
Résout l'ordre des dépendances entre les tâches d'une mission.
read:boundary:validate
Vérifie qu'un élément enfant proposé reste dans le périmètre de son parent.
read:task-routing:route
Choisit le bon routage pour une tâche d'après sa description et ses exigences.
service:satisfaction:score
Score dans quelle mesure le résultat d'une mission satisfait son objectif.
service:decomposition:propose
Propose une décomposition pour une mission à partir d'un objectif et de constats.
service:decomposition:coder
Produit une décomposition orientée coder pour une mission.
service:proposal:record
Enregistre un élément proposé sur une mission.
service:decomposition:materialize-tasks
Matérialise une décomposition acceptée en vraies tâches.
service:mission:create
Crée une nouvelle mission — le seul node qui engendre une mission enfant.
Workspace — lire et écrire dans des workspaces sandboxés · 6 types de nodes
Node
Ce qu'il fait
workspace:read_file
Lit un fichier d'un workspace.
workspace:list_files
Liste les fichiers sous un chemin de workspace.
workspace:write_file
Écrit un fichier dans un workspace (sandbox uniquement — jamais votre dépôt).
workspace:create
Crée un workspace neuf et retourne sa poignée.
workspace:merge
Fusionne plusieurs workspaces en un seul et retourne la poignée fusionnée.
service:workspace:copy-tree
Copie une arborescence source dans un workspace.
Git — lire des fichiers de dépôt et pousser du travail · 4 types de nodes
Node
Ce qu'il fait
read:gitlab_get_file
Lit un fichier d'une branche de dépôt.
read:gitlab_list_files
Liste les fichiers sous un chemin de dépôt.
service:mission:integrate
Intègre la branche d'une tâche de coder dans la branche de la mission, en routant l'issue sur les arms onSuccess / onRefusal / onFailure (multi-arm).
service:git-push:default
Pousse le travail du run sur une branche.
Research — enquêter, synthétiser, critiquer · 6 types de nodes
Node
Ce qu'il fait
service:research:investigate-codebase
Enquête dans la base de code pour une requête.
service:research:investigate-docs
Enquête dans la documentation pour une requête.
service:research:investigate-web
Enquête dans les sources web pour une requête.
service:research:synthesize
Synthétise les constats codebase, docs et web en une seule réponse.
service:research:critique
Critique une synthèse au regard de la requête d'origine.
service:research:record-findings
Enregistre des constats de recherche sur une mission.
Review — les pipelines de revue de code et UX · 7 types de nodes
Node
Ce qu'il fait
ReviewEngine:Default
Revoit un artifact et produit des constats (génératif).
service:review-engine:discover-targets
Découvre ce qu'un projet offre à revoir dans un domaine donné.
service:review-engine:review-target
Revoit une cible découverte (par item).
service:review-engine:submit-report
Soumet le rapport de revue assemblé pour une session.
service:ux-review:discover-pages
Découvre les pages d'un projet pour la revue UX.
service:ux-review:review-page
Revoit une page à la recherche de problèmes UX (par item).
service:ux-review:submit-report
Soumet le rapport de revue UX pour une session.
Validation — validation physique, pilotage de cibles et runs par lots · 20 types de nodes
Node
Ce qu'il fait
service:canary:prepare
Prépare un run canary et ses cas de test.
service:canary:run-test-case
Exécute un cas de test canary (par item).
service:canary:analyze
Analyse les résultats du run canary.
service:run-acceptance:prepare
Prépare les cas de validation pour accepter un run.
service:run-acceptance:run-built-target
Exerce une cible construite pour un run (par item).
service:run-acceptance:analyze
Analyse les résultats de la validation d'acceptation.
service:run-target:lease
Prend un lease sur une cible en marche à piloter ; retourne un id de lease.
service:run-target:drive-case
Pilote un cas contre la cible sous lease (par item).
service:run-target:release
Libère le lease de la cible.
service:llm-preset-validation:load
Charge les cellules de validation de presets à exécuter.
service:llm-preset-validation:run-cell
Exécute une cellule de validation de preset (par item).
service:llm-preset-validation:evaluate
Évalue un run de validation de presets.
service:validation-runs:load
Charge un run de validation de modèles à partir de modèles et de prompts.
service:validation-runs:run-model-group
Exécute un groupe de modèles (par item).
service:validation-runs:record-execution
Enregistre la réponse ou l'erreur d'une exécution.
service:validation-runs:finalize
Finalise un run de validation de modèles.
read:validation-runs:group-executions
Lit les exécutions enregistrées pour un groupe de modèles.
service:batch-processing:create-batch
Crée un batch à partir d'un ensemble de chunks.
service:batch-processing:process-chunk
Traite un chunk du batch (par item).
service:batch-processing:aggregate
Agrège les chunks traités d'un batch.
Knowledge — interroger bases de connaissances, experts et logs · 3 types de nodes
Node
Ce qu'il fait
read:intelligence_knowledge_query
Interroge la base de connaissances d'un projet.
read:cortex:expert-query
Pose une question à un expert de domaine.
read:loki_query_range
Interroge les logs sur une plage de temps.
Communication — parler et rapporter · 2 types de nodes
Node
Ce qu'il fait
service:dialogue:send
Envoie un message dans une conversation.
service:report-compile:default
Compile un rapport titré et l'émet comme artifact.
Scaffolding — générer et exécuter le scaffolding d'un projet · 9 types de nodes
Node
Ce qu'il fait
service:scaffolding:generate
Génère une proposition de scaffolding pour un projet.
service:scaffolding:save-plan
Sauvegarde un plan de scaffolding pour un projet.
service:scaffolding:approve
Marque la proposition de scaffolding approuvée.
service:scaffolding:reject
Marque la proposition de scaffolding rejetée.
service:scaffolding:execute
Exécute le plan de scaffolding sauvegardé.
service:scaffolding:execute-step
Exécute une étape du plan (par item).
service:scaffolding:finalize
Finalise le run de scaffolding.
read:project-profile
Lit le profil d'un projet.
read:scaffolding:plan-steps
Lit les étapes du plan de scaffolding sauvegardé.
Improvement — le cycle de vie des propositions d'amélioration · 7 types de nodes
Node
Ce qu'il fait
service:improvement:propose
Enregistre une nouvelle proposition d'amélioration.
service:improvement:validate
Valide une amélioration proposée.
service:improvement:promote
Promeut une amélioration validée.
service:improvement:reject
Rejette une amélioration, avec une raison.
service:improvement:complete
Marque une amélioration terminée.
service:improvement:fail
Marque une amélioration échouée, avec une raison.
service:improvement:rollback
Annule une amélioration (rollback), avec une raison.
Support — le cycle de vie des cases de support · 8 types de nodes
Node
Ce qu'il fait
read:support:case-context
Lit le contexte complet d'un case de support.
service:support:classify
Classifie un case de support.
service:support:investigate
Lance une investigation sur un case de support.
service:support:apply-verdict
Applique un verdict à un case, y compris les liens de doublon.
service:support:escalate
Escalade un case.
service:support:request-verification
Demande une vérification sur un case.
service:support:resolve
Résout un case vers un état terminal.
service:support:link-investigation
Lie un case à la mission qui l'investigue.
Incidents — créer, classifier et clore des incidents · 5 types de nodes
Node
Ce qu'il fait
service:incident:create
Crée un incident et retourne son id.
service:incident:classify
Classifie un incident.
service:incident:timeline-entry
Ajoute une entrée à la timeline d'un incident.
service:incident:close
Clôt un incident.
read:incident:overdue
Liste les incidents en retard.
Onboarding — onboarding de projets et de charters · 17 types de nodes
Node
Ce qu'il fait
service:project-onboarding:start
Démarre l'onboarding d'un projet.
read:project-onboarding:progress
Lit l'avancement d'onboarding d'un projet.
read:project-onboarding:design
Lit le design d'onboarding d'un projet.
service:onboarding:decompose
Décompose une intention d'onboarding en étapes.
service:onboarding:approve
Marque une décomposition d'onboarding approuvée.
service:onboarding:deny
Marque une décomposition d'onboarding refusée.
service:aspect-onboarding:load-charter
Charge les aspects d'un charter pour l'onboarding.
service:aspect-onboarding:collect-analyses
Rassemble les résultats d'analyse par aspect d'un run en un seul tableau.
service:aspect-onboarding:complete-matters
Termine chaque matter dont l'aspect est achevé, fait avancer le suivant, et finalise le charter quand tous sont terminés.
service:onboarding:update-design-concern
Écrit la phase et les notes d'un aspect dans le tracker de design du projet.
service:aspect-onboarding:run-aspect
Exécute un aspect d'un charter (par item).
service:aspect-onboarding:advance
Fait avancer l'onboarding par aspects d'un charter.
service:aspect-onboarding:determine
Dispatche la revue de découverte qui produit une détermination de projet (le résultat arrive plus tard sous forme d'événement).
service:aspect-onboarding:refresh-summaries
Rafraîchit tous les résumés d'aspects et re-détecte les conflits entre aspects.
read:project-onboarding:concerns-settled
Lit si les préoccupations d'onboarding d'un projet sont toutes réglées.
service:project-onboarding:apply-determination
Replie les réponses d'une détermination dans le tracker de design du projet.
service:aspect-onboarding:reconcile
Termine les matters réglés par les déterminations et finalise le charter quand tous le sont.
Agents — les primitives génératives · 4 types de nodes
Node
Ce qu'il fait
Coder:Default
Dispatche une tâche de coder et attend l'artifact résultant (génératif).
Coder:AsyncDefault
Dispatche du travail de coder et route l'issue sur les arms onSuccess / onFailure / onRefusal (génératif ; l'un des deux nodes multi-arm).
llm
Un tour de modèle borné sur son entrée — sans outils (génératif).
agent
Une boucle d'agent multi-tours avec toolset explicite et budget (génératif ; utilisé par plusieurs flows intégrés sys-).
ComplianceChecks — checks réglementaires déterministes · 24 types de nodes
Des checks déterministes — la plateforme les évalue mécaniquement ; aucun modèle n'écrit un verdict de conformité. Groupés par famille réglementaire : cra-* (Cyber Resilience Act), pld-* (responsabilité produit), aiact-* (AI Act), nis2-* (NIS2).
Node
Ce qu'il fait
service:compliance:sca-check
Vérifie les résultats d'analyse de composition logicielle (dépendances).
service:compliance:clause-map
Vérifie le mapping des clauses d'un contrat.
service:compliance:roi-completeness
Vérifie la complétude d'une soumission ROI.
service:compliance:incident-timeliness
Vérifie la timeline d'un incident contre les délais de déclaration.
service:compliance:cra-sbom
CRA : vérifie le SBOM soumis.
service:compliance:cra-sca
CRA : vérifie les composants déclarés (analyse de composition).
service:compliance:cra-secure-update
CRA : vérifie le canal de mise à jour sécurisé.
service:compliance:cra-techdoc
CRA : vérifie la documentation technique.
service:compliance:cra-ce-marking
CRA : vérifie les preuves de marquage CE.
service:compliance:cra-reporting
CRA : vérifie les obligations de déclaration.
service:compliance:pld-disclosure-pack
PLD : vérifie le pack de divulgation.
service:compliance:pld-provenance
PLD : vérifie la provenance des composants.
service:compliance:pld-update-channel
PLD : vérifie le canal de mise à jour.
service:compliance:pld-retention
PLD : vérifie les règles de rétention.
service:compliance:aiact-techdoc
AI Act : vérifie la documentation technique.
service:compliance:aiact-registration
AI Act : vérifie l'enregistrement.
service:compliance:aiact-gpai-doc
AI Act : vérifie la documentation GPAI.
service:compliance:aiact-logging
AI Act : vérifie les obligations de logging.
service:compliance:aiact-transparency
AI Act : vérifie les obligations de transparence.
service:compliance:aiact-conformity
AI Act : vérifie les preuves de conformité.
service:compliance:aiact-retention
AI Act : vérifie les règles de rétention.
service:compliance:aiact-serious-incident
AI Act : vérifie le traitement des incidents graves.
service:compliance:nis2-incident-timeliness
NIS2 : vérifie les délais de déclaration d'incident.
service:compliance:nis2-retention
NIS2 : vérifie les règles de rétention.
ComplianceAssess — les runs d'évaluation de conformité · 3 types de nodes
Node
Ce qu'il fait
service:compliance-assess:prepare
Prépare un run d'évaluation de conformité ; retourne les ids de run et de profil.
Un seul node de la palette est legacy : service:research:llm, une étape de recherche des débuts, supplantée par le node générique llm. Le validateur le bloque à la publication dans les nouveaux drafts. Les workflows que vous avez déjà publiés sont des graphes figés : ils continuent de se résoudre tels quels.
