Scrydon

Process Flows

Créer des Process Flows avec le SDK — étapes, tâches, personas, modèles d'actions et déclencheurs vocaux — et les distribuer sous forme de packs

Cet artefact est distribué dans un Pack. Pour le cycle de vie partagé — installation, pack build, upload — voir Packs & SDK d'authoring.

Un Process Flow est un workflow structuré et reproductible avec des étapes, des tâches et des personas — lancements de projets, audits, onboarding, revues de due-diligence. Vous le créez une fois comme Process Flow avec ce SDK et le distribuez dans un .scrydon-pack.tar.gz ; la plateforme l'instancie à chaque exécution comme un Process Flow.

Le SDK et le pack sont le seul chemin d'authoring. Les Process Flows sont définis en code avec ce SDK et installés via le téléversement Settings → Packs de la plateforme. Il n'y a pas d'éditeur in-app. Une fois un pack installé, les administrateurs d'espace de travail ajoutent le modèle à un environnement depuis la Marketplace, le rendant instanciable dans les Process Flows.

Les bundles de process flow sont des données pures. Le bundle est du JSON — aucun code exécutable ne figure jamais dans l'archive. La logique personnalisée est référencée par ID contre des workflows système ou organisationnels.

Scrydon Pack Bundles. Les process flows sont distribués sous forme d'archives .scrydon-pack.tar.gz qui regroupent le flow avec son ontologie (et, dans les prochaines versions, les seeds KB et les block packs). Le pack s'importe atomiquement — installation de l'ontologie, rebind slug → class ID tenant, matérialisation du process flow, le tout en une seule transaction. Construisez avec bunx @scrydon/sdk-authoring pack build ; inspectez avec bunx @scrydon/sdk-authoring pack inspect. Voir la spec et packages/sdk-authoring/src/packs/examples/ai-boardroom/ pour un exemple fonctionnel.

Installation

bun add -d @scrydon/sdk-authoring zod
npm install --save-dev @scrydon/sdk-authoring zod
import {
  defineProcessFlow,
  defineStage,
  defineTask,
  defineAction,
  definePersona,
  defineVoiceTrigger,
} from '@scrydon/sdk-authoring/process-flows'

Anatomie d'un modèle

ÉlémentRôle
PackageIdentité du bundle : id, name, version
TemplateLe flow lui-même — vue par défaut, configuration d'exécution, métadonnées
PersonaRôles auxquels une tâche peut être assignée (one, many ou system)
StageUne phase ordonnée. Les transitions sont manual, automatic ou approval
Task TemplateÉléments de travail à l'intérieur des étapes. Portent des actions, des dépendances, des attributs par défaut
Action TemplateCe que la tâche demande à l'utilisateur de faire — checklist, document, approval, workflow, entity_link, file_upload, distribution, voice_trigger
Voice TriggerBloc d'enrichissement vocal optionnel délimité à un chemin

Un exemple complet

import {
  defineProcessFlow,
  defineStage,
  defineTask,
  defineAction,
  definePersona,
} from '@scrydon/sdk-authoring/process-flows'

export default defineProcessFlow({
  manifestVersion: 1,
  package: {
    id: 'acme.kickoff',
    name: 'Acme Customer Kickoff',
    version: '1.0.0',
  },
  template: {
    slug: 'acme-kickoff',
    name: 'Customer Kickoff',
    description: 'Standard onboarding flow for new enterprise customers',
    version: '1.0.0',
    defaultView: 'tracker',
    executionConfig: {
      stageFlow: 'sequential',
      taskFlow: 'parallel',
      allowRuntimeTaskCreation: true,
    },
    metadata: {
      icon: 'rocket',
      color: '#2563eb',
      tags: ['onboarding', 'sales'],
    },
    personas: [
      definePersona({ slug: 'csm', displayName: 'Customer Success Manager', cardinality: 'one' }),
      definePersona({ slug: 'champion', displayName: 'Customer Champion', cardinality: 'one' }),
      definePersona({ slug: 'system', displayName: 'System', cardinality: 'system' }),
    ],
    stages: [
      defineStage({
        slug: 'discovery',
        name: 'Discovery',
        transitionMode: 'manual',
        estimatedDuration: { value: 5, unit: 'days' },
      }),
      defineStage({
        slug: 'rollout',
        name: 'Rollout',
        transitionMode: 'approval',
      }),
    ],
    taskTemplates: [
      defineTask({
        slug: 'collect-stakeholders',
        stageSlug: 'discovery',
        name: 'Collect stakeholders',
        defaultAssignedRoleSlug: 'csm',
        actions: [
          defineAction({
            name: 'Stakeholder list',
            actionType: 'document',
            isRequired: true,
            metadata: { persona: 'csm' },
          }),
        ],
      }),
      defineTask({
        slug: 'kickoff-call',
        stageSlug: 'discovery',
        name: 'Kickoff call',
        dependsOnTaskSlugs: ['collect-stakeholders'],
        actions: [
          defineAction({
            name: 'Record kickoff call',
            actionType: 'voice_trigger',
            isRequired: true,
            metadata: { triggerPath: '/kickoff/' },
          }),
          defineAction({
            name: 'Capture summary to KB',
            actionType: 'workflow',
            isRequired: false,
            workflowId: 'system.summarize-meeting',
            metadata: { promoteToCorpus: 'summary' },
          }),
        ],
      }),
      defineTask({
        slug: 'rollout-plan',
        stageSlug: 'rollout',
        name: 'Approve rollout plan',
        dependsOnTaskSlugs: ['kickoff-call'],
        actions: [
          defineAction({
            name: 'Approve plan',
            actionType: 'approval',
            isRequired: true,
            metadata: { persona: 'champion' },
          }),
        ],
      }),
    ],
    voiceTriggers: [],
  },
})

