Extensions
Un seul nom, un seul SDK, un seul cycle de vie — créez des boîtes à outils, des modèles, des ontologies, des workflows, des process flows, des sources de données, des notebooks et des serveurs MCP, et livrez-les comme une seule extension.
Une extension fournit des boîtes à outils, des modèles, une ontologie, des
process flows, des workflows, des sources de données, des notebooks et des
serveurs MCP. Vous l'écrivez avec un seul defineExtension, vous la construisez
avec une seule commande, vous l'installez pour toute l'organisation, puis vous
l'activez par espace de travail.
Il n'y a qu'un seul nom pour tout cela, et ce qu'une extension apporte est ce qu'elle fournit.
defineExtension, defineToolkit, defineModels, les outils, les
déclencheurs, les blocs et tous les types de contenu qu'une extension peut
porter.
Le versionnage, et la livraison des releases depuis une source Git ou OCI.
L'installation, la connexion des comptes, le changement de version et l'activation par espace de travail.
Les extensions que Scrydon publie et révise.
Ce qu'une extension fournit
Une extension déclare un bloc provides, et chaque emplacement est facultatif.
Livrez une boîte à outils seule, une ontologie seule, ou tout à la fois.
| Emplacement | Ce qu'il apporte | Guide |
|---|---|---|
toolkits | les outils qu'un agent peut appeler, les déclencheurs qui lancent un workflow et le bloc de workflow sur le canevas — partageant un identifiant et un même jeu de portées | Création |
models | les modèles que vous fournissez pour une famille : llm, embedding, stt, tts, image, video, ocr, moderation | Familles de modèles |
ontology | types d'objets, types de liens, types d'actions, règles d'identité et liaisons | Ontologies |
processFlows | étapes, modèles de tâches, personas, modèles d'actions, déclencheurs vocaux | Process flows |
workflows | graphes de blocs exécutables — portes d'approbation, routages, automatisations | Workflows |
dataSources | sources de collecte déclaratives : requête REST, DSL de mappage borné, colonnes typées | Sources de données |
notebooks | notebooks d'analyse | Notebooks |
mcpServers | serveurs MCP enregistrés pour l'organisation | Serveurs MCP |
Les boîtes à outils et les modèles sont compilés et s'exécutent en bac à sable. Tout le reste est du JSON pur et n'exécute jamais de code fourni par l'appelant.
Les extensions s'écrivent en code — il n'y a pas d'éditeur intégré. Si vous préférez ne pas écrire ce code vous-même, voyez Créer une extension avec un agent de codage IA : décrivez en langage naturel ce que vous voulez et laissez un outil comme Claude Code, Cursor ou GitHub Copilot l'écrire, la valider et la construire.
Installer le SDK
bun add -d @scrydon/sdk-authoring zodnpm install --save-dev @scrydon/sdk-authoring zodVérifiez la résolution :
bunx @scrydon/sdk-authoring --versionLe cycle
Composez l'extension avec les aides define*(). Ce sont des fonctions
identité à l'exécution : leur rôle est de restreindre les types pour que
votre éditeur détecte une erreur avant la construction.
Un schéma Zod valide le manifeste à la construction, et la plateforme le
valide de nouveau à l'installation. extension validate pointé sur un
répertoire CONSTRUIT exécute localement toute la porte de synchronisation.
Une commande produit un seul conteneur : extension.json plus un
sous-répertoire par membre déclaré — code/ pour les boîtes à outils, les
familles de modèles et la déclaration de connexion (auth, configFields),
et ontology/, process-flow/, workflow-<slug>/, data-source-<id>/,
notebook-<slug>/, mcp-server-<id>/ pour le contenu.
Via une source d'extensions sur Paramètres → Plateforme → Extensions → Sources, ou un envoi ponctuel depuis la même page. La plateforme valide le manifeste, stocke l'artefact et enregistre la release dans le catalogue de l'organisation. Aucun redéploiement.
CLI
bunx @scrydon/sdk-authoring extension --help
bunx @scrydon/sdk-authoring extension init [name] [--outDir dir]
bunx @scrydon/sdk-authoring extension build [--entry extension.ts] [--outDir dist]
bunx @scrydon/sdk-authoring extension validate [path] [--manifest-only]
bunx @scrydon/sdk-authoring extension inspect <path>
bunx @scrydon/sdk-authoring extension test [--level static|sandbox|live]
# Whole-repository builds, for a Git source:
bunx @scrydon/sdk-authoring extension build-dist <srcDir> --outDir <destDir>
bunx @scrydon/sdk-authoring extension build-source [rootDir] [--check-catalog]build-source --check-catalog échoue tant que scrydon.yaml et dist/ ne
concordent pas, et nomme chaque extension en cause : missing_entry
(construite, mais aucune entrée du catalogue ne la désigne, elle ne peut donc
jamais être installée), missing_artifact (une entrée désigne un chemin jamais
construit), version_mismatch (l'entrée et le extension.json construit
divergent) et stale_artifact (un dist/<nom> dont le src/<nom> n'existe
plus). Les entrées oci et les entrées git-tar hors de dist/ sont listées
comme non vérifiées. --waive ne couvre jamais ces constats.
build accepte un répertoire et découvre automatiquement extension.ts, puis
déduit un répertoire source pour chaque membre provides déclaré à
<baseDir>/<member.path>. Une extension qui mélange les types se construit sans
aucun indicateur par type.
L'archive
| Quoi | Archive | Du code ? | Validée par |
|---|---|---|---|
| Une extension | <extension.id>-<extension.version>.scrydon-extension.tar.gz | code/ lorsqu'elle fournit des boîtes à outils ou des modèles, ou déclare une connexion (un champ de configuration, ou un credential autre que none) : ESM compilé, un manifeste et un SBOM CycloneDX | ExtensionManifestSchema, les schémas de manifeste par type, l'inspecteur CycloneDX, la garde des dépendances natives et le validateur de cycles du DAG |
Livrez votre première extension
Types d'objets, types de liens, types d'actions et règles d'identité. → Ontologies
Portes d'approbation, routages et automatisations que votre process flow invoque par slug. → Workflows
Étapes, modèles de tâches, personas, modèles d'actions, déclencheurs vocaux. → Process flows
Sources de collecte déclaratives : requête REST, DSL de mappage, colonnes typées. → Sources de données
bunx @scrydon/sdk-authoring extension build ./my-extensionParamètres → Plateforme → Extensions → Sources → Envoyer une extension, ou l'API d'administration. Une installation atomique pour tout ce que l'extension fournit.
Et ensuite
defineExtension, boîtes à outils, modèles, outils, déclencheurs, blocs, et
la boucle construction / installation.
Fournissez des modèles llm, embedding, stt, tts, image, video,
ocr ou moderation.
Publiez des releases depuis une source Git ou OCI et laissez l'organisation récupérer les mises à jour.
Installez pour toute l'organisation, puis choisissez les espaces de travail.