Types d'actions

Type d'actionUtiliser pour
checklistUne tâche simple que l'utilisateur marque comme terminée
documentUn document que l'utilisateur doit produire ou joindre
approvalUne porte d'approbation — assignée à un persona, bloque les tâches en aval jusqu'à l'accord
workflowRéférencer un workflow exécutable — soit par workflowId (un workflow système ou org déjà existant dans le tenant) soit par workflowSlug (un workflow distribué dans le même Pack — voir Workflows). Les deux sont mutuellement exclusifs
entity_linkLier la tâche à une instance d'objet typé via l'ontologie
file_uploadUn dépôt de fichier — les octets sont ingérés dans la KB de l'instance
distributionEnvoyer vers un canal (email, slack, teams) ; supporte le quorum, fire-and-forget, all-acknowledged
voice_triggerCapturer de l'audio contre un chemin — le STT s'exécute et la transcription alimente la KB

Voir Types d'actions pour une analyse approfondie par type avec des exemples prêts à copier-coller, des notes sur l'UX à l'exécution, et les champs de métadonnées que chaque type lit.

Lier un process à un domaine org-KB (knowledge.promotionTarget)

Un process flow peut déclarer que sa base de connaissances d'espace de travail doit alimenter un domaine spécifique de base de connaissances organisationnelle. Ajoutez knowledge.promotionTarget au manifeste du modèle :

import { defineProcessFlow } from "@scrydon/sdk-authoring/process-flows";

export default defineProcessFlow({
  manifestVersion: 1,
  package: { id: "acme.project-review", name: "Project Review", version: "1.0.0" },
  template: {
    slug: "project-review",
    // ...stages, taskTemplates, personas...

    // Declare the org-KB domain this process instance's KB feeds into.
    knowledge: {
      promotionTarget: {
        partitionSlug: "learnings",       // The governed org-KB domain slug.
        objectTypeSlug: "ProjectLearning", // The Learning object type in the ontology.
      },
    },
  },
})

Quand agentic crée une instance de process, la base de connaissances d'espace de travail créée automatiquement naît liée au domaine déclaré. Aucune configuration in-app n'est nécessaire.

Si knowledge.promotionTarget est omis, la KB de l'espace de travail est créée sans lien et ne se promeut jamais automatiquement.

Déclencher la condensation des apprentissages à l'approbation

Pour finaliser automatiquement la KB de l'espace de travail quand une étape se termine, ajoutez promoteToOrgKb: true à une action approval finale :

defineAction({
  name: "Sign off on project review",
  actionType: "approval",
  isRequired: true,
  metadata: {
    persona: "knowledge-lead",
    promoteToOrgKb: true,  // Triggers the learnings condense on approval completion.
  },
})

À la complétion de l'étape contenant cette tâche, la plateforme condense automatiquement la KB de l'espace de travail lié en enregistrements d'apprentissage typés et les met en file d'attente dans le domaine org-KB déclaré. L'approbation EST la porte de finalisation — aucune action « promouvoir » séparée n'est nécessaire.

promoteToOrgKb est valide uniquement sur actionType: "approval". Le définir sur d'autres types d'action n'a aucun effet.

Un administrateur d'espace de travail peut également déclencher la condensation à tout moment en utilisant le bouton Promouvoir les apprentissages dans la vue KB de l'espace de travail, sans attendre qu'un process se finalise.

Voir Promotion de contenu pour le fonctionnement de la condensation, le client broker à deux niveaux, et la colonne système references.

Ancrer une étape IA dans des connaissances gouvernées (metadata.retrieval)

La direction inverse : une action workflow qui exécute un agent @system/* peut être ancrée dans (a) un ou plusieurs documents téléversés plus tôt dans le flow et (b) un domaine org-KB gouverné — de sorte que l'agent raisonne sur des entrées réelles et des connaissances organisationnelles antérieures plutôt que sur le nom de la tâche seul. Déclarez-le avec metadata.retrieval sur l'action :

defineAction({
  name: "AI Qualification Assessment",
  actionType: "workflow",
  isRequired: false,
  executionMode: "automatic",          // run when the stage is entered
  workflowId: "@system/agent-project-qualifier",
  metadata: {
    aiAgent: "project-qualifier",
    // Where the agent result lands, by target ACTION TYPE (see below):
    // an assessment on this workflow step itself, and an advisory banner
    // on the flow's human approval action.
    outputSurface: [
      {
        kind: "workflow",
        contentType: "project_qualification_assessment",
        pageTitle: "AI Qualification Assessment",
      },
      {
        kind: "approval",
        targetTaskSlug: "go-no-go-decision",
        advisorySource: "ai-qualification",
      },
    ],
    retrieval: {
      // The document(s) the agent must judge. `fromTask` is the slug of an
      // earlier task whose upload you want; `mode: "full"` requests the whole
      // document (loaded as completely as the KB exposes).
      inputs: [{ fromTask: "upload-source", mode: "full" }],
      // The governed domain to consult. `partition` is REQUIRED — an object
      // type can live in several domains, so retrieval never fans out across
      // partitions for a governance-sensitive read.
      orgKb: {
        partition: "learnings",
        objectType: "ProjectLearning",
        limit: 8,
        domainClassification: "internal",
      },
    },
  },
})
ChampSignification
retrieval.inputs[]{ fromTask, mode }. Charge le(s) document(s) téléversé(s) à fromTask (un slug de tâche). mode: "full" (par défaut) demande le document entier — aujourd'hui le runtime injecte la copie la plus complète exposée par la KB (extraits riches) ; "summary" une forme condensée.
retrieval.orgKb{ partition, objectType, limit, domainClassification }. Consulte un domaine gouverné. partition et objectType sont requis ; limit est par défaut 8 ; domainClassification est par défaut internal et n'est utilisé que pour le high-water-mark des pages de référence générées quand des lignes gouvernées ont informé le résultat.
outputSurfaceOptionnel. Une sélection ou un tableau. Le kind de chaque sélection est le type d'action cible sur lequel le résultat atterrit, plus la configuration par surface. kind: "workflow" écrit une évaluation en référence seule sur l'étape agent elle-même (contentType, pageTitle) ; kind: "approval" fusionne un conseil d'une ligne sur l'action d'approbation de la tâche nommée par targetTaskSlug (advisorySource étiquette sa provenance). Les autres types d'action sont réservés pour les futures surfaces.

La récupération gouvernée respecte le niveau d'habilitation — et la page ne le dilue jamais. La lecture org-KB s'exécute au niveau d'habilitation et aux marquages de l'utilisateur assigné à l'étape (le détenteur de son defaultAssignedRoleSlug), appliqués côté serveur — l'agent ne voit que les lignes que cet utilisateur peut lire, et un domaine vide/interdit ne produit aucune ligne. Toute surface que l'agent écrit dans l'espace de travail cite les connaissances antérieures par titre uniquement ; il ne copie jamais les valeurs de champs gouvernés dans un espace de travail qui ne peut pas appliquer les marquages de la source.

Aujourd'hui workflow (évaluation sur l'étape) et approval (conseil sur une action d'approbation cible) sont les surfaces de sortie implémentées. La spécification retrieval elle-même est générique et fonctionne pour toute étape d'agent @system/* nécessitant un ancrage.

Validation du DAG de tâches

Les tâches peuvent déclarer :

  • dependsOnTaskSlugs — d'autres tâches qui doivent d'abord se terminer
  • unlockAfterTaskSlug + unlockDelay — une porte douce qui s'ouvre N jours/semaines après la fin d'un prédécesseur

Le CLI inspect exécute la détection de cycle DFS (BLANC/GRIS/NOIR) et échoue fermement sur tout cycle. Codes d'erreur stables :

CodeSignification
task_cycleUne arête de dépendance participe à un cycle
unknown_dep_slugdependsOnTaskSlugs référence un slug de tâche inconnu
stage_unknowntaskTemplates[].stageSlug ne correspond à aucune étape

Construire, inspecter, téléverser

bunx @scrydon/sdk-authoring pack validate src/pack.ts
bunx @scrydon/sdk-authoring pack build src/pack.ts --outDir dist
# → dist/<package.id>-<package.version>.scrydon-pack.tar.gz
bunx @scrydon/sdk-authoring pack inspect dist/acme-kickoff-1.0.0.scrydon-pack.tar.gz

Connectez-vous en tant qu'administrateur de l'organisation et ouvrez Settings → Packs dans l'application plateforme. Cliquez sur Téléverser un pack et déposez votre .scrydon-pack.tar.gz. Quand le pack contient un workflow, la boîte de dialogue vous demandera de choisir un environnement d'espace de travail — les définitions de workflow s'installent dans cet environnement. Le contenu ontologie et process-flow s'installe au niveau organisation quel que soit le sélecteur.

Le flux de téléversement de la plateforme est le point d'entrée canonique pour tous les types de contenu de pack depuis l'ADR 2026-05-21 Unified pack upload surface.

Après l'installation du pack, un administrateur d'espace de travail ouvre Marketplace dans la barre latérale agentic et clique sur Ajouter sur la carte Process Flow pour le rendre disponible dans cet environnement. Une fois ajouté, tout membre de l'espace de travail peut démarrer un nouveau Process Flow à partir de celui-ci. Voir Marketplace.

Pour l'automatisation, la route agentic sous-jacente accepte toujours les téléversements. Passez workspaceEnvironmentId uniquement si le pack contient du contenu workflow ; sinon c'est optionnel.

curl -X POST "$AGENTIC_URL/api/packs/import?organizationId=$ORG_ID&workspaceEnvironmentId=$ENV_ID" \
  -H "Cookie: $SESSION_COOKIE" \
  -F "file=@dist/acme-kickoff-1.0.0.scrydon-pack.tar.gz"

Structure du bundle

<bundle>.scrydon-pack.tar.gz
├── pack.json                          # top-level pack manifest (PackBundleManifestSchema)
├── ontology/
│   └── manifest.json                  # OntologyManifestSchema — may be empty for flow-only packs
├── workflow-<slug>/                   # optional — zero or more workflow subdirs
│   └── manifest.json                  # WorkflowManifestSchema
└── process-flow/
    ├── manifest.json                  # ProcessFlowManifestSchema
    ├── assets/                        # optional — JSON / image assets referenced by the flow
    │   ├── icon.svg
    │   └── preview.png
    └── meta/                          # optional — non-functional metadata (e.g. sbom.cdx.json)

Chaque sous-répertoire fait l'aller-retour comme un artefact autonome valide. Extensions d'assets autorisées : .json, .svg, .png, .jpg, .jpeg, .gif, .md. Les liens symboliques, liens durs, chemins absolus et traversées de chemin (..) sont rejetés par l'inspecteur.

Quand un pack contient des workflows, l'importateur les exécute dans leur propre phase avant l'installation du process-flow — de cette façon, chaque workflowSlug sur un modèle d'action se résout en un workflowId matérialisé avant que le process flow atterrisse dans la base de données. Voir Workflows pour le contrat de rebind de slug.

Limites de sécurité

L'inspecteur runtime lit l'archive en mode streaming (analyseur tar.list uniquement — n'extrait jamais sur disque) et applique des limites strictes :

LimiteSeuilCode d'échec
Archive compressée5 Moarchive_too_large
Total non compressé10 Mototal_size_exceeded
Taille par fichier5 Mofile_too_large
Nombre de fichiers200too_many_files
Lien symbolique / lien durn/asymlink_rejected
Chemin absolun/aabsolute_path_rejected
Traversée de cheminn/apath_traversal_rejected
Répertoire de niveau supérieur non autorisén/adisallowed_path
Extension non autoriséen/adisallowed_extension

La route /import retourne 413 pour les violations de taille et 400 pour les violations de structure ou de graphe.

Pourquoi pas de code exécutable

Les process flows sont déclaratifs. La logique personnalisée est référencée — par workflowId (un workflow déjà présent dans le tenant) ou par workflowSlug (un workflow distribué avec le modèle dans le même Pack) — pas bundlée. Même quand un Pack distribue des workflows dans des sous-répertoires workflow-<slug>/, la représentation sur disque est du JSON pur ; le catalogue de blocs runtime réside dans la plateforme. Cela rend la surface déterministe, reproductible et téléversable par des auteurs non-ingénieurs.

Où aller ensuite

Sur cette page

Sur cette page